Secure areas to load XEX-files

[Creature XL]

Personally, I load my XEX files from AspeQT with the QMeg4 OS. Which is kind of a "Game DOS" as was used back in the day. NConverter or something

However, I want to be kind to my fellow Atarians and am sure some of you use a hard disk or some such stuff, therefore I want to make the game loadable from DOS. "Loadable" means, it is loadable but destroys the DOS memory. But at least it is loadable

 

What i remember is that DOS 2.5 used the area from $0700-$1f00. however, MyDOS, used the RAM up to $2200 or more. Depending on the number of configured drive buffers. Right now I am using $2600 as a start point is it high enuff for most/ all configs?

[drac030]

I think $2000 is the standard "magic border", which no DOS should cross. Such a common program as Turbo BASIC XL loads at $2080, so...

Edited June 2, 2011 by drac030

[Creature XL]

I think $2000 is the standard "magic border", which no DOS should cross. Such a common program as Turbo BASIC XL loads at $2080, so...

Thanks.

That is easy to achieve. Maybe my memory was failing me with the MyDOS memory usage. Its a long time I used my 800XL with a DOS and my Speedy1050

 

However, Let's see if others have "bigger" DOSes

[+CharlieChaplin]

Well,

 

when programming on the emulator you should mostly stay away from these memory areas:

 

$D000-D7FF : the area for the custom chips, the computer will not work without it, so any program using "big" portions of this memory area will not work on a real Atari (its of course ok to use a few bytes or direct jumps into this area, e.g. to switch on stereo, etc.)...

 

$0700-09FF: when a program does not work under DOS, one mostly uses a Gamedos or Bootloader instead, but even a Gamedos or Bootloader requires some RAM, usually this is the smallest RAM area required by Gamedos versions or Bootloaders (like N-DOS Converter, Micro-DOS, Picodos, MyPicoDos, etc.); use this area and you can be sure that your program will not work with DOS nor Gamedos/Bootloader (most likely only on the emulator)...

 

There is for example a BAS2XEX converter (PC program) that converts Atari Basic programs into XEX files, but it always uses $0700-xxxx, RUN $0700 and therefore the created XEX file will not work on a real Atari unless patched or relocated; the tip-animator uses $0400-xxxx as a standard for 64k files, unless one types in another start-adress (alas, some users did not and therefore created tip-animations that do not work on real Ataris; even some XRAM tip-animations did use $0400 as start adress, thus they are for emulator use only)...

 

To create files for use under DOS is relatively simple, use $2000 as lowest start-adress (and/or RUN adress), especially if they are multi-load and/or require DOS routines. Alternatively use a relocator or a packer with relocator (like e.g. Super-Packer by Bewesoft) that loads at $2000 but puts the data in the DOS area after the program has loaded/initialized (Code3-Cruncher also does this, programs packed with it can be loaded from DOS, but one cannot return to DOS); of course this only works for programs that do not use multi-load and/or do not require any DOS routines (since DOS gets overwritten then)...

 

Just my thoughts... I am no programmer, only a "user"...

-Andreas Koch.

[+JAC!]

One more vote for $2000. If I remember correctly, DOS 2.5 with 4 drives is still below this. Of course mighty MyDos with many buffers can go beyond, but I always use $2000 and never had any problems reported.

[flashjazzcat]

$2000 here too.

[Fox-1 / mnx]

I always use a safe $2200 as the limit as $21xx is the max. I've ever seen in a DOS. (Turbo-Dos with full XF551/Happy/Speedy compatibility enabled).

[Rybags]

Using APE or SIO2SD or similar, it's not a big issue since you can boot XEX and the device provides the loader, so you can use any DOS memory.

 

The issue in reality applies mostly to real HDD users.

 

In that case, DOS 2.5 is probably a moot point, who'd want to use one of the "primitive" DOSes with a HDD ? The other thing with 2.5 is that you have to do Binary Load with DUP present which moves the MEMLO requirement upwards.

 

So you'd be stuck in the thorny situation of having to accomodate bigger DOSes that use more RAM. On top of that, some DOSes also use RAM under the OS so you can't touch that during loading either.

 

