Unsupported? .Z80 file header values

[chernandezba]

Hi

I've recently purchased the itchio 40years speccy bundle. One of the games included:

https://payndz.itch.io/dungeon-raiders

Has two downloadable files: tap and z80.

The z80 file can't be loaded on Fuse (gives me a libspectrum warning), RVM (crashes the emu) or ZEsarUX (my emulator). Looking at the file and taking a look at ¿official? Z80 file specs:

https://worldofspectrum.org/faq/reference/z80format.htm

That file has that field "Length of additional header block" with value 31. According to the specs:

"The value of the word at position 30 is 23 for version 2 files, and 54 or 55 for version 3;"

So it seems that 31 value does not follow the official documentation. However, I've modified ZEsarUX to handle it as a version 2 file, loaded the additional header and data, and I also find a block type number 3: this is a 48k file and that block is for 128k files... I also supported that block type as data starting at address 16384, and now it can be loaded in ZEsarUX.

Anyone knows about it? Is there an additional .Z80 specification that explains that?

By the way, the ZXSP emulator can load that snapshot

Cheers

[TomD]

Hi

I've recently purchased the itchio 40years speccy bundle. One of the games included:

https://payndz.itch.io/dungeon-raiders

Has two downloadable files: tap and z80.

The z80 file can't be loaded on Fuse (gives me a libspectrum warning), RVM (crashes the emu) or ZEsarUX (my emulator). Looking at the file and taking a look at ¿official? Z80 file specs:

https://worldofspectrum.org/faq/reference/z80format.htm

That file has that field "Length of additional header block" with value 31. According to the specs:

"The value of the word at position 30 is 23 for version 2 files, and 54 or 55 for version 3;"

So it seems that 31 value does not follow the official documentation. However, I've modified ZEsarUX to handle it as a version 2 file, loaded the additional header and data, and I also find a block type number 3: this is a 48k file and that block is for 128k files... I also supported that block type as data starting at address 16384, and now it can be loaded in ZEsarUX.

Anyone knows about it? Is there an additional .Z80 specification that explains that?

By the way, the ZXSP emulator can load that snapshot

Cheers

Any idea what is in the extra 8bytes? I have seen custom z80 snapshot formats before like with the z80stealth emulator but it didn't load so can't be that. I also thought it might be SAMRAM but that should follow the standard format. Sorry I'm no help

[chernandezba]

Any idea what is in the extra 8bytes? I have seen custom z80 snapshot formats before like with the z80stealth emulator but it didn't load so can't be that. I also thought it might be SAMRAM but that should follow the standard format. Sorry I'm no help

Looking at these 8 bytes:

4F 08 01 00 00 00 FF FF

they probably follow the specification:

55 2 Low T state counter -> 084F
57 1 Hi T state counter -> 01 (so t state counter= 01084fh= 67663)
58 1 Flag byte used by Spectator (QL spec. emulator)
Ignored by Z80 when loading, zero when saving -> 00
59 1 0xff if MGT Rom paged -> 00
60 1 0xff if Multiface Rom paged. Should always be 0. -> 00
61 1 0xff if 0-8191 is ROM, 0 if RAM -> FF
62 1 0xff if 8192-16383 is ROM, 0 if RAM -> FF

These values are completely logic, so this seems to be some kind of version "2.5", between version 2 and 3.

Anyone have another theory?

[ketmar]

i wonder what emu/tool produced that file. yes, it looks sane, and simply omits some info almost nobody is using anyway. but as Z80 has no signature, accepting all "sane" header sizes doesn't look ok for me, it is better to fix the tool.

[chernandezba]

i wonder what emu/tool produced that file. yes, it looks sane, and simply omits some info almost nobody is using anyway. but as Z80 has no signature, accepting all "sane" header sizes doesn't look ok for me, it is better to fix the tool.

Yes, fixing the tool seems logic. It's an AGD game so I assume the snapshot is produced with some of its tools. It's curious: the itchio download provides two files: a tap and a z80. Maybe the author notices the z80 file doesn't load on all emulators and put the tap file too?

On the other hand, maybe ZXSP emulator can load this file just by chance: it is ignoring valid z80 header sizes and the data type 3 is loaded despite this type is not allowed as a 48kb block.

I also wanted to contact the author of the game (Andy McDermott) but haven't found his email. However, I've found another game made by him, also with AGD:

http://www.indieretronews.com/2017/08/s ... -andy.html

The .z80 file has the same 31-byte ¿bad? header...

[chernandezba]

Update: I've talked to Andy and the snapshots are saved using ZXSP. So it's probably a bug on that emulator...

[chernandezba]

Tested on QAOP emulator and the z80 snapshot also fails. Also tried to save a 48k snapshot from ZXSP and same error on trying to load it on other emulators

[Ast A. Moore]

Indeed. I just loaded it into zxsp and then re-saved it as a .z80 file. This produced a file that which also wouldn’t load in other emulators. Same thing if I create a .z80 from a different machine state in zxsp; so, yes, it seems plausible that the original was created with zxsp.

[Luzie]

Update: I've talked to Andy and the snapshots are saved using ZXSP. So it's probably a bug on that emulator...

Should we or I write at the ZXSP http://zxsp.blogspot.com/p/about-zxsp.html author about it?

[chernandezba]

Should we or I write at the ZXSP http://zxsp.blogspot.com/p/about-zxsp.html author about it?

Maybe... But I see the last version is too old (2015-05-18 - Version 0.8.0pre27) so I assume he is not updating it anymore

[Luzie]

Should we or I write at the ZXSP http://zxsp.blogspot.com/p/about-zxsp.html author about it?

Maybe... But I see the last version is too old (2015-05-18 - Version 0.8.0pre27) so I assume he is not updating it anymore

OK. I will try my luck on getting in touch with him.

[kio]

Hello,

just to start with: it won't be fixed. (probably)

I lack resources to compile a new version on an Apple Mac, my iMac is too old, the OS is too old, i can't update iCode and i would have to pay Apple an anual fee of $99,- (if it hasn't changed ever since) just to provide free software.

I worked on a new version, adding e.g. rzx tape replay, but somewhere i messed up the resource management and zxsp was unstable, so i wouldn't release it in this state and i couldn't go back to a stable version, because way back then i didn't use git or something similar. And there was no good intermediate manual backup. So that's the state.

Besides that i view the Z80 export as 'conformant'. The header extension length is correct, it's just not a match to any version produced by the original Z80 emulator. From what i understood at that time, other values would be perfectly legal. Btw. at that time i wanted to barter some extensions to the Z80 format at WoS, but the reaction was like "do what you like, nobody is going to use your files anyway".

My understanding was, h2len can be any reasonable value, otherwise one could just store the version number.
Of course your opinion may differ.

The current source of zxsp has an interesting comment in the Z80Head.write() function (which i didn't remember):

Code: Select all

assert(h2lenl == z80v2len-2-z80v1len || h2lenl >= z80v3len-2-z80v1len);	// other emulators are soo picky…

So the current source will no long store a size not supported by some other emulators. Though still the 'illegal' extensions, invented by other emulators and zxsp. (for saving the Spectra or one of the b&w models. Right: nobody will use this anyway.)

What is it what's *not* saved by zxsp?

Code: Select all

uint8 joy[10], stick[10], mgt_type, disciple_inhibit_button_status,disciple_inhibit_flag;

actually, i didn't know what to store for the joystick key settings, because it wasn't documented and i assume one byte is a key code and Apple key codes don't match key codes from an IBM PC.
The MGT and Disciple bytes are also never needed, because zxsp doesn't emulate them.
So the omitted parts are actually not used.

It's just that some programs are too picky.
A fact which i also noted, when i implemented rzx save conforming to the specs and found other emulators couldn't handle them. Or which was the case when i implemented gif export acc. to specs and found not a single program which would position all frames correctly. Mozilla/Firefox was the best back then. So i replaced the parts which everybody else just didn't care to implement or test until rzx loaded in other emulators and gifs displayed correctly (in most programs).

Keep happy,

kio !

[Ast A. Moore]

Hi @kio! Fancy seeing you here.

[chernandezba]

Besides that i view the Z80 export as 'conformant'. The header extension length is correct, it's just not a match to any version produced by the original Z80 emulator. From what i understood at that time, other values would be perfectly legal. Btw. at that time i wanted to barter some extensions to the Z80 format at WoS, but the reaction was like "do what you like, nobody is going to use your files anyway".

My understanding was, h2len can be any reasonable value, otherwise one could just store the version number.
Of course your opinion may differ.

Yes, I see the .z80 specs are not very clear about using another header sizes, but seems to be some kind of "standard" sizes

So the current source will no long store a size not supported by some other emulators. Though still the 'illegal' extensions, invented by other emulators and zxsp. (for saving the Spectra or one of the b&w models. Right: nobody will use this anyway.)

In my opinion it would have been better to create your own snapshot file format. That's what I did on ZEsarUX, my .ZSF file format can store every data and info of all my emulated machines; otherwise, I couldn't use any file format to store all these data

It's just that some programs are too picky.

Well the file header size could be considered as "ok, I can handle that kind of file" and all emulators could read it. However, as I said in one of my posts, you are using machine id "3" in '48 mode, and according to the .Z80 specs at wos page, that id is totally undefined

Code: Select all

        Page    In '48 mode     In '128 mode    In SamRam mode
        ------------------------------------------------------
         0      48K rom         rom (basic)     48K rom
         1      Interface I, Disciple or Plus D rom, according to setting
         2      -               rom (reset)     samram rom (basic)
         3      -               page 0          samram rom (monitor,..)
         4      8000-bfff       page 1          Normal 8000-bfff
         5      c000-ffff       page 2          Normal c000-ffff
         6      -               page 3          Shadow 8000-bfff
         7      -               page 4          Shadow c000-ffff
         8      4000-7fff       page 5          4000-7fff
         9      -               page 6          -
        10      -               page 7          -
        11      Multiface rom   Multiface rom   -