How to avoid corrupt atari basic save file - memory safekeeping

[bugbiter]

I just saved a Turbo basic file after the memory at the end of the program was partly modified. The Program still listed alright, but after loading the saved program the loading process ends with two 'ready' messages and there seems to be no program in memory.

 

I know since early Atari days that these things can happen, of course I should have made a backup every once in a while, or better use List"d:". A day's work is lost and I will have to do it again.

 

I wonder if there is a chance to put the file right again, after all the data in the basic save file is still there and maybe there are only some wrong pointers in the file that can be reconstructed?

 

My program uses APPMHI, dpeek(14) after all the DIM statements to determine the lowest ram I can use and then still keeps 100 bytes distance for safety. But to be honest I have no clue how APPMHI can change during the program run and there must be also something like a basic return stack that can vary depending of the loop nesting depth, so how can I be safe not to destroy my basic code with my own data in memory?

[Rybags]

Yep, Runtime Stack sits at the top of Ram used by Basic and will grow/shrink with loop/subroutine entries.

Sometimes when reserving memory it's just a whole bunch easier to move the RAMTOP (dec 106) pointer downwards, reopen the screen and use the memory above it.

Though problems there, older OS versions can write beyond end of screen when doing a clear opertion and any OS needs that pointer to be on a 4K boundary if you want to use any graphics mode that needs >4K - ie Gr. 8 or 15.

 

The LIST then ENTER <filename> trick is handy to keep programs free of bloat ie it overcomes the 16 bytes growth of Basic Rev B and ensures unused variable names are freed up.

But if you have a SAVEd program that has corruption such that reloading gives you nothing, then that makes things somewhat harder.

I don't know if there's any utilities around that can help.

About all I could think of is to use a hex editor to change the pointers within the program data such that the last line of the program is omitted. And keep doing that until the corruption goes away.

To do that you need to know some Basic internals - books like Inside Atari Basic have the info needed there.

 

As for stopping it happening again - when reserving memory using that method, it's probably best to get your screen mode set, all arrays dimensioned before allocating memory.

Also it's safer but not necessarily more convenient to reserve memory by using strings and ADR to find where they are.

Strings will stay where they are so long as you don't change the program mid-run.

[fujidude]

Makes me think that all BASIC programs should be stored as LISTed rather than SAVEd. Sure, I know the tokenized (SAVEd) versions are a little more compact on the disk or tape, but perhaps it's worth it?

[bugbiter]

Thanks for those hints!

A LISTed program is so much easier to restore if a file should get partly corrupted. Normally I always list to a temp file occasionally during coding, but as you know, Mr. Murphy ensures that I didn't whenever something strange happens.

[kenjennings]

List/Enter also cleans up the variable table which frees up some space ( if you've been hacking around in the program... or if the last programmer was hacking around on it.)

[Kyle22]

You can attempt to de-tokenize it. The only program I have is for BASIC-XE, but it will work with Atari BASIC, BXL, and Turbo, but the extended command set (in Turbo), such as DPOKE, BGET, and any other keywords not in Atari BASIC may come out wrong. It's worth a try.

 

This is a BASIC-XL program. The disk contains the BXL runtime, so just boot it, or load AUTORUN.SYS. It works in SDX if you X AUTORUN.SYS.

 

Good luck.

 

Basic XE Detokenizer v1.11 (1989-06-04)(Psycho).zip