Programming my own Mac emulator

[mcayland]

A bit of a bump, but Mihai fixed up Mac OS X. Now it displays properly (mostly). We've looked into BeOS a little bit and it seems to be quite the challenge, since it expects the 53c94 emulation to be accurate.

If it's any consolation I had the same issue with QEMU's ESP emulation and ended up doing almost a complete rewrite to allow MacOS to boot under the Q800 machine. Are the problems related to mixed DMA and FIFO transfers or something else?

[kataetheweirdo]

I think we fixed those problems (seems to be FIFO transfers), but now we have issues in the ESCC emulation to fix. But just to be sure, here's the problem we were having, paraphrased from maximumspatium:

53c9x SCSI controllers implement a couple of multi-step commands (Select with ATN for example). Those chips will generate a single interrupt when a multi-step command is completed. SW can then read the Sequence Step register to determine how far the internal sequencer was able to execute some command. Sequence step counter is implemented internally using SS0-SS2 bits. They can be read via Sequence Step and FIFO flags registers.

NCR and AMD docs for the chips tell us that reading the Interrupt Status register while INT is asserted will clear the Interrupt, Status and Sequence Step registers. That behavior was implemented in DingusPPC.
I was surprised that the 53c94 driver in BeOS refused to work with my 53c94 emulator resulting in a hang while transferring data using PIO.

I then found out the cause. The [BeOS driver] reads the FIFO Flags register and issues the Transfer command only if the obtained register value is not zero. The FIFO Flags register returns a combination of the current FIFO position and SS0-SS2 bits. FIFO position will likely be zero at this point. If SS0-SS2 bits are also zero the driver will hang. I fixed the above problem by leveraging an internal variable for the SS0-SS2 bits that won't be cleared when the Interrupt register is read. They are cleared at the beginning of a multi-step command. Each step will update both SS0-SS2 bits and the Sequence Step register whose value is held in a separate variable. All other commands don't touch the SS0-SS2 bits.

[adespoton]

I think we fixed those problems (seems to be FIFO transfers), but now we have issues in the ESCC emulation to fix. But just to be sure, here's the problem we were having, paraphrased from maximumspatium:

53c9x SCSI controllers implement a couple of multi-step commands (Select with ATN for example). Those chips will generate a single interrupt when a multi-step command is completed. SW can then read the Sequence Step register to determine how far the internal sequencer was able to execute some command. Sequence step counter is implemented internally using SS0-SS2 bits. They can be read via Sequence Step and FIFO flags registers.

NCR and AMD docs for the chips tell us that reading the Interrupt Status register while INT is asserted will clear the Interrupt, Status and Sequence Step registers. That behavior was implemented in DingusPPC.
I was surprised that the 53c94 driver in BeOS refused to work with my 53c94 emulator resulting in a hang while transferring data using PIO.

I then found out the cause. The [BeOS driver] reads the FIFO Flags register and issues the Transfer command only if the obtained register value is not zero. The FIFO Flags register returns a combination of the current FIFO position and SS0-SS2 bits. FIFO position will likely be zero at this point. If SS0-SS2 bits are also zero the driver will hang. I fixed the above problem by leveraging an internal variable for the SS0-SS2 bits that won't be cleared when the Interrupt register is read. They are cleared at the beginning of a multi-step command. Each step will update both SS0-SS2 bits and the Sequence Step register whose value is held in a separate variable. All other commands don't touch the SS0-SS2 bits.

Wasn't that ESCC emulation issue the same thing Arbee was talking about a month or so ago for MAME PPC emulation? Seems to me that all three of you are starting to narrow in on the same implementation issues?

[andreas_g]

Maybe have a look at Previous. It has a quite accurate ESP simulation: https://sourceforge.net/p/previous/code ... /src/esp.c