> > I'd imagine if you're > > changing the actual pixel clock mid scanline that's very tricky to create a stable > > display with even on real hardware. > > You're assuming that the desired effect is a stable display. > > Demos often simulate display corruption, throwing in random pixel clocks would > certainly achieve that & it would only look correct on real hardware. > > MAME's arcade roots shows up in spades.
I think display timings are actually a problem even with the arcade side of things.
We still basically assume that the screen drives the timings when in reality the timings of everything else drive the screen.
hap speculated that the Moon Cresta sync bug might be as simple as the number of cycles before the first interrupt occurs for example. MAME assumes that the interrupt comes from the screen, so it always occurs after exactly one frame of time after boot while in reality it could be anything and the display would sync to output of the PCB from that point forward.
the discrete stuff basically drives the signals directly too.
Don't think you can blame it on arcade roots, it's just something that wasn't considered, like a lot of other things at the time (it was 20 years ago, we were still learning) or were ignored because it was easier to ignore them (waitstates, cpu cache, interruptible CPU fetch-execute cycles etc.)
If you take pretty much any emulator from 20 years ago most of these things weren't real considerations then. If you were to write a well researched emulator from scratch today, they would be because there are now thousands of examples of where such things are important due to research done in that time, and a lot more test code about.
If anything it's just a case of "MAME is showing it's age" and "Doing things properly is hard"
|