3D In Motion!

I had some time off between cooking for the family x-mas dinner and had a look at Warp3D. I had looked at it before and back then it just crashed the system.

This time around I noticed that the ramlib_ppc task was the culprit. So I googled around and found that it was a common problem within WarpOS/Warp3D. The stack is just too small.

So I upped the stack size for ramlib_ppc and installed a 68k patch for ramlib itself and now the sonnet library hanged on a DSI when opening Warp3DPPC.library. Debugging showed that this was because Warp3DPPC.library was loaded into FAST memory. Memory the PPC on the sonnet card cannot reach.

So the InitSonnet program was adjusted to pre-load all the Warp3D libraries to the memory of the Sonnet and below is the result (e.g. 75 FPS on the Warp3D gears program).

On a side note: I had ordered multiple Sonnet cards from the US for $25 USD dollar a piece on http://resale.headgap.com/. Too bad they now removed it from their web shop without replying to me. I guess they didn't had it in stock anyway...

Happy New Year :-)

Picture(s) of the Day: Sonnet goes 3D

The pictures aren't very good, but hey... :-)

Here's the Sonnet running gearsppc.exe from the warp3d demo folder.

Here's a screenshot with my camera from a timedemo of 640x480

And here's 800x600. These are exactly the same results as the highest FPS on http://www.amigaspeed.de.vu/ indicating maybe there is a limit? 1024x768 sadly crashed.

Here a very bad picture of the test version of WipeOut. Couldn't get full screen... Something about not having the right modes.

Happy Holidays!

Happy Holidays!

Happy Holidays from the SonnetAmiga Team!

As the year closes it's time to show a clip about the current state of the library. ;-)

The fade in the sound is the monitor switching resolutions (it's a monitor with build-in speakers). As people might remember, this is 2 out of 3 of my personal goals done.

See you all in the next year! The new year resolutions are

*) Warp3D support
*) WarpDT support (Goal 3)
*) A4000D non black mediator mod
*) A4000D black mediator support
*) A1200 TX/SX support.

Hopefully Santa has some secret stash of Sonnets somewhere.... ;-)

Picture of the Day: DualPPC

Here's a picture of the workbench of my A1200 with a TX mediator and a BlizzardPPC:

More coming soon.

Quake II

While doing my weekly round on the Amiga forums, the following thread on the English Amiga Board caught my eye:

http://eab.abime.net/showthread.php?t=74679&highlight=quake2

It's about optimizing and playing with the open source part of the Quake 2 engine.  Somewhere halfway in the thread (and still in 2014, I think) there are WarpOS compiled binaries which begged to be tested on the Sonnet.

Of course, as far as I understand the comments made in the thread, the code is far from optimized. And that it wouldn't be as fast as with Warp3D (around 26 FPS at 640x480 on a 233 MHz 604e - with Voodoo3 - see http://www.alinea-computer.de/amigaspeed/q***e2.html)

Here is a video with the Sonnet running Quake 2 on a Radeon without Warp3D:

As it can be briefly seen, a speed of 14 FPS is reached with 640x480 using the software renderer. Which is about 4 times slower per MHz as the 604e with Warp3D. So I guess the next step is to get Warp3D going for the Sonnet. That way other games like WipeOut will become available for the Sonnet too (and along with a nice speed increase on some other games).

As a side note. You can see that the A3000UX is sporting 400+ MB of memory. This is actually 64 FAST ram, around 200MB Video RAM and 128MB Sonnet RAM. The latter two being available to the PPC at (almost) full speed. This is about as much as we can cram reliable in the 512MB Zorro-III window of the mediator without further MMU tricks. With a Voodoo this would be 16MB Video RAM (max) and 256MB Sonnet RAM (max) as the start of the Sonnet memory must be on a boundary of a power of 2 so either 512MB which cannot be done with the current code (it clashes with the video ram) or 256MB.

Until next time.

Picture of the Day: Multitasking

Introducing Picture of the Day (POTD) a.k.a.  Progress in Pictures.

A picture of the sonnet card doing multitasking. Running are the dnetc client, pixelomania and landscape. Programs finished during this time were cyberpi and cybermand.

Have fun!

MooOOoo!

One of the early goals of the project was to get some specific stuff running on the G3 processor. The WarpDT suite, the MP3 engine for AmigaAMP and the dnetc client (see distributed.net).

It took me the better parts of a week to finally get some results regarding the dnetc client. Of course it is a good thing that for every program I try to run I need to do a lot of bug fixing in the sonnet library, but it can be tiresome sometime :-) On the other hand it gives me more and more insight on the inner workings of WarpOS. Anyway here the first output of the client:

