Well, sort of. We are talking about the BigFoot Killer NIC here with a dedicated NPU for helping out with the network traffic to reduce latency and ping. It was advertised as giving you an edge to kill virtual people faster.
So why for the Amiga then? Well, the Network Processing Unit, or short NPU, is actually an MPC8343E PowerPC CPU running at 400MHz. The card also had 64MB DDR RAM on-board.
Here's a picture of the card with mega-awesomeness-superduper heat sink:
That NPU can be used to run WarpOS software when plugged into the Mediator:
This is a cheap alternative to the more expensive PPC accelerator cards. It only has 64MB on-board so don't expect running Quake III on it. Currently people are looking whether or not the on-board RAM can be upgraded by the means of modding.
Of course it is fun to play with the old stuff on the Sonnet and the Rapture card. But how about new stuff?
The old GCC compiler for WarpOS (2.95.3) was hopelessly outdated and VBCC doesn't support C++ and most of the C sources out there need some adaptation to compile on VBCC.
Enter another project of mine: mos2wos. This stands for MorphOS to WarpOS and is a set of tools to develop for WarpOS on MorphOS machines. Now you can use the newer GCC binutils from MorphOS and what is even better, you can use GCC compilers version 4.4.5, 5.5.0 or 6.4.0 to produce WarpOS executables!
It took a few months to mature, but it is getting to a point that it is getting usable with a freshly compiled SDL library especially made for WarpOS and a very up-to-date C library (newlib 3.0) making porting even more easy!
How useful is it? Here are some examples compiled with version 0.8:
Some glitches here and there and a annoying mouse pointer in the way, but it's getting there. I also notice I need to silence my A3000UX PSU one of these days.
There has been a little movement on the WarpOS front as of late. Cowcat, who did a great job the last few years on Quake2 and BlitzQuake now tried his hands on Hexen II.
Here is the result:
Sound needs an overhaul and I guess I need a better camera, but for a first beta is it really cool. Well done!
When deleting hyperionvideo.library (no movies...alas) and with using the latest ReWarp library you can actually play Shogo MAD and Freespace (sort of...). At least it seems to be a lot more stable than with the old powerpc.library. No crashes while playing. There's one at the start of Shogo which isn't in the old library. I have to track that one down.
Starting up Shogo through the shell as the start GUI crashes (with both ReWarp and old powerpc lib):
The loading screen if you are fast enough. With no movies it goes by quickly:
The in-game menu. Warp3D renderer also works, but the game becomes very dark and unplayable. Maybe there is a gamma option somewhere. Also some glitches in the 3D with hardware acceleration enabled:
Start of the game using the software renderer:
Second level:
Bit further in the second level. Sometimes, NPC models seem to be missing:
Let's look at FreeSpace. Here the launcher works (with the wizard.library from OS4Depot). Don't forget to activate the Warp3D patch when playing. This game is actually playable now:
Works with all sounds enabled:
The tech room with the various models:
Flying around in your ship.. I rather have a blue HUD :-)
As a bonus here's a screenshot of Heretic II demo which also works:
WipeOut2097 running. It has black boxes for shadows. Maybe some Warp3D setting:
At this stage, it has become apparent that 2 things can hamper your experience regarding ReWarp:
Stack. If you encounter a DSI it is most likely stack related. WarpOS programs seem to need a lot.
Warp3D: I recommend Wazp3D to check if it runs in software and patchWarp3D from Aminet if your Amiga freezes (with no GR).
The original warposemu has documentation stating what works and what doesn't. Next time we'll go through the 'does-not-work' list.
Progress on the ReWarp project has been slow but steady.
Most of the functions are in with only a few important ones missing (like WaitTime which is used by WipeOut). Also no FPU alignment exception code has been added. Last night, the code for CreateTaskPPC was added and the last of the tools from WarpOS (Multitasking) now finally worked.
So how about games? In the previous posting we had a movie of a Sam440 running QuakeWOS. Warp3D games crashed or gave strange output. They worked on wazp3d, but very slow.
Or is it more of the same? Anyway, I've been keeping myself busy with the re-implementation of the WarpOS emulation for AmigaOS4.
The last version of the original implementation is from 2009 and does not support (directly) the newer machines like X1000 and Sam460. Which means that popular games WarpOS games like WipeOut2097 can not be played under OS4.1FE.
During the Neuss show, Timothy de Groote from Hyperion had asked me, with my experience with WarpOS, if I could have a look at it. At the time, the sonnet library was still missing key features and I told him that I needed to implement those first. With the Aminet release of the sonnet library, that was accomplished.
Now I don't own any of the machines on which the original did not work. I have a very old AmigaOne XE 800MHz G4 machine and an even older A4000T with CyberstormPPC, both running OS4.1. Somehow, the A4000T is faster in the reboot so I started the project there (and I needed a lot of reboots in the early start-up of the project). Not having the machines became an obstacle after a few weeks of programming so Timothy kindly provided me with a Sam440 machine which I could borrow for development.
As the chip in the Sam440 is almost the same as in the 460 (the core of the AMCC440 and AMCC460 is both PPC440), I''m confident that anything running on the Sam440 should be running on the Sam460. The X1000 has the PA6T chip which is very much compatible with the older (G2-G3-G4-G5) types of PowerPC so anything running on the AmigaOne XE and my A4000 should also be running on the X1000.
The project is still in the early stages, but here's a move of running Quake on the Sam440:
Only 15% of the total functions of WarpOS have been implemented, but these are the most used/important ones so a lot of stuff should already work. Warp3D is a bit problematic as there seem to be a bit of incompatibilities between V4 and V5 of Warp3D. I have to look into that in the future.
With the introduction of the latest features in the sonnet.library: Correctly working mirror tasks and a shared signal system between the two CPUs, the compatibility with WarpOS has increased. Also some speed was gained (5-10%).
The major result is that in FreeSpace there now is sound. Also the timing task and the sound output task within ScummVM WOS are now correctly working.
Here are some movies with build 140 in action:
Samurai Showdown 4 for the Neo Geo (NeoMAME): I noticed later that the health bar is missing. This is an artifact of the chosen FrameSkip parameter (2):
Here ScummVM for WarpOS version 0.7.1. (no newer version, sadly enough): The heavy hick-up in the beginning is encoding related. It is however not running at full speed due to extra context switches due to CHIP memory access attempts by the PPC.
Finally FreeSpace: The Great War: I had to turn of music streaming due to artifacts in the sound output. It is not always there when I start the game. Need to investigate that one further. I cut out parts of loading screens to shorten the movie a bit.
The (working) programs and games in the previous movies/pictures had in common that they mostly consist of 1 running PPC task. The ones with more running tasks would freeze up after a while (main task got stuck in wait) or lost sound (sound task got stuck in wait).
A lot of debugging time went into this and a race condition was found during the messaging between the 2 CPUs.
1) AmiGeneratorT / Mortal Kombat II
2) DarcNes / Double Dragon
3) AmiGeneratorT / Sonic
4) WarpScummVM / DOTT
5) MAME / 88Games
6) UAEWOS / AIBB on LSD101 disk
7) WarpSNES / SuperMario World.
Some stuff is not optimized yet. ScummVM is accessing a lot of FAST memory still which maybe can avoided as each access is a context switch. Sound with Double Dragon is a bit weird in the menus, but I have seen this on a BPPC too.
Sorry for such a bland WB, I forgot to place my WB picture back after tests with WarpDT (no, not working yet). Also I really should install a silent fan into that A3000.
And see if you can spot the growling cat during the movie ;-)
The past few weeks have been mostly involving bug fixing, optimizing and other boring stuff. The coming weeks will probably see more of that, as the library is far from bug free.
But to fill the void here's a movie. The sound has been turned off. Also, my phone stopped recording during the last bit as its memory was full. So I guess that's for another movie.
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...
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.
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.
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
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.
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.