+therealbountybob Posted June 5, 2014 Share Posted June 5, 2014 Probably discussed before...is there a list of memory locations that are usable for storage - even the odd bytes here and there? Ideally one showing differences between a typical DOS type file load vs a bootable disk/ATR ? Also those that could be used with certain provisions? [to be clear a list usable by the game/program itself, not while in the editor/assembler] It would be neat to have an assembler equates file with the usable locations indicated rather than having to read up on each one, or by trial and error, or both as it's not clear (tabmap & logmap spring to mind) - I'm still working on my assembler game (Ramp Rage), it's looking like it will be be an ATR so I can use more RAM. I'm sure every spare byte will be useful Thanks Quote Link to comment Share on other sites More sharing options...
+JAC! Posted June 5, 2014 Share Posted June 5, 2014 (edited) If your program is big (i.e. needs much RAM), the best is to use a packer like exomizer to pack the final result into a single .XEX that can be loaded from regular DOS (and then unpacks to the required, possbly low ($700) address). But there a some considerations you should make, so people can enjoy your program if you do "exteme" things. I've summarized them just recently in the "Atari 8-bit Programming Tips and Recommendations": http://www.wudsn.com/index.php/productions-atari800/tutorials/tips. Edited June 5, 2014 by JAC! 2 Quote Link to comment Share on other sites More sharing options...
Xuel Posted June 6, 2014 Share Posted June 6, 2014 I agree a list like what you propose would be interesting. Here are my thoughts: If you take complete control of the machine (i.e. disable OS and disable or re-vector interrupts), then the only locations that you can't use for storage are the hardware registers, i.e. D000-D7FF and FFFA-FFFF. If you want to be able to drop back into DOS, for example to load more levels, then there are lots of things below 2000 that you should be careful not to disturb. Theoretically, you could just copy 0-1FFF somewhere else, e.g. under the OS or extended memory, during game play, and then copy it back when you want to go back to DOS. You just have to make sure you also restore the stack pointer to what it was. As for individual locations, it depends on what features of the OS and DOS you want to use. As you mentioned, there are probably lots of single bytes here and there that you could clobber if you didn't care about the specific feature it provides. Generally you're free to use 80-FF and 480-6FF for free-standing programs, i.e. that don't depend on BASIC or another language cart or floating point. If you don't need the OS text and graphics processing, i.e. E:, S:, lines, fills, etc., then you can use 50-7F. If you're careful not to grow the stack too much, you can usually get away with using 100-17F or thereabouts. If you're not using cassettes, you can use 3FD-47F. If you don't want to return to DOS, you can of course use 700-2000. A lot of the above doesn't apply if the user has custom OSes or DOSes installed. To cater to those folks, it would be best to stick to just 80-FF and maybe 600-6FF and of course 2000-BFFF. But so many games just take full control of the machine, so I don't think it's unreasonable for new games to do the same as long as you don't need DOS. As JAC! said, you can let DOS load stuff into 2000-BFFF and then do whatever you want. 2 Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 10, 2014 Share Posted June 10, 2014 If you don't need the OS text and graphics processing, i.e. E:, S:, lines, fills, etc., then you can use 50-7F. The XL/XE OS moves several non-display variables into this region, including KEYDEF at $79-7A and PALNTS at $62. I've also seen other OSes and DOSes creatively reuse parts of this region already. Definitely recommend staying clear of all of $00-7F while the OS is active. 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 10, 2014 Share Posted June 10, 2014 If CIO isn't being used then the z-page IOCB copy can be used. Don't trust any location <= $7F to retain it's contents after the user presses Reset. Using locations under $7F you need to be mindful of function and the fact that some are different among the OSes. There's "blobs" of areas under $400 which can be used, hardly worth cherry-picking though. If you just stick to the print and tape buffers it provides some work area with little chance of problems. If you get real desperate, use the first half of the stack. Quote Link to comment Share on other sites More sharing options...
Marius Posted June 10, 2014 Share Posted June 10, 2014 Years ago I did some research on the OS Rev. 2 XL/XE and made some notes on which bytes are really spare and never used. Also with Mapping The Atari in my hand I was able to find some unused bytes. It's only a matter of a few bytes here and there. I'm not sure you are interested in that, and I really have to look where I stored it (If I did that anyway). Quote Link to comment Share on other sites More sharing options...
Creature XL Posted June 10, 2014 Share Posted June 10, 2014 I am with Xuel (quite often we think alike ) When you go for an asm game disabling the OS is the best way. With xBIOS you can still load stuff from disk without repsecting the OS buffers. It takes only 2k (I assume the buffers are included). I was "afraid" to disable the OS at first. But there are really few things you have to take care of yourself (like reseting the IRQs when I recall correctly). And the advantages you gain are enorm. For instance the entry to the DLI or Timer IRQ is faster ( either don't use vectors at all or put them in the Zeropage) If there is no example online I can paste my code in the next days. Using mapping the Atari is a good idea when you want to leave the OS running. Although, custom OSes might have done the same and repurposed "free" locations. 3 Quote Link to comment Share on other sites More sharing options...
Marius Posted June 10, 2014 Share Posted June 10, 2014 running OS independent is always a good idea since -when you use 48K max- you keep also Atari 400/800 compatibility. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted June 10, 2014 Share Posted June 10, 2014 >Definitely recommend staying clear of all of $00-7F while the OS is active. Even with deactivated OS, you should stay away from $08-$0d and be careful if you overwrite the DOS area. Otherwise the machine will most likely hand upon RESET. See my link above for the details. 1 Quote Link to comment Share on other sites More sharing options...
Xuel Posted June 10, 2014 Share Posted June 10, 2014 >Definitely recommend staying clear of all of $00-7F while the OS is active. Even with deactivated OS, you should stay away from $08-$0d and be careful if you overwrite the DOS area. Otherwise the machine will most likely hand upon RESET. See my link above for the details. Are there values that a game or demo could poke back into there at the end (or maybe at the title screen) if it needs the whole zero page for some reason? I suppose that still wouldn't solve the problem if the user presses RESET before the end. Quote Link to comment Share on other sites More sharing options...
Xuel Posted June 10, 2014 Share Posted June 10, 2014 running OS independent is always a good idea since -when you use 48K max- you keep also Atari 400/800 compatibility. You bring up a good point. If you really want to maintain compatibility with 400/800 machines, then you must assume some dependence on the OS since you can't re-vector the interrupts. You can only get control after the OS passes it to you through the OS-provided vectors. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted June 10, 2014 Share Posted June 10, 2014 >Are there values that a game or demo could poke back into there at the end (or maybe at the title screen) if it needs the whole zero page for some reason? I suppose that still wouldn't solve the problem if the user presses RESET before the end. Sure, you can preserve and restore the values. But as you mention you cannot forsee when the user presses RESET. So if you overwrite them (for other reasons that actually putting in a RESET callback on warmstart), you should make sure you set COLDST to a non-zero value. Then the machine at least performs a coldstart instead of locking up. Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted June 10, 2014 Share Posted June 10, 2014 Well, the advantages & disadvantages of XBIOS are already discussed at atarionline.pl forum. If I understood some of the opinions correctly, they said something like this (disclaimer: I am no programmer, I do not speak polish language and Google translate is not always the best): + XBIOS switches off the OS, requires only 2k memory while making 60k RAM available on a 64k computer + offers a lot of built-in stuff, e.g. depacking on-the-fly (LZ4) is possible, playing sound/music while loading is possible, etc. + many more things which I do not know or understand - SIO-dependant, XBIOS will not work from cart. or harddisk or any other non-SIO media - DOS 2.x dependant, thus your program will never work under a non DOS 2.x filesystem (like SDFS) - some of the released XBIOS programs (e.g. Mazezam, Deathchase XE) will only work under a *certain* version of XBIOS, they will not work under newer XBIOS versions nor the latest XBIOS version... - many other things which I do not know or understand I would not code a program that only works under XBIOS, but hey I am not a programmer, so this is your decision... ----- Games generally: +1 for programs where Reset does a coldstart... (e.g. POKE 580,1 or X=USR(58487) in Basic) I don`t like programs that are completely Reset-proof; my thirty year old real Atari does not like to be switched on/off all the time due to programs being Reset-proof. Don`t steal the Reset-vector ! +1 for programs that are not OS (e.g. OS-A, OS-B), DOS (e.g. only DOS 2.5) / DOS-filesystem (e.g. DOS 2.x filesystem) dependant Its much cooler if a program works under more than just one OS, DOS (or Gamedos) or DOS-filesystem... We should e.g. avoid such programs: OS-A only: http://a8.fandal.cz/search.php?search=OS-A&butt_details_x=x OS-B only: http://a8.fandal.cz/search.php?search=OS-B&butt_details_x=x +1 for programs that are NOT density dependant Programs that work well with 128 Bytes per sector, should also work with 256 Bytes per sector and/or even 512 Bytes per sector (and vice versa)... say goodbye to sector-counters (and other things) that are density dependant ! +1 for programs that are NOT fully SIO-dependant / SIO-speed dependant or do NOT use a custom SIO-routine its nice if a program can work with a higher speed than 19,2 kBaud (programs like Digi-Paint, Overmind-Demo or Sweet-Illusions Demo that are unprotected but still only work with standard speed are not nice!) and there is a higher probability that they will work from harddisk or (flash-) cartridge, unlike A.R. or Seven Cities, etc. +1 for programs that work on real Ataris and NOT only on the emulator I still enjoy using my real A8`s for gaming and other purposes (the emulator is only used to test things quickly or to speed up certain things, e.g. packing A8 files with full speed under the emulator) +1 for programs that come as files (and not as bootdisks/boottapes) ...as long as these files can be loaded from (floppy/hard) disk on the real A8, as well as (floppy/hard) disk-image on the emulator... +1 for programs that do NOT use some "unused sectors" of a DOS/Gamedos disk to store data ...with another DOS or Gamedos these "unused" sectors (e.g. sector 720 or sectors 1025-1040) might be in use again... Enough for now. 1 Quote Link to comment Share on other sites More sharing options...
xxl Posted June 10, 2014 Share Posted June 10, 2014 (edited) > XBIOS switches off the OS, requires only 2k memory while making 60k RAM available on a 64k computer not true. xB takes only 1KB and do not switch os. > SIO-dependant, XBIOS will not work from cart. or harddisk or any other non-SIO media not true. Also works with hdd/cart. but true is xB also allows to write a program so that it works only with a specific device. here with CART: > DOS 2.x dependant, thus your program will never work under a non DOS 2.x filesystem (like SDFS) works with AtariDOS FS (MyDOS,TopDOS,BiboDOS and so) but do not works with Sparta DOS FS. > some of the released XBIOS programs (e.g. Mazezam, Deathchase XE) will only work under a *certain* version of XBIOS true. new version of xB v3 has many more func and variables, some xB functions have been clarified. Edited June 10, 2014 by xxl Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted June 10, 2014 Share Posted June 10, 2014 Hmmm, I thought that I did read somewhere at atarionline.pl forum that XBIOS does not work with HDD or cart. and it does switch off the OS (both confirmed untrue), must have been the "great" Google translation then that gave this false impression... When I write DOS 2.x filesystem, I mean DOS 2.0/2.5 compatible filesystems, like DOS 2.0, DOS 2.5, Turbo-DOS, Bibo-DOS, Super-DOS, Top-DOS, My-DOS, etc. You know DOS 3, DOS XE and DOS 4 are also from Atari and they are not DOS 2.0/2.5 compatible at all. Your definition "works with AtariDOS FS" is a little bit unclear I think... (which AtariDOS?) Quote Link to comment Share on other sites More sharing options...
xxl Posted June 11, 2014 Share Posted June 11, 2014 > I thought that I did read somewhere at atarionline.pl forum that XBIOS does not work with HDD or cart. and it does switch off the OS (both confirmed untrue), must have been the "great" Google translation then that gave this false impression... earlier versions yes. therefore I recommend to use xB v3 :-) > Your definition "works with AtariDOS FS" is a little bit unclear I think... (which AtariDOS?) You right - AtariDOS2 FS family. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted June 16, 2014 Share Posted June 16, 2014 There is also the Printer buffer (which I think is at 900 decimal?) that could be used if you aren't using the printer. There are also an assortment of zero page locations unused by the OS which are available too. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.