As you can see, the speed is as what is to be expected from a 500 MHz MPC750 processor. It still crashes on exit, but I guess that's for the next week :-)

And yes, I have not forgotten to look at the A1200, but I first want to have this 100% running.

Getting closer to Warp Speed!

The past few months I've told people again and again that the context-switch (the switch between both CPUs) was a major pain in getting to the full speed of the 500MHz MPC750 processor. With the time anything being between 12-20ms. This is a very long time if you take into account that the CyberStormPPC performs a context-switch within 0.5ms (so 25-40 times faster).

With the exchange of the Voodoo3 card with a Radeon card I even noticed the context-switch time going up to 90ms. At first it was a real bummer, then it dawned upon me that something was not right.

Further investigation revealed that the Sonnet was not connected to any interrupt line properly all this time. The interrupt being looked at was actually being triggered by the voodoo card. The Radeon card lacked this interrupt resulting in the longer context-switch time. (Technically, the 12-20ms while using the Voodoo was actually some kind of VBLANK of the Voodoo card, dependent on the actual refresh rate of the screen).

So the code was rewritten to let the pci.library set up the interrupt (no, I don't have the Elbox SDK...) and the following was the result:

This is almost exactly like the context-switch time as found on the CyberstormPPC cards. But what does this mean in real-life performance? Remember Quake doing 28FPS in the previous video at 320x240x8 (with the Voodoo3)? Well...here is a screenshot while using the new code (and the Radeon):

This is much closer to the expected performance. For example, Mediator plus Voodoo3 plus CyberstormPPC 233MHz does 30 FPS according to http://www.amigaspeed.de.vu/ This is all still using software renderers, by the way.

Next up is to try to get it all working in an A1200TX mediator. Stay tuned!

Quake revisited

The goal of this project was just to get the sonnet running for doing the heavy lifting next to the 68K. So datatype work, decrunchers, that kind of stuff...

Don't know what went wrong....

Anyway, last time I posted a Quake movie there was no sound and the direct access to the framebuffer (turbogfx option) was not working so it was running using the WPA8 routine from the cybergfx library.

That (and the camera shaking) has been fixed. I even threw in a neat icon to start the Sonnet from the Workbench. So let's look to a timedemo then. Keep in mind that it is still a software renderer, and that the card is crippled due to slow context-switches between the 2 CPUs. For a comparison, see http://www.amigaspeed.de.vu/q***e.html

Have fun!

Some more games on the Sonnet

Some more stuff is now almost working out of the box. I won't bore you with another movie. Here are non-shaky but nevertheless not so very good quality 'screen'shots.

More Mandelbrot...

Nah... :-)

This weekend I've been mostly busy to write some experimental routines to capture and handle Amiga hardware access by the PPC. This is the result for now

At the moment there is no sound. This Amiga 3000 does not have a sound card and the sonnet library at the moment does not handle CHIP memory correct (for Paula).

Also it now uses the WritePixelArray8 (WPA8) routine as direct frame buffer manipulations only result in a black screen with occasional flashing. That mode should be a lot faster than the WPA8 method, but I  could't wait to show you a working game.

Mandelbrot Revisited

Now that some of the more tedious stuff is in place, it is time to look if we can get some more programs to work. At the moment, no WarpOS program works directly. First it has to be patched so the AmigaOS loads the program into sonnet memory instead of Amiga memory (see the sonnetpatch program for that on git).

Then all kinds of memory requests can be made by the program. As FastMem has the highest priority, it ends up allocating this instead of sonnet memory. That's fine for 68K only programs, but not for our WarpOS programs we want to run on the sonnet. For now, a simple patch has been made that redirects memory allocations from PPC programs. The patch just looks at the last 4 characters of the CLI name and redirects if it is 1005 (for example Voxelspace_1005). It is not ideal, but it works for now (see the InitSonnet program, also on git).

One of the more simple programs, yet visually nice to look at is FlashMandelWOS. Here's a link from youtube where it runs on a 66MHz 68060 and a 200MHz 603e.

So we patched the program using sonnetpatch, then we just rename it to FlashMandelWOS_1005 and this is the result:

This is an example of one of the programs which plays nice with the two different OSes (AmigaOS & WarpOS). The requesters come up slowly as it is done by the 68K accessing the slow (from the 68K perspective) sonnet memory, but the speed of program itself is very nice.

Next up is to get some programs working which don't play nice. This is mostly during the start-up of the program. To do this we have to intercept Amiga RAM access by the PPC and redirect them to the 68K and direct the result back to the PPC. This is slow, but if it is only done during start-up (for example QuakeWOS checks the front most screen directly from the intuition library) it may be unnoticeable.

