|
8088 mph we break all your emulators
#338745 - 04/08/15 09:56 AM
|
|
|
As of April 7th 2015, there are no IBM PC emulators in the world that can run the demo properly.
http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/
Time to fix this ;-)
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: RdW]
#338746 - 04/08/15 10:44 AM
|
|
|
Holy CRAP that is awesome.
They are doing things with the CGA hardware that even the IBM guys who designed the thing would probably look at and go "no way is it possible to do THAT with a CGA card"...
Oh and who is going to stand up and volunteer to fix the MESS IBM 5150 driver so it can run this beast? 
Edited by jonwil (04/08/15 10:46 AM)
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: jonwil]
#338749 - 04/08/15 01:02 PM
|
|
|
> Holy CRAP that is awesome.
> They are doing things with the CGA hardware that even the IBM guys who designed the
> thing would probably look at and go "no way is it possible to do THAT with a CGA
> card"...
Most of the stuff that they're doing simply involves counting cycles (including wait states) and abusing the MC6845 chip, which certainly isn't unique to the CGA card. Even wringing 256 or 1024 colors out of it isn't that surprising overall; they're just abusing composite NTSC to induce artifact colors. This is in fact how the Apple II itself generates color, and was a technique used by a number of Sega Genesis/Megadrive developers to get more colors than its anemic 512-color palette provided, so applying it to another composite NTSC system should come as little surprise to anyone.
> Oh and who is going to stand up and volunteer to fix the MESS IBM 5150 driver so it
> can run this beast?
Nobody. Between MESS and DOSbox, MESS actually runs the demo better. DOSbox falls over on the parts that really abuse the MC6845, and I sincerely doubt anyone at all is going to take the time necessary to make a sub-cycle-accurate 8088 core in MESS just to run one demo that, when you pay attention to the man behind the curtain, just isn't that impressive.
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: MooglyGuy]
#338750 - 04/08/15 04:05 PM
|
|
|
> they're
> just abusing composite NTSC to induce artifact colors. This is in fact how the Apple
> II itself generates color, and was a technique used by a number of Sega
> Genesis/Megadrive developers to get more colors than its anemic 512-color palette
> provided, so applying it to another composite NTSC system should come as little
> surprise to anyone.
Lots of CGA games use artifact patterns to get 16 colours on CGA monitors. Nobody's ever used them to get 1K colours before, though - there are quite a few tricks necessary to do that.
> > Oh and who is going to stand up and volunteer to fix the MESS IBM 5150 driver so it
> > can run this beast?
>
> Nobody.
Well, actually... I have an ongoing project to make a cycle-exact 8088 emulator (that I will have a bit more time for now I'm done making the demo). MESS will be welcome to use this code once it's done.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: 8088 mph we break all your emulators
[Re: reenigne]
#338754 - 04/08/15 10:07 PM
|
|
|
> Well, actually... I have an ongoing project to make a cycle-exact 8088 emulator (that
> I will have a bit more time for now I'm done making the demo). MESS will be welcome
> to use this code once it's done.
Cycle-exact (meaning correct cycle counts for the instructions), or cycle-by-cycle (meaning you can interrupt instructions on any cycle)?
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: R. Belmont]
#338755 - 04/09/15 12:04 AM
|
|
|
> Cycle-exact (meaning correct cycle counts for the instructions), or cycle-by-cycle
> (meaning you can interrupt instructions on any cycle)?
I'm thinking the former, though it's whatever is necessary to make the emulator behave the same way as the real hardware. I don't think it should be necessary to interrupt instructions on *any* cycle (definitely not in the IRQ sense), but there may be some instructions that have multiple time-sensitive externally observable effects - e.g. a word access to CGA RAM will have two separate wait states, each synchronizing with the CGA's LCLK and possibly generating a flake of snow.
|
|
|
| Moose |
|
Don't make me assume my ultimate form!
|
|
|
|
|
Reged: 05/03/04
|
|
Posts: 1483
|
|
Loc: Outback, Australia
|
|
|
|
Send PM
|
|
|
Re: 8088 mph we break all your emulators
[Re: RdW]
#338756 - 04/09/15 01:26 AM
|
|
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: reenigne]
#338766 - 04/09/15 07:38 AM
|
|
|
> I'm thinking the former, though it's whatever is necessary to make the emulator
> behave the same way as the real hardware. I don't think it should be necessary to
> interrupt instructions on *any* cycle (definitely not in the IRQ sense), but there
> may be some instructions that have multiple time-sensitive externally observable
> effects - e.g. a word access to CGA RAM will have two separate wait states, each
> synchronizing with the CGA's LCLK and possibly generating a flake of snow.
I don't know if it's specifically the PC or some other system using an 8088/8086, but I seem to recall hearing about a system in MESS that's finicky because the hardware's floppy controller can actually halt the CPU mid-instruction. For something like that, you need to actually have per-cycle emulation rather than just instructions with correct cycle counts. It's kind of scary how some companies designed their hardware.
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: MooglyGuy]
#338771 - 04/09/15 10:47 AM
|
|
|
> I don't know if it's specifically the PC or some other system using an 8088/8086, but
> I seem to recall hearing about a system in MESS that's finicky because the hardware's
> floppy controller can actually halt the CPU mid-instruction. For something like that,
> you need to actually have per-cycle emulation rather than just instructions with
> correct cycle counts.
Oh wow, fascinating stuff. I've never heard of a PC that does that - I guess it would have to be done by gating the CPU's clock line. That must have been a tricky circuit to get working in the first place, let alone to emulate!
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: MooglyGuy]
#338773 - 04/09/15 11:32 AM
|
|
|
> I don't know if it's specifically the PC or some other system using an 8088/8086, but
> I seem to recall hearing about a system in MESS that's finicky because the hardware's
> floppy controller can actually halt the CPU mid-instruction. For something like that,
> you need to actually have per-cycle emulation rather than just instructions with
> correct cycle counts. It's kind of scary how some companies designed their hardware.
It's an Eastern Bloc PC clone that does that. If you can think of it, someone has designed hardware that does it.
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: reenigne]
#338780 - 04/09/15 04:32 PM
|
|
|
> Lots of CGA games use artifact patterns to get 16 colours on CGA monitors. Nobody's
> ever used them to get 1K colours before, though - there are quite a few tricks
> necessary to do that.
By all means, fill me in on said tricks. I'm also curious to know if there are any specific limitations as to what colors can be next to each other, and if there are any limits on the range of colors you have available. If I had to wager a guess, it partly involves abusing luminance transitions, and partly involves the I and Q components having differing amounts of bandwidth available to them, and therefore, different effective horizontal resolutions for their particular portion of the signal.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: 8088 mph we break all your emulators
[Re: reenigne]
#338781 - 04/09/15 04:49 PM
|
|
|
> Oh wow, fascinating stuff. I've never heard of a PC that does that - I guess it would
> have to be done by gating the CPU's clock line. That must have been a tricky circuit
> to get working in the first place, let alone to emulate!
Depends on the bus interface. For the 68000 it's dead easy to withhold /DTACK for an arbitrary number of cycles while the hardware being accessed does stuff (the SCSI interface on 680x0 Macintoshes does this via some gate array magic to allow reading/writing data 4 bytes at a time from the 8-bit-wide SCSI controller). Dead easy in hardware anyway, it's a PITA to emulate
Anyway, MAME in the past standardized on getting the cycle counts right, lately we've been rewriting CPU cores to be able to stop on any cycle because it keeps coming up. The FIFO in Sega Model 2 will stall the i960 main CPU if it's empty, and it'll stall the geometry DSP if it's full, for instance.
|
|
|
|
|
> By all means, fill me in on said tricks.
The technical write-up is now online at http://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/ .
> I'm also curious to know if there are any
> specific limitations as to what colors can be next to each other,
The are no such limits. Any of the colours can be placed in any of the pixels in the 80x100 grid.
> and if there are
> any limits on the range of colors you have available.
The exact set of colours is fixed by the hardware. The palette looks something like this:
> If I had to wager a guess, it
> partly involves abusing luminance transitions, and partly involves the I and Q
> components having differing amounts of bandwidth available to them, and therefore,
> different effective horizontal resolutions for their particular portion of the
> signal.
It's a good guess but I and Q have the same amount of bandwidth in a composite signal - it's only broadcast (RF modulated) NTSC where Q has lower bandwidth.
[ATTACHED IMAGE]
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: R. Belmont]
#338784 - 04/09/15 05:06 PM
|
|
|
> Depends on the bus interface. For the 68000 it's dead easy to withhold /DTACK for an
> arbitrary number of cycles while the hardware being accessed does stuff
Sounds like the equivalent on the PC to the "+IO CH RDY" line on the ISA bus. A peripherial can pull this low to suspend one of the phases of a bus access cycle, introducing wait states. That's not quite the same as interrupting the CPU on an arbitrary cycle, though - the execution unit can keep on running during these wait states, and the bus interface unit can only be suspended in one of its phases.
|
|
|
|
Re: 8088 mph we break all your emulators
[Re: reenigne]
#338800 - 04/10/15 08:22 AM
|
|
|
> Sounds like the equivalent on the PC to the "+IO CH RDY" line on the ISA bus. A
> peripherial can pull this low to suspend one of the phases of a bus access cycle,
> introducing wait states. That's not quite the same as interrupting the CPU on an
> arbitrary cycle, though - the execution unit can keep on running during these wait
> states, and the bus interface unit can only be suspended in one of its phases.
From an emulation point of view, it's roughly equivalent. What hardware does usually is stop the cpu on a bus access. Since instructions can do more than one bus access (the 68000 can reach around 68 I think) it means suspending the execution in the middle of an instruction. From a cpu emulation software point of view, there are four possible points to stop execution: almost never (static recompilers), at a branch (dynamic recompilers), at the end of an instruction (traditional cpu cores) or at any time (cycle-precise cpu cores). Each level increases overhead and the amount of state to track, but also increases timing precision. Any time vs. at a bus access is pretty impossible to distinguish externally, and in practice cycle-precise cpu cores are an hybrid of the two.
OG.
|
|
|
Index 
Threaded 
8088 mph we break all your emulators
Reply
[Re: 
