Just read https://scalibq.wordpress.com/2015/04/19/8088 … t-need-sprites/ ...
UniPCemu still fails a bit at 3 points: the cycle-accurate racing part(with the raster lines, because of not 100% cycle-accurate CPU(but close)), and the 2 sprite recompiler parts(perhaps one of those blanking routines?). IBM logo has noise for background around it(what it doesn't move over, leaving a infinity shape where the logo turns over it), sprite blinks fast when scrolling off the top of the screen? The intro rollover works better now(more in sync, with a darker bar appearing on top of the rollover during the last ~1/5(rollover height ~x2-3) of the screen, with a height of around x2-3 the rollover effect itself).

Edit: 8088 MPH atm reports a metric cycle count of 1482 now for some weird reason? The credits run fine, though?

I've improved the prefetching a bit. Now, the instruction starts executing it's execution phase(and it's first memory/BUS access request to the BIU, if it has any) after it's finished prefetching and handling it's BIU timing, instead of during the cycle it handles the last prefetch/EA cycle.

Now 8088 MPH reports 1544-1546 metric cycles, which is a lot closer(no changes during any of the mentioned parts though. All other parts are unaffected(no crashing)).

So it's still about ~122 cycles off on the metric cycle count?

Just found out something: the noise in the vectorball part of the demo seems to be only blue and green(looks like from the sprite rendering part), with blue lines in the top right corner on a green background. The 'noise' seems from it switching between color and black/white modes(static image otherwise)?

Just found out something: CGA applies the memory write waitstates when updating the memory mode(changing mapped memory layout)? So when updating the memory with the new layout(due to changing VGA memory mapping it uses) it sets the waitstate for the current instruction(which it shouldn't)!

superfury wrote on 2020-03-12, 09:59:

Just found out something: CGA applies the memory write waitstates when updating the memory mode(changing mapped memory layout)? So when updating the memory with the new layout(due to changing VGA memory mapping it uses) it sets the waitstate for the current instruction(which it shouldn't)!

Not sure what you mean by this. The CGA memory wait states are the same for all modes. There are no additional wait states for CGA port writes, only the one imposed by the motherboard.

reenigne wrote on 2020-03-12, 14:08:

superfury wrote on 2020-03-12, 09:59:

Just found out something: CGA applies the memory write waitstates when updating the memory mode(changing mapped memory layout)? So when updating the memory with the new layout(due to changing VGA memory mapping it uses) it sets the waitstate for the current instruction(which it shouldn't)!

Not sure what you mean by this. The CGA memory wait states are the same for all modes. There are no additional wait states for CGA port writes, only the one imposed by the motherboard.

Well, that was one of UniPCemu's issues. When software would write the CGA ports to change the memory mapping for rendering(e.g. switching the memory mode by writing the CGA mode control register with a new mode), chainging bit 2,4,5 to switch to 2-color, 4-color or text mode(and being in a different mode of those 3 previously), it would trigger UniPCemu to rewrite the CGA/MDA shadow RAM(which it keeps for any writes to the CGA memory addresses) back to the VRAM, effectively moving the current bytes of the CGA RAM to their VGA-compatible locations(which are used with the selected mode).
Using said shadow RAM for reads makes sure that the reads and writes to CGA/MDA RAM behave as expected on a CGA/MDA card. Otherwise, the memory would leave the old values in their VGA-compatible places, messing up the entire CGA emulation.

The issue with said remapping lied with the way it would trigger the CPU(writing the shadow RAM to real VRAM) into using the CGA waitstates(wait for 8 dots, next lchar(16 dots period), next CPU cycle) in a semi-HLT state(actually a HLT state with a special meaning, effectively acting as a delay to the CPU's EU and BIU). It was only supposed to do that for memory accesses(reads and writes), not for the updating of CGA memory(by writing to the mode control register).

From your own blog: https://www.reenigne.org/blog/the-cga-wait-states/

UniPCemu just was applying that not only to CGA memory accesses(which is correct) but also to the mode control register being written with a new mode which changes the memory layout when compared to VGA adapter settings(because it's in actuality still keeping a VGA-based system in the background for it's rendering. It just has some modifications making it act like a CGA/MDA instead of a VGA(although lots of VGA registers are still used in the background to handle things like memory mapping, some rendering parameters etc.)).

You can see it actually working out CGA to VGA mapping values in the VGA registers at https://bitbucket.org/superfury/unipcemu/src/ … a/vga_cga_mda.c applyCGAmodecontrol function, applyCGAPaletteRegister function for CGA, and the applyMDAModeControl for MDA. Those write special values into the VGA's registers(most of them are actually still used during rendering) compatible with the CGA.

Mostly the only thing that changes with the CGA compared to the newer video cards(EGA and up) is the way it handles some translations between the CGA registers to the VGA registers(mostly for memory writes, reads use the shadowed VRAM instead), writes applying to the shadow VRAM as well, and various rendering parameters using the VGA's precalcs and some VGA registers unchanged.

A screen capture of the vector balls part(all other screen captures are the same, except the IBM logo turning differently):

As can be seen, the surrounding image doesn't change, it's static(only the vector balls area does).

It also keeps switching between those two surroundings, nothin in-between(some pixels changed or anything like that). It's just a static image surrounding it, blinking between color and b/w modes it seems.

Edit: OK. Looking at some earlier captures it changes a little bit, but only at the beginning of the vector balls part, not when it's fully running a second or more.

Great Hierophant wrote on 2020-03-09, 19:55:

It won't even work fully on a Tandy 1000, although it comes pretty close on the earlier models.

Next month (April 5) will be the fifth anniversary of 8088mph, I hope one could expect some good news regarding its complete emulation.

It's worked fine in 86Box for a LOOOOONG time now, several months at least. Even the latest stable release (2.07) runs it almost perfectly, barring some extremely minor timing issues that we think are related to DRAM refresh timings

superfury wrote on 2020-03-12, 18:16:

Mostly the only thing that changes with the CGA compared to the newer video cards(EGA and up) is the way it handles some translations between the CGA registers to the VGA registers(mostly for memory writes, reads use the shadowed VRAM instead), writes applying to the shadow VRAM as well, and various rendering parameters using the VGA's precalcs and some VGA registers unchanged.

None of this is making any sense to me. What do VGA registers have to do with emulating CGA? What are you defining as "shadow ram" when it comes to CGA? And why does the IBM part of 8088 MPH have all that noise around it?

What do VGA registers have to do with emulating CGA?

UniPCemu keeps using the VGA registers for all basic rendering(e.g. 1/2-bit modes, text mode setup, different palettes) and MMU window(the memory accessed by the CPU) functionality. It's just hidden behind the CGA mode control and Color registers. So that's the VRAM window registers and settings. VGA Sequencer and attribute controller handle the rendering from VRAM still. It's just hidden by the emulation, while the registers are made unaccessable for the CPU(basically ignoring writes&reads from them). The CRTC registers are mostly replaced by the CGA/MDA overrides, but some(e.g. byte/word mode etc.) are still actually used by the precalcs normally. What in fact happens is that the raster timing is fully overwritten for CGA compatibility, while most other settings for the sequencer&attribute controller(mainly used for the different pallettes for the color register) are retaining their settings from the actual VGA registers in the register set.
Writes to the CGA- or MDA-specific(color and mode for CGA, just mode for MDA) registers simply write CGA or MDA-compatible values for the mode to said registers, then updates all VGA precalcs based on them. Said precalcs are used for rendering the display and handling the VRAM accesses by the CPU. Although the CGA/MDA have some little customization on the rasterline rendering for processing NTSC/RGB modes without a DAC processing step. And of course some extra CPU waitstates for CGA and CGA/MDA memory wrapping for the CPU VRAM window is enabled.
Look at vga_precalcs.c for the CGA/MDA/VGA precalcs, vga_mmu.c for memory mapping itself, vga_renderer.c for the renderer(using vga_sequencer_*.c and vga_attributecontroller.c) and of course vga_cga_mda.c for the CGA/MDA overrides and mode/color registers of the CGA/MDA and CRTC overrides for horizontal/vertical timings.

What are you defining as "shadow ram" when it comes to CGA?

It's a simple byte array the size of the VRAM addressed by the CPU. Writes to any VRAM address write a copy of the byte written to said shadow RAM. Reads just ignore what's fetched by the VGA emulation and just return the shadow RAM's data(although still affecting the VGA latches(which are unused)). When it detects a mode change affecting the VRAM layout, the CGA memory map update routine simply does a simulated VRAM write(like a move to [b800:x] from shadowram[x], although directly in the VRAM routines handling the VGA mapping of VRAM from the CPU, bypassing the CPU wrappers), which will change the VRAM like the CGA has updated it's memory reading pattern in a semi-VGA mode change style, thus keeping the illusion that memory is handled like a CGA. Although currently no memory is cleared when changing modes(perhaps it should?). Hmmm...
Look at vga_mmu.c for the VRAM map and shadow RAM and CPU waitstates starting up(the rest of the wait-states is done by vga_renderer.c).

And why does the IBM part of 8088 MPH have all that noise around it?

It used to run correctly in the past, still trying to figure that out myself. Currently a bit baffled why that happens(seeing as the CPU instructions run fine).
Perhaps something to do with the shadow RAM update? It looks like data from the previous(DeLorean) sprite demo background that's scrolled up/down, but garbled.
Perhaps an issue with the VRAM remapping not properly clearing the other mode's memory it had before(that's unused by the new memory mode, required to be zeroed)?

Edit: Having fixed the memory map updating to clear the full VRAM array correctly(before writing the shadow RAM to VRAM, updating it's mapping), the noise from the IBM logo disappears completely. It was writing new values from shadow RAM to VRAM, while not clearing any existing VRAM when switching modes(only when switching to non- CGA monochrome mode with CRTC mode control register bit 6 set(thus switching to non-[CGA monochrome graphics] with byte mode only). Of course the memory would need be cleared whenever changing the memory mode(thus the VRAM layout in VGA-compatible VRAM), not just in that one case.

That just leaves the cycle-accurate part(the raster beam racing) and the Delorean Sprite recompiler just before the fading out to white making the odd or even(I think it was the odd) scanlines of the DeLorean sprite blink) while scrolling the bottom half of the DeLorean off the screen. Those simply seem to be blinking between the sprite and the buildings background it seems. It only happens during that part(scrolling the bottom half of the car off the top of the screen, the top half already having scrolled off the screen), the rest of the sprite demos are having no issues anymore.

Edit: Also, the opening rollover has a big darker area now, the size if almost half the screen, following the rollover?

The new version I've just released has the improved 808x timings for 8088 MPH(although still 120ish cycles short somewhere for some instructions combined, according to the metric cycle count, at 1547 cycles).

Alegend45 wrote on 2020-03-13, 16:51:

Great Hierophant wrote on 2020-03-09, 19:55:

It won't even work fully on a Tandy 1000, although it comes pretty close on the earlier models.

Next month (April 5) will be the fifth anniversary of 8088mph, I hope one could expect some good news regarding its complete emulation.

It's worked fine in 86Box for a LOOOOONG time now, several months at least. Even the latest stable release (2.07) runs it almost perfectly, barring some extremely minor timing issues that we think are related to DRAM refresh timings

I tried 8088MPH out on the last public build of 86Box and I am rather impressed. The demo ran without obvious flaw. I appreciate that 86Box is rather easy to use.

First of all: Happy 5th anniversary to 8088MPH and everyone involved!

But let's get deeper into the technical details:

IIRC the 1024 color mode outputs only the duplicated first scanline of every character row and does that by starting a new CRTC frame for every scanline of the picture.

Would it be possible to solve that problem in a more elegant and more compatible way using the CRTC's interlacing functionality?

I.e. you would set a text mode with 80x100 character cells of 8x2 correction: 8x4 pixels, but with interlacing enabled, which should technically omit every other line.
Normally, the card would then alternate between even and odd fields at 60Hz, but it should technically be possible to suppress that by reinitializing interlacing in the vertical blanking interval.
With the specific characters used, the effect should be the same.

I read somewhere that IBM's CGA cannot output proper synchronization signals for an interlaced mode, but that would be irrelevant for this particular use case.

So the question is: Has this approach been considered during the creation of 8088MPH? And would it even work or am I missing something?

Benedikt wrote on 2020-04-05, 09:57:

First of all: Happy 5th anniversary to 8088MPH and everyone involved!

Thank you! I hadn't realised the anniversary was this weekend.

Benedikt wrote on 2020-04-05, 09:57:

But let's get deeper into the technical details:

IIRC the 1024 color mode outputs only the duplicated first scanline of every character row and does that by starting a new CRTC frame for every scanline of the picture.

Not quite - every other scanline.

Benedikt wrote on 2020-04-05, 09:57:

Would it be possible to solve that problem in a more elegant and more compatible way using the CRTC's interlacing functionality? […]
Show full quote

Would it be possible to solve that problem in a more elegant and more compatible way using the CRTC's interlacing functionality?

I.e. you would set a text mode with 80x100 character cells of 8x2 correction: 8x4 pixels, but with interlacing enabled, which should technically omit every other line.
Normally, the card would then alternate between even and odd fields at 60Hz, but it should technically be possible to suppress that by reinitializing interlacing in the vertical blanking interval.
With the specific characters used, the effect should be the same.

I read somewhere that IBM's CGA cannot output proper synchronization signals for an interlaced mode, but that would be irrelevant for this particular use case.

So the question is: Has this approach been considered during the creation of 8088MPH? And would it even work or am I missing something?

This is not a technique that had occurred to me at the time we released 8088MPH. But it is something that I have played with since. I have written code to do it and it does work, though it's more difficult to get working than you might imagine (especially if you want it to work on machines other than a 4.77MHz 8088). It is elegant and has a lower CPU overhead, but is probably not more compatible. Either way the compatibility would be limited to machines that generate the composite colours in the same way (which is probably the limiting factor, at least for 8088MPH's purposes) and either way you would need a genuine 6845 CRTC or something very compatible (and the interlacing parts of the 6845 are probably less well-cloned than the parts that need to be compatible for 8088MPH's technique to work). But look out for this in a future release!

Just found a bug in the post-execution timings (2/3 cycles after the execution of the ADD/SUB/etc.), where the cycles were counted at the same time as the execution phase's start, instead of after it finishes(creating more proper timing).

Still reporting 1547 metric cycles.
Edit: Also, the IBM logo seems to have fixed itself now! 😁
Edit: Also, the cycle-accurate portion of the demo(the free-running part of racing the beam) seems to have become more accurate somehow. It now displays around constant ~1cm breaks in the rendering(on the background color being used). Each scanline seems to shift it ~1cm to the left, ending the break where the previous one started(horizontal coordinate on the CRT).

Does that tell something about what's going wrong with the timing?
So it roughly looks like this:

1aaaaaaaaaaaaaaaaaaxxxxxxxxxxxxxaaaaaaaaaa
2aaaaaxxxxxxxxxxxxxaaaaaaaaaaaaaaaaaaaaaaa
3xxxxxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

With 'x' being the gaps in the background color before it seems like a new color is started.
One interesting fact about this is that the 'gaps' in the background color appear to be of a constant size, not changing all the time.
Edit: OK. Running it again to get some screen captures of the current beam racing effect, I see something interesting: when the rollover effect runs, when it reaches about half the screen, a darkened area appears, which goes down with the scrolling effect until it reaches the bottom quarter of the screen, at which point it seems to stay at the same position until the rollover effect ends, at which point it disappears?
Also, the noise that was appearing during the IBM vectorball part seems to have disappeared?

Edit: OK. Something's going weird right now, about a bit into the running of the 3D pyramid effect after said captures, the music starts barfing, becoming some weird low noise or tone. This continues on until the credits starts it's music(which runs normally).

Was just debugging the 80386 emulation when I noticed something strange: the EU timings at the end of opcodes 00-3B(all modrm ones) were misbehaving their timing. They weren't executing their final timings(2 cycles for non-memory, 3 for memory, 3 for CMP). So that's quite a lot of cycles missed in total.

Edit: The metric cycle count is now 1564!
Edit: And the graphical glitch during the rollover effect is gone again!

One interesting thing I noticed: when running the scanline racing, some kind of staircasey thing started to appear, which I think I saw returning multiple times during the part of the demo:

Edit: So it's still 104-124 metric cycles short. Since metric cycles are the amount of PIT cycles, that means 416-496 CPU cycles are missing somewhere?