Breaking news! Or actually non-breaking news!
Just now I have managed to run 8088 MPH in an emulator for the first time, with all effects showing, and giving a reasonably accurate rendition of real hardware. The emulator is 86Box, and I have created a simple ZIP file here for you to try it. Everything should be pre-configured. Just wait for DOS to boot (can take a while), enter the date and time. Then type:
b: <enter>
8088mph <enter>
And you should be good to go. It’s not entirely perfect, the timing seems to go up and down a bit, the cycle-exact end-tune seems to play too fast. But it’s the best I’ve seen by far, and a lot better than nothing.
Scali's OpenBlog™ 
Lovely. Thanks for putting this together. I have just gotten a Tandy 1000HX and expanded it (am expanding it) and am having fun with its CGA composite out. I wish it would run this demo, but I am told that it will not.
I think it probably will, when you switch it to 4.77 MHz mode (with ALT-S I believe).
Bisqwit recorded this from his Tandy 1000: https://www.youtube.com/watch?v=rAUM89Xu7jo
Huh. I’d been told it would absolutely not run on anything other than an IBM brand official CGA card, old or new. Interesting. I’ll see if I can write out the .360 image to my 720K drive (with dskimage). Thanks. Will report back.
That certainly isn’t true. Clone cards tend to have wrong colours, and most of them seem to have slight timing issues, which you can mainly see in the Kefrens part, but other than that, the demo generally runs fine. Here’s a capture from a Commodore clone with a Paradise CGA card for example: https://youtu.be/4hfojBF-1Uk
And this is a Compaq clone: https://youtu.be/TB8zvzpMiFY
Also, you don’t need to use a disk image. Just a standard bootable DOS disk, and copying the files, will do the trick (you can also run the demo from HDD that way).
Sadly, it didn’t work. In slow mode it said I was 4% off timing from their test timing loop and running the program could destroy my CRT… I ran it and some of it looked colorful in composite, but not most. (In fast mode I was 29% off sync or so.) Tried a few times. Using Tandy’s MODE SLOW command to drop down to 4.77. It is an 8088-2 CPU. Unlike the 8088, the 8088-2 is fabricated using Intel’s nMOS tech called HMOS. Perhaps that makes things faster at even 4.77 mode? Ah well.
It is highly unlikely for any software to destroy a colour CRT. There is a real problem with (cheap/poorly designed, such as IBM’s) MDA/Hercules monitors. Namely, they take their sync signals directly from the video card. If you get these signals too far wrong, you can overload the flyback transformer, and it will burn out.
However, more high-end monitors have their own sync circuit, which they merely calibrate to the signal from the video card. I have an MDA/Hercules monitor that was designed like that (built by Philips), and it is physically impossible to destroy it with software, because the monitor circuit itself makes sure that the flyback transformer always works within a safe/sensible range.
As far as I know, all colour monitors are designed like this, at the very least the composite ones are, because for TVs it’s pretty much a requirement: they take their sync signals from the antenna input, and you can’t well have your TV burn out every time the signal drops out. And a composite NTSC monitor is basically a TV without the tuner part. In short, I wouldn’t worry about a (composite) CRT being destroyed by our demo.
There is only one effect that is even ‘risky’ in that sense in the first place: the Kefrens bars. It relies on some cycle-exact code to toggle CRTC registers at every other scanline. If the CPU timing is wrong, the scanlines may get triggered too soon or too late, leading to an image that is too short or too long. Still the horizontal sync should remain in tact (as that is governed by the CRTC’s internal counters), and that’s the ‘dangerous’ one for the flyback transformer.
All other effects in the demo either do not modify the timing of the CRTC at all, or perform polling of the CRTC status to ensure proper timing, regardless of CPU speed (which explains why the Kefrens bars effect was by far the most difficult for emulators to get right).
Also, the fabrication technology doesn’t matter. There is only one 8088-architecture, and the later fabrication technology merely makes higher clockspeeds possible. Any timing discrepancies will be caused by the design of the peripheral chips, video circuit and such (as I wrote in another blog, I have a Philips clone which can run the demo 100% when I use the IBM CGA card in it, but not with its ATi Small Wonder card… and when I stick that ATi Small Wonder in my IBM 5160, it doesn’t display the Kefrens bars effect properly either, because its timing is different from a real CGA card).
Interesting. I was not worried about killing my CRT, but I was unaware of the risk with MDA screens you describe. If I had a mono screen attached to my 1000HX, as the person in the Tandy 1000 video you posted earlier does, it would look just like his run of the demo — in greyscale it would seem fine. I wonder if he has proper composite color out were he to try it on that 1000. I somehow doubt it.
I was unaware you were part of the crew that put this demo together, as it sounds you were. Impressive to say the least. I’ve been a fan of the demoscene since I got my A2000 in 1989 and have several of my current retro machines 90% for scenedemos.
Thanks, yes I did a number of blogs on the demo shortly after release. My main contributions were the sprite part and the polygon part.
Hey, Scali, I just wanted to let you know that 86Box runs 8088MPH completely flawlessly now, AFAIK. The test routine at the beginning doesn’t show ANY timing differences! The 8086/8088 code was rewritten based on reenigne’s findings for his emulator XTCE, though there was some bugfixing needed :p. I hope that one day, someone might be able to break 86Box again, and when that day comes, you bet your ass we’ll try to fix it!
Pingback: MartyPC: PC emulation done right | Scali's OpenBlog™