Hacker News new | comments | show | ask | jobs | submit login

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.

Has this been the case for you?

Also, 8088mph is super cool; great job on it!

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.


I remember that one, it's 3GHz for perfect emulation of a SNES which had a <25 MHz CPU. https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...

25 MHz is mentioned in the article as a basic requirement of the earliest SNES emulators. The SNES CPU itself clocks in at less than 4.

So it's not the clock speed, but an oscillator at 21.47MHz that I was accidentally citing.

Ah that makes sense - 6x the CPU clock of 3.58something.

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).

You, sir, are a true hacker. Respect.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact