Re-using RAM used by DOS but keeping CIO working!

[+therealbountybob]

My previous abbuc assembler games have been boot disks; this time I have a DOS2.5 disk with an exe file as I'm saving and loading a High Score Table. I'm really tight on RAM what with this, a title screen image, a music player and the music data.

 

I want to re-use any RAM between $0400 and $1CFC(?) / the end of DOS, but keep CIO functional. I'm currently using IOCB2 if that's any help. (I do not need to return to DOS)

 

Thanks

[Rybags]

"saving and loading a High Score Table" - so, you're wanting to do file I/O to the D: device still I take it?

 

You'll still need DOS then. Or the FMS part at least. The memory you can actually use isn't fixed either since there's different Doses and also variability depending on # of drives and buffers allocated.

 

If you're preserving Dos though and not otherwise using Basic, a language processor, the FP Rom - you should be perfectly safe to use memory from $400 through to $6FF.

Fairly sure that $400 (cassette buffer) is only ever used to read the boot sector of a disk and nothing else.

 

A quick/dirty trick you could use with Dos 2.x is to read your high score file and do NOTE commands to work out what sectors it uses. Then just use direct disk I/O to do future read/writes. Of course you'd need to preserve the link data in the last few bytes, and it'd probably be a good idea also to have signature bytes on each record and read the sectors first to ensure the proper disk is still inserted.

A potential problem with NOTE is that some Doses like 2.x return the absolute sector and byte numbers but others e.g. Dos 3 return an offset from the start of the file (which programatically is actually more desirable but doesn't allow working out where on the disk the file is).

 

Alternatively you could probably read the file and check the DCB bytes around $300 to work out the sectors used.

[baktra]

There are always multiple options.

 

1. A possibility is to use a DOS that has footprint smaller than DOS 2, but still provides a fully-featured D: device. But a need to use $0400-$1CFF makes it almost impossible to find such kind of slim DOS.

 

2. Move some data to RAM under ROM, if possible, or the nature of your software allows that.

 

3. As suggested before, use sector disk i/o to process the file. I even wouldn't hesitate to bypass DOS and locate the file using disk directory read with sector disk i/o. Unfortunately, this will work only with DOS 2 compatible file management systems, unless you add support for more.

 

4. Use XBIOS with the same disadvantages as in #3

 

5. Brute force solution - backup the data from $0400-$1CFC to the RAM under ROM and restore them when CIO needed.

 

6. Forget the file management system and write the high score table just as raw sectors.

Edited May 27, 2018 by baktra

[flashjazzcat]

Many techniques here to ensure your game is never used with any other DOS but DOS 2.5. The suggestion of using the RAM under the OS makes most sense, since all it prohibits is running on a standard 400/800 and use with disk-based SpartaDOS.

[ivop]

I happen to know somebody who is working on a very small DOS.SYS. Just 3 pages (786 bytes) and support for two concurrent IOCBs, read, write, dir and MyDos subdirectories. Can't disclose more about it, but this would be a perfect fit for your project

[+therealbountybob]

Thanks guys, as usual it's all down to time with the abbuc deadline approaching. I'm not too worried at this stage about supporting other devices/doses just want to pick one that leaves me with the most space for my code. Yes Ivop that sounds perfect.

 

If there is some assembler code or an article anyone can point me to regarding a direct sector read / write then I'll take a look. [OK baktra posted a link thanks - I have de re Atari but am always terrified of it!] The table is 221 bytes long, needs to be written, read and ideally the IO checked to prevent corruption if the table or disk was missing (i'm using the CIO status to do this at the moment)

 

The IO is only a nice to have, but as I've gone as far as having a High Score Table it would be nice to keep the save/load if I can.

 

Back to my original question I will probably try blatting (overwriting!) some areas of DOS see if the CIO r/w still works; could I re use the other IOCB space perhaps?

Edited May 27, 2018 by therealbountybob

[baktra]

 

If there is some assembler code or an article anyone can point me to regarding a direct sector read / write then I'll take a look.

 

A code snippet from this article could help. See the READSEC label in the listing, it shows how to read a sector.

[xxl]

all these solutions: 3 sec. dos, xbios etc. are programmed for the AtariDOS filesystem - which is not a fault in any way because it saves a lot of memory space.

Fox also programmed 768 bytes DOS - read / write files (without creating new ones).

[phaeron]

Note that DOS 2 rewrites the serial IRQ vectors on boot to work around bugs in OS-A -- overwriting DOS and then calling into SIOV/DSKINV will crash. You might need to overwrite DOSINI and force a warmstart to get the serial vectors reverted to the ROM routines.

[Irgendwer]

I happen to know somebody who is working on a very small DOS.SYS. Just 3 pages (786 bytes) and support for two concurrent IOCBs, read, write, dir and MyDos subdirectories. Can't disclose more about it, but this would be a perfect fit for your project

 

