Questions about the Speccy and it's emulation
Out of interest, and to raise another interesting discussion, I have some questions about the Spectrum and it's emulation;
1) Is everything known about the Spectrum (from a technical point of view, not historical or financial or anything like that)? Are all of the correct timings, all of the effects of video contension, all of the possible affects of all Z80 instructions etc known?
2) The XBox (the original, not the 360) actually ran at slightly different speeds, depending on each unit, as Micro$oft bought the memory from different manufacturers, and bought some that had been partially disabled as part of it didn't work (you still got the full 64MB that the XBox needed, but sometimes you got a 128MB stick of memory in there, with a knackered half that the XBox couldn't see. A friend of mine always insisted that Halo ran faster on my XBox than his, but I could never see it, then I read about the memory issue, and I've always assumed that that was what my mate saw (I couldn't see it, but then I'm not too bothered by frame rates). Did the Spectrum ever suffer from issues like this?
3) How does EmuZWin (and maybe other Speccy emulators?) support a "take back" feature? See, in EmuZWin, holding down a certain key makes the game jump backwards successive steps. Does the emulator store snapshots every second or so, or what? I mean, it can't read the Z80 machine code in backwards steps, as many instructions could use one or two or more bytes and the it would be impossible to tell this from just working backwards, right?
4) What games or demos are particularly problematic for Spectrum emulation? I imagine that demos like Overscan, NMI 2 and the second part of the Shock Megademo all test the emulator, as they need such precise timing and border control, but what else? I seem to recall that Elite could be problematic - I think I read it in the Warajevo instructions, but I can't remember why. And wasn't Sabre Wulf hard, as it needed very precise usage of some Flag register flags that weren't well understood?
1) Is everything known about the Spectrum (from a technical point of view, not historical or financial or anything like that)? Are all of the correct timings, all of the effects of video contension, all of the possible affects of all Z80 instructions etc known?
2) The XBox (the original, not the 360) actually ran at slightly different speeds, depending on each unit, as Micro$oft bought the memory from different manufacturers, and bought some that had been partially disabled as part of it didn't work (you still got the full 64MB that the XBox needed, but sometimes you got a 128MB stick of memory in there, with a knackered half that the XBox couldn't see. A friend of mine always insisted that Halo ran faster on my XBox than his, but I could never see it, then I read about the memory issue, and I've always assumed that that was what my mate saw (I couldn't see it, but then I'm not too bothered by frame rates). Did the Spectrum ever suffer from issues like this?
3) How does EmuZWin (and maybe other Speccy emulators?) support a "take back" feature? See, in EmuZWin, holding down a certain key makes the game jump backwards successive steps. Does the emulator store snapshots every second or so, or what? I mean, it can't read the Z80 machine code in backwards steps, as many instructions could use one or two or more bytes and the it would be impossible to tell this from just working backwards, right?
4) What games or demos are particularly problematic for Spectrum emulation? I imagine that demos like Overscan, NMI 2 and the second part of the Shock Megademo all test the emulator, as they need such precise timing and border control, but what else? I seem to recall that Elite could be problematic - I think I read it in the Warajevo instructions, but I can't remember why. And wasn't Sabre Wulf hard, as it needed very precise usage of some Flag register flags that weren't well understood?
Post edited by ewgf on
Comments
So, by XBOX it may be faster with faster RAM if there is some setting of RAM controller speed.
By Spectrum RAM speed depends strictly from ULA and CPU clock speed, so no speed variations except very little caused exactly by slightly diff. crystals in diverse models.
3. Take back - game stores all time last couple seconds in some way. How exactly? Ask authors. For modern PC it is not problem to record all relevant parameters as RAM content, CPU state, border color etc. - let say 5 times per second... By Speccy is not so much to record.
No, but we now know a very great deal about the internals. I'd challenge anyone to write a program that runs differently on the real thing than on say, SpecEMU (and yes, I'm including memory fade in that statement). Other Speccy emulators may have flaws, but they're not generally significant now.
Not from RAM, no. 128k models ran faster than 48k though.
You're right - it takes snapshots. That's all, there's no real trick to it. Any emulator could do this now that we have the .szx format for storage. EmuZWin would not be my first choice of emulator though, even with this feature.
Aside from the more complex russian TRDOS demos (but mostly because of the insane hardware they've added to those machines), I'd be reasonably certain stating that there are no programs now that are problematic. SpecEMU will run more software than any other emulator, in my experience.
D.
Easy. Undocumented flags after SCF/CCF.
I wouldn't ;)
Seemingly impossible to get that right. Results from test code give inconsistent undocumented flags behaviour running the same code on the same (NEC-based) machine multiple times. Given that, I think it would be difficult to tell apart an emulator from a real machine using SCF/CCF as long as the emulator occasionally threw in the odd quirk here and there for now ;)
Oh, so it's not the RAM speed itself, but additional setting(s) too? I'm not saying XBoxes are necessarily faster, mind you, just that I read somewhere that Micro$oft used different (and sometimes semi-knackered) RAM (and I do know for a fact that they did use different DVD drives, so RAM from different manufacturers seems possible), and a mate of mine always said that Halo ran faster on my 1.4 XBox than on his (1.0 I think, maybe 1.1, I can't remember) XBox.
OK, thanks.
I suppose so - copying 48k (or even 128k) of PC RAM into a temporary buffer every second or so, wouldn't tax a half decent PC nowadays, either speed or memory wise. And no doubt the saves would be a continuous loop, so that the oldest gets over-written.
Oh right. Isn't it possible just to perform these operations and record the flags' settings, or am I missing something?
Especially not for games, which is what 99% of Speccy emulation is for (at least in my case).
Oh I know that, though it's something like the CPU is 35.MHz to 3.55MHz, which I'd imagine is negligable (except for messing up the border effects in Starion and Paperboy :x). Is the 128 faster in other ways too, such as the motherboard or RAM access/writing?
EmuZWin is nice, but unstable, sadly.
But what programs proved problematic whilst emulators were evolving?
No, the results differ for the same input data on the real machine.
See the tech wiki details on this.
A few off the top of my head...
- Enduro Racer: undocumented instructions
- Sabre Wulf: undocumented flags
- Aquaplane (also The Sentinel and Starion): precise timings (including contended memory)
- Arkanoid, Cobra, Sidewize: floating bus
After that, throw some demos at your machine, possibly starting with Shock Megademo.Also, didn't some speed loaders/protection methods use undocumented instructions too?
Did multi-channel 48K beeper sound pose a large problem for emulation authors, or was it easy (relatively) provided the host PC was fast enough to handle the timing correctly?
Indeed, this is the "Floating bus" issue mentioned by Phillip.
If a game reads any unnattached port, then it will in practice read the data currently on the ULA bus. Most of the time this will reult in $FF being read in i.e. when the ULA is idle, but sometimes you will get an attribute byte read in, as the ULA works it's way down the screen.
Basically, the affected games are deliberately coded such that they fill the very bottom part of the screen with a known attribute (ATTR) value, and then use an instruction like "IN A,($FF)" in a loop, repeatedly comparing the result to that ATTR value, exiting the loop when only when the value is found.
Since the above instruction is reading a port on which no real hardware is attached, it will read the "floating bus" instead.
The purpose being to synchronise the game with the display, which allows for flicker-free gameplay when you stall execution in the main game loop until the bottom part of the screen is reached by the ULA.
Bat'n'ball games are particularly prone to using this "floating bus" method of screen synchronisation - e.g. Ricochet by Firebird is another one.
The +2A/+3 do not have this floating bus behaviour, and therefore these games just freeze within the "IN A,($FF)" loop on those systems, never reading the ATTR value that would allow exiting from the synchronising loop.
The affected games can usually be patched to get around this though.
So the later releases weren't as flicker-free as the previous versions I assume? Or did they find another way to achieve the same purpose?
Bytes:Chuntey - Spectrum tech blog.
I patched Ricochet for my own use, because I wanted to play it on my then PDA under the Pocket Clive emulator which does not (or did not) emulate the floating bus at the time.
A quick'n'dirty fix was to replace the floating bus code with a halt instruction, which has the crude effect of stalling the main game loop once per frame.
The patched version worked fine, but there was occasionally some flicker introduced when there were a lot of game sprites appearing on the screen IIRC. The game was still playable though.
I don't know exactly how the official Arkanoid re-release was patched as I haven't looked at the code, but I'm guessing that they must've used a more elaborate and precisely timed replacement for the floating bus code in an official retail product?
Yep, quite frequently. The undocumented use of the IX/IY modifying prefixes was particularly popular.
Not really. I mean, from emulation point of view it doesn't make a difference whether the 48k player is multichannel or not. Emulators simply treat the beeper just like a 1bit DAC, regardless of what it is playing.
Patrik
Look out Spud here we come. :D
It would be interesting to see whether they are exploiting the finite speed that the speaker can move, or the reactance of the circuit itself to generate analogue waveforms. Pulse width modulation is a popular way of controlling various things in an analogue way from a purely digital output.
Might have to get one of these beeper demos and probe the speaker output with my oscilloscope to see what they are doing :-)
BTW, the title tune in Starfox always comes to my mind when this is discussed.
...in which case it certainly smells a bit like they were using the effects of the circuit's reactance to generate an analogue value.
Incidentally, as alluded to earlier on pulse width modulation schemes in general, it may be a point of interest that this is how SA-CD is encoded - as one bit digital data. Actually, pulse width modulation is the wrong term - it's pulse density modulation. To cut to the chase, wikipedia has a nice picture on how it works:
Nope......
I made a tidy living (well, I upgraded over 50 of them) upgrading xboxes to 128 megabytes by soldering in 4 additional 100 pin TQFP chips into the 4 empty spaces available on pre issue 6 boards
there is NO difference in performance for any applications other than Linux, and some earlier edition emulators...mame ran KOF and a few other larger games splendidly with 128 meg on board!......Linux was actually useable too!!
the 'speed' story is due to microsofts useage of differing grades of memory....some boxes would use chips that were rated at quicker access rates than the system actually needed......the system was designed to run with the lowest common denominator, i.e. slow chips......faster chips made no difference to performance!!
one upgrade on an xbox you rarely saw was upgrading the standard 733Mhz 'celeron' style processor with a 1.4Gig pentium M .....those things ran HALO and a few other 'well programmed' things much faster!!!
Unlike most games where PAL versions are 50Hz and bordered and NTSC versions are 60Hz and full-screen (apart from the occasional optimised game which was coded to run full speed on PAL systems, Sonic 2 being a notable one), PAL Halo was optimised to be smoother in full screen 50Hz PAL. PAL Halo in 60Hz suffers from a slightly odd framerate and occasional tearing. This is because of how the PAL version was coded, in the way that you can't just throw it into 60Hz mode and have it speed up.
If you don't care about such things, you won't notice, but you can see it if you're one of those types who looks closely enough.