Fuse - the Free Unix Spectrum Emulator / Bugs / #336 A lot of RZX files don't play properly

Sergio Baldoví - 2017-04-24

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.

I think SZX spec aims to keep backward compatibilitiy. If a block is skipped we have a functional machine with some feature/peripheral disabled. RZX purpose seems more strict as aims for perfect reproduction, though.

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

Had a closer look. Unknown blocks are not treated as errors but reported as errors. I think this is valueable information for debugging/development.

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?

SZX specification never bumps major version, only bumps minor version on block additions. The spec states:

"Software must be able to correctly parse current and future versions of this file format that have the same major version number."
"Do not use the chMajorVersion and chMinorVersion values to decide on parsing strategies. Use the ZXSTBLOCK at the beginning of each block to navigate through the file."

So I'm keen to skip the PLTT block (as other unsupported blocks) and let the RZX playback fail (if has to). Patch attached.

libspectrum_szx_pltt.diff

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Fredrick Meunier - 2017-04-24
  
  Looks good to me.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Sergio Baldoví - 2017-04-24
    
    Thanks all. Commited in [7a61f0] (PLTT block).
    
    Affected RZXs:
    
    darkcastle.rzx darksceptre/darksceptrecropped.rzx mmturbo2.rzx nightbreed/night02.rzx nightbreed/night03.rzx nightbreed/night04.rzx nightbreed/night05.rzx stockmarket.rzx
    
    Related
    
    Commit: [7a61f0]
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-04-25

Thanks. Tape traps fix committed in [9e07ec]. That fixes the playback of:

bloodaxe.rzx mysterynile.rzx henryshoard/Henry's Hoard (1985 version fixed).rzx henryshoard/Henry's Hoard (1986 version fixed).rzx henryshoard/Henry's Hord (1987 MicroHobby version fixed).rzx

I'll do some tests with fast-loading and accelerate-loaders after the next release.

Related

Commit: [9e07ec]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-05-01

I've recorded the play of Cobra's tape (alkatraz protection). Accelerate-loader changes the execution path and makes the recording not playable by Fuse itself. No surprises. It has been disabled in [740a20].

Fastload and detect-loader have no effect on playback compatibility.

Reminder to the future: SpecEmu and Spectaculator tend to fail playback with interspersed snapshots made by Fuse.

Related

Commit: [740a20]

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

windale - 2017-05-30

Can we please have an option to turn off the 'warning: RZX frame is longer than 79000 tstates' please ? Sometimes the warning just doesn't go away and I have to Ctrl+Alt+Del to quit the emulator. Otherwise I have to manually build a seperate exe with the warning taken out.

Also, on Windows you can press the 'Pause' button to pause the screen (useful to read text that skips too fast in RZX replays) but on the Linux Retropie version there is no pause function. Can this be added please ? I imagine these two would be very quick and easy to implement.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-05-31
  
  Can we please have an option to turn off the 'warning: RZX frame is longer than 79000 tstates' please ? Sometimes the warning just doesn't go away and I have to Ctrl+Alt+Del to quit the emulator.
  
  There are recordings (marsport.rzx, moonalert.rzx, DizzyXII-Game.rzx, tauceti-se.rzx, etc.) where this error pops very often. I agree that it's annoying when the emulator becomes unresponsive and this situation should be avoided by default. I think that the first warning could be displayed on the UI and the rest could be redirected to stderr. I'll give it a try soon.
  
  Also, on Windows you can press the 'Pause' button to pause the screen (useful to read text that skips too fast in RZX replays) but on the Linux Retropie version there is no pause function. Can this be added please ? I imagine these two would be very quick and easy to implement.
  
  Retropie use the SDL UI. The only option to pause the emulation is enabling the menu but that hides part of the screen. I don't think it's so easy to implement as has been long accepted this situation. I've created [feature-requests:#113] based on your suggestion. Thank you.
  
  Related
  
  Feature Requests: #113
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-05-31

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 ?

