It would definitely be interesting to see. I mean, seeing full motion video on a 5150 with SoundBlaster audio is impressive enough, but I think it would be really cool if there were a way to do something similar on completely stock hardware. I think making the code compatible with newer machines would be pointless however, because even lowly 286s will often have VGA graphics and some sort of an aftermarket sound device.

Another idea I just thought of, what about something that takes advantage of the Tandy 1000's sound and graphics chipsets? I don't think a lot of demos have been done to exploit that, partly because the demoscene is more of a European thing, and Tandys were really only popular in North America.

I don't think Tandy 1000 had DMA for sound either. It basically just has a 3-voice PC speaker I think (a la PCjr)?

HunterZ wrote:

I don't think Tandy 1000 had DMA for sound either. It basically just has a 3-voice PC speaker I think (a la PCjr)?

Yes, although the difference with the PCjr is that the PCjr's PC speaker and SN76489 audio were mutually exclusive. There's a a status register you can write to, to select either PC speaker or SN76489 audio to be routed to the internal speaker.
On Tandy, both are mixed together, so you can do 5-channel audio on a Tandy: the 3 square wave channels and the noise channel from the SN76489, and then an extra channel from the PC speaker. This is especially useful when you use the PC speaker to play digital samples (the SN76489 can be tricked to play digital audio as well, but you sacrifice one of the 3 square wave channels to do so, so the PC speaker is a better trade-off).

Scali wrote:

HunterZ wrote:

I don't think Tandy 1000 had DMA for sound either. It basically just has a 3-voice PC speaker I think (a la PCjr)?

Yes, although the difference with the PCjr is that the PCjr's PC speaker and SN76489 audio were mutually exclusive. There's a a status register you can write to, to select either PC speaker or SN76489 audio to be routed to the internal speaker.

Substitute "external" for internal" and you are correct. The internal speaker only outputs PC speaker audio. However, you can have the internal speaker play PC Speaker and the external speaker play SN76496 audio at the same time, Thexder does this when run on a PCjr.

8088 MPH was nominated for two Meteorik awards, in the categories "Best low-end demo" and "That's not possible on this platform!".
Last Friday, we won the Meteorik award for "That's not possible on this platform!": https://2016.meteoriks.org/winners#nominees-3

^ kudos!

Congratulations! 8088MPH deserves it.

I wholeheartedly agree! You guys deserve this, 8088MPH is simply put amazing. I totally lost my shit when I first saw it (just take a look at my reaction on the first post 🤣).

Maybe nice to report that almost all of 8088 MPH is now working on x86EMU(Last commit, not released yet). Also thanks to Reenigne and Scali for helping out fixing the bugs in my CGA emulation!