For now, let's end with another teaser.

.

More progress and bugs to thanks for it

One of the more complex programs for WarpOS is wosdb, one of the few debuggers for WarpOS. It had been sitting there on the issue list (https://github.com/Sakura-IT/SonnetAmiga/issues) for quite a while now. Until recently, the code for the sonnet library wasn't as far as to even think about getting it working. It is for example one of the few programs using exception handlers and next to that a score of other functions from the library like cache manipulation, memory pool creation and deletion, signaling, waiting for signals and some more.

A lot of effort was put to get it all working prior to Neuss as it would mark a level of code maturity. Sadly, Neuss came a bit too soon. However, a few weeks down the road and we have some results.

The most difficult part was to make the cache play nice as the debugger does not work with real breakpoints but placing trap instructions on the addresses it wants to put a breakpoint on. There are still some quirks to iron out but most things can be done like stepping through a program, disassembling and displaying memory and setting breakpoints. Hopefully it will help to get the even more complex programs going.

As for some more eye-candy which didn't make Neuss: Here is a teaser/still from a certain flashy program.

Neuss Event

As the Amiga celebrates its 30 years of existence, there were events all around the world set up by Amiga enthusiasts. I couldn't make the Amsterdam event (where I really wanted to check out the UltimatePPC) but the Neuss event was far enough later in the year to show something working, or so I hoped.

It was my intention to show something like an MP3 playing or some fast gfx decoding, but It was not te be. Almost all the effort went into making the library as stable as possible. It would be embarrassing to have to reset the Amiga every other couple of minutes.... Also a lot of effort was put into getting the wosdb WarpOS debugger going. I'll come back to that later.

So in the early morning of the 10th of October I set up my stuff in the event hall.

I was wedges almost behind the stand of Alinea Computer (here on the right) and Pascal from Ares Computer) but that didn't put a damper on things :-) Anyway, the A3000UX had thankfully survived the trip and below you see the Voxelspace demo running:

I was happy that in the end the Amiga crashed only once during the 8 hours it was on. At some points I had to break off the demo and show some other stuff (Cybermand etc.) and then back to the voxel demo. It all worked flawlessly. I removed the cap from the Amiga not only to let the people see what was inside, but because I was also afraid to overheat the machine (See the Aging Electronics post). At home, I'm actually running it again with the Amiga closed at the moment.

As seen on the picture the FPS of the demo is just about faster than a 060 and 40% slower than a 200MHz 604e PPC at this resolution. This is because of the many context switches going on between the PPC and the 68K processor. I'm looking whether I can improve here. I have to say that at higher resolutions the G3 becomes faster compared to the 604e or 68K. That is maybe for another posting.

I want to thank all the people I spoke with that day, it was real fun to meet you all. And I want to thank Markus especially for talking me into coming, as I threw all kinds of arguments in his face NOT to come :-)

A forced break

With the breakdown of the Voodoo3 card I was forced to take a break from coding for a while. A vacation and the Witcher III also didn't help :-)

It took a while for a Voodoo3 card to show up on any of the online market places and when it did, it came in two. With the help of my partner in crime from Poland, I even got a third one, so I guess that problem is solved for the time being. I also saw some Sonnet cards on Ebay for $35-50 even with 256MB of memory installed. Too bad they only shipped to the US.

Early September, I set out for 2 goals to be achieved before the Neuss event in Germany. The first one was a working wosdb. It is a debugger made by Frank Wille for WarpOS back in the days. I also wanted to show some eye-candy on Neuss, being a picture decompression datatype or a working AmigaAMP PPC MP3 plugin or dnetc client. The Amsterdam came too early to show something, but the Neuss event should have given me enough time to get somewhere, or so I thought.

Getting wosdb working took longer than expected. The program relies on a number of WarpOS functions I hadn't implemented yet or not tested yet, but if it could be made working, a lot of functionality of the sonnet.library would be shown to be working. Like exception-handlers, memory functions, message functions and task-switching.

There were a couple of obstacles. No implemented pool memory functions yet. This was fixed by code from the AROS project. No implemented exception-handler code. These were written from scratch. A bug in one of the library node manipulation routines and an access to Amiga memory, specifically the memory list.

That last item forced me finally to implement some MMU page table code to intercept calls to Amiga FAST memory. But in the end this was the result:

Next time something about the Neuss Amiga 30 Years event in Germany.

Aging electronics

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..

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:

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.

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.

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.

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.

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.