Usually ROMs are not stored in RZXs files, so ideally the emulator that record the file and the emulator that play the file should use the same ROM, otherwise, the instructions executed in the playback could differ and the keyboard inputs stored in the RZX file would not be valid.

I've checked the ROMs used in different emulators:

v5.03 CRC32(10751aba) Fuse (formerly), Spectacol, ZXDS, R80, Unreal Speccy, Z80 Stealth (Beta128)

v5.03 CRC32(c43d717f) Spectaculator, SpecEmu, Zero, X128 and Z80 Stealth (Pentagon)

v6.04 CRC32(d8882a8c) Spin 0.666

In earlier versions, Fuse was using a diferent ROM from the ones in Spectaculator and SpecEmu. With the ROM with CRC32(c43d717f) there are 57 RZX files that play fine in Fuse, all Pentagon machines. See attached file for a complete list.

The trdos.rom with CRC32(10751aba) was the last original (Technology Research) version.

The trdos.rom with CRC32(c43d717f) is similar to the original 5.03, with some commands modified to use stepping rate 6 ms instead of 30 ms. There is also a new entry point at 0x0800 that change the stepping rate before jumping to 0x3d9a. That explains the playback errors.

As Spectaculator and SpecEmu are the most common creators in RZX files from rzxarchive, I suggest to anyone interested in RZX playback to use the ROM wih CRC32(c43d717f).

rzx-error-pentagon.ods
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

windale - 2017-06-01

Thanks for looking into this, I hope the option can be added to skip the Warning.

So I was right, using a different rom version fixes nearly 60 more RZX's (that use TRDOS). Would this also apply to the others that give errors (different 48k/128k roms) ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-06-02

Would this also apply to the others that give errors (different 48k/128k roms) ?

I don't think so. There are very few Spectrum rom versions, identical in different emulators. But other peripherals could have the same problem (e.g., +D).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-06-13

There are some recordings from Pentagon 128K + built-in Beta128 + Multiface interface. This is an incompatible setup. Spectaculator [1] disables Multiface for pentagon machines since version 7.0, but SpecEmu has Multiface enabled (forced) in all machines.

Fuse don't allow the use of Multiface for pentagon machines, so the playback of these files won't be fixed:

alienstorm.rzx firegear/FireGear_01.rzx firegear/FireGear_02.rzx firegear/FireGear_03.rzx firegear/FireGear_04.rzx smagly.rzx zunny2.rzx

[1] http://www.spectaculator.com/2008/06/spectaculator-7-0-released/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

windale - 2017-07-05

These RZX's now work correctly since the last update or two :-

Alienstorm
Fire Gear (4 Parts)
Ivan 'Ironman' Stewart's Super Off Road
Shadow of the Unicorn (7 Parts)
Smagly
Street Fighter
Zunny II

Did you say something about also using a different Plus D rom ? Is the one in Spectaculator different to Fuses ? If so, can you let me know what the CRC32 is please ?

