ZX Spectrum Clone - ZX Sizif-512

[jamesh]

no just writing using a sd imaging tool [...]

That's the problem, then. HDF image (and it looks like Workbench is available as HDF images only) has variable length header (depending on the HDF spec used), so you must remove that header otherwise all data structures will have unexpected offset and none will be recognised. Sorry, I have no idea what tool may do this on Windows (simple dd(1) will definitely work, but check the HDF spec first).

[creed79]

ok so I have it running in 3e mode using the mar oceana image linked a few posts back and I want to export/save the version of Auf Monty thats in this image as it has a really configurable trainer and I just dont know how to do it? I have tried using the fuse emulator and saving a snapshot to my pc but i wont load back in esxdos on my divmmc so what am i doing wrong? does anybody have a direct link to the snap or tap or instructions how to extract it myself?

[jamesh]

I want to export/save the version of Auf Monty thats in this image as it has a really configurable trainer

I'd say use Miguel's 3e tool (there is a GUI front end, sorry, not using it myself so do not remember it's name). There is a thread here about accessing 3e files. You'll need to remove PLUS3DOS header, but it's always 128 bytes long.

However, options provided by that BASIC loader seem to be exactly the same as the POK file available from this site. You should be able to use that POK file from esxDOS.

[creed79]

Thank you both options work brilliantly! - does anybody know how the eprom is laid out? Id like to make a custom rom for my Sizif512

[jamesh]

does anybody know how the eprom is laid out? Id like to make a custom rom for my Sizif512

ROM banks are described at the top of the Makefile. Beware, some parts are interconnected and I have not found a good explanation of those dependencies yet (perhaps, I simply do not understand how it works). E.g., obviously bank02 is needed to handle long NMI press, but why it is present in the "lower" quarter only, I have no idea.

[jamesh]

I guess that utility isn’t going to win any popularity contests, but it may help someone else. Besides, I learned a lot while working on it. Hence, presenting

tape2esxdos -- set of tools for transferring arbitrary files to ZX Spectrum machine via tape input. Git repo with sources and binaries.

a bit of history

At some point I realised that I needed a way to transfer files to the SD card “as is” without pulling the card from the DivMMC unit or, in my case, Sizif-512 board. Just copy the binary stream, no headers added, no container, nothing. Like I said, “as is”. And… I could not find one. Again, a perfect excuse to write one myself, always wanted to see how you can create a dot command for esxdos...

Disclaimer: yes, I am aware of the .sercp tool bundled with the recent esxdos. But you need a serial cable with those weird BT connectors for 128 (and USB UART, unless you have a retro PC), or a USB UART dongle if you have a modern board or... nothing helps at all if you have ye olde good 48k. So the purpose of this tool was to avoid any additional/unusual hardware, tailored for infrequent usage. Besides, on my Sizif .sercp was really really finicky, my tool was much more reliable.

Since tape data flows in one direction only (tape to speccy), two way comms are not possible, and the data stream has to have enough meta data to allow receiving code properly write all the inbound bytes to disk. That’s why the source file must be prepared with the “split.py” command line tool. Oh, the target file name will follow 8+3 convention, AFAIK, this is esxdos limitation, no long file names yet. Besides, tape allows file names up to 10 characters anyway, 8 + dot + 3 is 12, so not every valid DOS name can be preserved in a TAP header. split.py will try to truncate the file name if necessary.

data transfer protocol

Data blocks have unusual type id 0x88 and use address and vars fields in a different way, storing chunk IDs (numbers) there. Maximum chunk size is 16384, number of chunks is, well, “unlimited” – 65535. As the name suggests, split.py cuts the data to be transferred into a series of chunks no bigger than the internal buffer on the receiver’s side. Theoretical total maximum length of the data is 16384*65535 which is, wait, just below 1GB? Surely, no one will send that much data to speccy, 640k at 4x speed takes a bit less than 15 minutes.

We started with regular CODE blocks, but could not quickly find a tool enabling us to handcraft necessary headers. And if you have to have a script to produce headers, why not to use it to produce bespoke format?

Also, the script can insert headerless blocks multiples of 256 bytes between data blocks. Those headerless blocks will be ignored by anything reading the tape, but they may be necessary if your SD card is not fast enough to write a chunk before the next one arrives.