I'm one of the creators of this demo. For the past several months I've been working on a cycle-exact 8088 emulator (that will eventually be able to run 8088 MPH properly). I don't have it hooked up to any audio or video output yet, but for the first time last night it ran automatically-generated testcases all night without finding any differences from the real hardware.
I remember reading a writeup a few years ago from the guy who made BSNES, and him mentioning to get cycle exactness requires a crazy amount more CPU power than getting "cycle-good-enough-for-99%-of-things", and that he had to do some elaborate cooperative threading to get decent performance.
My current emulator is quite a lot slower than other 8088 emulators, but still quicker than real-time - it gets about 12.9MHz on a 2.67GHz Core i7 920. There are probably quite a few more things that could be done to optimize it.
My "cooperative threading" consists of just having a "wait(n)" function which is called from the CPU Execution Unit emulator to emulate everything else for n cycles (i.e. the CPU Bus Interface Unit, the bus itself and everything else connected to it including the DMA controller and interrupt controller). That wait() function is the major bottleneck according to profiling, so if I modify it to do as little as possible (most of the time do very little other than increment a counter and compare to the top item in a priority queue) that would probably help a lot.
When I was writing a cycle-accurate 6502 emulation, I ported the transistor-level 6502 emulation to Go (which is what I wrote my emulator in), and then ran that and my emulation over the same test suites, checking that every load and store matched up exactly. Very useful.
It's too bad there is no transistor-level model of the 8088 yet (at least a publicly available one). There have been some detailed die shots of the 8088 but only of the top layer, which misses out about half of the data in the microcode ROM and probably a lot more besides. So I've been having to rely on running the testsuite on a real IBM 5160, which is pretty slow. I'm saving the results into a database which as of now is up to about 313MB. That allows me to test changes to the emulator much more quickly (at least on the tests that have already run on the hardware).
It’s a cycle-counting effect, as there is simply no time to monitor for horizontal retrace. To ensure the cycle counting was consistent, several things were done including changing the system default DRAM refresh from it’s default interval of 18 to 19, to get the DRAM refresh periods to line up with CRTC accesses.
When I ran across this a couple years ago, I transferred this to the IBM PC (which was my first computer) over a serial cable (I still have Telix installed) from a Windows XP desktop since it also had a serial port, and use Hyperterminal to transmit the file. And in order to get it to that computer I had to put it on a USB drive.
It was pretty cool seeing it run. That PC was what I used from 1987-1993 and it was mostly obsolete during that time but I tried to get everything I could out of it. There was nothing that approached what this demo was able to do graphically. (There were a lot of cool music programs even for the PC speaker back then though.) Although, I get a memory parity error partway through the demo because I don't have the full 640k due to some bad memory chips on the memory expansion card.
It helps that they designed it for composite output, since I no longer have a CGA monitor, but you can still hook it up to TVs.
I had to transfer it to a win2k machine via network, then wrote a serial transfer program in gwbasic and visual basic 6.
I don't have a CGA but some ati clone (forgot name, it can emulate a bunch of modes including hercules), so I couldn't get colors to work in their new 1k mode. The color burst was either not recognized at all or the picture wasn't stable. But that might have been an issue with the modern TV, or both.
Most effects worked really well with that card surprisingly. Kefrens bars started halfway through the screen for some reason but otherwise were fine too.
This link is amazing. The explanation of which characters are used, and the process they used to get to the 1024 colors, is fantastic. Thank you for sharing this!
About the sound, I remember playing an mp3 through PC speaker on a 386 computer, as well as having a special config for wolf3D that made it play its soundblaster sound effects through the PC speaker, so its single voice square wave can produce arbitrary sound.
Does anybody know and has time to explain why emulators cannot play this demo? I always assumed emulators recreated the hardware in software, so why won't they be able to do something the hardware could?
In theory emulators recreate the hardware in software. In practice, emulators approximate the hardware in software.
In the case of PCs, there is so much hardware variation, that it was never a requirement to be very accurate in terms of speed, unlike machines such as the C64, Amiga, Atari ST, NES and various other machines, where many tricks found in games and demos depend on manipulating specific hardware registers in very specific timeframes.
This demo has various effects that depend on the exact speed of the CPU and hardware. No PC emulator is anywhere near that accurate, leading to effects not working correctly, or just hanging altogether (eg the end-tune depends on instructions being in the prefetch-buffer at a specific time).
Another issue was the 1k colour effect, which exploits the way the NTSC signal is generated. Most emulators didn't emulate NTSC composite very accurately (just treating it as a 16-colour mode).
The timing in this demo is so critical, that even most clones with an 8088 at 4.77 MHz and a CGA-compatible clone card do not play the demo correctly.
OpenEmulator, a little-known emulator for the Apple II, has an absolutely fantastic NTSC emulation, done with GPU shaders. I'm in the process of porting it to WebGL, so that (a) I and others can actually understand it, and (b) so that others can use it.
Edit: very interestingly, if I copy/paste your exact question on Google, it gives me the Ars link as a first result (in incognito mode). I don't think my comment had any influence (too short time to update the index), Google is truly magical.
"emulators recreate hardware software" gets good results. The rest of the query is fluff. Adding "cannot" makes the results even better, which is magical.
