DingusPPC: A more accurate PowerPC Mac emulator

I tried to add few lines into help output and README. (attached)

Still not quite work for my case (booting self-created cd with yaboot/Linux)

 

Attachments

Recent updates have fixed Apple Pippin emulation. BeOS can also boot up now, albeit somewhat slowly. Performa 6400 emulation is also being worked on.
Cool, nice to see a 603 'Mac' and 603ev being emulated. I guess they'll get onto infinite Mac at some point. Does 5200/6200 emulation work given that Valkyrie is emulated? I had a look in the machine list, but couldn't see it. In theory is it simply a question of adding the right machine description, e.g. machinecrusader.cpp whose contents reference the correct peripherals?


It's listed as a project, but there's no content.

 
In theory is it simply a question of adding the right machine description, e.g. machinecrusader.cpp whose contents reference the correct peripherals?
Yes. But there may be hidden things missing from the emulation such as Board ID registers. Schematics and memory dumps, etc. may show these hidden things.
 
The major things that are missing for the Performa 5200/6200 emulation are the F108 memory controller and PrimeTime II I/O controller.

We haven't found any documentation for these yet, nor has code been found.
 
Yes. But there may be hidden things missing from the emulation such as Board ID registers. Schematics and memory dumps, etc. may show these hidden things.
The major things that are missing for the Performa 5200/6200 emulation are the F108 memory controller and PrimeTime II I/O controller.
So, what you're saying is that Performa x200 emulation isn't ready for PrimeTime :ROFLMAO: !

The best information I had was the developer note, which doesn't really give a lot away. Looking at the architecture diagram, F108 and Primetime II are most of what constitutes the Px200s including SCC, SCSI, IDE, SWIM II, VIAs, sound controller etc.

1723278976585-png.76820


I also note that the Taylor Design website appears to be down, so one can't get the developer notes from there. However, a copy is at PeterHuman.net.


I realise this doesn't help. Maybe there's still some P5200 developers around somewhere who have documentation squirrelled away.
 
The major things that are missing for the Performa 5200/6200 emulation are the F108 memory controller and PrimeTime II I/O controller.

We haven't found any documentation for these yet, nor has code been found.
PrimeTime and PrimeTime II are essentially re-spins of IOSB. The fun part of all of those chipsets is that they expect to be able to halt processor bus read/write bus transactions indefinitely while the SCSI bus catches up. That's a serious pain for emulation, although it's probably a lot simpler on PPC where there aren't the side effects of MOVE.L (A1)+, (A2)+ to deal with when you need to rewind.
 
Hi @Arbee ,

Thanks for this!
PrimeTime and PrimeTime II are essentially re-spins of IOSB.
So, in theory we could guess that PrimeTime II is IOSB and see how far we get? And if we know PrimeTime II is a respin of IOSB, does that mean there's some effective documentation after all?
The fun part of all of those chipsets is that they expect to be able to halt processor bus read/write bus transactions indefinitely while the SCSI bus catches up.
<Mindblown>. This doesn't make sense to me (yet). The SCSI bus isn't part of the main bus, so in what sense is it catching up? In my mind, SCSI is DMA-driven (or effectively, since the SCSI chip can transfer data without CPU intervention). So, data transfer is inevitably asynchronous: the SCSI chip sends a command (or series of commands) to the SCSI device and then the SCSI device sends its bytes (e.g. the bytes from a sector) to the SCSI chip which then generates bus transactions to send data to the target memory locations.

Then to me, SCSI doesn't need to 'catch up', since it's always way behind and because data transfers from the device to the SCSI chip can take a wide span of time depending on e.g. seek times or the speed of the drive, then the SCSI chip will perform data transfers as and when data is available.
That's a serious pain for emulation, although it's probably a lot simpler on PPC where there aren't the side effects of MOVE.L (A1)+, (A2)+ to deal with when you need to rewind.
I'm sure that's true, no idea how MOVE.L (a1)+,(a2)+ could interfere with a SCSI data transfer.

Looking forward to a bit of education!
 
I boot and run the Quadra/LC 630 in MAME by treating PrimeTime II as a slightly different IOSB. The differences are mostly centered around the ATA controller being added and that changes how interrupts work a bit.

The SCSI thing is this: on reads, Apple does an unrolled loop of MOVE.L from the 539x. Each MOVE.L requires the hardware to gather two 16-bit words from the 539x. If the 539x de-asserts /DRQ at any time, the 68040 is kept waiting (by not asserting /DTACK) until all 32 bits are available. Same situation on writes: it firehose-blasts the 539x 32 bits at a time, and when that fills the 539x's 16 byte FIFO, the 539x de-asserts /DRQ and IOSB/PrimeTime therefore withholds /DTACK until the FIFO can accept at least another 16 bits.

This is fun in emulation because most emulators run CPU instructions as indivisible atomic operations: a MOVE.L (A0), (A1)+ will transfer the word and increment A1 by 4 and you can't stop it. (Some CPUs in MAME, notably the 6502 and Z80 families, *are* cycle-by-cycle interruptible). The operation of IOSB and its clones means you have to either be able to stop and resume the instruction in the middle or you can do what I did and have the CPU save off the registers before every instruction. If it gets a signal that the read can't complete, it'll write a meaningless temporary value, increment A1 by 4, and then immediately back up the program counter and A1 to their previous values and try the instruction again until IOSB/PrimeTime don't pull the "no data available" alarm or the CPU runs out of cycles for that frame. (In reality we actually suspend the 68k entirely until data arrives (read) or the FIFO drains down (writes) to avoid wasting host CPU time).

Just using DMA the way you're supposed to as the Quadra AVs and all other PowerMacs do is so much more civilized.
 
Last edited:
Back
Top