OS-Reset routine

[Creature XL]

To make MJO restart when you hit RESET, I put the address of the re-init routine in DOSVEC (10/11).

This worked to some extend, however, it seems as some of the RAM is zero'd by the OS although WARMST does not equal "0".

It's ofcourse possible that the mistake is somewhere in my code, however, I wanted to rule the possibility out that it is caused by the OS. So the simple question is:

 

How to I make my programm Reset-resistent without any portion of the main RAM gets cleared by the OS?

 

It's not much of a problem, because you can reload the game and further there should be no reason to restart, but it would make it a bit more "round".

 

thanks for any hints (I might try to debug this more with Altirra later)

[Rybags]

The OS manual tells what gets wiped.

 

Anything z-page from around $10 - $7F will be wiped. So best to only use that for temporary stuff.

 

Page 2 gets wiped, page 3 mostly wiped (all on 400/800 ? )

 

$400 - <base of display list> will be safe. Of course, DList base will depend on Basic/cart state and RAM size.

 

If you're using DOSVEC ($A) you should also clear the Boot flag (9) so the OS doesn't try and initialize DOS first... if someone loads your game from DOS and your game wipes out Dos, then that's a surefire way for a crash.

[Creature XL]

The OS manual tells what gets wiped.

 

Anything z-page from around $10 - $7F will be wiped. So best to only use that for temporary stuff.

 

Oh, I have to check this. Of course I have lots of pointers in that area.

 

If you're using DOSVEC ($A) you should also clear the Boot flag (9) so the OS doesn't try and initialize DOS first... if someone loads your game from DOS and your game wipes out Dos, then that's a surefire way for a crash.