This is a video made two days ago(recent commits only fixes the blank screens inserted during parts that isn't the Kefrens Bar effect and the issues with the IBM PC XT BIOS(First revision)):
https://youtu.be/Dzdp7q05gr8

The only things that don't work fully are the Kefrens Bar effect(too fast, but visible) and the credits tune being just a little bit deformed(very little bit, mostly a bit of noise added and a very little bit(slightly) higher tunes), because it currently uses 8 cycles/instruction(80(1)86 emulation) or 9 cycles/instruction(80(1)88 emulation). The recordings have been made with the 8086 as far as I can remember.

The rest of the demo runs without errors. Check my Youtube channel for the last version recorded(just a few minor improvements in the latest commit, just fixed flashing of black screens, except for the Kefrens Bars effect). I only still need to make it cycle accurate to fix those timing issues and run the entire 8088 MPH without errors.

Also, since the Youtube video screen is resized to CGA monitor resolution(Using the emulator's new Force CGA aspect ratio option(Just like it's current release's Force 4:3 mode), the demo laggs a bit due to resizing each frame(which is practically the most CPU hungry part of the emulation. The CPU can even slow down to ~50% speed during the parts with many screen updates(Kefrens Bars effect especially)).
If I can optimize that away, it'll run at normal speed(Still taked at least ~50us to resize a VGA frame on a 333 MHz PSP CPU(Don't know about the Windows build exactly), so atm still too heavy for the PSP to run(The whole app has been too heavy in it's current state with the PSP build since I moved to Windows to ease development)).

I recently took out my CBM PC-I to check how 8088 mph runs on it, here are the results:
Captured with Bt878 based card: https://www.youtube.com/watch?v=4hfojBF-1Uk
Captured with DVI2PCIe card: https://www.youtube.com/watch?v=vAyxsk23pMY

Problems:
-Colors are a bit off
-Some flicker in the plasma part
-Kefrens Bars part skips itself
-Hangs on final part

The chipset is Paradise PVC2.

elianda wrote:

I recently took out my CBM PC-I to check how 8088 mph runs on it, here are the results:
Captured with Bt878 based card: https://www.youtube.com/watch?v=4hfojBF-1Uk
Captured with DVI2PCIe card: https://www.youtube.com/watch?v=vAyxsk23pMY

That looks very similar to my PC20-III (which has a PVC4, I believe).
However, I believe mine does not have colorburst in 80-column mode (or was that just the ATi Small Wonder?).
Note also how your BIOS font is different from the IBM one, my PC10-III has that same font. I believe that this is because Commodore uses a Phoenix BIOS, which has its own font, rather than copying the IBM one.

I am surprised to see that the 1024-colour effects actually come out that well. The colours are off a bit, but only in hue, it seems. That is, the gradients are still gradients, so transitions in colours are still okay. If you run old CGA graphics on new CGA cards, or vice-versa, you see discontinuities in the gradients, because they are just different. It's interesting to see that this card pretty much matches the new CGA in that sense.

elianda wrote:

-Some flicker in the plasma part

Yes, that looks weird, I wonder if it has to do with the blink attribute.

elianda wrote:

-Kefrens Bars part skips itself

It looks like your system has only 512K of memory. That is not enough for the Kefrens part, which is why it skips.
With 640k it would likely have worked.

elianda wrote:

-Hangs on final part

This again is exactly like my PC20-III. I tried running the demo with a real IBM CGA card installed, and that didn't fix the problem.
The PC20-III uses an integrated Faraday FE2010 chipset, which appears to have some slightly different timings, which results in the freeze.
I tried a custom build of the endpart, where only the music plays, and the screen is not updated, and that version works. So the screen updates seem to throw off the timing in some way, even with a real IBM CGA card.

Scali wrote:

This again is exactly like my PC20-III. I tried running the demo with a real IBM CGA card installed, and that didn't fix the pro […]
Show full quote

elianda wrote:

-Hangs on final part

This again is exactly like my PC20-III. I tried running the demo with a real IBM CGA card installed, and that didn't fix the problem.
The PC20-III uses an integrated Faraday FE2010 chipset, which appears to have some slightly different timings, which results in the freeze.
I tried a custom build of the endpart, where only the music plays, and the screen is not updated, and that version works. So the screen updates seem to throw off the timing in some way, even with a real IBM CGA card.

That's surprising to me. The screen updates aren't doing anything particularly strange (just writing to VRAM and updating the start address register, same as the sprite part). When you made the custom build, did you by any chance have the string "DOSBOX EQU 1" at the top of mod.asm? The thing in the credits that usually causes it to hang at the start is the dependence on the prefetch queue behaviour (modifying a value in RAM that should already have been prefetched, and then assuming that the old value will get used). The EQU statement gets rid of that assumption, but reduces the accuracy of the timing slightly.

If it really is the screen updates then the most likely explanation is that the machine is getting confused by accesses to the second copy of VRAM at addresses 0xbc000-0xbffff.

reenigne wrote:

When you made the custom build, did you by any chance have the string "DOSBOX EQU 1" at the top of mod.asm?

I'm quite sure I didn't, because I rebuilt it a few times, to try and pinpoint the problem (and was aware of that setting). And most variations caused the hang.
Also, I think I'd notice the music playing slower. The music was spot-on.

reenigne wrote:

If it really is the screen updates then the most likely explanation is that the machine is getting confused by accesses to the second copy of VRAM at addresses 0xbc000-0xbffff.

Hum... that may have something to do with it. The card is a 64K version (Plantronics-compatible), so perhaps it does something different.
Then again, when I used a real IBM CGA card, it still didn't work. And the onboard video should have been disabled then (or at least switched to MDA/Hercules-compatible mode, so it won't interfere. Not entirely sure how I solved that one at the time), so it should not have had any effect at all.

Scali wrote:

elianda wrote:

-Some flicker in the plasma part

Yes, that looks weird, I wonder if it has to do with the blink attribute.

Probably not, since it seems to depend on placement rather than color (the blink attribute would manifest itself in the 1024c screens, too).

I also see a slight 'stutter' in the animation throughout the demo - not a capture issue I think, since it actually seems to be slowing things down over time. It's more apparent in some sections than in others (moire, 3D "IBM" sprites, polygon part)... wonder what's going on there.

Hi guys!

First of all, thanks elianda for the captures! I wasn't too sure if it's my PC-I that produces the off-colours or if it is my LCD TV. CRTs with NTSC mode are impossible to find in Europe.

I can confirm that the Kefren bars work on a PC-I with 640k. However, the background raster bars look like they all jump a few lines up after about 3/4 of the screen (so on the right side). Since this happens consistently across all the lines down to the bottom I suspect that it's also a weird timing problem.

The plasma bar flickers exactly like in the video. @scali: Does it occur on the PC 20-III? You considered it strange, so I guess not. It could be a difference in behaviour of the PVC4 vs the PVC2 of the PC-I.

Also, the stuttering in the videos are a result of the capturing, the demo works fluently on the PC-I, until it hangs itself at the beginning of the final part.

I've noticed a few other peculiarities on my machine during repeated showings of 8088mph. One time it didn't show part with the DeLorean floating in front of the scrolling facade, and the music in the 3D part sometimes fails at a predictable point a couple of seconds into the pyramid rotation, though the demo itself does go on until the hang up of the final part. I'm beginning to suspect the PC-I's PSU showing its age, though I don't know for certain.

Well, one thing that may cause a problem is that some parts can be skipped by pressing a key. The sprite part is one of them iirc, as is the moire effect and the polygons (but only after the pyramid is shown, because during that part it does some other stuff in the background, and does not enter the 'mainloop' that checks for keyboard until after that).
So it could happen that if you press a key somewhere, a certain part of the demo gets skipped, but it may be much later in the demo, because it could be that your key remains in the buffer for a long time until you reach a part that checks the keyboard.

So be sure not to touch the keyboard once the demo starts.
It's been a while since I've run the demo on my PC20-III. I will have to hook it up again sometime, and do a capture, see what happens.

Ah, yes. That could very well have been the problem as this happened in the chaotic showing at the local Commodore meeting. 😁
Sitting in peace alone at home, I'd lean backwards in my chair and enjoy a demo with a bit of distance between the keyboard and myself.

I've improved my emulation again:
https://www.youtube.com/watch?v=8aOhDyys2NY (A little recording of my current build(still unreleased) with pretty accurate 8088 CPU running 8088 MPH)

For the first time (it finally works correctly!) recorded using the XBox game app without needing to use external software to record it. This means no more trailing audio from now on 😀.

It now runs 8088 MPH with only lagg during the Kefrens Bars. I had to open the pause menu sometimes to make it synchronize the clock with realtime in order to not make it speed up ridiculously at some points, trying to get realtime by running at maximum speed(although the application doesn't notice this, since it's synchronized itself to that clock. The user does, however, notice it running ridiculously fast:( ).

It's not far off 😀
One thing I notice during the roll-down of the title-screen and the sprite-part is that your PIT is not synchronized to the CRTC properly.
When the title screen rolls down, we set the title-screen part to a bright palette, while the text-part of the screen is a darker palette (to get the gray text instead of white). In your video I can see the bright and dark floating over the screen as a 'bar', because it is not synchronized with the roll-down animation.

The sprite-part uses a similar approach of reading the PIT to figure out where it is on the screen, and when to redraw the sprite, to avoid flicker. In your video, the sprite flickers, because apparently the values that are read from the PIT do not correspond with the position on screen, like they do on real hardware.

Well, both are in fact 'synchronized' with the CPU:
- First, the CPU executes an instruction, which increases a time variable(double variable counting nanoseconds passed when executing the instruction. This value is based on the cycles spent by the CPU multiplied by the duration of a cycle(in this case 1000000000/4.77million(exact number is a floating point division to be accurate, so NTSC(About 14) divided by 3.0). This increase in time is used to increment the time in all other hardware(and keep them in sync).
- The (S)VGA/CGA/MDA(CGA/MDA are extensions like ET3000/ET4000 (just like in Dosbox, modifying behaviour of the basic VGA/CRT emulation)) which redirect and/or modify values written to CGA Mode Control/Palette and CRTC registers, mapping them to VGA-compatible values, as well as modifying the render clock to CGA frequency(Which also is the NTSC signal undivided). The VGA emulation uses the time given by the CPU spent to increase it's counters and draw as many pixels and/or updates the CRTC virtual beam to new locations(pixel increase, vretrace, hretrace for the GPU, which resizes the frame rendered to the SDL display, based on emulator settings) for the time that has passed, to get up-to-date.
- The PIT essentially does the same as the VGA for it's timing, but it runs on a different frequency(quarter of the CPU frequency), it also renders audio (PC speaker), bases on a 44.1 kHz clock, double buffered.

PIT: https://bitbucket.org/superfury/x86emu/src/bc … pit.c?at=master
Sequencer: https://bitbucket.org/superfury/x86emu/src/bc … cer.c?at=master
CGA/MDA: https://bitbucket.org/superfury/x86emu/src/bc … mda.c?at=master
VGA core/timing: https://bitbucket.org/superfury/x86emu/src/bc … vga.c?at=master
Core of the emulator, combining all functionality: https://bitbucket.org/superfury/x86emu/src/bc … ore.c?at=master

So, essentially, all timing is based on the CPU cycles spent each instruction/HLT state. Or is there an error in the timing somewhere?