Closed jhoger closed 3 months ago
Never mind... I figured out a workaround... use LOADHX.BA to directly load a staged campaign binary from cassette.
Change line 21
21 cs$ = "CAS:"
Change line 23 to
23 sa%=-19968
Stage TEST_CAMPAIGN.HEX as the next file on the cassette.
CLEAR 256,45568
Run, and it will load the binary. It will take a while, but the Turbo button can be used to speed it up.
Then, CALL 45568
This works, so no special LDHX.HEX needed.
Alternatively it would be nice to include a .CO formatted file of the test campaign in the releases. Although such a large CO file cannot fit in the memory file system, it can be loaded directly from the cassette queue to cleared RAM through either CLOADM cassette I/O or LOADM"0:" through a TPDD emulator with TS-DOS in "DOS-ON" mode.
And being binary it would remove the hex conversion overhead.
Thanks a lot for bringing this up, and also thanks a lot for digging in on getting it running on another emulator! As of #18 and thanks to @majick, the build system now outputs a .co
binary.
Any chance you could release a fast hex loader variant that pulls hex data from cassette?
The purpose is to allow it to easily load into CloudT ( https://bitchin100.com/CloudT ).
CloudT Model 100 Javascript-based emulator file access is based around cassette virtualization, as cassette is the only fully supported external storage access built into the Model 100 ROM.
For example line 21 of LOADHX.BA says
21 cs$ = "COM:88N1E"
Changing it to
21 cs$ = "CAS:"
and RUN makes it load the next file staged on the cassette queue instead of from the serial port. It works fine in CloudT.
But this just gets the fast loader in which is hard coded to load its data from serial, so then it's stuck at
Loading B200
Thanks