8088mph detects cycle count deviation about martypc HOT 13 CLOSED

I've written a blog post about the 8088MPH CPU test. If you've been following this issue, you may find it interesting.

https://martypc.blogspot.com/2023/08/the-8088mph-cpu-test.html

from martypc.

I'm aware of this issue. I believe it is more an issue with timer accuracy than the CPU, as I have taken the CPU test routine from 8088MPH and ran it through hardware validation. The issue started when I fixed an issue with the PIT latch. Both 8088MPH and Area5150 will still run.

from martypc.

Ok, this is finally "fixed". Adding another wait state wasn't the answer, but it was a clue.

I was doing my DMA state machine processing after advancing T-state, when I should have been doing it before. This means that the HRQ->HOLDA transition delay wasn't being properly calculated; and so DMA timings were off. The DMA logic itself was fine (thankfully no blog retractions needed), it was just all effectively a cycle off.

Unfortunately during this work I have discovered I need improved synchronization between the PIT and DMA. Specifically; the when Timer Channel #1 is started with a final OUT to write the count register; a DREQ must occur on the correct cycle following. It's not simply just the timer reload value * 4; since the timer does not load the new value until the next falling edge of the timer clock.

My current logic was 4 cycles off or one timer tick; I need to look into why. Hardware seems to take another tick, even taking into consideration the delay load tick. I pass the CPU test with this 4 cycle adjustment, but I don't want to just stick a magic number in the code and call it a day.

There's a bit more research to do as well. Commands to the 8253 aren't clocked like the timer channels are - they are latched on the IOW signal. Certain things like setting mode 2 should immediately set the timer output HIGH - and potentially cause an interrupt / DMA cycle, even before the timer is even ticked once. I don't currently have a means of adjusting the DMA scheduler mid-instruction, so I have to think about how I'm going to handle this scenario.

The good news is that 0.1.4 will be more accurate than ever; the bad news is that it might take a bit longer to come out.

from martypc.

I haven't commented on this in a while, but I've been working on it.

"But isn't MartyPC hardware validated", you ask, and yes, yes it is, but the validator is just a bare CPU; there is no DMA going on to interrupt it, there are no wait states on bus transactions to slow it down, the validator can't be in a different clock phase than the timer. There is a difference between an 8088 CPU in isolation and a full IBM 5150 system humming along with all components.

This problem started when I fixed the behavior of the timer latch register - due to a boneheaded bug, the timer latch wasn't actually latching on the latch command, so 8088MPH would try to freeze the timer count, yet the timer would continue to tick through a few extra instructions until read out. This increased the number of ticks that 8088MPH thought the test actually took , and subsequently we passed, essentially, by accident. With this corrected, we run the test slightly too fast now. We must complete the test in 1668-1688 timer ticks, and we currently do so in 1653. 15 timer ticks may not seem like a lot, but that's 60 CPU cycles - practically an eternity, you could hide several instructions in that period of time. I'm used to hunting down a cycle here and there. Hunting down 60 cycles feels like searching for an invisible elephant.

I've fixed some issues with the DMA scheduler. DRAM refresh DMA is controlled by timer channel #1, when it hits terminal count, a DREQ signal is generated, and a whole process begins that i wrote about on my blog. I felt like I investigated DMA pretty thoroughly and had mastered it; could I have made a mistake? It's certainly possible; but yet, the end credits of Area 5150 that hum along in perfect cycle-counted scanlines (with DMA on) are evidence that I can't be too far off. This is an interesting case where passing 8088MPH's cpu test is actually harder than running 8088MPH itself.

Not many programs are going to mess with the DRAM refresh timer - it was in normal circumstances set by the BIOS and left alone. 8088MPH and Area5150 do a trick by slowing the timer down imperceptibly, to make DRAM refresh occur in more predictable intervals (an even 4 times per CGA scanline). MartyPC reprograms it's DMA scheduler in this event, and without that, the end credits of Area 5150 would never work. But what it wasn't doing right was reprogramming the DMA scheduler when the timer mode wasn't changed, but just reset; this is what the 8088MPH CPU test does to make sure that DMA occurs during the test in a reproducible fashion.

It would be nice if that fixed it; but it didn't.

"Doesn't 86box pass this?" - As it turns out, ironically, 86box might just be passing it by accident as well. If we break the CPU test down into individually timed blocks, the individual block timings are all off; but of course, only the total matters in the end to pass. It's like if you were asked to calculate 2+2+3+3 and you figured 2+2=3 and 3+3=7, so the answer is 10. You got the right answer but your operations were wrong. Unfortunately if you shuffle those operations around later in a different sequence, you won't be so lucky.

The 8088 is a surprisingly complicated little CPU, and it's hard enough getting things cycle accurate with it in isolation. There's no such thing as a table of instruction timings for the 8088; every instruction that accesses memory can take a variable amount of time to execute. With DMA active, matching code execution cycle-for-cycle is kind of like trying to accurately transcribe Latin while a goat is screaming in your ear.

from martypc.

Type Y and continue, if the emulator burns up you can always download it again :)

from martypc.

fun fact: you can skip the test entirely by passing NOCHECK as a commandline argument. This is what the autoexec.bat for the web demo of 8088MPH does to hide my shame :)

from martypc.

hide your shame ?

from martypc.

I didn't want the first thing people see when they run the demo to be a big ol' warning about blowing up your monitor.

from martypc.

Nah, that's easily done with any software on any hardware by using incorrect monitor timings and resolutions.
That demo is very weird as I cannot get it to run on any of my hardware 8088 XT clones.

from martypc.

Nah, that's easily done with any software on any hardware by using incorrect monitor timings and resolutions

I don't think we're on the same page, i'm talking about my web demo of 8088mph
https://dbalsom.github.io/martypc/web/player.html?title=8088mph

there is no danger to anyone's monitor here.

from martypc.

Oh, I thought you were talking about running the demo on hardware as the message don't make sense to blow up an emulated monitor if the demo is intended for emulators only :)

from martypc.

I've traced the issue down to DMA; when I change the 8088MPH CPU test to disable DMA, I am timer-perfect (the test fails as its too fast, but it reports the same cycle count on my IBM 5150 as it does in my emulator).

I made a little test utility to compare the elapsed timer ticks after a CPU test routine with DMA disabled, and with DMA enabled:

Hardware: 67D vs 6DA (1661 vs 1754) - DMA 5.6% slower
Emulator: 67D vs 6BE (1661 vs 1726) - DMA 3.9% slower

As you can see without DMA they are exact; but the emulator is too fast when DMA is on. This is puzzling; if DMA is inaccurate, how are the cycle-exact effects in Area 5150 working?

from martypc.

I modified DMA to de-assert READY for one additional cycle.

Go figure.

from martypc.