Getting files on the SD.

Getting files on the SD using SJASMPlus and deZog without removing the SD card from the next.

What you will need

There is some excellent file system code in filesys.asm from the LowResDemo that comes with CSpect so there is no need for me to post that here.

Within that code is a Save function which takes a file name just like the load function.

// In: hl = file data pointer
// ix = address to save from
// bc = size

So to load a file you will need a structure like this:-

fontFile:		dw	FONT_SIZE // bytes to load
			db	“c:/game/common/font.bin",0 // name on disk

however, for saving a file you don’t need the size as that is part of the call

			fontFile:	db “c:/game/common/font.bin",0 // name on disk

So in assembler you would

			ld	hl, fontFile
			ld	ix, $c000
			ld	bc, FONT_SIZE
			call	save

Its that simple, well not quite, that is great if you have the file in $c000 and you know the length of the file. But we want something more.

So in my code I have

			ORG	endCommon

			include "includes/Level1/shellboss.asm" 
			include "includes/Level1/shellbosseye.asm"
			include	"includes/Level1/paths.asm"
lastLevel1Data:		SAVEBIN "../build/level1/code.bin",endCommon,lastLevel1Data-endCommon

so my level code gets compiled at the correct address, then saved locally to my development machine.

Then at the end of the code before the SAVENEX I use the MMU command to swap in a bank into $c000 and then include that file as a bin file and at that address.

			MMU	6 e, 12
			ORG	0xc000
level1CodeStart:	incbin	"../build/level1/code.bin"
			SAVENEX AUTO            // Save every 16k bank with data in it 

A small idiosyncrasy i have found is that sjasmPlus requires the file to be there before you start your compile, so a simple solution is to comment the incbin out then compile so it builds the file first, but still a small price to pay for all that swapping and changing of the SD card in and out, which may wear out the SD slot in the next sooner than expected.

Anyhow onwards with the code

Then when deZog transfers the nex file to the Next, it transfers my File to save. Then its just a matter of calling my save function to save the memory.

			codeFile: db “c:/game/level1/code.bin",0 // name on disk	

			nextreg	REG_MMU6,12		// Next memory management via machine 
			nextreg	REG_MMU7,12+1		// code uses 8k banks.
			ld	hl, codeFile
			ld	ix, level1CodeStart
			ld	bc, endLevel1Code -level1CodeStart
			call	save

That way it saves the file transfer process. I bet your wondering why I do this elaborate method? It is so the files on the disk get updated every time I compile and run my code, so even if I make changes the updated data is already on the disk.

I already hear you say why are you swapping banks? That so the incbin does not overwrite my game data in $c000

The other response I am expecting is what about one of those Toshiba Air SD cards, firstly I am not spending over £30 on an SD card and I did purchase another make, only to find out they don’t work as expected they are for putting in your SDLR camera so you can view the photos on Android or Apple phones, it did not work in my next. So save your pennies for buying TX-1696 and use this code method.

I use this method for transferring game image files too, its only the file path that changes.

Side note: I am so tight on memory with TX-1696, im having to find bytes here and there, so I placed my save game files functions in the video memory as they are only called at the start of my code, and never used again so it can be over written with the graphics.

transferFile:		incbin	"F:/Projects/Komodo/Sources/Output/linefont.bin"

Hope this helps you too.