I still have to compile a custom build to get rid of the RZX Warning messages :(

Last edit: windale 2017-07-05

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-07-09
  
  These RZX's now work correctly since the last update or two :-
  
  Oh! I see... alienstorm, firegear, smagly and zunny2 need trdos.rom v5.03 with CRC32(c43d717f). The multiface interface is not used in these recordings.
  
  Did you say something about also using a different Plus D rom ? Is the one in Spectaculator different to Fuses ? If so, can you let me know what the CRC32 is please?
  
  Both use the same ROM with CRC32(569f7e55). A few recordings (countabout, countcats, crimequiz and cyborgterminator2) actively use +D interface and have a broken playback. It looks like an unknown error in +D implementation.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

windale - 2017-07-21

A new RZX released today (21st) gives this error :-

libspectrum_rzx_playback: more INs during frame 0 than stored in RZX file (9)

http://www.rzxarchive.co.uk/s/semisis.rzx

As I said, this is a new file so what's missing from FUSE that prompt's this error ? As usual, it works fine on Spectaculator.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-07-22
  
  I don't see any problem with the playback of semesis.rzx. Check you don't have any superfluous interface enabled (or delete fuse.cfg in %USERPROFILE%).
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

windale - 2017-07-22

Deleting the 'fuse.cfg' fixed it. I'm not sure why though because all I change is the Filter. An incompatibility between versions in the fuse.cfg ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-07-22
  
  Deleting the 'fuse.cfg' fixed it. I'm not sure why though because all I change is the Filter. An incompatibility between versions in the fuse.cfg ?
  
  I'm sure there was an interface enabled. When you load a snapshot or a RZX, peripherals are enabled as demand until the end of the session. If you save the settings, the current peripherals are set permanent.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Fredrick Meunier - 2017-07-24
    
    If this happens again it would be great to capture the fuse.cfg with problems so we can figure out what happened - generally loading the snapshot from the RZX should disable any conflicting hardware.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Sergio Baldoví - 2017-07-24
      
      It's easy to reproduce:
      
      Open montana.rzx (+D is enabled)
      
      Open semesis.rzx
      
      The case is peripherals are activated when loading snapshots and rzx files but only deactivated if they are incompatible with the current machine. When you close the application, the configuration saved in the settings file will be restored in the next application start. Saving the settings after loading a file is like a russian roulette, e.g., you want to save a bigger graphics filter but also permanently enable +D interface.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Fredrick Meunier - 2017-07-25
        
        Right - makes sense and relates back to the old discussions of having a more "VM"-like configuration in Fuse rather than configuration-based.
        
        Now we have a stronger definition of peripherals settings vs other settings, we may be able to handle this by resetting all peripherals to be disabled prior to loading a snapshot?
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Fredrick Meunier - 2017-07-27
        
        Maybe something as simple as this (untested) - maybe should be in snapshot_copy_from() instead to apply to all snapshot loading.
        
        rzx_reset_peripherals.patch
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Fredrick Meunier - 2017-07-28
        
        That doesn't work - this one looks more like it. Comments anyone? I'm inclined to think it is a step up over the status quo.
        
        rzx_reset_peripherals_v2.patch
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Sergio Baldoví - 2017-07-28
        
        I agree that we should disable peripherals when loading RZX and snapshot files to run the same machine as stored in file. But minimal snapshots are also used to autostart tapes and disks. In that case disabling peripherals is not recommended, e.g.
        
        fuse -m 48 --melodik
        
        File -> Open -> tape
        
        Is Melodik disabled?
        
        IMO the v2 patch looks good for RZX/snapshots but current code looks good for autostart option. Maybe we should mix both cases?
        
        In [bugs:#328] I tried to fix a related problem but lacked global vision.
        
        Related
        
        Bugs: ~~#328~~
        
        Last edit: Sergio Baldoví 2017-07-28
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Fredrick Meunier - 2017-07-28
        
        Yes, we need something to deal with autoload snapshots. They already don't fit the model so well as the saved state in the snapshot may not incude the proper initialising of all the hardware configured by the user in the current session.
        
        We have discussed having partial snapshots in the past that just contain e.g. RAM contents and CPU state rather than other hardware - maybe another choice these days would be to have autoload RZX files? We would reset the machine, then start RZX playback to start the loading process.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Sergio Baldoví - 2017-07-30
        
        We have discussed having partial snapshots in the past that just contain e.g. RAM contents and CPU state rather than other hardware
        
        I think unused blocks would be set to default values (interface not present) and current settings would be ignored.
        
        maybe another choice these days would be to have autoload RZX files? We would reset the machine, then start RZX playback to start the loading process.
        
        Sorry, I don't understand this idea. A RZX file without an initial snapshot and read inputs to go to the current auto-load position? It would be slightly slower because of ROM initialisation. If perhiperals are not disabled the playback could fail.
        
        I've attached a new patch (under testing) inspired by v1. Peripherals are disabled before opening snapshots and RZX files.
        
        rzx_reset_peripherals_v3.patch
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

A lot of RZX files don't play properly

Group

Searches

Help

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

Discussion

Related

Related

Related

Related

Related