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" endLevel1Code: SAVENEX AUTO // Save every 16k bank with data in it SAVENEX CLOSE
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" endTransfer:
Hope this helps you too.