peteym5 Posted February 28, 2015 Share Posted February 28, 2015 I am planning a future Role Playing/Adventure Game that will be many times larger than the existing ones I made already. One problem I can see going larger is people will not be able to play and solve it in one sitting. I am looking into a means of saving the players progress to a disk file, but would only need the portion of DOS that saves and loads from disk. I am not sure if the OS can do this without having DOS loaded in first. I know Basic XE and MAC/65 need to boot DOS first before those can save to disk. Does anybody have a suggestion? I know another option like using a flash cartridge is being considered, however last time Video61 tried to put a game on Flash cartridge, a third had to be returned because people someone plugged them in with pins cross connected and scrambled or erased the flash memory. It is possible some people were trying to do something with the cartridges also. So that is why we prefer putting games out on EPROM cartridges. A third alternative is enter a code to continue. The code will contain information to reset all the game variables to a prior state so one can continue from a point. However I can see people passing along the codes so so others can cheat. I think the hard core adventure game players will be faithful and not get codes from someone else. But if you bought the game and enter a code that gets you to the end quickly, then you should have no room to complain about not get the full enjoyment out of a game because you cheated. Quote Link to comment Share on other sites More sharing options...
Alfred Posted February 28, 2015 Share Posted February 28, 2015 You don't need DOS to save something to disk. Just make it a requirement that a player needs a blank disk to save games and roll your own save data function. Sector i/o is pretty trivial if you use the builtin os routines, it would be easy to save or load blocks of memory. Quote Link to comment Share on other sites More sharing options...
dmsc Posted February 28, 2015 Share Posted February 28, 2015 Hi!, You don't need DOS to save something to disk. Just make it a requirement that a player needs a blank disk to save games and roll your own save data function. Sector i/o is pretty trivial if you use the builtin os routines, it would be easy to save or load blocks of memory.No, please!!! I lost many disks in my childhood because my brother saved something over from programs/games that do direct disk writing... I remember trying to read my (big, weeks of work) basic program to discover that it was all corrupted :-( Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 28, 2015 Share Posted February 28, 2015 A raw dump is probably the best idea. Inadvertantly trashing disks could be prevented by having a seperate utility which creates the disks and puts a signature on them that the game then checks for before saving to. A minimal Dos could be done probably in under 1K that allows writing to a Dos 2.x disk. It'd be primitive to the point of not having stuff like delete or ability to overwrite existing files or add to them. But really, the raw dump method is probably best. The only advantage having a Dos present and using that is that backing up saves becomes easier. Codes can only go so far (ie not very). I remember Megalomania being great in that a sequence of 20 letters or so was sufficient but all it needed to keep track of really was the level, what your population was and probably a few other minor things. Once you go beyond what can be stored in a sequence of a couple of dozen characters it becomes impractical to have people enter the sequence. Quote Link to comment Share on other sites More sharing options...
kenjennings Posted February 28, 2015 Share Posted February 28, 2015 ... A minimal Dos could be done probably in under 1K that allows writing to a Dos 2.x disk. It'd be primitive to the point of not having stuff like delete or ability to overwrite existing files or add to them. ... Well, a minimal DOS like that sounds better to me. Its such an obvious need... a general purpose disk support utility for games. Has nobody written this before ? A disk written by direct I/O likely won't look to DOS like it has anything on it and has a higher chance of being accidentally reformatted/overwritten. Quote Link to comment Share on other sites More sharing options...
peteym5 Posted February 28, 2015 Author Share Posted February 28, 2015 I have to figure out where "Open file", Write/Read sector, "Close File" routines are in the O/S. My concern is the "D:" handler needs to be loaded so it can be saved to specific file names on an Atari formatted disk. I can always read/write directly to sectors without a disk directory or file names. Just people have to be careful about over writing data. The other issue is my prior games shut down the O/S so RAM from $C000 to $FFFF can be used. A new game would have to be set up not to use certain low memory pages (2,3,4,5) and parts of page 0 if I want to have a save/load progress option. I am looking to see if someone did a minimal DOS, "D:" handler, etc. It could check a disk before to make sure it is something geared for my game. Probably do it by reading a specific sector to see this is a disk with DOS files on it already. (A directory sector?) before over writing. Quote Link to comment Share on other sites More sharing options...
xxl Posted February 28, 2015 Share Posted February 28, 2015 Does anybody have a suggestion? yes. xBios: http://xxl.atari.pl/?p=1076 4 Quote Link to comment Share on other sites More sharing options...
ricortes Posted March 1, 2015 Share Posted March 1, 2015 Interesting question. If you only need ~128 bytes and are writing to lowest common denominator, use sector 720 of a single density disk. I don't think the VTOC is that difficult to read and translate if you need more room. You could just check for free sectors on the disk, use those, and mark them as in use. The numbers wouldn't add up i.e. you would have a disk where the total available sectors would not add up for files and free, but it wouldn't trash anything else on the disk and DOS wouldn't trash your sectors. I seem to recall a couple of games doing it along those lines with flourish: The marked the VTOC full with all sectors used and put a blurb about the game in the directory sector. When you would look at the disk with a DOS disk a directory listing would be ~welcome message. 1 Quote Link to comment Share on other sites More sharing options...
peteym5 Posted March 2, 2015 Author Share Posted March 2, 2015 I will be looking at that xBios thing and prefer to use something that can save to named files on disk. I have to go through and make sure there are no memory conflicts because my bigger games typically bypass the O/S and use all of pages, 0, 2,3,4,5, etc. and I know some of these are used by the O/S when it comes to disk drive access. So it is going to take some reconfiguring. The xBios pages are in Polish and would have to spend some time translating it and figuring out what does what. Thankyou for all your help and we will see what happens. Quote Link to comment Share on other sites More sharing options...
xxl Posted March 2, 2015 Share Posted March 2, 2015 The xBios pages are in Polish and would have to spend some time translating it and figuring out what does what. :/ yes :/ but if you have questions just ask. Quote Link to comment Share on other sites More sharing options...
gozar Posted March 2, 2015 Share Posted March 2, 2015 A cartridge can boot up DOS, so you could just use DOS 2.5 or MyDOS dos.sys (dup.sys not needed). Analog issue 17 has an article on using disks without DOS by calling the built in ROM routines. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 3, 2015 Share Posted March 3, 2015 Not sure what the write cycles are, but if you're using a flash cart you could just write the game data to the flash ROM. Should be rather a long time before it wears out. Just erase one sector and flash the data. Quote Link to comment Share on other sites More sharing options...
peteym5 Posted March 3, 2015 Author Share Posted March 3, 2015 (edited) One issue with loading in DOS/DUP is that it consumes some memory and leaves less to RAM that these games may need. The mini XBios + OS seems to be good option. I have to see what memory areas I need for OS disk operations. For XBIOS, which memory locations in RAM it needs. Do we need IOCB block area reserved, zero page locations, page 3 for devices, etc? Edited March 3, 2015 by peteym5 Quote Link to comment Share on other sites More sharing options...
gozar Posted March 3, 2015 Share Posted March 3, 2015 Yeah, I hadn't thought of memory issues with dos.sys. That Analog article talks about dumping/loading memory straight to/from sectors using the built in ROM routines, which could do what you want without the memory overhead. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 3, 2015 Share Posted March 3, 2015 I'd just raw dump sectors - practically every other game out there does so. Allowing a Dos to load opens up too many scenarios to have to cope with. Having your own Dos means trying to cater for multiple different storage system types which can quickly turn to bloatware. Other thing to consider is many people will just be using emulation devices, makes it easy to mount disks anyway. 2 Quote Link to comment Share on other sites More sharing options...
xxl Posted March 4, 2015 Share Posted March 4, 2015 For XBIOS, which memory locations in RAM it needs. Do we need IOCB block area reserved, zero page locations, page 3 for devices, etc? by default xB uses OS i/o routines so any RAM locations that OS use are reserved. but if you use jsr xBIOS_SET_DEFAULT_DEVICE (SIO i/o) then all RAM besides xBIOS locations are free. default xB header and jsr xBIOS_SET_DEFAULT_DEVICE : $00-$ff - free $200-$6ff - free $700-$7ff - xBIOS i/o buffer $800-$bff - xBIOS $c00-$cfff - free $d000-$d7ff - atari hw $d800-$ffff - free if you set your own xB header eg.: head_fname .byte c'YOURAUTFILE' ; your autorun file head_xbios .byte >$D800 ; xB reloc adress head_buffer .byte >$DC00 ; xB buff reloc adress head_init .word INITAD ; INI vector adress head_run .word RUNAD ; RUN vector adress head_io .word xSIOV ; SIO I/O head_io_reloc .word head_rts ; dummy for SIO I/O head_PORTB .byte $fe ; ROM OFF head_NMIEN .byte $00 ; NMI OFF head_IRQEN .byte $00 ; IRQ OFF head_xSIOV .word xSIOV ; dummy head_rts .byte { RTS } ; dummy then: $00-$ff - free $200-$cfff - free $d000-$d7ff - atari hw $d800-$dbff - xBIOS $dc00-$dcff - xBIOS i/o buffer $dd00-$ffff - free remember: using jsr xBIOS_SET_DEFAULT_DEVICE means SIO Drives (peripheral) default header (just for compare) : head_fname .byte c'XAUTORUN ' head_xbios .byte >$0800 head_buffer .byte >$0700 head_init .word INITAD head_run .word RUNAD head_io .word AOSV head_io_reloc .word AOSV_RELOC head_PORTB .byte $ff head_NMIEN .byte $40 head_IRQEN .byte $c0 head_xSIOV .word xSIOV head_rts .byte { RTS } 1 Quote Link to comment Share on other sites More sharing options...
peteym5 Posted March 11, 2015 Author Share Posted March 11, 2015 I decided to try to disassemble that xBios plus find and replace the labels so I can assemble it as part of a cartridge ROM. I know any buffers have to remain in RAM and looks like pages 2 and 3 cannot be used by the program. I think I am currently leaving those sections alone. Any 0 pages locations used by the O/S during disk operation also needs to be set before disk functions. Quote Link to comment Share on other sites More sharing options...
snicklin Posted March 11, 2015 Share Posted March 11, 2015 I find with xBios that the best way of working out how it works is to read the code in the set of examples. I'm using xBios and am getting to do things that I couldn't dream of doing without it. Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 12, 2015 Share Posted March 12, 2015 Hi! I decided to try to disassemble that xBios plus find and replace the labels so I can assemble it as part of a cartridge ROM. I know any buffers have to remain in RAM and looks like pages 2 and 3 cannot be used by the program. I think I am currently leaving those sections alone. Any 0 pages locations used by the O/S during disk operation also needs to be set before disk functions. That probably won't work, because xbios has code to relocate itself and it's buffers, and also uses self-modifying code. I think that the best option is simply to boot in an emulator with a custom header with your preferred address and then dump the emulator memory to a file. Then, in your cart, you can copy the xbios image to destination address before running. Quote Link to comment Share on other sites More sharing options...
peteym5 Posted March 12, 2015 Author Share Posted March 12, 2015 by default xB uses OS i/o routines so any RAM locations that OS use are reserved. but if you use jsr xBIOS_SET_DEFAULT_DEVICE (SIO i/o) then all RAM besides xBIOS locations are free. default xB header and jsr xBIOS_SET_DEFAULT_DEVICE : $00-$ff - free $200-$6ff - free $700-$7ff - xBIOS i/o buffer $800-$bff - xBIOS $c00-$cfff - free $d000-$d7ff - atari hw $d800-$ffff - free if you set your own xB header eg.: head_fname .byte c'YOURAUTFILE' ; your autorun file head_xbios .byte >$D800 ; xB reloc adress head_buffer .byte >$DC00 ; xB buff reloc adress head_init .word INITAD ; INI vector adress head_run .word RUNAD ; RUN vector adress head_io .word xSIOV ; SIO I/O head_io_reloc .word head_rts ; dummy for SIO I/O head_PORTB .byte $fe ; ROM OFF head_NMIEN .byte $00 ; NMI OFF head_IRQEN .byte $00 ; IRQ OFF head_xSIOV .word xSIOV ; dummy head_rts .byte { RTS } ; dummy then: $00-$ff - free $200-$cfff - free $d000-$d7ff - atari hw $d800-$dbff - xBIOS $dc00-$dcff - xBIOS i/o buffer $dd00-$ffff - free remember: using jsr xBIOS_SET_DEFAULT_DEVICE means SIO Drives (peripheral) default header (just for compare) : head_fname .byte c'XAUTORUN ' head_xbios .byte >$0800 head_buffer .byte >$0700 head_init .word INITAD head_run .word RUNAD head_io .word AOSV head_io_reloc .word AOSV_RELOC head_PORTB .byte $ff head_NMIEN .byte $40 head_IRQEN .byte $c0 head_xSIOV .word xSIOV head_rts .byte { RTS } What file do I insert or include with this header? Quote Link to comment Share on other sites More sharing options...
dmsc Posted March 12, 2015 Share Posted March 12, 2015 Hi! What file do I insert or include with this header? The xbios.com file has 6 sections: - $2400 to $241b (len=28) The header - $241b to $2613 (len=505) The code to load the AUTORUN file and relocate XBios - $2000 to $23ff (len=1024) XBios itself - $02e0 to $02e1 (len=2) Run address, points to $245a. - $2611 to $2863 (len=595) The XBios menu - $03c0 to $03e1 (len=34) The code to call SIOV in ROM, needed if you use RAM under ROM. You can binary edit the file to remove the sections that you don't need, or you can append your file including a new header after the sections, overwriting memory. For example, XBios menu, at $2611, overwrites the last 3 bytes of the AUTORUN code, replacing a jump to self-test with the menu code. Quote Link to comment Share on other sites More sharing options...
xxl Posted March 12, 2015 Share Posted March 12, 2015 What file do I insert or include with this header? config header as a separate file? interesting idea. I think I would use it. :-) Quote Link to comment Share on other sites More sharing options...
xxl Posted March 12, 2015 Share Posted March 12, 2015 (edited) - $03c0 to $03e1 (len=34) The code to call SIOV in ROM, needed if you use RAM under ROM. hmmm, this is I/O module for AtariOS. if you want I/O during ROM OFF use xBios I/O module and simply delete this part or... at ini use jsr xBIOS_SET_DEFAULT_DEVICE and now delete I/O module for AtariOS. Edited March 12, 2015 by xxl Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted March 13, 2015 Share Posted March 13, 2015 xBIOS is simple enough to use... used that extensivly at AD:6502 (the loading times relate due to poor coding of me and using the build in LZ4 IO depacker ). but not sure XXL can answer if he used self modifying code which prevents to put it into ROM. Quote Link to comment Share on other sites More sharing options...
xxl Posted March 15, 2015 Share Posted March 15, 2015 config header as a separate file? interesting idea. I think I would use it. :-) http://www.atari.org.pl/forum/viewtopic.php?pid=204923#p204923 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.