Whatever you choose, you won't keep everyone happy.

 

Best idea is to at least keep your code as high as possible. You can always move it downwards after the load has completed.

[phaeron]

I would not advise making executables with an "emulator only" layout even if you don't intend for them to run on real hardware, because it's likely that your XEX will be broken by emulator accuracy improvements. For instance, current versions of Altirra write some OS page zero and page two variables during the XEX load that are not strictly necessary to load the executable, but which are expected by certain programs that improperly assume OS state on run consistent with a disk load. It's possible that hardware registers may be included in this in the future.

 

Altirra will not load program code into the $D000-D7FF hardware region. It processes the segment load with CPU writes and any segments that go there will be written to hardware registers like on a real Atari. It's also not a good idea to attempt to load hardware registers with a segment in that range since much of POKEY and some of ANTIC will be hit by an SIO loader. You can, of course, do so from an INIT segment as long as you're not depending on the state carrying across the next segment load.

 

Some additional restrictions I would suggest:

• Don't load into zero page, at least the OS reserved region ($00-7F). I've seen people accidentally include these segments and then it breaks on all real loaders.
  
• Don't load on top of the stack or OS database ($100-3FF).
  
• Don't load into $8000-BFFF until you have shut off the display or set up a different display list. A couple of programs sporadically fail because they overwrite the OS display list and crash when ANTIC encounters a JVB instruction with the DLI flag set ($C1).
  

[Creature XL]

Just to underline the fact that I said in my post I would use the memory for data only.

just because i never released anything doesn't mean I never coded anything before

But I guess some answers are helpful for newbies. Therefore they are valid and welcome!

 

If $2200 (or even $2000) is a good limit I am a happy man. that is easily achievable.

Thanks for reminding me of upper limits, I haven't thought about them. They shouldn't matter for my game, though.

I need the whole 62k ($0000 - $ffff, excluding the obvious: (part of) stack, HW-register). As I am using my own mini-kernel I can use the whole ZP and all other buffers (below $600) AFTER LOADING! (just to point it out again .

 

Its a simple game, however, it features a big tile-map. Can't say more, as I am still waiting for assets.

 

PS: If I really finish that thing and know what memory I need exactly, I might consider making an 130XE version which does not destroy everything in the RAM

 

 

 

EDIT:

What happens when someone runs the program on an 16k or 48k machine? I guess 48k is the same as 64k without the switchable OS-ROMs? Sorry for me A8 is 800XL.

Edited June 3, 2011 by Creature XL

[Rybags]

DOSes and loaders don't check RAM size so the game will load to an extent and attempt to run.

 

Best idea is to have a preloader that runs early - have it switch off Basic and check that the RAM amount you need is present.

 

If not, display message such as "48K required - remove cartridge and restart".

[drac030]

Some additional restrictions I would suggest:

• Don't load into zero page, at least the OS reserved region ($00-7F). I've seen people accidentally include these segments and then it breaks on all real loaders.
• Don't load on top of the stack or OS database ($100-3FF).
• Don't load into $8000-BFFF until you have shut off the display or set up a different display list. A couple of programs sporadically fail because they overwrite the OS display list and crash when ANTIC encounters a JVB instruction with the DLI flag set ($C1)

Some more:

 

1) while loading don't keep interrupt handlers in $4000-$7FFF or $D800-$DFFF

 

2) even if you moved the ROM to RAM, don't load directly to $D800-$DFFF

 

It may also be a good idea to load a small init segment first in a safe location (such as $0600-$06FF), which would check the memory pointers (MEMLO, RAMTOP) and availability of RAM under the ROM, and abort loading if conditions are not met.

[Marius]

One confusing thing with menu based dos is that the menu (dup) is not the dos itself.

 

So when you see the mydos or dos 2.x menu and you investigate the memory, you might get the idea that the DOS uses quit a lot of memory. That conclusion is wrong. Since the menu is in memory.

 

Try this:

 

Create an empty disk or ATR.

Format with the desired dos.

Put only the dos.sys on it (delete the dup.sys afterwards)

