[strim]

Originally Posted by Hedeon

The current knowledge I have regarding PCI address space: The current window is set to 512MB in Z3 space (with a jumper) and is setup using the MMU (I think) from 0x60000000 to 0x80000000.

Whether this location is a window address or a mapping done by a MMU, you can check easily by comparing output of ShowConfig and pciinfo. If the memory address space of memory board (the 512MB one) as shown in ShowConfig overlaps with memory addresses given by pciinfo, then MMU is not used. If the MMU is used, then board address in ShowConfig and memory addresses outputted by pciinfo do not overlap.

There's a setting somewhere in ENV that enables/disables MMU usage. I think in your situation, using MMU mappings would only further complicate the matters.

If I remember correctly, by default, in no-MMU mode, pci.library never changes the window position, it just sets the position to the same PCI address as the address of Zorro memory board on Amiga side. So that the driver accessing let's say 0x60000000 on Amiga side hits the same address on PCI side.

The mediator itself (through the PCI library) sets up a memory range in the unused VooDoo GFX memory which can be addressed from the Amiga. Currently it is 3 MB located around 0x6D000000. I use this memory for access. The question is of course, can the Sonnet access this space through the Mediator (without translation/certain MMU setup).

You need to check what's really programmed in the BAR register of Voodoo card. It will tell you the address on PCI side of a bridge. I'm not sure if pciinfo outputs address after translation, or the true PCI address set in BAR. Anyway, this will be the address to use when programming Sonnet.

As maybe obvious from the above, I'm not too versed in MMU programming (yet) which I think is needed to set up PCI memory space correctly?

Not necessarily, you can avoid using MMU at all. There's a window into PCI address space and no amount of programming gonna change that. Using MMU to translate addresses only creates an illusion of linear address space. And if you are doing such low level programming, having this additional level of abstraction can additionally complicate things.

Thanks for the suggestions; I’ll come back here when I have further questions. I like a good puzzle, but I’m not certain if there is a solution :-)

Considering that SharkPPC never surfaced, there might be hardware problems we don't know about.

As I don't have the SDK for the PCI library

It is only available under super restrictive non disclosure agreement (we wouldn't be able to have this talk if either one of us had the access to official SDK). It's kinda difficult to interact with the library, without any kind of documentation. That's why for the purpose of your work, I suggest dumping it entirely and write the necessary parts yourself.