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

[+David_P]

Sector 720 on a SS/SD DOS 2.0S disk comes to mind.

[+slx]

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

[+therealbountybob]

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

[+slx]

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

[phaeron]

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.

[+slx]

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

[+therealbountybob]

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

[+therealbountybob]

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

[Rybags]

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

[Kyle22]

If it's a game, use Sparta 2.3 or even 1.x. LoMem is less than $1000 in certain versions.