+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: Help & Support (https://www.boriel.com/forum/forumdisplay.php?fid=16)
+---- Thread: Custom TAP loader with SCREEN$ (/showthread.php?tid=1008)
Custom TAP loader with SCREEN$ - patters - 01-17-2021
I have a Sinclair BASIC loader for my game which will CLEAR 32767, load a SCREEN$, LOAD ""CODE, and finally RANDOMIZE USR 32678. I have assembled the loader and the SCREEN$ into a TAP file - but how to I get zxbc.py to append its output to this TAP file? I can't seem to get it to work.
When I try:
Code:
./zxbc.py -t --append-binary ../loader+scr.tap ../arti12.basI get a file arti12.tap as expected but it doesn't load the machine code. If I browse the TAP file in Fuse emulator I see that zxbc.py appears to have prepended an additional self-contained TAP file into the loader TAP file, rather than appended the binary data. Am I doing this wrong, or is this a bug?
I have managed to work around the issue by producing a .bin file instead, and then Fuse's 'Import Binary Data' option and then saving the memory range back out to the mounted TAP file - but it would be much nicer to automate that with zxbc.py if possible.
Thanks
RE: Custom TAP loader with SCREEN$ - boriel - 01-17-2021
(01-17-2021, 06:24 PM)patters Wrote: I have a Sinclair BASIC loader for my game which will CLEAR 32767, load a SCREEN$, LOAD ""CODE, and finally RANDOMIZE USR 32678. I have assembled the loader and the SCREEN$ into a TAP file - but how to I get zxbc.py to append its output to this TAP file? I can't seem to get it to work.
When I try:
Code:./zxbc.py -t --append-binary ../loader+scr.tap ../arti12.bas
I get a file arti12.tap as expected but it doesn't load the machine code. If I browse the TAP file in Fuse emulator I see that zxbc.py appears to have prepended an additional self-contained TAP file into the loader TAP file, rather than appended the binary data. Am I doing this wrong, or is this a bug?
I have managed to work around the issue by producing a .bin file instead, and then Fuse's 'Import Binary Data' option and then saving the memory range back out to the mounted TAP file - but it would be much nicer to automate that with zxbc.py if possible.
Thanks
As you know, ZX Basic creates a default simple basic loader if you specify -B (or --BASIC) option.
But if you want to compose a multi-binary file, this is a different thing.
ZX Basic does not allow (currently) to provide your own BASIC loaded (I've been working on that, and it's near to be done, but it takes time). Basically, you can provide your own .bas loaded + binaries (screens, etc) + .BAS source code. It's not ready. Sorry.
"Append-binary" can be repeated multiple times. It will append the given binary file(s) at the end of the .TAP file one after another.
A possible solution is:
- Create your main BASIC program (by default ORGs as 32768) and save it in .BIN (raw) format (don't use -t or -T)
zxbc mygame.bas (this will create mygame.bin, you can use -o <filename> so set output filename)
- Create a screen and save it in binary (i.e. SCR) raw format
- Create a loader in ZX BASIC and save al together:
Code:
10 BORDER 0: PAPER 0: INK 7: CLS
20 LOAD "" SCREEN$
30 LOAD "" CODE 32768
40 RANDOMIZE USR 32768Compile this with:
Code:
zxbc --org=26000 -taB loader.bas --append-binary screen.scr --append-binary main.bin
RE: Custom TAP loader with SCREEN$ - boriel - 01-17-2021
Another solution is:
Remember that .tap files can be concatenated (i.e. in Windows COPY /b file1.tap file2.tap global.tap).
So you can use the loader screen you already have (which you said CLEARs mem, and loads the SCREEN)
Compile your game with -t and copy /b loader.tap + game.tap final.tap. This should generate a tap that should work.
RE: Custom TAP loader with SCREEN$ - patters - 01-18-2021
Thanks, if I also use -o I can control the Spectrum filename that's inside the compiler's TAP file, otherwise it has a .tap suffix. I can accomplish what I originally set out to do in this one-liner in fact which is ideal, given how frequently I build the code. I'm on Mac OS so no copy /b for me.
Code:
./zxbc.py -t -O3 ../arti14.bas -o arti.bin && cat ../loader+scr.tap ./arti.bin > artillery.tapRE: Custom TAP loader with SCREEN$ - boriel - 01-18-2021
(01-18-2021, 12:30 AM)patters Wrote: Thanks, if I also use -o I can control the Spectrum filename that's inside the compiler's TAP file, otherwise it has a .tap suffix. I can accomplish what I originally set out to do in this one-liner in fact which is ideal, given how frequently I build the code. I'm on Mac OS so no copy /b for me.
Code:./zxbc.py -t -O3 ../arti14.bas -o arti.bin && cat ../loader+scr.tap ./arti.bin > artillery.tap
Ah, great you're in a *nix system.
That should work, but you needn't to name your output file arti.bin. -t creates a .tap regardless of the -o name suffix.
Anyway, I'm thinking on make the compiler to create a custom loader for all the binaries, but there's been a (rather long) discussion on whether it's a task on the side of the compiler or of an external tool (i.e. a linker which I'm heavily working on).
Z88DK (C compiler) for example delegates this task to an external tool and makes sense...
So to sum up: Yes, this process need to be improved, but with an external tool.
RE: Custom TAP loader with SCREEN$ - patters - 01-18-2021
If I don't specify the output filename with -o, then the compiled code shows up as "Bytes: arti.tap" in the concatenated tap file - which looks a bit weird on the Spectrum side. Is that because it has inherited the name from the filesystem object that was merged in? Or is that metadata inside the actual tap file which the compiler produced?
RE: Custom TAP loader with SCREEN$ - boriel - 01-18-2021
(01-18-2021, 04:06 PM)patters Wrote: If I don't specify the output filename with -o, then the compiled code shows up as "Bytes: arti.tap" in the concatenated tap file - which looks a bit weird on the Spectrum side. Is that because it has inherited the name from the filesystem object that was merged in? Or is that metadata inside the actual tap file which the compiler produced?
Yes, that's right. The filesystem filename is used for the tap file. I had forgotten that.