http://www.mr-atari.com/Mr.Atari/TinyDOS/

[+CharlieChaplin]

Hmmm,

 

the first thing that came to my mind was Carsten Strotmann's 3-Sector-DOS, but alas, it is read-only, so of no help for you: https://atariwiki.org/wiki/Wiki.jsp?page=3%20Sector%20read%20only%20DOS

 

I also remember several small DOS-like programs from Antic, Analog and/or Compute, named Micro-DOS, Macro-DOS and a few others. Afair, most of them behave like a Gamedos, so again read-only and no writes possible. But maybe I should take another look and see if I remember it correctly.

 

At the last Abbuc general meeting S.Dorndorf showed me his new version of XDOS where a lot of functions are external now and can be loaded when they are required and killed from memory when they are no longer needed (last in = first out). So the next version of XDOS will have a much lower lomem than the older ones - maybe Stefan can tell us how low the lomem of the barebone version (with absolutely no external drivers and functions loaded) will be ?

 

There is also DOS2XL (and DOS2XA) by Atari++ author thorfdbg, this one uses a very small footprint ($0700 - 09xx or 0Axx ?) in the low RAM area and places most of its code in the RAM under the OS, which of course means, your game must not use any RAM under the OS and errm, due to this DOS it would be for 64k machines only... think DOS2XL (and DOS2XA) are part of Atari++ emulator, so you can download them with it or maybe contact the author for a copy of them (and he can also tell you the differences about DOS2XL and DOS2XA). Both versions are DOS 2.x compatible and support 90k and afaik also 130k format.

 

Not sure how they (XDOS, DOS2XL, DOS2XA, etc.) behave with 3x SIO or harddisk/PBI or 65816 and such, so expect a tornado or a tsunami, several curses and name-callings running towards you, if you should choose one of these DOS versions and the chosen one does not work with higher SIO speeds or harddisks or other enhancements...

 

Last not least, is the mentioned 3-sector DOS by Fox available for download somewhere ?

Edited May 27, 2018 by CharlieChaplin

[Rybags]

You could use IOCB space for what it's worth. If in Basic though, leave #6 alone since graphics commands open it and #7 can be used but Basic uses it for stuff like loading programs.

There's also the printer buffer, and you could get away with using about 160 bytes of the stack.

 

IMO the best method for your score saving would be read 120 bytes then check the DCB for sector #

Also check the buffer length so you know if it's using 256 byte or bigger sectors.

Then read 130 bytes and check the sector # again (120+130 = 250 bytes which is the payload for 2 x Dos 2 sectors)

 

An alternative with Dos 2.5 disks is to use spare sectors. Sectors 1025-1040 are unused on ED disks so you could use a couple of them for your own purpose.

 

The move stuff under OS method - that automatically rules out older machines under 64K. Really, if your game is sufficiently big to need so much memory then maybe just make it to use an entire floppy, though the downside is you'll probably be stuck with standard SIO speed.

Edited May 28, 2018 by Rybags

[pirx]

or a final solution - use

1. datamatrix and

2. hi score cafe.

https://github.com/pfusik/datamatrix6502

http://xxl.atari.pl/hsc/

3. ????

4. PROFIT

[Fox-1 / mnx]

Just some thoughts... In stead of focusing on the SIO...

 

* If I read it correctly you seem to have the title screen in memory all the time so I assume it's reused every time a new game is started. Maybe it's possible to use the fancy title screen only at load time and replace it with a more simple (read: lower memory usage) one to use in-game?

 

* In case you have multiple long display lists: are those hard coded with .byte arrays? You can construct these with routines and rebuild them each time you need them, thus reusing the same memory space for all display lists. Only useful if these are pretty large since you need space for the build-code too.

 

* Did you plan more features but left them out because of memory constraints? Since you have DOS loaded anyways you can eat your heart out when you're loading data from disk at the time it's needed.

 

* Is there any eye-candy that is not really necessary to play the game? You can relocate it under the O.S. memory when running on XL/XE and skip it in case it runs on 800.

[ivop]

 

http://www.mr-atari.com/Mr.Atari/TinyDOS/

 

LOL, didn't know he already released it

[baktra]

 

LOL, didn't know he already released it

Is there a public download link, though?

[+therealbountybob]

Just some thoughts... In stead of focusing on the SIO...

 

* If I read it correctly you seem to have the title screen in memory all the time so I assume it's reused every time a new game is started. Maybe it's possible to use the fancy title screen only at load time and replace it with a more simple (read: lower memory usage) one to use in-game?

 

* In case you have multiple long display lists: are those hard coded with .byte arrays? You can construct these with routines and rebuild them each time you need them, thus reusing the same memory space for all display lists. Only useful if these are pretty large since you need space for the build-code too.

 

