Makes the Akiko C2P work again on TF330 boards ((c) Stephen J. Leary)
with the latest firmware.
· A CD32
· A TF330 board with the latest firmware*, or any board with a 68030
· Optional: mmu.library (http://aminet.net/package/util/libs/MMULib)
to have the data-cache automatically disabled for Akiko
* the tool will work on any CD32, but the issue seems to only affect some 68030
boards, due to the way the 68030 data cache works.
First test that the executable works on your system by launching it and checking
If it gives no errors, you can install it:
copy AkikoTFFix C:
And possibly add it to the user startup, like this:
* REMEMBER THAT MY TOOL WILL ONLY REENABLE AKIKO * in a OS-friendly fashion, but
to fully have the C2P routines working, you'd still need to either:
· Disable the CPU DATA cache (with: CPU NODATACACHE, for instance)
· Install the mmu.library (http://aminet.net/package/util/libs/MMULib)
The latter is preferred, so you won't have the (small) performance hit due to
a disabled cache.
DoomAttack comes with two C2P for Akiko. The "c2p_akiko" is more OS friendly
than the "c2p_akiko2", but also has a fatal bug, that will hang your CD32.
I've added a fixed version for those of you that like OS friendly code (for some
reason, Commodore required to obtain access to the Blitter before using Akiko. I
guess they had no more development time in the attempt to save the company from
If you are really curious, keep reading for the...
On a TerribeFire 330 board ((c) Stephen J. Leary) and the latest firmware the OS
is unable to detect Akiko, and this happens because the OS does a simple test to
make sure Akiko is actually working before other programs can also access it).
For some reason on a 68030 the data-cache invalidates the (simple) C2P performed
by Akiko, so the OS thinks Akiko is not working and won't set a pointer to it in
the graphics.library, aka: GfxBase->ChunkyToPlanarPtr). This issue seems to be
due to a "feature" of the 68030 data cache. Given the (simple) way Akiko works
(reading/writing multiple times from one single address, also known as a "corner
turn memory"), the OS would fail to test it when the data cache is on.
This also makes other programs like DoomAttack, Wing Commander and Fusion fail
to detect Akiko. And also any software using RTG by means of the
graphics.library/WriteChunkyPixels() function will not get the benefit of the
C2P acceleration provided by Akiko under these circumstances.
My tool will look for Akiko and reinstate the hw pointer. This makes the
aforementioned softwares work again.
Most notably, I was able to launch DoomAttack with the "c2p_akiko2" routine, and
it would fail back to the RTG mode (ie WriteChunkyPixels()). The original OS
routine is terribly slow and only gives ~2/3 FPS. By launching my tool while the
game was open, the FPS jump instantly back to 9-12 (the maximum speed achievable
by a 6803050Mhz!).
Repetita iuvant: again remember you'd still need to deactivate the 68030 data
cache or install the mmu.library (this will set the Akiko address as non
Final notes about Akiko: bear in mind that Akiko was not designed to be a proper
coprocessor (as the Amiga way of doing things would have required), but they
just had some space left on the main controller chip (again, Akiko) and thought
of a way to help a bit the standard 680EC020 coming with the CD32. Also, this
was probably due for marketing reasons (even in the hope to raise a bit the
Amiga asset value for a possible buyer of the company). As said above, the CPU
needs to write and read back all the data from Akiko.
This this means that on a 6803050 Akiko will:
· accelerate OS-friendly software (WriteChunkyPixels)
· slightly accelerate optimised software (DoomAttack gives +0.5 fps on my
· decelerate when a properly optimised CPU C2P routine is used
(Wing Commander CD32 Patched, as an example, is much faster with the
CPU C2P routine).