#336 A lot of RZX files don't play properly

[BogDan Vatra]

windale reported this problem on Spectacol's bug tracker: https://github.com/bog-dan-ro/spectacol/issues/48

When I tried to play http://www.rzxarchive.co.uk/s/switchblade.rzx with fuse, it prints an error, then it loops the first part of the movie.

[windale]

Does anybody know the cause of this ? Also, '19 Part 1 Boot Camp' plays in slow motion.

http://www.rzxarchive.co.uk/0/19bootcamp.zip

[windale]

Iron Lord gives a similar error to Switchblade.

http://www.rzxarchive.co.uk/i/ironlord.zip

[Sergio Baldoví]

It seems that the broken floating bus (recently fixed) was causing the major part of issues playingback RZX files.

The RZX playback is a bit tricky because the state of emulation of both emulators (recorder and player) should be close. IMO, files from 48k/128k machines without peripherals are quite compatible. But there are also old files recorded with buggy versions.

Having said that, the recordings might be examined to determine the cause.

• switchblade.rzx, 48k, Spin 0.5
• nineteen1.rzx (19 Part 1 Boot Camp), 128k, Spin 0.6
• Ironlord_1.rzx, 128k + Interface 1, Spin 0.5

[windale]

Has the cause of this been identified ? There are a lot of RZX's that end prematurely or don't even start and they give a similar error like 'libspectrum: wrong number of INs'. I would love to see better RZX compatibility on this. Every file i've tried has worked fine on Spectaculator, Jonathan Needle must be an awesome programmer.

[Sergio Baldoví]

I've done a batch test on rzxarchive and 281 of 5014 files (~6%) fail at playback. List attached.

Surprisingly, there are some files recorded by Fuse that are not playable nowadays:

• barbarian_pal.rzx
• head.rzx
• pyramid.rzx
• rainbow.rzx
• starcontrol/broodhome.rzx
• starcontrol/dreadnought.rzx
• starcontrol/guardian.rzx
• starcontrol/terminator.rzx

[Fredrick Meunier]

Head over Heels and other RZX recordings from pre 0.6.2 versions of Fuse may not play back on newer versions where retriggered or delayed interrupts are encountered, see [bugs:#22], [bugs:#38] and [bugs:#67] for more details.

All the above files were recorded in Fuse 0.5.0, 0.5.1 and 0.6.1.

[Sergio Baldoví]

Thanks for pointing that. Not sure if the EI/HALT kind of problem happens often, but I suspect Fuse should do the right thing for recording and Fuse/libspectrum could be flexible on playback. My knowledge about Z80 is limited and I've never gone far about this.

[windale]

You tested all of them ?! How did you do it so fast (and play them all to the end) ? There are also a lot of other RZX's that are marked as 'Denied' and not available on RZXArchive, some of them can be found on a different website.

[Sergio Baldoví]

I've used a hacked version of Fuse running full-speed, with a shell script for orchestration and data collection. Obviously, unattended. It does not make sense processing more files, there should be a few (but repetetive) different problems.

[Sergio Baldoví]

Let's start with the easy ones...

The following files are truly corrupt:

• boovie2/Boovie2_31.rzx: Unknown block type 0xff
• karyssia/KaryssiaP1.rzx: Unknown block type 0x8f
• karyssia/KaryssiaP2.rzx: Unknown block type 0xe0
• karyssia/Karyssiap3.rzx: Unknown block type 0xf0
• kikstart2.rzx: Unknown block type 0xfe
• lifeterm.rzx: Unknown block type 0xe0
• loadsofmidnight/loadsofmidnightp1.rzx: Unknown block type 0x27
• loadsofmidnight/loadsofmidnightp2.rzx: Unknown block type 0xd7
• loadsofmidnight/loadsofmidnightp3.rzx: Unknown block type 0x4c
• monstermaze.rzx: Unknown block type 0x52
• snakepit.rzx: Unknown block type 0xff

I've found out that some versions of SPIN could append junk data at the end of files.

The following files are only playable with Spectaculator:

• crimesantaclaus/CscDv1.rzx
• crimesantaclaus/CscDv2.rzx
• crimesantaclaus/CscDv3.rzx
• crimesantaclaus/CscDv4.rzx
• sliders/Sliders01.rzx
• sliders/Sliders02.rzx
• timecop/TimeCop.rzx

These where recorded with Spectaculator 6.1, using a Scorpion ZS 256 machine and a Z80 snapshot. Spectaculator was using 0..15 block IDs for RAM pages, but the convention is using 3..18 block IDs [1]. Newer versions of Spectaculator use the common convention but have backward compatibility.

[1] http://www.zx-modules.de/fileformats/z80format.html

[windale]

karyssia
kikstart2
lifeterm
loadsofmidnight
monstermaze
snakepit

These all seem to play in Spectaculator (snakepit gives an error at 100%) ? Does Spectaculator just ignore most errors and play them anyway (some of the courses near the end of kikstart2 looked a bit suspect) ?

[Sergio Baldoví]

An emulator can play a recording until unknown data is found or can refuse to play the recording. Both methods are valid. IMO, silencing errors is not advisable.

In these cases, the junk data/corruption happen at the end of the files. It could be possible to trim these bytes and get RZXs compliant to the specification. I've sent an email to rzxarchive suggesting this action.

boovie2/Boovie2_31.rzx: offset 155129
karyssia/KaryssiaP1.rzx: offset 112775
karyssia/KaryssiaP2.rzx: offset 122171
karyssia/Karyssiap3.rzx: offset 127443
kikstart2.rzx: offset 192361
lifeterm.rzx: offset 123251
loadsofmidnight/loadsofmidnightp1.rzx: offset 43519
loadsofmidnight/loadsofmidnightp2.rzx: offset 39693
loadsofmidnight/loadsofmidnightp3.rzx: offset 44861
monstermaze.rzx: offset 15006
snakepit.rzx: offset 18579

[windale]

I noticed that some of the RZX files (with errors) in the list you made are new recently released like 'Sam Mallard' & 'Homer Simpson' etc (both used Spectaculator), so FUSE is obvioulsy missing something.

[windale]

Is there any progress on this ? Maybe backward compatibility just for RZX playback so it would kick in when the errors are occured.

[windale]

@sergio
Is there any chance you could post your hacked version of Fuse that you used to test all the RZX files (for Windows) ? Will it save the report to a text file ?

[Sergio Baldoví]

Of course. It's heavely hacked, though.

• Fuse is now a process (no GUI) that ends after playback with exit status: 0 (success), 1 (error) or 2 (warning).
• Error messages are printed to stdout.
• A bash script organise the rzx files playback and print tab separated values to stdout, that could be easely open as a spreadsheet.

[windale]

Thanks, but unfortunately I have no idea how to use those files on Windows 7. I already have all the RZX files on my hardrive and they have been properly named so I don't need the 'files.txt' file. Is there a way to get Fuse to (very) quickly run through all the RZX files from a directory on my hardrive and save the results ?

Also, is there a way to silence the 'warning: RZX frame is longer than 79000 tstates' on Fuse ?. The RZX's play fine after closing this error but some keep displaying it infinitely.

[Sergio Baldoví]

Thanks, but unfortunately I have no idea how to use those files on Windows 7. I already have all the RZX files on my hardrive and they have been properly named so I don't need the 'files.txt' file. Is there a way to get Fuse (very) quickly run through all the RZX files from a directory on my hardrive and save the results ?

Sorry, this script was designed to run on unix. It's difficult and painful to do what you want on Windows.

Also, is there a way to silence the 'warning: RZX frame is longer than 79000 tstates'. The RZX's play fine after closing this error but some keep displaying it infinitely.

Removing these lines from the rzx.c file should do the trick:

   ui_error( UI_ERROR_WARNING, "RZX frame is longer than %u tstates",
        RZX_SENTINEL_TIME );

but I think that compiling a custom build is out of your comfort area.

"The RZX frame is longer than X tstates" is an abnormal condition that sometimes doesn't affect the playback. Fuse avoid repeated messages for 1 second, but as windale says, some rzx files prompt theses messages very often, being intrusive to the user. Maybe we could limit this message to only once in a playback. Anyone think this would hide useful information?

[windale]

Maybe we could limit this message to only once in a playback. Anyone think this would hide useful information?

It would be good if there was an option to turn the warning off in the options.

Do these errors have anything to do with the version of roms being used ? If I load the RZX file '100.rzx' with a basic install of Fuse it says i'm missing the Pentagon roms then it says 'RZX frame is longer than 79000 tstates' and then 'Wrong number of IN's'. If I add the Pentagon roms then all the errors go away. Would using different versions of roms than the ones included get rid of the errors on other RZXs ?

[windale]

Just noticed something with the attached RZX for example. At the end of the replay it gives this error :-

libspectrum_rzx_playback: more INs during frame 143294 than stored in RZX file (907)

If you turn off 'Fastloading', 'Use tape traps' & 'Accelerate loaders' it doesn't give any errors.

[Sergio Baldoví]

Just noticed something with the attached RZX for example. At the end of the replay it gives this error :-

Good catch. Thank you! It seems like the game/user tries to save the final score board to a tape.

While playing a RZX, Fuse ignores input and output from/to peripherals as they are stored in the file. But tape traps are not being ignored and trigger a playback error.

While recording a RZX, Fuse should disable acceleration methods that divert from normal execution path, as they are not portable to other emulators. I think that tape traps, fast-loading and accelerate-loader should be disabled, whereas detect-loader looks portable.

Quick fix attached. Tests needed.

[windale]

Someone else will have to test this if possible because I have no idea what to do with a .diff file. I've only just tried and succeeded in building Windows FUSE with the RZX tstates warning removed. Hopefully an option can be added to stop this warning as well otherwise i'll have to keep building a seperate version on every new release.

The error also happens on 'Brian Bloodaxe' and a few others that I can't remember.

Can anything be fixed with the following that may fix other RZXs ? :-

At the end of Continental Circus
libspectrum_rzx_playback: more INs during frame 42370: expected 1, got 0

At the end of Cauldron 2
libspectrum_rzx_playback: more INs during frame 65951: expected 101, got 100

At the end of Cerius
libspectrum_rzx_playback: more INs during frame 23501 than stored in RZX file (8)

At the end of Nightbreed (part 2-5) (RZX Plays fine after the error)
libspectrum: szx_read_chunk: unknown chunk id 'PLTT'

[Fredrick Meunier]

At the end of Nightbreed (part 2-5) (RZX Plays fine after the error)
libspectrum: szx_read_chunk: unknown chunk id 'PLTT'

This one is an unofficial SZX element for handling ULA+ colour information.

We have handling for it in the ULA+ branch, but in this case we have no handling for block and the message is informational only. Arguably we could silently ignore this warning - any thoughts on this anyone?

[Sergio Baldoví]

We have handling for it in the ULA+ branch, but in this case we have no handling for block and the message is informational only. Arguably we could silently ignore this warning - any thoughts on this anyone?

I'd be happy ignoring this error. In the rzxarchive there are 8 files with a PLTT block. In most cases I think ULAplus was accidentally enabled in SpecEmu, e.g., levels 2, 3 and 4 from nightbreed were recorded with ULAplus enabled and the rest with ULAplus disabled.

With a real ULAplus recording, the display would have garbage.

[Fredrick Meunier]

I'd be happy ignoring this error.

I'd normally think of this kind of thing as an error, except that in this case, the SZX file format specifically says:

• All blocks start with a ZXSTBLOCK structure. Any unrecognised blocks should be skipped without reporting an error.

So conformant SZX processing requires that this not be treated as an error.

I agree that with ULA+ modes other than simple pallette substitutions, the display would likely be garbage. Strictly speaking I guess SZX files which include blocks which have these kinds of non-fail safe behaviour should be bumping the major version?