Put an autorun.sys binary on it that is not more than a jmp $e480 (jumps into qmeg monitor program)

 

Now investigate memory and see where your memory is not used! You also could check memlo and memtop and all that.

[Rybags]

But... DOS 2.0, 2.5 etc have the binary loader contained mostly within the DUP, so if the program loads too low it will overwrite that.

[Marius]

@rybags

 

Good Point! I did not know that!

[Creature XL]

Rybags, how are Autorun.Std files loaned then? Aren't they loaded without DUP? Just asking, no arguing

[Rybags]

That's a point too... maybe I should have said "some of the b-loader" WRT DUP.

 

Would have to do a trace or something - I've typically found though that loading anything that overwrites too low into DUP just hangs the system.

 

I'm not sure if any sector/drive buffers get relocated when you load DUP, that's another possibility for overwrite if they do.

 

Another possibility is that there's some different code that does B-Load vs running Autorun.

[+JAC!]

> Autorun.sys / Aren't they loaded without DUP?

Yes. Only DOS.SYS is required to be present.

[flashjazzcat]

Mapping says:

 

You can run some machine language programs from within BASIC by typing OPEN #1,4,0,"D:filename" then X=USR(5576).

 

This works of course, and is below DUP, but presumably it doesn't work with ALL binary files. I assume DUP contains the code which actually opens the file and does some sense checking on it when you choose option "L".

Edited June 16, 2011 by flashjazzcat

[drac030]

Mapping says:

 

You can run some machine language programs from within BASIC by typing OPEN #1,4,0,"D:filename" then X=USR(5576).

 

That's illegal. The documentation should not contain such "advices".

[flashjazzcat]

That's illegal. The documentation should not contain such "advices".

Certainly - it's not an official entry point. However, I guess it was a suggested workaround for the lack of a CIO command for "Binary Load".

[Alphasys]

Mapping says:

 

You can run some machine language programs from within BASIC by typing OPEN #1,4,0,"D:filename" then X=USR(5576).

 

This works of course, and is below DUP, but presumably it doesn't work with ALL binary files. I assume DUP contains the code which actually opens the file and does some sense checking on it when you choose option "L".

 

Ofcourse it doesn't work with ALL binary files. Basic is active! So any binary file using $A000-BFFF won't work

 

By the way, does Mapping also tell what dos this works for? When I check the listing for DOS2.0S's FMS, it ends at $1501, while the call is made to $15C8, so it's not 2.0S that this works for, unless there's a resident part of the DUP that it calls...?

Edited August 11, 2011 by Alphasys

[flashjazzcat]

Of course it doesn't work with ALL binary files. Basic is active! So any binary file using $A000-BFFF won't work.

Of course.

 

By the way, does Mapping also tell what dos this works for? When I check the listing for DOS2.0S's FMS, it ends at $1501, while the call is made to $15C8, so it's not 2.0S that this works for, unless there's a resident part of the DUP that it calls...?

It appears to refer to DOS 2.0s, and I believe the call is to the non-resident portion. This makes sense, given that there's no XIO call for binary load in the resident handler, so presumably they placed the entire mechanism in DUP since that's the only place it's normally called from.

[Rybags]

More research would be needed... like has been said, AUTORUN doesn't need DUP.

 

But possibly there's shared and/or duplicated code/functionality. You can implement Binary Load very cheaply, much of the code path is just to perform the OPEN. Once you have the link to the start of the file, the remainder of the process can be done very cheaply.

 

If you're using a DOS with resident DUP or CP and want to get rid of Basic to load something else, you can just POKE 1016,1 and press RESET.

[StefanD]

$15C8 is a widely used call to load a binary file from the open IOCB #1 under ATARI DOS 2.x (2.0 and 2.5). A lot of BASIC programs use this call and some 6502 programs also - StarTexter for example. $15C8 is not part of the FMS (i.e. the D: handler), but it belongs to the routines to manage AUTORUN.SYS, DUP.SYS and MEM.SAV and is therefore resident (it is located in DOS.SYS). $15C8 is also supported by TurboDOS and XDOS for compatibility reasons.