On Fri, 21 Mar 2025, Andrew Randrianasulu wrote:
> чт, 20 мар. 2025 г., 23:41 BALATON Zoltan <balaton@eik.bme.hu>:
>> On Thu, 20 Mar 2025, Andrew Randrianasulu wrote:
>>> Will look at ATA situation, some said SATA was more likely to work on
>> real
>>> machines.
>>
>> I think we've tested that too at some point. There's -device sii3112 that
>> I've added for sam460ex and AmigaOS but this is a common chip also found
>> on some Mac compatible SATA cards. You just need the FCode ROM from one of
>> those, which were available in updates to these cards. There was one from
>> SeriTek and one from WiebeSATA3112 and I think at least one of those
>> worked with my patches to OpenBIOS to run the ROM so it should work with
>> real OpenFirmware too. Although that can be a workaround, it would still
>> be interesting to know why the on board IDE does not work. Maybe it
>> emulates the IDE found on the G4 but the G3 had something different? There
>> were names like Keylargo and O'Hare but I don't remember what these were
>> exactly.
>>
>
> according to dppc files ...
>
> https://github.com/dingusdev/dingusppc/blob/master/devices/ioctrl/heathrow.cpp
>
> https://github.com/dingusdev/dingusppc/blob/master/devices/ioctrl/macio.h
>
> Heathrow , O'hare, GrandCentral all revisions of macio chip ....
>
> /** PCI device IDs for various MacIO ASICs. */
> enum {
> MIO_DEV_ID_GRANDCENTRAL = 0x0002,
> MIO_DEV_ID_OHARE = 0x0007,
> MIO_DEV_ID_HEATHROW = 0x0010,
> MIO_DEV_ID_PADDINGTON = 0x0017,
> };
In QEMU macio-oldworld sets PCI device_id to PCI_DEVICE_ID_APPLE_343S1201
which is 0x10 so seems to match Heathrow. Does that match with what a
beige G3 should have?
well, according to this file
there are TWO types of G3 BEIGE
Power Macintosh G3 (Beige) Tower
Power Macintosh G3 (Beige) Desktop
hm, default storage device here seems to be ATA ....
Also, I was wrong about Ethernet on those ...
=====
BMac aka BigMac is an Ethernet media access controller cell integrated in the
Heathrow and Paddington I/O controllers.
According to a former Apple employee, BMac has been licensed from Sun.
It's therefore not surprising that it has a lot in common with the Sun
"Happy Meal" (HME) controller.
There are three BMac based HW configurations:
- BMac in a Heathrow I/O + LXT907 PHY used in Power Macintosh G3 (Old World)
- BMac+ in a Paddington I/O + LXT970 aka ST10040 PHY in Power Macintosh Blue & White (New World)
- BMac+ in a Paddington I/O + DP83843 PHY in a Bronze Keyboard PowerBook G3
No official documentation has surfaced so far. Fortunately, the official source
code as well as the STP2002 datasheet provide enough information on the BMac device.
===== quote end ====
and yea, some people updated their G3 cpus to G4 in those machines, so G4 in g3beige is valid combo .. not sure about real memory ceiling .. some said 1.5 Gb ?
(G4 has Keylargo which is 0x22, G5 may have an even
newer, something like K2 but that's not emulated and O'Hare may be in
older Macs then so not interesting for us.)
> but what worties me most - Dppc's emulation of
> device_write/device_read/dma_read/dma_write seems to be much more complex
> than qemu's (living in hw/intc and hw/misc/macio)
>
> And there is whole comment about ide1 being mediabay (so you can put floppy
> there ...)
>
> uint8_t cpu_id = 0xE0; // CPUID field (LSB of the MIO_HEAT_ID)
> uint8_t mb_id = 0x70; // Media Bay ID (bits 15:8 of the MIO_HEAT_ID)
> uint8_t mon_id = 0x10; // Monitor ID (bits 23:16 of the MIO_HEAT_ID)
> uint8_t fp_id = 0x70; // Flat panel ID (MSB of the MIO_HEAT_ID)
> uint8_t emmo_pin; // factory tester status, active low
>
> // subdevice objects
> MacioSndCodec* snd_codec; // audio codec instance
>
> NVram* nvram; // NVRAM
> ViaCuda* viacuda; // VIA cell with Cuda MCU attached to it
> MeshController* mesh; // MESH SCSI cell instance
> EsccController* escc; // ESCC serial controller
> IdeChannel* ide_0; // Internal ATA
> IdeChannel* ide_1; // Media Bay ATA
>
> ======
>
> of course dppc is modern (c++20?) c++ so some of this might be
> architecture difference between emulators, but I am afraid it might be more
> complex than just wrong dma channel or address ....
A lot of difference may just be different implementation and maybe DPCC
implements DMA in the same object whereas in QEMU there's a separate DBDMA
emulation that I think is also used for IDE and sound. So if you add that
too and all the IDE emulation in QEMU then it may be similar complexity
just broken down in different ways. But we're missing SWIM MESH and the
ethernet from QEMU for sure, these are only emulated for q800 but not
hooked up in macio and may be needed for the Mac ROM.
The macio IDE is in qemu/hw/ide/macio.c. It does not have traces but has a
debug define that you could enable and see if the Mac ROM tries to access
this device at all and if it gets some error or it could be guessed from
the accesses where it might fail. If it does not even poke the device
there's some other problem before that but if it appears in the device
tree then probably it at least detected it but maybe failed to set it up
because got some unexpected results.
yea, something to try and check out ;)
But dog walk first ;)