While the death of my beloved non-yellowed A3000 keyboard last month wasn't really worth mentioning, now the Voodoo card also has died. The screen just froze and the Amiga refused to reboot. I had to turn it off and on again to get it going. Now the voodoo card is no longer recognized by the mediator.
As the Sonnet needs PCI memory to start up, the development is on hold for the moment until I got a replacement. I noticed they are rather rare.
The A3000D is a cramped machine and Voodoo cards get rather hot. I would rather put it all in a tower. But then I would first need a 3.3V mod on the A3000T/A4000T mediator. I'll be looking also into getting it all to work on a Radeon card.
Stay tuned..
Tuesday, June 23, 2015
Friday, June 19, 2015
Dual CPU systems and their problems
While it took only a few weeks to get the first WarpOS programs going, some nasty problems reared their head which couldn't be solved immediately. As this project was intended to get me more active again with my Amiga and also to dust off my 68K assembly knowledge and finally get into PPC assembly it took me a while to know what was going on.
From the start, a second WarpOS program started after booting the system could and often would crash the PPC. It took a few weeks to understand that cache coherency was the problem and even more weeks to solve the problem. We can now run different WarpOS programs parallel and after each other.
As it stands now, the core is nearing completion. Of course, mostly the simple approaches were taken for speed regarding development, like a very simple scheduler. These things can be upgraded after we have a working library. Development speed isn't that high anyway with an average of 1 hour a day of me having time for it.
So what is there still to do... The communication from the 68K to the PPC is working but not really robust (read: it is hacked together). That is first on the list to do. After that, we need to finish up the remaining functions of the library except for the MMU functions. Next is the MMU address translation. At the moment, it is not in-line with WarpOS as the sonnet.library uses BATs instead of TBL. Then we finish up the MMU functions.
Then begins the more fun task of improving WarpOS compatibility so we can run the PPC MP3 decorder of AmigaAMP, the dnetc client and the WarpDT datatypes to name a few.
Here a screenshot of running WarpRace on the PPC and the 68K. Note that a recent update slashed the context switch from Call68K from 20ms to 13ms.
And here a teaser about a project I am looking into at the moment. Hint: PrPMC. Not sure it will ever come of the ground, though:
Wednesday, April 29, 2015
Some more progress: Simple PPC multitasking.
Now that we can execute PPC code from the 68K side, the next step is to execute 68K code from the PPC side. In WarpOS, this is done with the Run68K() function.
In a standard WarpOS program, the PPC task is setup by a 68K task, as the OS is 68K. When the PPC code is called from the sonnet library, the 68K task enters the WaitPort() function so the Amiga OS can execute other tasks while the 68K tasks waits for the PPC. We can use this same port from the PPC side (and so this waiting 68K task) to execute 68K code by sending a message to this port containing the information needed (called PPStruct within WarpOS). Actually, this port, set up by the sonnet library, waits for two types of messages (at the present). A message signaling that 68K code needs to be executed, or a message stating that the PPC has finished its code.
It's actually a bit more complicated than this, but we'll save the real tech talk for another time.
At the moment, the sonnet library only supports synchronous executing, which means that the 68K task waits for its PPC mirror task to complete before continuing and the other way around. For multitasking on the PPC side, we need to have code in place that puts the PPC task in a wait state when this happens and schedule another 'ready' PPC task. This code is commonly known as a 'Scheduler'. All this is of course already implemented on the 68K side by the Amiga OS.
When the 68K is ready, it signals the PPC that it can continue its code. So the sonnet library scheduler sets the task again in a 'ready' state and decides to put it into running based on priority compared to other 'ready' tasks,
So after putting Run68K() and a simple task scheduler in place, the WarpOS program 'Tabletennis' now works on Sonnet:
Now the less fun work begins as with the more complex programs, the ugly beast of cache coherency and consistency in a dual CPU system rears it head. So next up is to write code which properly handles the flushing and invalidation of caches.
In a standard WarpOS program, the PPC task is setup by a 68K task, as the OS is 68K. When the PPC code is called from the sonnet library, the 68K task enters the WaitPort() function so the Amiga OS can execute other tasks while the 68K tasks waits for the PPC. We can use this same port from the PPC side (and so this waiting 68K task) to execute 68K code by sending a message to this port containing the information needed (called PPStruct within WarpOS). Actually, this port, set up by the sonnet library, waits for two types of messages (at the present). A message signaling that 68K code needs to be executed, or a message stating that the PPC has finished its code.
It's actually a bit more complicated than this, but we'll save the real tech talk for another time.
At the moment, the sonnet library only supports synchronous executing, which means that the 68K task waits for its PPC mirror task to complete before continuing and the other way around. For multitasking on the PPC side, we need to have code in place that puts the PPC task in a wait state when this happens and schedule another 'ready' PPC task. This code is commonly known as a 'Scheduler'. All this is of course already implemented on the 68K side by the Amiga OS.
When the 68K is ready, it signals the PPC that it can continue its code. So the sonnet library scheduler sets the task again in a 'ready' state and decides to put it into running based on priority compared to other 'ready' tasks,
So after putting Run68K() and a simple task scheduler in place, the WarpOS program 'Tabletennis' now works on Sonnet:
Now the less fun work begins as with the more complex programs, the ugly beast of cache coherency and consistency in a dual CPU system rears it head. So next up is to write code which properly handles the flushing and invalidation of caches.
Monday, April 13, 2015
Some first results!
Of course I wanted to get some results quickly, but how to achieve that? Looking at WarpOS there are 2 critical functions who could help me to get just that: Results!
RunPPC and Run68K are the two main functions which execute code, RunPPC is called from 68K code to execute PPC code and Run68K is the other way around.
Looking at some of the sources of the demo programs included with WarpOS, the most simple ones just used RunPPC. But after a few hours of coding and a working RunPPC there was nothing to show for. Of course: code got executed, but no meaningful PPC functions were there yet, let alone functions with any meaningful output. So GetInfo() was included in the first version of sonnet.library and various tag functions. This resulted in the very first WarpOS-like program to be run: GetInfo!
Here it is. The MPC750 showing itself for the first time. The GetInfo program reads (amongst other info) the PVR which is a special register of the PowerPC with the CPU info in it.
Looking at the sources of the other WarpOS demo programs, it seemed that CyberPI was an easy program to convert. As the PowerPC of the Sonnet can only access the memory on the Sonnet itself (and PCI memory). WarpOS programs need to be patched to be loaded into the Sonnet memory. Three simple patches later this was the result:
CyberPI with 100000 decimals is completed in 1 minute and 28 seconds. Compared to:
50 minutes on a 25 MHz 68030
30 minutes on a 25 MHz 68040
15 minutes on a 50 MHz 68060
9 minutes on a 150 MHz 603e
4,5 minutes on a 200 MHz 604e
Cybermand also looked like a program which could be patched easily. And it worked almost out of the box:
Next stop is to get the Run68K going followed by multitasking (scheduler) on the PPC.
RunPPC and Run68K are the two main functions which execute code, RunPPC is called from 68K code to execute PPC code and Run68K is the other way around.
Looking at some of the sources of the demo programs included with WarpOS, the most simple ones just used RunPPC. But after a few hours of coding and a working RunPPC there was nothing to show for. Of course: code got executed, but no meaningful PPC functions were there yet, let alone functions with any meaningful output. So GetInfo() was included in the first version of sonnet.library and various tag functions. This resulted in the very first WarpOS-like program to be run: GetInfo!
Here it is. The MPC750 showing itself for the first time. The GetInfo program reads (amongst other info) the PVR which is a special register of the PowerPC with the CPU info in it.
Looking at the sources of the other WarpOS demo programs, it seemed that CyberPI was an easy program to convert. As the PowerPC of the Sonnet can only access the memory on the Sonnet itself (and PCI memory). WarpOS programs need to be patched to be loaded into the Sonnet memory. Three simple patches later this was the result:
CyberPI with 100000 decimals is completed in 1 minute and 28 seconds. Compared to:
50 minutes on a 25 MHz 68030
30 minutes on a 25 MHz 68040
15 minutes on a 50 MHz 68060
9 minutes on a 150 MHz 603e
4,5 minutes on a 200 MHz 604e
Cybermand also looked like a program which could be patched easily. And it worked almost out of the box:
Next stop is to get the Run68K going followed by multitasking (scheduler) on the PPC.
Monday, March 23, 2015
Flying at G3 Speed!
The next hurdle took the better part of half a year. Mostly as I shelved the project after unsuccessfully getting the PPC to execute code. But a posting on the English Amiga Board (http://eab.abime.net/showthread.php?t=76633) resulted in help from someone who had some success starting the card up on a modified Prometheus card The Prometheus (and most Mediators) are missing a 3.3V line. Well, lucky for us the Mediator 3000Di has one!
It only took the flipping of 2 bits to get the PPC to execute the code set up at $fff00100 which is the default vector of a PowerPC chip after reset. After re-reading the MPC107/TSi107 manual I actually found the paragraph stating the way to negate a reset of the CPU. Strangely enough, this was not mentioned in the example on how to boot the CPU but in a different part of the manual.
This person was also kind enough to share the code he lifted from the Mac driver for the Sonnet to initialize its RAM. So after a bit of tinkering we finally had code running on the PPC!
I don't have any meaningful pictures of it, as the only thing it does it to move bytes around in memory, but what was accomplished is that the RAM of the Sonnet was made to be recognized by the Amiga. This is done in the same manner as how the excess Video RAM is recognized and used by the Mediator software.
Next stop is to try to run software on the Sonnet which gives some meaningful output to a console or screen. It also would be great if this could be achieved using existing WarpOS software.
It only took the flipping of 2 bits to get the PPC to execute the code set up at $fff00100 which is the default vector of a PowerPC chip after reset. After re-reading the MPC107/TSi107 manual I actually found the paragraph stating the way to negate a reset of the CPU. Strangely enough, this was not mentioned in the example on how to boot the CPU but in a different part of the manual.
This person was also kind enough to share the code he lifted from the Mac driver for the Sonnet to initialize its RAM. So after a bit of tinkering we finally had code running on the PPC!
I don't have any meaningful pictures of it, as the only thing it does it to move bytes around in memory, but what was accomplished is that the RAM of the Sonnet was made to be recognized by the Amiga. This is done in the same manner as how the excess Video RAM is recognized and used by the Mediator software.
Next stop is to try to run software on the Sonnet which gives some meaningful output to a console or screen. It also would be great if this could be achieved using existing WarpOS software.
Monday, February 23, 2015
Signs of Life
Of course, where to start debugging a library which is officially encrypted? Well, in the distant past some people already wrote a decrypt program for the pci.library (the background story of the 'why' is also interesting, but maybe for some other time).
After a bit of digging the culprit was found (and accidentally, also the spider recognition code. Again, another story).
The Sonnet is a PCI card based on the MPC107 chip set, also known as the TSi107 chip set (at least mine is). This makes the Sonnet actually a non-transparent PCI-bridge. This means that the Amiga cannot directly communicate with the resources on the card.
To achieve this, these kind of PCI-bridges have address translation units (ATUs) on board so you can address the card through PCI memory. This is different from 'normal' PCI cards.
The Mediator treats the Sonnet as a normal PCI card. It writes all ones to the Base Address Registers (BARs) of all the PCI cards it can find. The PCI card responds with setting up a mask in the BAR to indicate how big the needed address space is. This will be allocated in PCI memory by the Mediator.
However, BAR0 of the Sonnet is actually an ATU. Writing all ones to this register does not result in what the Mediator expects. The value returned causes an infinite loop in the Mediator as it cannot allocate the appropriate size of memory it thinks it needs by reading back the ATU.
We insert some code to skip BAR0 if the PCI Vendor/ID matches the Sonnet and we add the approriate info to the vendors.txt file... et voila:
The Mediator reads all the values in one go and stores them inside a big array. As you can see, I inserted a dummy value for Memspace0 (BAR0) in this array.
Now we have the card detected without crashing, we are going to try to get it to execute code. The next task is to read up on how to program the MPC107 chip set. That's for another day.
After a bit of digging the culprit was found (and accidentally, also the spider recognition code. Again, another story).
The Sonnet is a PCI card based on the MPC107 chip set, also known as the TSi107 chip set (at least mine is). This makes the Sonnet actually a non-transparent PCI-bridge. This means that the Amiga cannot directly communicate with the resources on the card.
To achieve this, these kind of PCI-bridges have address translation units (ATUs) on board so you can address the card through PCI memory. This is different from 'normal' PCI cards.
The Mediator treats the Sonnet as a normal PCI card. It writes all ones to the Base Address Registers (BARs) of all the PCI cards it can find. The PCI card responds with setting up a mask in the BAR to indicate how big the needed address space is. This will be allocated in PCI memory by the Mediator.
However, BAR0 of the Sonnet is actually an ATU. Writing all ones to this register does not result in what the Mediator expects. The value returned causes an infinite loop in the Mediator as it cannot allocate the appropriate size of memory it thinks it needs by reading back the ATU.
We insert some code to skip BAR0 if the PCI Vendor/ID matches the Sonnet and we add the approriate info to the vendors.txt file... et voila:
The Mediator reads all the values in one go and stores them inside a big array. As you can see, I inserted a dummy value for Memspace0 (BAR0) in this array.
Now we have the card detected without crashing, we are going to try to get it to execute code. The next task is to read up on how to program the MPC107 chip set. That's for another day.
Sunday, February 22, 2015
Messing about with a Sonnet Crescendo 7200 G3 500 MHz
Well, in the end I just bought a second handed A2000 Mobo for like 5 euro's.... On to the next project :-) Here we have a Sonnet Crescendo 7200 model 500 MHz G3. It is fabled that this is the infamous SharkPPC from Elbox. Anyway, here it is installed in an A3000 with a Mediator board.
Took me a while to find the 5V EDO or FPM memory for it, but Ebay (and patience) is your friend. It has now 3x16MB installed on it. Doing a pciinfo (a tool from the mediator package) just hangs the A3000. We'll look at the problem in the pci.library next time.
Subscribe to:
Comments (Atom)