That is not much of a problem. I initially tried to make it runnable from DOS (had a thread in this very forum) however, later in the game (pun intended) I realized that it is absolutely not possible. Even some file-loaders might not work. At load time everything is squeezed into RAM (besides the game with the 17kb map-data, there are 3+1 G2F pics (20+3*6kb). I think I spend a total of 3 days figuring out where to put everything. But with ld65 its so easy to move stuff around. Without it, I might have given up.

 

I basically use the RAM from $0400-$0700 and then from $0c00 to $fff0 while loading and after the loading the rest from $700 to $c00 is used as well

 

Just a reminder, the next four beating the (fixed) Abbuc-release version under 12 minutes can get the RC4

[Rybags]

I find it good to just leave low RAM alone for the benefit of loaders. Start the load as high as possible even if it means wiping the screen (you can always provide your own little screen anyway).

 

Some loaders sit around $480 - $9FF and even higher and often they use the cassette buffer $400.

 

If you can swing it so low RAM is used for work area then it works out well.

 

Since we have nice emulation now that can inject binaries into memory without a Dos, it's made developing stuff much easier.

 

But no matter what you do, most games that use over about 32K or so of the lower 48 will encounter problem with some loaders and Doses.

[Creature XL]

Some loaders sit around $480 - $9FF and even higher and often they use the cassette buffer $400.

[..]

Since we have nice emulation now that can inject binaries into memory without a Dos, it's made developing stuff much easier.

 

A list with the used area(s) for loaders might be interesting. I have sent S.Dorndorf an eMail (with an release candidate attached), because I use his Qmeg 4.04 and it has problems. I hope he responds. Basically, all I need is a ROM-image of Qmeg 4.04 to debug with Altirra. On the real HW I can load it successfully with MyPicoDOS.

[+Stephen]

Some loaders sit around $480 - $9FF and even higher and often they use the cassette buffer $400.

[..]

Since we have nice emulation now that can inject binaries into memory without a Dos, it's made developing stuff much easier.

 

A list with the used area(s) for loaders might be interesting. I have sent S.Dorndorf an eMail (with an release candidate attached), because I use his Qmeg 4.04 and it has problems. I hope he responds. Basically, all I need is a ROM-image of Qmeg 4.04 to debug with Altirra. On the real HW I can load it successfully with MyPicoDOS.

PM Sent

[+CharlieChaplin]

To make MJO restart when you hit RESET, I put the address of the re-init routine in DOSVEC (10/11).

This worked to some extend, however, it seems as some of the RAM is zero'd by the OS although WARMST does not equal "0".

It's ofcourse possible that the mistake is somewhere in my code, however, I wanted to rule the possibility out that it is caused by the OS. So the simple question is:

 

How to I make my programm Reset-resistent without any portion of the main RAM gets cleared by the OS?

 

It's not much of a problem, because you can reload the game and further there should be no reason to restart, but it would make it a bit more "round".

 

thanks for any hints (I might try to debug this more with Altirra later)

 

 

But err,

 

if you make the game completely reset-proof, then please add a key or key-combination to leave the game (do a coldstart). Its easy to leave reset-proof games on the emulator, but its not nice having to power-off your real A8, every time you want to leave a reset-proof program. And err, the A8 machines are some 30 years old, the next power-off and power-on again might be the last one for your beloved Atari machine...

 

Besides, whats the reason to press Reset ?!? Here and there one can read that programs are reset-proof in case you accidently pressed reset - but no-one ever did press Reset accidently !

I never did in the last 30 years ! The only reason why someone does press Reset is, because he wants to leave the program. So, we need a possibility to leave the program, please. (Last not least, if your program were a commercial one and copy-protected, there are some nice A8 freezers that can especially freeze programs that are reset-proof; the Abbuc program "the Reset-machine" is one of them...)

 

But, if all else fails, I will call my usual hackers Fandal & Homesoft, to remove this reset-resistance for me... In other words: I HATE A8 programs that are completely reset-proof (with very few exceptions)...

 

-Andreas Koch.

COLDSTA.XEX

Edited January 4, 2012 by CharlieChaplin

[Shawn Jefferson]

Why not just make reset do a cold start? Much easier and probably more useful.

[Rybags]

These days it's usually the best option. And if the game requires lots of RAM, it's even possible to allow a return to Dos, although that's probably more trouble than it's worth.

 

If a game can easily quit to the title screen then there's no reason really not to just have Reset do a coldstart.

 

As for a list of z-page locations used by loaders - kinda hard. There's so many loaders out there in use. If people are using devices like SIO2SD or SIO2PC, then all the old loaders that only work with simple ED Dos disks are still valid.

 

In any case, there's no reason for a game to hog z-page locations whilst loading. A simple save/restore mechanism only costs a few extra bytes and helps keep the compatability.

[Mclaneinc]

I'd never given much thought to the frailty of the poor old real hardware until I read what Charlie Chap said, in the day finding the old reset vector was dead handy for a bad coder like me and I loved to set whatever hacks I did with it just for the constant running choice but yes, you now have to think of the poor old switches and dodgy old components not liking the old surge and mechanical oomph of a power up.

 

Ye, reset proof but with a key combo to save the switch..

[Rybags]

These days lots of people have active Ramdisks, so coldstart ability means they have a chance of being preserved too.

[+CharlieChaplin]

Why not just make reset do a cold start? Much easier and probably more useful.

 

Well,

 

guess what kind of XEX I posted above ?!? One can append it to any program and (most of the time, alas NOT always) when you hit Reset, the program will do a coldstart. It is the same as Poke 580,1 in Basic afaik. And it is one of the short tools I almost always add to COM/XEX files (as well as a Basic off switch, coded by Bill Wilkinson and released thru Compute!)...

 

Don`t worry that the (Atari) Basic-off switch uses page 4, after it has executed and switched off Basic, page 4 is fully available again (already tested with hundreds of programs that also make use of page 4)...

 

-Andreas Koch.

 

P.S.: It does not matter where in a file you add the Coldstart routine (at the start, in the middle, at the end), however for the Basic-off switch to take effect, it should be the first data segment. So simply make a copy of it and give that another name, then append your program to it...

BASOFF.XEX

Edited January 5, 2012 by CharlieChaplin

[Rybags]

Page 4 is used as a buffer by some loaders.

 

If you don't mind hitting PortB direct, you can do it all needed in extra binary segments.

 

01 D3 01 D3 FF - set PortB to $FF (Basic off, OS on)

 

F8 03 F8 03 FF - set OS flag for Basic off (affects Basic behaviour on reset)

 

44 02 44 02 FF - set coldstart flag (machine will reboot if user hits reset)

[+CharlieChaplin]

Yes,

 

I know that there are loaders that use page 4 as a buffer, so the Basic off switch will not work there (luckily HiasSoft did code me several Basic off switches that could use either page 1 or page 4 or page 5 or page 6). And there are (as mentioned above) some programs that are completely reset-proof, so that even the coldstart-routine posted above will not work. Some more programs can be coldstarted by packing them (e.g. with Code3-Cruncher, it not only packs programs but also changes some code) and then adding the coldstart-routine, but again there are still programs that will not coldstart on Reset... since I am no programmer I cannot change anything there...

 

Maybe someone remembers the old A8 mega-demo collection page by Sven Gleich (1MB ATR images filled with lots of demos). At one point I changed all the ATR images and added this coldstart-routine (and the Basic-off switch) to all demo files. Approx. 80-90% of the demos then did a coldstart when pressing Reset. Sven was so kind to upload these newly created images to his homepage. Alas, (t)his homepage no longer exists... (but I have the mega-demo-images archived in my collection)...

 

-Andreas Koch.