Menu
▾
▴
#22 RZX playback broken
James Banks reports:
"I was watching the Head over Heels RZX file last night and it
stops just before the third crown is collected in Book World. When I
say it stops, the user can start to move the characters around
instead of the automatic playback of the rest of the file. I got the
Head over Heels RZX file from Philip Kendall's web page <http://
www.srcf.ucam.org/~pak21/spectrum/head.html>"
I can confirm this also happens on Fuse for UNIX as well as Mac.
The exact error message is:
libspectrum: libspectrum_rzx_playback_frame: wrong number of
INs in frame 109163: expected 8, got 0
Is this related to the timing improvements in 0.7.0?
Logged In: YES
user_id=29214
Directly, yes. Indirectly, no (Fuse 0.6.2.1 faile before the
marketplace with much the same error, so 0.7.0 is a slight
improvement here, but this is purely fortutious).
The fundamental problem is that the RZX format doesn't fully
store information on retriggered interrupts or interrupts
delayed after an EI. Fuse 0.6.2 significantly changed the
behaviour of Fuse's z80 core with respect to all this, and
so some RZX files recorded before that won't work with Fuse
0.6.2 or later. On the other hand, some RZX files recorded
with other emulators may well work when they didn't with
Fuse 0.6.2 or earlier.
The 0.7.0 timing changes just modify when the rare events of
retriggered or delayed interrupts happen, so affect when we
see this.
What we can do about this in the general case, I don't know...
Logged In: YES
user_id=11017
Am I being naive in thinking that a new revision of the RZX
format could sort this problem out for the future?
Last time RZX playback problems came up on fuse-devel, you
commented about the retriggered and delayed interrupt
heurisitcs:
"This still won't be perfect, as we still have no way of
knowing whether
the recording emulator intended for an interrupt to be
accepted when
writing an RZX frame. Essentially, Fuse currently makes a
best guess,
but this will be wrong for something somewhere... I think
the new code is better than the old code, though."
In that thread there was dicussion about recording more
markers in the file for interrupts and possibly frame ends,
did this get implemented? If not, would these address the
problem here (for a new recording)?
Logged In: YES
user_id=29214
I'd certainly hope that any revisions of the RZX format
solve this problem: I don't think it should be any more than
separating the "end of frame" and "interrupt" events.
But nothing's actually been implemented (or even discussed
AFAIK) on this front recently.
Logged In: YES
user_id=29214
A little bit more research on this one: at the end of frame
19497 (of head5.rzx), the interrupt happens right in the
middle of an EI/RET pair.
Fuse pre-0.7.0 (which the HoH RZX was made with) accepted
interrupts directly after an EI, so jumped to the IM2 ISR
here. Fuse 0.7.0 (correctly) doesn't accept interrupts
immediately after an EI, so doesn't jump to the ISR.
Normally, the interrupt would be accepted after the RET, but
when doing RZX playback, Fuse accepts interrupts only at the
end of an RZX frame, so doesn't jump to the ISR at all,
which unsurprisingly leads to the desync a few frames later.
That's what causing this. How to fix all this, I don't know
at the moment...
Logged In: YES
user_id=11017
As far as a fix goes, the options seem to remain:
1) not using the interrupt retriggering code on rzx playback
to get this particular rzx to play back (though that breaks
playback of Rockfall 2 and similar game recordings made with
current versions of Fuse and Spectaculator < 6), combined
with the Spectaculator-like changing of the recording of
RZXs so that if the last instruction at the end of a frame
is an EI one more instruction is executed before the
interrupt to fix future recordings of games with Rockfall
2-esque problems so they will play on older emulators, or
2) Revving the RZX format to handle end-of-frame vs.
interrupt events explicitly, current recordings with
problems will stay problematic (though we could combine this
with the playback workaround above), new recordings will
just work (to the best of our knowledge).
I am not sure how much feedback there has been about whether
the Spectaculator 6-style recording workarounds have still
got problems in any situations, and remain convinced that 2)
is the best solution for simple specifications, formats and
consistant implementations in the future. As least with 1)
we must have the RZX documents updated to record the
problems and workaround for the future.
In practice there seems to be no consensus to update the
format, and aside from the AMX mouse issue no known problems
with the workarounds on recording RZX approach.
As a result, barring massive new insights, I think the best
we could do would be to add the Spectaculator RZX recording
workarounds, make retriggered interrupts optional
(defaulting off) on playback to allow for Rockfall 2 and
similar recordings to be played back, and see if any
problems arise in the future which we could use to build
support for a new RZX revision.
Thoughts?
Logged In: YES
user_id=29214
Originator: NO
Merging this into #1654105. Please place any further comments there.