TF330 Performance Improvements

[alenppc]

This patched c2p routine works great on the TF328 for me! So I think the Akiko rev0 c2p doesn't work with 68030. Will test with a rev A if I can figure out how to revive my board.

[trixster]

I’m using v2 firmware. Akiko rev A

Whdload 3.1 setup using classcwb, blazewcp installed.

I’ve installed mmulibs with the installer; there’s now a 68030.library, 680x0.library and mmu.library in libs:

Muscan is installed but currently not called in my startup-sequence. Do I need this? Does mmu-configuration in envarc: have to be setup? Trying sys:rexx/rx Buildmmuconfig sys:envarc/mmu-configuration seems to crash the machine but I’m not sure I have to do this to correctly set up mmulibs. Guessing this crash is because my 030 does not actually have an mmu!

020 optimised c2p works fine and when doom starts up it confirms c2p double buffered is in use.

using the original Akiko and akiko2 c2p routines in doomattackprefs seems to load ok but when the game loads it says it’s running in RTG mode single buffered.

Using the akiko fixed patch from a little earlier in this thread also states RTG mode single buffered.

All versions, be they c2p double buffered or rtg single buffered, seem to run at the same fps in-game.

So are the akiko routines actually doing anything? Is the mmu 68030.library correctly configured?

[trixster]

For me the best is 020 blitter, by a good couple of fps. This is running Low Res NTSC 320x200

[alenppc]

Trixter, you need to run nibiru's akikofix utility before you can use Akiko c2p with the 330 (hopefully he'll post it here).

I am amazed at how much difference Akiko makes on the 328. Doom is actually playable on the lowly 020/14! Shame it was never really used back in the day.

And it does make a nice difference with the 030 as well. It's a shame Akiko rev0 has the bug that makes it useless on anything above 020.

[terriblefire]

For the TF360 i found a way to get a boot rom in there.. might work for a 128 byte rom for the TF330? If there was some code i could run to make Akiko detection happen then i could add that to my firmware?

[pipper]

WRT DoomAttack: I don't know what sources the DoomAttack version in use is based off,
but if its the same v0.8 source that's available on Aminet, there's a serious bug in how it allocates
the screen's bitmap, causing corruption with non-RTG modes (especially with the double buffered
c2p_020_blitter version)

A possible fix looks like this:
https://github.com/mheyer32/DoomAttack/ ... 4a188a1cbd

Disclaimer: I don't own a CD32, so I can't test if this makes any difference with the issues you're experiencing.

[nibiru]

For me the best is 020 blitter, by a good couple of fps. This is running Low Res NTSC 320x200

From my tests it seems 020+Blitter is basically equivalent to Akiko (double buffer), whereas in single buffer the 020+Blitter crashes.

I've published a slightly more polite version of my fix (with (c) message and better error checking) on Aminet. It also includes the patched OS-Friendly C2P for Akiko:

http://aminet.net/util/misc/AkikoTFFix.lha

Could you try this? Interestingly enough:

• For me it would even work after DoomAttack starts in RTG mode: the OS uses Akiko itself (when you call gfx.lib's WriteChunkyPixels() ).
• While doing the benchmarks, after I launched my fix utility, DoomAttack reverted to RTG, as if the OS would check for Akiko at multiple times (ie not just at boot).

I'd need to investigate more the second issue, I wish I had more time...

[nibiru]

This patched c2p routine works great on the TF328 for me! So I think the Akiko rev0 c2p doesn't work with 68030. Will test with a rev A if I can figure out how to revive my board.

Have you also checked Wing Commander Patched? It's perfectly playable with the "NoC2P" option that forces Akiko on the TF328.

It doesn't surprise me that on a 68020@14Mhz:

Akiko C2P: ready chunky bytes from fast-ram, write them to Akiko -- read back from Akiko -- write to chip-ram (the 68020 is sync with chip-ram).
CPU C2P: read chunky bytes, do *a lot* of bit operations, write to chip-ram

Edit: also the whole C2P is just a few bytes, so it fits perfectly in the instruction cache of the 68020 (and 68030, of course).

From what I've seen, on a 68030@50Mhz still gives a tiny advantage to Akiko, on anything above it (hint: TF360? ) Akiko would actually be slower (too many RAM accesses).

And this is also true for Wing Commander Patched: on the TF330 V2 is even too fast to play with the patched CPU C2P, while using Akiko makes it slightly slower and actually more playable

[trixster]

Using your new AkikoTFFix, here are some doom timedemo demo3 results (I think I’m using the retail wad, not the shareware or ultimate doom wad). There are 3863 realtics.

BlazeWCP installed. MMUlibs 68030.library and 680x0.library with patched WB3.1 setpatch.

Music (DAMusic_Midi.plugin) and sound effects are enabled.

I have reduced screen size so it has status bar and 2 levels of green border

020 Blitter - 11.83
020 Optimised - 10.77
Akiko2 - 11.86
Akiko fixed - 10.05

Sysinfo mips are 9.15 with mmulibs 030.library, down from 9.86

[nibiru]

Using your new AkikoTFFix, here are some doom timedemo demo3 results (I think I’m using the retail wad, not the shareware or ultimate doom wad). There are 3863 realtics.

BlazeWCP installed. MMUlibs 68030.library and 680x0.library with patched WB3.1 setpatch.

Music (DAMusic_Midi.plugin) and sound effects are enabled.

I have reduced screen size so it has status bar and 2 levels of green border

020 Blitter - 11.83
020 Optimised - 10.77
Akiko2 - 11.86
Akiko fixed - 10.05

Sysinfo mips are 9.15 with mmulibs 030.library, down from 9.86

Thanks. Pretty much in line with my findings.
I assume they are all in double-buffered mode.

BlazeWCP doesn't make any difference unless Doom starts in RTG mode (thus my fix didn't run). Still, I believe that Akiko would be pretty close to it.

You can try Akiko in single-buffered mode (020 optimized flickers and 020+blitter crashes in single buffer), and you should get an extra FPS out of it

I think you need to launch DoomAttack with --nodoublebuffer or something similar.