Software Failure/Guru "8000 0020" on program exit
 

I'm getting this error on program exit and I am not completely sure what it is or how it happened.

I am taking a wild guess here that it has something to do with me not doing what I supposedly should do on exit: "cleaning" the memory. If I hit "suspend" on the error, the memory I used is visibly gone from the system.

I have loaded one bank of info into memory, and after I started doing that, this error began to occur, hence my suspicion.

I tried to do FreeBank #BANK before "End", it says it cannot free memory.
I tried to do FreeMem Bank(#BANK), BankSize(#BANK), also fail.

Is this error related to this and if so, how exactly am I supposed to cleanly exit the program?
Is there even any functions in Blitz to see how much RAM I have free?
While we're talking this stuff, can you see the size of a file before you load it?

Is the program actually exiting? Or crashing just prior to exiting? Try using NPrints before and after any commands at the end of the program to see what might be snagging it. If it's just the End statement, it's possible that something's buggy with the Bank library, but I've used Bank before and left it to be freed by the End statement with no issues.

There are some commands for checking free RAM in some 3rd party libraries - ChipFree, FastFree and LargestFree will return the size of the largest free block in the relevant categories, and that's a library that's included with most Blitz setups (RISystemLib). But it's also possible to check whether a bank has been successfully allocated or not before using it - if there's not enough RAM, it will have the address set to 0 so using the Bank() function to check it before you will tell you if it's been allocated successfully or not.

You can get the filesize using the LOF function (Length of File) after you've opened a file with ReadFile. There are 3rd party libraries that also contain file size commands, but IIRC they're used to examine a file as part of a directory listing so you'd need to traverse the directory to get the filesize that way. It's doable, but opening the file, getting the size and closing it is probably the most straightforward method without using the dos.library Examine calls directly.

I have my program in a While loop waiting for mouse button input. So as soon as I press the button, that loop exits and goes straight to End, there's nothing else. So yeah I believe it does it on crash. And it wasn't doing it until I started to use the Bank mechanism. But it could be something else. At this point, who knows? I cannot even debug it, because it crashes blitz if I run this from SuperTED

How do I even know what libraries I do have? This is really a mess. Do I have to include anything, like I had to do the bb2 objects RES file?
I have that UBB2.1 Plus pack from http://ubb.plus , if that helps

That's a good workaround for the time being, but I'm actually trying to determine if I have enough RAM to load it in before it gets loaded, future proofing.

But I am using "LoadBank" to load the file... should I be using something else?

I expect to eventually need to add directory browsing and file loading from there, so I'd need to look into t his. But refer to point above: I have no fucking idea how to know what libraries I already have, or where to get more even.

Thanks for your help, as usual, Daedalus!

So the debugger doesn't catch anything? Hmmm, that makes things tricky alright. Does it crash Blitz at the same point, or before?


Yeah, you most likely do have those libraries - they were on the extras disk of the floppy version, and are included with pretty much every version that isn't the bare Kickstart 1.3 floppy-based version. But the easy way to tell is to type in the command and see if it gets highlighted by SuperTED.

Fair enough - it's harmless to try and allocate more RAM than is available, so long as you check to make sure it was successful. Outside Blitz, RAM allocation is done this way too - try and allocate and check the returned address to see if it was successful. But checking first makes sense too.

That's no problem - you can open the file using ReadFile, check the length of it, close it, and then use LoadBank to load it in. Opening it in itself doesn't take up much RAM because you're not actually loading anything but the file header, and closing it again frees that up.

:) Yeah, it's a little easier in AmiBlitz, but the simplest way in Blitz2 is to type in a command and see if it's recognised. To look through what's available in the 3rd party libraries, the documentation isn't included in the main manual so you have to hunt for it. But I would strongly recommend downloading the guides from the AmiBlitz Docs directory - most of the libraries are taken directly from the Ultimate Blitz CD, and while some of the files aren't relevant to Blitz 2.1, if you start with the BlitzLibs.guide file, that will link to both the standard and the 3rd party libs from a convenient location so you can browse them relatively easily. Some of the libraries will have been updated, but the functionality will be the same in 99.9% of cases so the documentation will work well for you (the Null() function is the only one that's significantly changed that I can think of).

You probably don't really need to worry about adding libraries - the Ultimate Blitz setup should already include all the standard ones. Adding custom libraries is fiddly and can result in your source being unreadable by another installation of Blitz so it's best not to do that unless you need to. It was different back in the day when you started off with the core libs and added as new ones were released...

Yeah the crash happens at the exact same point running from Blitz or on its own.
this is weird though, now, it is not giving me the error when I run it from Blitz, the Debugger just seems to "end" but the CLI window remains open and it never returns to SuperTED, no error, machine locked there :confused:confused

It definitely has to do with the file loaded, because if I skip the file loading, I get no errors.
Also is there a way for the debugger not to autoquit?

Good call, great tip, will do so!

Ohh I see, I thought trying to allocate more RAM than was available would overwrite areas of RAM already in use, so I didn't. Kind of C64 habits where the assembler would do something like that if I told it to, without checking :P

I'm gonna try to see if I have those libraries because I'd like to display how much free RAM I have. But I am still clueless as to why I am getting the 8000 0020 error. Is there really nothing I should do before end to exit cleanly?

I get EXACTLY the same issue after creating an exe in AmiBlitz 3 - runs fine through Blitz but as soon as I hit an end command to end the software while running independantly - instant Guru

Do you ever get stack related issues in blitz?

Hi!

I don't know Blitz Basic but you could try using StackAttack or StackWatch or similar programs to see if the stack is really involved in these problems?

Good luck! :)