exxos's Atari, Amiga & retro forum

Based on what I've read on the eab forums this is a 030 + Akiko C2P issue rather than an issue with the TF330. (the SX32 should have this issue as well)

Turning off data cache or installing the 680x0 libs from aminet http://aminet.net/package/util/sys/Mu680x0Libs is supposed to solve it.

I must say that I've tried both and couldn't get either Doom or Gloom runnning via akiko's c2p and I appreciate any help on this. (in fact I can't get Doom running without graphical artifacts in any way, but that's probably another story)
Hope that clarifies that though a bit..

terriblefire wrote: 01 Apr 2019 12:34

nibiru wrote: 01 Apr 2019 00:56
Sorry, I was busy, I've replied to the question above, what are the other questions? I might have missed them. I am glad to help and do more tests, I was only trying to get light and trying to understand if this issue only happens to me or involves other people.

Cheers.

There are a few unanswered questions on the other thread. When I run whichAmiga it always sees the C2P.

My tests on this have been to check CDs can be accessed and played correctly. That requires Akiko to function.

I’m afraid I really don’t know what I’m doing software wise. Perhaps someone else can assist

wairnair wrote: 11 Apr 2019 08:28 Based on what I've read on the eab forums this is a 030 + Akiko C2P issue rather than an issue with the TF330. (the SX32 should have this issue as well)

I must say that I've tried both and couldn't get either Doom or Gloom runnning via akiko's c2p and I appreciate any help on this. (in fact I can't get Doom running without graphical artifacts in any way, but that's probably another story)
Hope that clarifies that though a bit..

What firmware are you on? I've repeated *multiple* times that with the V1 firmware Akiko works (despite needing the data cache to be off), with the latest optimized firmware it seems to disappear entirely from the system. The RTG config for DoomAttack, that is supposed to use system's WriteChunkyPixels() (Akiko accelerated on the CD32), does a mere 2-3fps, meaning that even the OS doesn't detect Akiko anymore. Same applies for Fusion (Mac emulator), that disables the Akiko video driver on the TF330 with the V2 firmware. It's still possible to force Akiko with fusion, but I get a mangled screen, as if the CPU was not getting back the converted data (similar to what you get with the V1 firmware and the data cache on).

Also, nothing of this applies to the TF328. Could you try to put the V1 firmware back and check if Akiko finally works for you (of course the data cache still needs to be off, or else you'll see garbage)?

I went up and down (V1 --> V2 --> V1), and with both firmwares the CD drive worked OK, so it is not entirely Akiko related, but only the C2P bit seems not to be detected.

And to make this post somewhat useful :-), I just downloaded the DoomAttack source from Aminet (http://aminet.net/package/game/shoot/DoomAttack_src), and briefly looked at the akiko2C2p init code:
...unfortunately it seems that it relies on the OS, and my bet is that the OS gfx.library also marks Akiko as non-available at some point :roll: :cry:

I think the bit failing is:
I'll try to see what's supposed to be at that location. IIRC Commodore never documented the direct usage of Akiko (as they were trying to push people to rely on the gfx.library, which in theory was a good idea, but given the lack of power of both AGA and the CPUs adopted, was a good way to contribute to killing the Amiga (AGA hardware documents had to be reversed-engineered or leaked by C= UK...).

Update (and good news!): I've written a tiny asm utility that will force again the Akiko pointer into the GFX library... guess what happens with the V2 firmware? :lol: :lol:

I'll add some error checks to it (some output messages, etc.), and if allowed I'll publish it here in the next days.

I'm now pretty sure that with the V2 firmware the 030 data cache is *on* when the OS tests for a working Akiko, so that a simple attempt to convert 4 chunky bytes (final check for a working C2P hardware) fails.

This happens as Akiko has one of the silliest designs ever: the CPU always reads and writes to the very same address, and this conflicts with the 030 data-cache "feature". Probably Commodore ignored the "feature" as well, as Akiko only existed on the CD32 (and maybe on the CD1200, so with some combinations of accelerated A1200s this bug might have popped up again). If only AGA was released 2 years earlier and AAA - that had native chunky - in 1993...

Next week (Easter!) I'll also redo the C2P benchmarks and post the results. 8-)

If you release the Akiko patch utility I am going to include it with the CF cards I ship out. Also in my case I can’t get the Akiko c2p to work even with the TF328 so maybe it’ll help.

Ok, so this utility makes the c2p_akiko2 conversion work, but the screen gets mostly garbled but it seems pretty fast. c2p_akiko still fails for me. I don't know if this is related to the Akiko version since I now only have rev0 to test since my rev A board died :(

alenppc wrote: 17 Apr 2019 14:49 Ok, so this utility makes the c2p_akiko2 conversion work, but the screen gets mostly garbled but it seems pretty fast. c2p_akiko still fails for me. I don't know if this is related to the Akiko version since I now only have rev0 to test since my rev A board died :(

From your description I think there are two different issues:

1) screen garbled: this also happens to me without the mmu.library *or* the data cache on. Have you tried to forcibly turn the data cache off? either this or your Akiko has an issue. I added a bare minimum error check in my tool for the "$CAFE" identifier, this means that you *do* have an Akiko.

2) c2p_akiko: this doesn't work for me either.

I ran the benchmarks again... the increase in speed with Akiko (DoomAttack) is still there, but nothing that would make anyone scream.

One (really) interesting thing: while I was doing the benchmarks changing configs, DoomAttack failed again to detect Akiko (had to rerun my tool), and this makes me thing that the OS tries to detect Akiko multiple times, which is weird.

The other interesting finding:

• Launched DoomAttack without my patch, it went in RTG mode (ie: OS WriteChunkyPixels()) ~ 2/3 FPS
• My patch was run (while Doom Attack was open)
• Amiga + M, back to the Doom Attack screen in RTG mode: 9-10 fps (as with the c2p_akiko2...).

This basically says that anything that calls WriteChunkyPixels() (I can think of a few programs) would get a noticeable acceleration on a CD32, even if the way Akiko works is super-lame and doesn't free the CPU at all (it's a rotating memory... we should add a "chunky mode" to the CD32 in a different way ahah).

There is an error in the DoomAttack c2p_akiko routine:

jsr _LVOCacheClearU(a6)
move.l 4+12(sp),a0
move.l c2pi_GfxBase(a0),a6

Second instruction should be:
move.l 4+16(sp),a0

Gooeyblob wrote: 18 Apr 2019 00:20 There is an error in the DoomAttack c2p_akiko routine:

jsr _LVOCacheClearU(a6)
move.l 4+12(sp),a0
move.l c2pi_GfxBase(a0),a6

Second instruction should be:
move.l 4+16(sp),a0

Any chance you could recompile this?

alenppc wrote: 18 Apr 2019 19:44

Gooeyblob wrote: 18 Apr 2019 00:20 There is an error in the DoomAttack c2p_akiko routine:

jsr _LVOCacheClearU(a6)
move.l 4+12(sp),a0
move.l c2pi_GfxBase(a0),a6

Second instruction should be:
move.l 4+16(sp),a0

Any chance you could recompile this?

Fixed version is attached! 8-)

Although I don't think it would make a difference, as this bug only exists in the c2p_akiko, and the only difference with the c2p_akiko2 is that the former is more OS-friendly and obtains a lock on the Blitter before accessing Akiko (and this is another sign of a dying Commodore: lock the blitter to gain access to Akiko was probably quick and dirty, but also a total nonsense).

I was also getting screen corruption before installing the mmu.library. The mystery for your hardware is still open, next step I'll try to put on a CF your setup and see if the same happens to me.