wairnair wrote: ↑Thu Apr 11, 2019 8:28 am
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:
Code: Select all
MACHINE 68020
INCDIR AINCLUDE:
INCLUDE exec/libraries.i
INCLUDE lvo/exec_lib.i
INCLUDE c2p.i
;**************************************************************************
MOVEQ #-1,D0
RTS
DC.B "C2P",0
DC.L Chunky2Planar
DC.L InitChunky
DC.L EndChunky
DC.L C2PF_VARIABLEHEIGHT|C2PF_VARIABLEWIDTH
;**************************************************************************
;Init routine
;4(sp) Width
;8(sp) Height
;12(sp) PlaneSize
;16(sp) C2PInit
InitChunky:
move.l a6,-(sp)
move.l 4+12(sp),d0
move.l d0,bitplanesize
cmp.l #32767,d0
bgt.s .badplanesize
sub #4,d0
move d0,patch1 + 2
move d0,patch2 + 2
move d0,patch3 + 2
move.l 4.w,a6
jsr _LVOCacheClearU(a6)
move.l 4+16(sp),a0
move.l c2pi_GfxBase(a0),a6
cmp.w #40,LIB_VERSION(a6)
blt.s .nogfx40
move.l 508(a6),d0
beq.s .noakiko
move.l d0,C2Pp
move.l 4+4(sp),d0
move.l 4+8(sp),d1
mulu d0,d1
lsr.l #5,d1
subq #1,d1
move d1,size
move.l #1,rc
.badplanesize:
.noakiko:
.nogfx40: move.l (sp)+,a6
move.l rc(pc),d0
rts
...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
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...).