+David_P Posted June 21, 2018 Share Posted June 21, 2018 Sector 720 on a SS/SD DOS 2.0S disk comes to mind. Quote Link to comment Share on other sites More sharing options...
+slx Posted June 22, 2018 Share Posted June 22, 2018 (edited) 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.A lot of bootable game disks with high score features worked like that BITD. If you only save and load a fixed area of memory and don't need individual files it's pretty easy to write, too. Edited June 22, 2018 by slx Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted June 22, 2018 Author Share Posted June 22, 2018 I'm struggling for time, planning to take a couple of weeks off to finish the game at the end of July before the deadline so if anyone wants to write something to do the SIO save/load to a sector as detailed in the last few posts that would be great. I have 3x77byte tables to store. Not as urgent but if someone wants to code a load routine for additional playfields I can make good use of this in the future. (I'm working on a 130XE with MAC/65 but have usually been able to get code from other assemblers to work) Thanks Jason Quote Link to comment Share on other sites More sharing options...
+slx Posted June 26, 2018 Share Posted June 26, 2018 (edited) I'm struggling for time, planning to take a couple of weeks off to finish the game at the end of July before the deadline so if anyone wants to write something to do the SIO save/load to a sector as detailed in the last few posts that would be great. I have 3x77byte tables to store. I tried to clobber something together but had not time to test it yet. Doesn't really work yet, and I have no time to debug it further. I think I didn't get the device control block setup right. Reading material is in the OS Manual and Mapping the Atari at $300. I also found some Action! code referenced in this thread that looks good and should be convertible to assembler. ; sample SIO direct load/save for TRBB ; assumes data to be saved is stored in contiguous memory locations starting at TABLE ; org $4000 DDEVIC equ $300 DUNIT equ $301 DCOMND equ $302 DSTATS equ $303 DBUFLO equ $304 DBUFHI equ $305 DTIMLO equ $306 DBYTLO equ $308 DBYTHI equ $309 DAUX1 equ $30A DAUX2 equ $30B DSKINV equ $E453 COLBK equ $D01A TABLE equ $600 ;this should be the address of the table you want to load save SAVESEC equ 700 ;this should be the first sector where your data is written/read ; Test Code ; this fills page 6 with $80, saves them, fills it with $81 and loads ; the saved $80's back TEST LDY #$0 LDA #$80 FILL600 STA $600,Y INY BNE FILL600 JSR SAVETABLE LDY #$0 LDA #$81 FILL600A STA $600,Y INY BNE FILL600 JSR LOADTABLE WAIT LDY #$0 STY COLBK JMP WAIT SAVETABLE ;JSR here to save table to two sectors JSR Init_SIO LDA #$57 STA DCOMND ;write (with verify) LDA #$80 STA DSTATS ;send data to drive JMP PERFORM_IO LOADTABLE ;JSR here to load table from two sectors JSR Init_SIO LDA #$52 STA DCOMND ;read LDA #$40 STA DSTATS ;read data from drive PERFORM_IO JSR DSKINV ;call disk handler to read/write first sector ;error handler missing here CLC INC DAUX1 ;increase sector by one BCC MOVE_BUF ;in case of overflow INC DAUX2 ;increase high byte of sector number MOVE_BUF CLC LDA DBUFLO ADC #$80 ;add 128 (byte count for SD/ED sector) to buffer address STA DBUFLO BCC PERFORM_IO2 INC DBUFHI ;in case of overflow, increase high byte of buffer as well PERFORM_IO2 JSR DSKINV ;call disk handler to read/write second sector ;error handler missing here RTS ;return to game Init_SIO LDA #$01 STA DUNIT ;select drive 1 LDA <TABLE STA DBUFLO LDA >TABLE STA DBUFHI ;set data buffer to address of data to be saved/read LDA <SAVESEC STA DAUX1 LDA >SAVESEC STA DAUX2 ;set sector number of first sector RTS run TEST sio.asm sectio.act.txt Edited June 27, 2018 by slx 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 27, 2018 Share Posted June 27, 2018 You don't need to set the transfer direction (DSTATS) or timeout (DTIMLO) -- DSKINV does that for you based on the command. That's only needed when using SIOV. Quote Link to comment Share on other sites More sharing options...
+slx Posted June 28, 2018 Share Posted June 28, 2018 (edited) You don't need to set the transfer direction (DSTATS) or timeout (DTIMLO) -- DSKINV does that for you based on the command. That's only needed when using SIOV. Forgot to remove DSTATS when taking out DTIMLO on editing the post. I noticed they're set when following the DSKINV vector. Sorry, still no time to test. I think I last used this >30 years ago. Edited June 28, 2018 by slx 2 Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted July 8, 2018 Author Share Posted July 8, 2018 Not had time to look into the IO further as been busy breaking and fixing the game but I noticed the book (one of my favourites) "Assembly Language Programming for Atari Compters (M.Chasin) that I used the CIO routine from also has example programs for SIO and a DCB routine to read sectors direclty so I can probably get this going at some stage Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted August 6, 2018 Author Share Posted August 6, 2018 For abbuc version of Ski-It I didn't risk using the IOCB space as the game still has a few issues... Using DOS2.5 *clean* boot I figured my game code can safely start at $1D00 as DOS ends at $1CFC (perhaps someone can confirm this) but am wondering if after using the IO in game to load/save (IOCB #0) does DOS expand itself further into RAM? Thanks Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 6, 2018 Share Posted August 6, 2018 (edited) The end of Dos Ram will be variable depending on how many drives enabled and file buffers allowed. But generally once the boot is complete, DOS will set MEMLO which a language processor will use as it's program base (e.g. Basic, AsmEd, Mac-65 etc). From that time onwards there should be no further intervention from Dos for that particular memory pointer. But of course, entering DUP via the DOS command will invoke MEM.SAV or if it doesn't exist the program area will be overwritten. DOS will force a language coldstart by setting the WARM flag ( 8 ) to zero during it's DOSINI processing. Any language processor will always check that flag upon it's startup and warmstart - a zero value signifies initial startup or that memory has been overwritten and the program pointers should be reinitialized (ie same as coldstart). In theory if you knew you always used a certain DOS you could probably use the file/disk buffers as work area so long as there was no file activity going on at the time. Re other CIO stuff - you can corrupt DOS as much as you want without worry that other handlers would suffer. Of course make sure any D: IOCBs are closed first. Edited August 6, 2018 by Rybags 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 3, 2018 Share Posted September 3, 2018 If it's a game, use Sparta 2.3 or even 1.x. LoMem is less than $1000 in certain versions. Quote Link to comment Share on other sites More sharing options...
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.