TF330 Performance Improvements

68030 + SDRAM + IDE

Moderators: terriblefire, Terriblefire Moderator

wairnair
Posts: 34
Joined: Sun Dec 09, 2018 3:53 pm

Re: TF330 Performance Improvements

Post by wairnair »

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: Mon Apr 01, 2019 12:34 pm
nibiru wrote: Mon Apr 01, 2019 12:56 am
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.
terriblefire
Moderator Team
Moderator Team
Posts: 5368
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: TF330 Performance Improvements

Post by terriblefire »

I’m afraid I really don’t know what I’m doing software wise. Perhaps someone else can assist
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
nibiru
Posts: 22
Joined: Tue Mar 26, 2019 7:39 pm

Re: TF330 Performance Improvements

Post by nibiru »

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 :roll: :cry:

I think the bit failing is:

Code: Select all

move.l	508(a6),d0
beq.s	.noakiko
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...).
nibiru
Posts: 22
Joined: Tue Mar 26, 2019 7:39 pm

Re: TF330 Performance Improvements

Post by nibiru »

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-)
alenppc
Moderator Team
Moderator Team
Posts: 906
Joined: Thu Nov 08, 2018 12:59 pm

Re: TF330 Performance Improvements

Post by alenppc »

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.
alenppc
Moderator Team
Moderator Team
Posts: 906
Joined: Thu Nov 08, 2018 12:59 pm

Re: TF330 Performance Improvements

Post by alenppc »

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 :(
nibiru
Posts: 22
Joined: Tue Mar 26, 2019 7:39 pm

Re: TF330 Performance Improvements

Post by nibiru »

alenppc wrote: Wed Apr 17, 2019 2:49 pm 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).
Gooeyblob
Posts: 42
Joined: Thu Feb 28, 2019 8:23 pm

Re: TF330 Performance Improvements

Post by Gooeyblob »

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
alenppc
Moderator Team
Moderator Team
Posts: 906
Joined: Thu Nov 08, 2018 12:59 pm

Re: TF330 Performance Improvements

Post by alenppc »

Gooeyblob wrote: Thu Apr 18, 2019 12:20 am 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?
nibiru
Posts: 22
Joined: Tue Mar 26, 2019 7:39 pm

Re: TF330 Performance Improvements

Post by nibiru »

alenppc wrote: Thu Apr 18, 2019 7:44 pm
Gooeyblob wrote: Thu Apr 18, 2019 12:20 am 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.
Attachments
c2p_akiko_fixed.zip
(940 Bytes) Downloaded 247 times
Post Reply

Return to “TF330”