RZX for Sabre Wulf
I was just about to send an RZX for Sabre Wulf to the RZX Archive when I noticed they don't accept Ultimate's (and other companies' who haven't given permission) files. Why's that? Does the RZX contain a complete snapshot? I thought it would only log port I/O, maybe together with some additional stuff like T-states.
Post edited by J?rg Pleumann on
Comments
_________________
Dr Jones will never believe this
[ This Message was edited by: Alessandro Grussu on 2004-10-04 17:33 ]
Not correct, but irrelevant here. There's a huge difference between those companies which haven't given permission (most of them) and the few who have actively asked for their games not to be distributed.
You're basically right: All RZX logs is every port read and when interrupts occur.
However, without a snapshot to seed the Spectrum's state, this information is completely useless. This can either be embedded in the RZX file or supplied separately, but it's still needed.
[ This Message was edited by: Philip Kendall on 2004-10-04 17:39 ]
Still, maybe AIR format could be used for denied games...?
[ This Message was edited by: Ed on 2004-10-04 17:43 ]
Not really true: it's perfectly possible to produce an RZX file without an embedded snapshot (in Fuse, see Options/RZX/Always embed snapshot). This is useful for things like the Speccy Tour, where the people validating the recording will want to start with their known snapshot, rather than whatever you decided to embed in there.
So RZX files don't support usage with an external snapshot file or simply a running emulator session at all? No trick or "hidden option" to do this? Does Spectaculator (which I'm using) support AIR files?
Anyway, I wouldn't have expected RZX recording to be tied so closely to the core eumulation stuff. Really thought it would just log the I/O.
Sad. Does that really mean I have to put an MPEG on my homepage to give the world a chance to acknowledge my victory? :)
Ah! Wasn't aware of that. Thanks, Phil.
You appear not to understand the RZX format: it contains all port reads done by the Spectrum during the recording, and hence stores all the "keystrokes, etc." necessary to finish the game.
Only if they had exactly the same snapshot as was used to make the recording in the first place.
Basically, no. This may come as a shock to some people, but we (the designers of the RZX format) did actually think about this kind of thing, and there is simply no way round it.
Ok. I see the tristate logic involved here. :) My post was inaccurate, but I think I was able to make my point.
Which emulators do actually support this feature? Didn't find anything in Spectaculators options. Is there an external tool that allows me to mess around with an RZX file?
While I think about it, it must be rather tricky to get a standalone RZX in sync with a running program that is not in the same state that the RZX recording started in. Restoring register and system variable values might be a first step into the right direction, but I suppose you'll end up with saving the whole memory contents - so you'd have a snapshot again.
Ok. That still leaves the MPEG option open...
No. The designers of the AIR format thought it was a good idea to keep the details of the format closed, so it can't be used in any emulators other than RealSpectrum.
Wasn't that a bright idea?
It does just log the I/O...
Precisely the problem :)
Yes. See rzxtool from the Fuse utilities.
I have a nice Sabre Wulf RZX, done by Dunny, it's a couple of years old now. Shame I can't release it on the archive. The same goes for my Knight Lore RZX, completed on one life, and the Atic Atac RZX completed in 4mins 56 sec.
Daren
I can understand the timing, thing, state of a snap`d game being different, as on a lot of games say, even on the main menu, it flicks between Title, credits etc ... and a kepress might or might not bring you STRAIGHT away to the Title page or Start the game, if say it`s on a credits or score screen...
I think I have however, one Rzx, that asks for the game snapshot with which it was created, it`s from the last month on Rzx archive... although the game was also supplied (I forget which it was)..
However, even with the problems you are mentioning, what if, as opposed to loading an Rzx (and it then asking for the Snap, and continue with playback straight away) -
What if, you loaded a snapshot of a game that let`s you define key`s... since the game is the same whereever snapshotted, once you are in the define key`s bit of code... and it`s waiting for keypressed to be made... that is a known loop/bit of code/ state
So couldn`t the person start recording without saveing the game, from the point of waiting for redefined keys, and then the person loads up their game, presses a key to redefine, and at this point is able to either start playing back/ or load and start playing an Rzx..
Obviously, this is one example, with redefinable games, but even on a game that swaps Title screen / Credits page... if the Rzx-er recorded from the point at which the Title Screen just popped back up, and the replayer, loaded their snapshot, and started playing back `said` recording...
I hope Im reading the situation correctly :)
I hate to thin of never having replays for all the dizzy games, for Professional Ski Simulator etc etc
Extremely unlikely to work - RZX records frame by frame info on port reads, and the number of port reads in that frame. If your timing was off by *any* amount, then the error would accumulate until (about a second later) you completely screwed up the port reads and at least buggered up the define keys loop... And at worst, completely crashed the game.
Getting an RZX to play back accurately absolutely demands the exact same snap, the same as AIR files do. And believe me, it's been tried and tried to break this necessity, but can't be done.
At least, not if you want to be able to play back on any other emulator than the one you recorded on.
D.
I'm not quite sure it's impossible; see here for one way I think it might be doable. On the other hand, I wouldn't exactly call that a practical suggestion.
I do feel an RZX FAQ coming on though, as people seem to come up with a brilliant "new" idea of how to get round this problem about once a month (and generally it's exactly the same idea as the last time...)
[ This Message was edited by: Philip Kendall on 2004-10-04 23:19 ]
Sounds similar to something that came into my mind yesterday while thinking about a possible solution:
(1) Reference an external snapshot. Use an MD5 hash over memory contents to identify that snapshot properly, but give the user a chance to use a different one (after a warning).
(2) In the RZX file save:
- Processor state (registers and stuff)
- T-state counter
- A byte-wise DIFF between the original
snapshot and the current memory
contents, maybe together with some
bytes of context (like RCS/CVS do).
This should allow to reconstruct the full machine state given that the original snapshot is available. I can imagine that it will also work in a significant number of cases where the snapshot is not 100% identical. The implicit assumtion made is that there are mainly two kinds of changes taking place in main memory:
(1) Changes in game state (number of lives, positions etc.). This should be only minor changes in most cases. They will also be overridden anyway once a new game is started.
(2) Screen content.
My guess would be that the mechanism should work rather reliably when a clever point is chosen for taking the snapshot. The end of a loading screen that waits for a keypress should be good. A main menu should also be good. Maybe it's a good idea to include screen content in all cases. Don't know when copyright violation starts, though (just what you stated).
I don't think there's a necessity for checking the snapshot against a number of loads of the same game (as you proposed). Seems to make things more complicated than they need to be.
PS: Now isn't that a *really* *brilliant* *new* *idea* to get round this problem? Can I repost it next month? :)
Mind you, I could never have come up with the original RZX spec, there's finer minds than mine on the job.
D.
Well, it only has to work for a very small number of games -- those the publishers of which don't allow distribution for. :)
Since I can start recording of an RZX at any time, I'd rather expect RZX to take a snapshot, say, S1 at the moment the recording is started. Depending on how long the game has been in use, there will be a difference DELTA between the current machine state and the state immediately after the game has been loaded from a snapshot S0.
It should be possible to reconstruct S1 given DELTA and a snapshot that is either exactly S0 or relatively close to S0. If all registers etc. are restored to the value they had in S1, I see no reason why the INs read from the RZX should differ from the expected ones. The same code is being executed.
Or am I being overly optimistic? :)
As an alternative, wouldn't it be possible (and maybe even easier in this case) to "ground" an RZX file with a TZX file? Since we have the notion of a "perfect TZX image" we could just relate to that and have the RZX file replayed after the last block has been loaded (abstracting for a moment from multi-level games and special loaders).
What exactly is the pRNG seed? The seed used for the random function? Isn't that simply one of the system variables (if a machine code game actually uses the ROM function for getting pseudo-random numbers)? If so, it would be covered by the DIFF, I think.
A "perfect TZX" based system could, possibly, replace the snapshot. All you'd need is a "start" state which is a predefined Snapshot of a Spectrum just after having type LOAD "" ENTER. The emulator would then use that + the TZX to load into a known state, at which point the standard RZX cuts in.
Obviously there'd be a few technical issues to iron out but it ought to be possible. Ultimately though, I think it's more trouble than it is worth.
Which they won't as the ROM code is horribly slow. They'll use some method of their own, with the seed stored "somewhere".
I'm not sure you will end up in a known state after that. You've got the whole issue of contended IO timings to deal with, which are much less researched and emulated than contended memory timings.
And a pain in the bum to call, besides...
I always used to use a copy of the ROM routine, hacked to make it easy to call, until I devised my own version of the routine which uses the same algorithm as the ROM routine but is integer-only and hence about 5x faster.? Some people here may remember my posting this to css about 5 years ago...
misteaksmistrakesmisyaleserrurs— oh, sod it.D.