* Did you plan more features but left them out because of memory constraints? Since you have DOS loaded anyways you can eat your heart out when you're loading data from disk at the time it's needed.

 

* Is there any eye-candy that is not really necessary to play the game? You can relocate it under the O.S. memory when running on XL/XE and skip it in case it runs on 800.

thanks these are Interestng design thoughts Future plan was to look at using IO for other sets of data e.g. playfields. I'm pretty much aware of all the RAM locations I can use, my last boot game used everything including the stack! It's having DOS that is different this time. I need to plow through some of the examples/links above and read my copy of de re Atari

 

Thanks everyone - this is typical: you are pleased to get something working, in this case CIO/load/save/check and then there are another 20 ways of doing things

 

p.s. rybags - the game is fully in assembler (MAC/65)

[MaPa]

Or maybe try some compression like 6502 inflate routine (https://github.com/pfusik/zlib6502) ...

[Rybags]

Pretty impressive footprint for TinyDos - only uses around 1800 bytes, under 800 in game mode.

[ivop]

Is there a public download link, though?

 

Hmm, looks like he removed the download link of the first beta. I suppose he'll put it back when beta 2 is released, or you could send him an e-mail.

 

Pretty impressive footprint for TinyDos - only uses around 1800 bytes, under 800 in game mode.

 

Yes. Mr. Atari showed it to me in April. The reason he supports two file handles (one for reading, one for writing) is because he wanted to run MAC/65 on top of it. Also, in the end it should fit in the OS ROM instead of selftest, hence the extreme memory requirements.

Edited May 28, 2018 by ivop

[Heaven/TQA]

oh... another DOS for god's sake

 

are we the platform with most custom DOS around?

[baktra]

oh... another DOS for god's sake

 

are we the platform with most custom DOS around?

 

Yes, we are.

 

This is because Atari DOSes are not true kernels, but just software that provides an FMS proxy and a shell. These are easy to replace, especially in situation when there are just few common disk organizations (three major families - DOS 2, MyDOS, and SpartaDOS). Also very most of the software is not shell-dependent, so it doesn't matter much from what DOS the software is executed (MEMLO concerns aside, of course).

 

So these DOSes play a role similar to the desktop environments available for GNU/Linux. Many faces, but sameness inside.

 

And since this is a platform with very limited resources, we have both generalized (SpartaDOS) and specialized (MyPicoDos, TinyDOS, XDOS) systems to cover all needs.

Edited May 28, 2018 by baktra

[baktra]

thanks these are Interestng design thoughts Future plan was to look at using IO for other sets of data e.g. playfields. I'm pretty much aware of all the RAM locations I can use, my last boot game used everything including the stack! It's having DOS that is different this time. I need to plow through some of the examples/links above and read my copy of de re Atari

 

Thanks everyone - this is typical: you are pleased to get something working, in this case CIO/load/save/check and then there are another 20 ways of doing things

 

p.s. rybags - the game is fully in assembler (MAC/65)

 

Then it's time you made a conscious design decision and choose a path to follow... Choose wisely and good luck.

Edited May 28, 2018 by baktra

[thorfdbg]

There is also DOS2XL (and DOS2XA) by Atari++ author thorfdbg, this one uses a very small footprint ($0700 - 09xx or 0Axx ?) in the low RAM area and places most of its code in the RAM under the OS, which of course means, your game must not use any RAM under the OS and errm, due to this DOS it would be for 64k machines only... think DOS2XL (and DOS2XA) are part of Atari++ emulator, so you can download them with it or maybe contact the author for a copy of them (and he can also tell you the differences about DOS2XL and DOS2XA). Both versions are DOS 2.x compatible and support 90k and afaik also 130k format.

Dos 2.XL has a memory footprint of about 168 bytes in page 7, but it really needs these bytes to allow interfacing with CIO and SIO. The rest of the Dos is under the Os. Hence, Lowmem starts at around $7A8, but I would need to check for the precise numbers.

 

Dos 2.XA does not use the RAM under the Os, but has the regular memory footprint, i.e. the FMS goes up to 1A7C, so this is of no use. Otherwise, it is identical to 2.XL.

 

Last but not least, we have Dos 2++ which comes with Atari++, which is in ROM and part of the Os. It requires page 7 for its FMS internals, and everything from page 8 and up for the FMS buffers whose number depends on how many drives you want it to work with and how many files you want to keep open simultaneously. With just one drive and one file, LowMem could start at $900.

 

If there is any interest, I can surely provide access. Dos 2++ is the most modern of them, and you find the sources online already.

[Wilheim]

Another option is using SIO routines instead of CIO operations to save the high score, and reserve some sectors from disk for your high score table. I think it's not necessary to waste RAM in a DOS at all.