Hi!
Over the last year and a half or so, I've been working on a series of patches to
SheepShaver to allow TASing games for the classic MacOS. The patches are all
available on my github and provide, in short:
- Deterministic playback
- Input recording, re-recording, and replay
- Frame advance
- Savestates (mostly)
- Audio/video export via libav
This work was all intended to allow me to make a TAS of one of my favorite computer games as a kid:
Ferazel's Wand. With the patches applied, I was able to record some videos which I've posted to youtube:
https://www.youtube.com/playlist?list=PL-Qewl8D5Gq2OUVK-C4foXiwhMfRM1eTZ
These are mostly just a proof-of-concept, and there's a lot I know I need to improve on or completely redo in those videos. (That said, I am definitely interested in any feedback on the gameplay in these videos, so I can keep things in mind for the future.)
However, to get this up on TASVideos at all, there's a few obstacles, which is why I'm posting in the forums.
First, the most obvious thing is that SheepShaver is not an accepted emulator. I'd like to get it accepted! From looking over the
emulator requirements and
desired features, here's how SheepShaver stacks up:
Movie files/authenticity
Movies are (for now; this can change if necessary) stored in a format of my own devising. They can be saved and replayed without issue. Movies always start from power-on; starting from a savestate or loading a savestate is not possible. Movies
mostly only contain input; the only exception to that is that there is an instruction in the movie format for "dump the JIT cache", for reasons I'll explain later. There's (currently) no length on a movie other than "time of last input", but I can add that if necessary.
Re-recording
I've tested this extensively in my own usage, and I've only rarely gotten desyncs. It is possible to get random desyncs in some circumstances, but it is quite rare. Unfortunately, I haven't been able to discover the cause of this yet.
Emulation stability
Movie files are portable and extensible, and at this point I don't think I'll have any issues maintaining backward-compatibility.
Other movie information
Not added yet, but trivial to do so.
Accessibility
All the source is
available on my github. Right now, I've been doing all of my development only on linux, because SheepShaver has some interesting issues compiling for 64-bit and/or newer-than-10.6 OS X. I don't have a windows box around to test on, and I don't have very much familiarity with programming for a windows environment, but if necessary I can try to find someone to help me out here.
Possible to make AVI
Export is done with libav, and writes out a huge AVI. It's trivial to transcode after export, but I haven't looked much into doing the transcoding at export time.
Emulation quality
I saved this for last because it's kind of tricky.
SheepShaver does do some patching of the system files and ROM. This is one of the areas of the codebase that I'm not particularly familiar with, though. I don't know what is considered standard or acceptable here overall, though.
I think what it might come down to is that I don't think it would ever be possible to replay a movie file on real hardware, not because of the aforementioned patching, but because of the nature of the emulation. To be able to have precise, deterministic input replay, the emulator has to execute everything triggered by the 60Hz interrupt,
and then execute some more instructions. The "execute some more instructions" bit is the tricky part; because this is emulating a whole general-purpose OS
and a game, and not just a game intended to run directly on the hardware, it's much more difficult to determine "is the program just waiting for the next interrupt now?" The way I've solved this is just by simply limiting the number of cycles executed post-interrupt. The final nail in the coffin, as it were, is that this isn't a true "CPU cycles" count, but because SheepShaver has a JIT, it's effectively the number of JIT-translated blocks that have been jumped to.
Getting back to what I said earlier about the JIT cache: the JIT will as-needed translate PPC instructions to x86 and then execute the x86 parts directly. As an optimization, the translated blocks are kept around so that they can be re-used when appropriate. However, this causes a problem with savestates. If block A has a one-time jump to block B, and block B has a one-time jump back to block A, that can be executed as one 'cycle',
but only if both blocks are already translated. Otherwise, if block B is not already translated, this will be counted as multiple 'cycles',
but only the first time. What this means is: if you've play along, translate block A, record a savestate, translate block B, and then load the savestate, the JIT could be in a different state, and the 'cycle count' will be off. This was causing desyncs until I figured it out, and my solution-at-the-time-that-actually-seems-to-work-okay is to dump the JIT cache immediately after reading or writing a savestate.
Anyway, that's all about SheepShaver. Even if the emulator itself is accepted, there's a few other obstacles to getting a Ferazel's Wand video up on TASVideos. There's four things that someone would need in order to verify the movie:
- The movie file itself, naturally
- A New World ROM, which is (as far as I know) not able to be legally distributed
- A copy of MacOS 9.0.4, which Apple (for whatever reason) still cares about, and as such is not able to be legally distributed
- A copy of Ferazel's Wand, which Ambrosia Software is still selling (but only on CD-ROM), and as such is not able to be legally distributed
The latter three things on this list I all have, but couldn't give out. In this case, I'm not really sure what I can do. Working from a MacOS 9.0.4 installer CD image and the Ferazel's Wand CD image, I could make movies to prepare a hard drive, install the OS, and install the game, but this still requires files that I can't give out. I certainly could record the hash sums of the files that I have, but I don't know if there's any guarantee anyone else would get the same values with their own physical copies.
I hope that these are all surmountable issues. But, since I haven't been able to come up with a solution myself, I hope that the collective wisdom of the forum will be able to help.
Thank you for your time and consideration!
