-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get the sonnet.library working on the 1200TX mediator #21
Comments
Got some first results. Using the default MMU window of $80000000-$A0000000 did the trick. See http://amigafun.blogspot.nl/2015/12/picture-of-day-dualppc.html Will push the updated code later. |
Congrats on that, I saw the code, looks good to me. I really need to put back my A1200T together, now that I can test Sonnet with it. |
A (number of) function(s) appear(s) to be broken on the 1200TX. The only other program I tried didn't work (Quake2) It exits gracefully complaining about the soft_rend.dll not being available. It loads fine, however. I also see that the main program probes for a certain 68K port. I expect Run68K to be broken. Looking into it. |
Investigation into the problem is hindered by debug tools not correctly working in the environment created by the PCI library. Monam crashes and COP cannot read the gfx or sonnet memory (put into place using the MMU by the pci.library). Next to that some strange stuff is happening. The CyberPI program for example only outputs the pi result. The actual text before and after are not displayed. This is actually 68K code (Output() and Write()) called from the 68K part of the CyberPI program indicating that 68K lib function calling from gfx or sonnet mem is impaired, probably in combination with Z2 window shifting. I don't think we'll see a working Sonnet card on the A1200 this year. |
At the moment writing my own MMU setup code to replace the one in pci.library. Chopping up the 512MB from $80000000-$A0000000 in 8MB pieces. Every 8MB piece will point to the Z2 memory of $200000-$A00000. Only one 8MB will be marked valid, though The rest will be marked invalid. An access to an invalid 8MB piece will invoke the bus error handler. Inside this handler we'll shift the Z2 window and mark the new 8MB piece valid and the old one invalid. Will be using indirect page descriptors for VERY fast MMU switching. Both supervisor and user MMU trees must be addressed. In theory, this all sounds good, but I don't know yet if this will interfere with the workings of the pci.library. Even with MMU=no as option the pci.library still installs a bus error hook on the A1200, probably to catch PCI memory accesses. I'm optimistic, though :-) |
I wonder, would it be possible to use |
Also note that you should support 4MB pieces too, after all Mediator 1200 can be switched into 4MB window mode by jumper. |
Yes, I am using the mmu.library for this. Maybe pester the author about be able to set multiple indirect pages at once. I now have to do a Setproperties call for every page (4k...and that for 512MB)... Only during setup, though. The 4MB support will follow if this works for the 8MB window |
As I understand, @thorfdbg is the author of |
Oh, well, I've send him a mail already :-) It's a nice-to-have really as I can just program a loop. It is needed during setup only but it will shorten the setup time. Most setup time is already going in setting up the PPC MMU. |
Am 01.02.2016 um 13:06 schrieb Radosław Kujawa:
It's probably easier just to mail to this account. Not sure whether Greetings, |
Hello Thomas, Thank you for your answer. I was under the impression that using the I think I know enough to first try this all with the INDIRECT approach. I Let's see how that goes. Otherwise I'll do the single approach. I see that the docs don't explain what 'lower' (a1) is for The end goal is to make PCI memory access seem transparent to programs on Thanks again, Dennis.
That's one possibility. MAPP_INDIRECT has one drawback, however, and Then, you can rather quickly change the modes by SetPageProperties(). There is one drawback, however, namely that your properties will be If this is not acceptable, you can also install a page-table access AddContextHook(MADTAG_TYPE,MMUEH_PAGEACCESS,...) and you will be called as soon as the high-level function leaks through In case you want to recover from page faults, you should also set
MAPP_INDIRECT works also on larger page sets, though it then acts If you need to adjust an entire array, you have to use...
..exactly that. (-: It's a low-level function, i.e. on the same level as
As suggested above, I would go for SetPageProperties() which is usually 2016-02-01 19:55 GMT+01:00 Thomas Richter notifications@github.com:
|
Am 01.02.2016 um 20:17 schrieb DvdBoon:
The question is "how fast" is "fast enough". It would probably be A second question you need to answer yourself is whether the area you
Yes, as always. You need to set the MAPP_INDIRECT flag for that.
It will always point to the same descriptor for all papges in the area,
Not necessarily. You can also first set the pages to point all to the
Its the logical address for which the mapping has to be modified.
I see. So in essence, a write into the PCI area (logical address) has to If I may: It is probably easier not to use descriptors in first place. The downside is that this does not work for movem, i.e. it can only If nothing helps, I can probably add another flag to SetPageProperties() Let me know how it goes and whether I can do something for you to Greetings, |
Hello, 2016-02-01 21:04 GMT+01:00 Thomas Richter notifications@github.com:
For every access, that is correct.
I need to do a remap if the access is outside the current 8MB window. The
By looking at the upper bits of the logical address. These bits are used to Example: If I access $80000000. The mediator window need to move to this address so Then an access to $90000000 happens. Then I need to configure the mediator
I need to run 68K code from within PCI memory. As Amiga code is mostly
I need to run code inside the PCI memory. I think the above method is
I will, thanks for all your comments so far!
|
Using loads and loads of indirect pages using 1 page at the time with SetProperties takes too long, unfortunately (each access to SetProperties becomes slower and slower for every new page added). I am guessing doing a range using SetProperties is MUCH more efficient. I still like the indirect approach a lot. Maybe just set up with a single indirect page descriptor using the mmu.library and then adjust the table with all the needed indirect page descriptors outside of the mmu.library. |
Looking at the documentation of 040/060 it is maybe easier to just do a normal remapped for each 8 MB block. Set them all invalid except for the initial one and just change the 16 pointer level table descriptors which make up the 8MB blocks to mark them either valid or invalid when needed. I think i see the mmu.library does not (directly) support modification of tables. Probably won't work on other MMU's |
If you want my opinion, I think doing anything that would rule out 68030 usage is not very wise. 68030 is still hugely popular with Mediator owners (include me...). Maybe we could have separate methods of solving this problem for 68030 and 68040/68060. I have to admit I just don't know enough about 68k MMUs to be of any help here. I only dug a bit in NetBSD's 68k MMU code but it is very complex (over 66kB) and in NetBSD every process is living in a separate virtual address space - it's a design completely different than AmigaOS. Again, maybe @thorfdbg can add the necessary functions to I'd prefer to avoid messing with the MMU directly, I'm 100% sure that would cause further problems. Note that some people already have |
On 01.02.2016 22:29, DvdBoon wrote:
Try to setup the properties in inverse order, i.e. start with the
I believe I still have to think of a good design for all this. The Second, what happens if a context switch occurs and the tables are Third, what happens on DMA transfer. I need to cache-inhibit the Last, how to handle top-level modifications of the page layout. I do not have an immediate answer to these questions at this point, and But anyhow, thanks for looking into this. I'm confident we'll come up Greetings, |
All the help is appreciated :-). In the end, the only thing I really want is that I get notified when an access occurs outside the current Mediator window (being 8MB or 4MB depending on jumper) so I can slide this Mediator window to reflect the correct PCI memory range. I constrain this to only PCI memory addresses $80000000-$A0000000 to make life easier. 512MB should be enough for now. You say something about page sizes? I don't want to control them. I just noticed that I can also mark the pointer tables as being invalid. As I see it, there are 128 root tables controlling 32MB each (which is too big) the next level are pointer tables which control 128kb each. So I need to mark 32 (not 16, I miscalculated...) pointer tables as invalid to invalidate all the pages in the next level (at least on the 040. I assume that the 060 is the same. Don't know about 030). Also assuming a page size of 4k, Haven't looked what happens at a size of 8k. Or am I wrong here? I'll try the reverse addressing you mentioned first to stay mmu.library compliant. |
As an addition: (if the reverse addressing does not work) So I am thinking about doing 64 (in the case of 8MB) remaps of 8MB each with every one pointing to $200000 and marked as being valid. The level above it (the 32 table pointers for each 8MB window) I'll mark as invalid. When a hit occurs, I set the correct window (setting the (U)DT bits) on valid and slide the mediator window to the correct PCI memory address. The window we slide away from we mark as invalid. No need to use INDIRECT. Just need access to the pointer tables. |
On 02.02.2016 10:44, DvdBoon wrote:
Which you don't. (-: The problem is really that I cannot even ensure Greetings, |
For my information, you mean that on the mmu.library level, there is no tree just a list of pages? Ok, I get it now, I think :-) I could set it all up using the mmu.library and then directly poke at the pointer tables using the hardware, but with an outside rebuildtree everything gets lost. I'll come back to here when I tried the INDIRECT approach with starting at the top of the address range. |
Setting the properties in reverse order worked. Only the RebuildTree takes forever now. |
Am 02.02.2016 um 11:14 schrieb DvdBoon:
As a related question: How large is the window you want to map in? Does Thanks, |
The Mediator 1200 window into PCI memory space is 4MB or 8MB, depending on hardware configuration (a jumper, actually). The size does not change. If you want I can give you a detailed description how does it work. |
I like to map 64 8 MB windows or 128 4 MB windows to 1 static 8 or 4 MB window. If all windows are in place just switching on and off (valid/invalid) would be the fastest, I think. OR I like to map 1 8 MB window or 1 4 MB window to 1 static 8 MB or 4 MB window if creating and destroying a single remap on the fly is fast enough. In this case the whole 512 MB is invalid except for the 8 or 4 MB remap which is created on the fly. The previous one is destroyed (made invalid again). These 8 MB or 4 MB windows are on a 8 or 4 MB boundary starting from $80000000 up to $A0000000 The static window is $200000-$A00000 (Mediator Z2/PCI memory window, can also be $200000-$600000 in case of 4 MB).. The window size is determined at power up (using a jumper on the mediator) and does not change during operation. Extra info as to why the 512 MB: 512 MB is wanted as to address 256 MB of Radeon GFX memory and 128 MB Sonnet 7200 memory (or 128 Radeon / 256 Sonnet or 32 Voodoo / 256 Sonnet etc etc). These must be on their own 256 MB and 128 MB etc boundary so actually at least 128 MB is wasted. (small part in use by PCI config registers). This gfx/sonnet memory (~360 MB) has to hold PPC and 68K code. So for example: |
Am 02.02.2016 um 22:34 schrieb Radosław Kujawa:
I believe I understand how it works. I'm just trying to get the Part of the problem is that you would need to do the switch under However, most high-level mmulib interface functions use semaphore IOWs, the only chance to get the page swap done is by low-level Greetings, |
I'd highly suggest to use method discussed in this thread to access PCI memory space only. Remember that the window within Z2 memory space ( To access the PCI configuration space through this MMU mapping, we'd also need to mess with the second Mediator board, the one within Z2 I/O space. This board is internally divided into two 64kB spaces. However, the first 64kB is used to access Mediator bridge setup registers. The second 64kB space is shared between PCI configuration and PCI I/O space. Whether you see config space or I/O space there depends on register at offset Long story short, it would make things even more complex. I'm afraid touching it will create further problems, as only pci.library knows the current state of this area. On a side note, I really should write an article about low level Mediator programming... |
The PPC now starts up on the A1200 without the use of the MMU routines from the mediator (ENV:Mediator/MMU = No). It sets up its memory block of 128MB and reports it to the system. The next step is to use Thor's MMU library to shift the Z2 window around within this memory block when needed. I foresee a problem with 68K code from Z2-Window1 trying to access data from Z2-Window2. Both code and data needed by that code need to be located in 1 window. Any ideas welcome. |
As we know, AmigaOS exec will by default allocate the memory with highest priority first. Typically, this is the memory on turbo board. Unless we are talking about hunk marked explicitly as Sonnet PPC/Mediator DMA. If we have all hunks in the executable marked correctly, chances of such problems are minimal. But then, if we use some automated method to patch the binary and just add the Sonnet memory extended attribute to every hunj... Of course 68k code might also end up in Sonnet memory. Second thing... I was under impression that MMU can handle the situation where some service routine has to be executed to fetch both the code and data needed by the running application. If some 68k task is running on top of this virtual 128M address space, why does it care how often are we changing the window position? It only sees the virtual addresses. Maybe I'm missing something here? Besides, Mediator's memory management routines do seem to work in this exact situation? |
Hi folks,
Again, placing memory that is mapped by the MMU is a bad idea, and I The problem becomes even worse in case the memory can go away any time,
The MMU is not the problem, the processor is. As far as I remember, the IOW, in such a case, you end up with a ping-pong of bus-errors, and The 68030 is much more microcode driven than the 68060, and there it may
You're probably missing the situation where the data an instruction
I highly doubt this. I would rather believe that they simply ignore Greetings, |
I'm open for any other ideas. The way it is set up now on the A3000/A4000: PPC sets up physical memory from 0x0 - 0x10000000 Sonnet ATU (address translating unit) maps 0x70000000 PCI memory to Physical 0x0 Sonnet memory. Sonnet memory now is visible in PCI memory starting from 0x70000000. Any access from the 68K to 0x70000000 actually gets through to Sonnet memory 0x0 thanks to the Sonnet ATU. Any access from the PPC to 0x70000000 get remapped to 0x0 thanks to the PPC MMU. So both PPC and 68K access actually 0x0 when addressing 0x70000000. The Z3 window is from 0x60000000-0x80000000 and it also as a default points to the same addresses. (So 0x70000000 is actually 0x70000000). MMU is not in use by the pci.library (not needed). The Z2 window is from 0x200000-0xa00000. It is mostly in a state that it points to gfx mem/gfx hardware registers courtesy of the gfx driver. (0x200000 points mostly to either 0x80000000 or 0x90000000; addresses are a little bit different than on Z3). It can move to other PCI addresses if need be. Let's for the sake of argument say that, again, sonnet memory is at 0x70000000. So if we want to access 0x70000000 as in our previous example, we need to shift the Z2 window to this address and access 0x200000 OR access 0x70000000 with the 68K MMU redirecting 0x70000000 to 0x200000. The latter keeps addressing consistent for both processors (pointers etc.). And is what I want to achieve with the mmu.library WarpOS programs get loaded inside this 0x70000000-0x80000000 area as we can not readily distinguish 68K code from PPC code (except maybe for the first code hunk which is always 68K). So the Z2 windows needs to shift to different spots within 0x70000000-0x80000000 for the 68K to execute code or fetch data if need be. Indeed, maybe loading data from disk by WarpOS programs would give problems....But it normally would go through 68K DOS/Read(). I don't know how DMA is in this case. A couple of things: Data is mostly manipulated by the PPC (for speed, why else have a PPC) and not the 68K. I'll know after trying :-) |
I'm sure the issues Thor is mentioning are valid, but this discussion is in context of Mediator 1200 series only (we don't need to mess with MMU setup on big box Mediators). In case of Mediator 1200 we don't have to worry much about DMA. Nothing besides the CPU will access Mediator 1200. Even if some A1200 turbo boards have DMA-capable devices (like SCSI controllers), they typically only DMA to on-board memory on turbo card (no one ever expected that something will sit between the turbo board and main board, which has only chip RAM). Of course I could imagine some badly written driver might try that, but I think the risk is minimal. It would be a problem if we were talking about A3000/A4000, where DMA can happen to memory located anywhere. In context of Mediator itself, DMA can happen on the PCI bus only. Since PCI bus has separate address space (shared only through the window with 68k space), it shouldn't bother us. Such DMA-capable driver has to be specially written for the Mediator and would never use 68k addresses (since PCI device can't access 68k side at all). Btw. On a side note, I'm sure that you know but I wanted to stress that Z2 window address can change (it's not hardcoded to be at 0x200000, but is subject to normal AutoConfig mechanism). Of course when the window is 8MB there's just no more space available so it does have to fit at 0x200000 or it won't work at all. |
Just wanted to show (hopefully) how it works on the Z3 Amigas and what the problems are when transposing this on the A1200. Also, concerning AutoConfig, only the last few updates were regarding correct error handling and giving out error messages ;-) I still need to add window size checking, for example. |
Letting some time pass between various attempts to get it working on the A1200 let to the realization that maybe the 8MB window is actually made up from 2x 4MB windows. And indeed, some testing showed that it actually is the case. I successfully pointed the first 4 MB to 0x98000000-0x983fffff and the second 4 MB window to 0x99000000-0x993ffffff (so 0x200000 pointed to 0x98000000 and 0x600000 to 0x99000000). @rkujawa It was indeed bit 12 which is the selector. This makes it a lot easier regarding code and data in different windows. |
It's certainly possible. I must have never noticed the problem on NetBSD, as if I remember correctly, I mostly tested with 4MB window. However, I am a bit worried about trying to change window position bypassing pci.library. It might lead to some breakage of Mediator drivers. Or the these drivers might try to change window position when we least expect that. |
Drivers change the window by The voodoo driver does this using some sort of VBlank interrupt.as far as I 2016-07-20 9:22 GMT+02:00 Radosław Kujawa notifications@github.com:
|
As far as I can see, the changes to the mmu.library do what they are suppose to do. I can set up a memory range, for example 192MB at 0x40000000 for the sonnet and redirect it dynamically to the Mediator Z2 window at 0x200000. So that is good news. With FileX I can look at an arbitrary address range within that window. I can see the PPC debug output and also see the sonnet libbase and functions within this range. So also the library is correctly set up in Sonnet space. The bad news is that shifting the Mediator window seems to interfere with the Voodoo driver. Gadgets and icons are not updated, for example. Other things like the FileX window contents are updated. Looking a bit closer at the pci library I noticed that when the MMU is used by the pci library, the drivers only use a 4MB window, leaving the second 4MB window (at 0x600000) probably for the MMU. Needs some more investigation. |
I wonder if in this situation it would be better to use pci.library function for changing window position? At least that should solve the problem with other drivers using pci.library? |
I am using the functions of the pci.library at the moment. I'm not sure if I am using them correctly, though, because I lack the documentation. I can have a look at other drivers. And have another look at the bus exception handler of the pci.library. Want I meant with above post is to let the Mediator think it has a 4MB window and directly manipulate the second window with the sonnet.library. I think that is what happens when the option MMU=yes is set. Also with that option the pci library installs its own bus exception handler and manipulates the MMU directly. We don't want that. Like I said, I am now manipulating the full 8MB window using the pci library functions with MMU=no in ENV/Mediator. |
Understood. I thought you're no messing with the window register directly. I hoped that with the new version of pci.library we'd be able to avoid patching it. I agree with the idea to use 4MB window and try to manipulate the second one with sonnet.library. Using the pci.library's MMU mode is problematic, also agreed about that. Just that when MMU=no, library assumes that it can present the whole 8MB window space to the drivers... Which again is problematic, if we want to steal half of that. |
I'm going to revisit this soon. As it stands now, there are two options. One through the mmu.library (with MMU=no) and one through the pci.library (with MMU=yes). A recent development confirmed some of the above assumptions regarding the pci.library so I want to retry that again. I think that I now know why the earlier attempts were not succesfull. During the Sonnet Interrupt. I have to move the window myself. Normally this is done by the pci.library when MMU option is enabled but during interrupts the programmer has to do it. Looking back to the earliest code the sonnet interrupt did move the window but not always when needed. The interrupt calls functions like putmsg, getmsg and replymsg and these functions can address memory ranges which are not within the same Z2 window thus getting the wrong info. The solution would be to write those functions as part of the interrupt, such that the Z2 window gets moved to the right position (address of the message, address of the msglist, address of predecessor, address of successor and address of msgport for example). Fingers crossed. I already noticed that some WarpOS software depend on some output being negative when a failure occured. With the address range above 0x80000000 (and thus negative when signed) some of the programs don't work correctly. CyberPi for example. |
wXR at EAB added a bounty for this issue: |
PCI memory seems to be copyback. I need it to be cache inhibited like on the A3000/A4000. Maybe in the future this will change. Also, the address at which the WarpOS programs are running on the A1200 (>2GB range) does not help. I'm trying to get something in place that will bring it <1GB range (the max range the sonnet can install its memory into). |
I have a pci.library now which sets pci memory as cache inhibited. I'll try to move all Zorro window conflicting stuff out of the interrupt and into the master control process. (Supervisor versus user mode) and see if that improve things. The >2 gb addresses issue still needs to be resolved too. |
Again, no luck. Programs just halt after a while. Can be immediately, can be after 10 seconds. There is no crash. Both the 68K and the PPC task go to a wait status. |
Seems that it is related to the time between putting data in the queue that needs to be transferred to the PPC. When a message pointer is put in a certain register of the mpc107 this pointer is automatically transferred to a circular FIFO on the PPC side and an interrupt is raised. When writing two values into this register close to each other time-wise, the first message gets lost as it is not transferred to the ppc. I saw a same kind of behavior with the big box mediator while reading from this register. It should give unique pointers but sometimes the ppc side was not updated quickly enough and two consecutive pointers were equal. A simple compare and reread sufficed. Here it is a bit more difficult as I cannot test whether the message was updated correctly while writing. I might have to organize the FIFO manually and just use a simple interrupt when done. |
There are more latency problems. Every message that goes through the ports (the 2 PCI registers on the PCI memory side, OFQPR and IFQPR, ) have a chance to be missed on the A1200 Mediator. |
Looks like both the reading of free messages to send to PPC and reading of messages send from the PPC (so in both cases the 68K reading from the EUMB registers in PCI space) are affected. Now I also re-read when a duplicate is found from messages send from PPC and Voxelspace has been running for 2 hours now. Not sure if writing to the registers is affected. I already rewrote the sending of messages to PPC, but releasing used messages is also done by writing to these EUMB registers by the 68K. However, there is a pool of 4K messages so any problems here will show up MUCH later. |
Received an updated pci.library where the mediator automatically adjusts the zorro window also in the 0x10000000-0x20000000 range. Strange behaviour of some programs (Quake quitting on memory allocation error, cyberpi not printing any printf text, voxelspace not showing info window) seem to be resolved. |
move.l #$89000000,a0 does not work with current pci.library version. Version 11.0 and 12.0 worked with above program. Back to Elbox. |
Got a fixed library from Elbox and on the A1200 the Sonnet memory is now placed at 0x20000000 and up. This has solved some of the issues like no text output in WarpOS programs due to addresses being negative when >0x80000000. Simple stuff (the demos and tools from the WarpOS distribution seem to work now on my Amiga with the latest build. So the hanging which happened intermittently was also caused by the previous version of the pci.library. Voxelspace however seems twice as slow as normal. QuakeWOS (the software 3D version) crashes after loading AHI. There seems to be some memory trashing somewhere. |
Fixed the memory error. Now another error popped up while starting QuakeWOS. Some jump to zero page. |
If the Amiga OS handles anything which is in Sonnet memory, there is a chance on a crash. For example, the Wait() function inside the library crashes when entered with the 68K stackpointer pointing to Sonnet memory. I think this has something to do with the Supervisor context of the 68K MMU. The Wait() function itself calls Switch() which enters supervisor mode. Placing a StackSwap() with a normal Amiga memory stack pointer before and after the Wait() fixes this issue, but any switch to Supervisor mode with for example the 68K stack pointing to Sonnet Memory or the task structure itself residing in Sonnet memory can (not always) lead to a crash. I have to contact Elbox to see if their library uses the Supervisor context MMU (correctly). I know it is fully functional in mmu.library. Maybe consider again to try to implement the mmu.library. A complete rewrite of the AllocMem() patch is also a posibilty. 68K stack, 68K task structures needs to go to 68K memory, PPC segments, PPC library/device bases need to go to Sonnet memory. Seems more more and harder to implement, though. |
Latest build adds more compatibility. Stack and task structures are now forced to 68K memory. All the WarpOS v4 packages demos now work. FlashMandel works. WarpRace works. Voxelspace increased in speed from 80 to 100FPS at standard 320x240. Context switches are being measured at 400us. (In comparison the A3000 does 125FPS/200us). QuakeWOS crashes or hangs inside input.device. Same with Quake2 and ADoomWOS. Input device tries to traverse a list and data on it is from Sonnet memory. Somehow the memory is not there and it loads $FFFFFFFF into address registers. Looking into Supervisor mode and/or an Interrupt being installed by those games. Asking Elbox to fix the Supervisor MMU context also still an option. |
QuakeWOS was hanging as data was not loaded correctly. De first 16 bytes of files are skipped if the buffer of Read() is in PPC memory. This has been fixed for now by intercepting the Read() and putting the buffer in FAST RAM and then copy it to PPC memory. Now QuakeWOS runs with sound off. With sound on it still hangs during sound initialization. Most apps work now. Audio does not work. Warp3D needs testing. |
The assembly version of the library will not support the 1200TX mediator beyond what is implemented now. Refer to https://github.com/Sakura-IT/PowerPCAmiga for possible support in the new C version in the future. |
At the moment, the sonnet.library only supports the A3000Di mediator. This is a mediator which has the needed 3.3V line. The only other mediator which has the 3.3V line (and with a much larger userbase) is the mediator TX (when connected to an ATX PSU).
The current state is that the PPC is initialized by the sonnet library. It sets up its memory and communicates this with the 68K. The 68K however cannot properly address the sonnet memory. This is probably due to the Z2 window.
I suspect there are functions inside the pci.library to fix this. The memory of the sonnet should be initiated the same way as graphics memory (using the pci.library) and the relevant pci.library functions will probably contain MMU code.
I will investigate this further.
The text was updated successfully, but these errors were encountered: