Performance of Akiko C2P on 030/50 CD32 systems - Page 13

alexh · 03 June 2024, 11:17

Out of curiosity did anyone with a TF328 (SX32 non Pro) come forward to test if 020@14MHz+FastRAM+C2P is slower than 020@14MHz+FastRAM+Akiko?

Karlos · 03 June 2024, 11:19

Quote:

Originally Posted by alexh

Out of curiosity did anyone with a TF328 (SX32 non Pro) come forward to test if 020@14MHz+FastRAM+C2P is slower than 020@14MHz+FastRAM+Akiko?

The only HW tests we've seen are from Lunda's 70MHz Beast. I am very curious to know where the cutoff point is.

Lunda · 03 June 2024, 11:37

Quote:

Originally Posted by Karlos

For the sake of completeness and curiosity, I've added Fast 2 Fast tests for the Akiko Naive, Akiko Naive (reg buffered) and Kalms versions.

Workbench screen mode set to PAL Hi-Res Lace 8 colors for fast chip writes. I often forgot to set this before testing...

Code:

Akiko Detected
Akiko verification test without CACR manipulation
C[0]: 0x80808080 P[0]: 0x01010101 E[0]: 0x0000000F FAIL
C[1]: 0x40404040 P[1]: 0x01010101 E[1]: 0x000000F0 FAIL
C[2]: 0x20202020 P[2]: 0x01010101 E[2]: 0x00000F00 FAIL
C[3]: 0x10101010 P[3]: 0x01010101 E[3]: 0x0000F000 FAIL
C[4]: 0x08080808 P[4]: 0x01010101 E[4]: 0x000F0000 FAIL
C[5]: 0x04040404 P[5]: 0x01010101 E[5]: 0x00F00000 FAIL
C[6]: 0x02020202 P[6]: 0x0000000F E[6]: 0x0F000000 FAIL
C[7]: 0x01010101 P[7]: 0x000000F0 E[7]: 0xF0000000 FAIL
Akiko verification test with CACR manipulation
C[0]: 0x80808080 P[0]: 0x0000000F E[0]: 0x0000000F PASS
C[1]: 0x40404040 P[1]: 0x000000F0 E[1]: 0x000000F0 PASS
C[2]: 0x20202020 P[2]: 0x00000F00 E[2]: 0x00000F00 PASS
C[3]: 0x10101010 P[3]: 0x0000F000 E[3]: 0x0000F000 PASS
C[4]: 0x08080808 P[4]: 0x000F0000 E[4]: 0x000F0000 PASS
C[5]: 0x04040404 P[5]: 0x00F00000 E[5]: 0x00F00000 PASS
C[6]: 0x02020202 P[6]: 0x0F000000 E[6]: 0x0F000000 PASS
C[7]: 0x01010101 P[7]: 0xF0000000 E[7]: 0xF0000000 PASS
Got Timer, frequency is 709379 Hz
Running Test Cases
	Allocated aligned fast buffers at 0x513f7250 and 0x5141b750
	Allocated aligned chip buffer at 0x3e010
Case 0: Copy
	Vanilla Fast to Chip Copy, 8 longwords at a time.
	No initialisation needed.
	Elapsed: 168320 ticks, 237 ms [20 frames, 84 fps]
	Perf   : 6904981 bytes/second

Case 1: Null C2P
	Chunky read from Fast and planar write to Chip, but no conversion.
	No initialisation needed.
	Elapsed: 167704 ticks, 236 ms [20 frames, 84 fps]
	Perf   : 6930344 bytes/second

Case 2: Akiko C2P (Limit)
	Register to Akiko to Register throughput
	No initialisation needed.
	Elapsed: 80951 ticks, 114 ms [20 frames, 175 fps]
	Perf   : 14357408 bytes/second

Case 3: Akiko C2P (Limit)
	Register to Akiko to Register throughput, CACR Write Allocation Disabled.
	No initialisation needed
	Elapsed: 128206 ticks, 180 ms [20 frames, 111 fps]
	Perf   : 9065461 bytes/second

Case 4: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip.
	No initialisation needed.
	Elapsed: 271686 ticks, 382 ms [20 frames, 52 fps]
	Perf   : 4277903 bytes/second

Case 5: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 347120 ticks, 489 ms [20 frames, 40 fps]
	Perf   : 3348255 bytes/second

Case 6: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko.
	No initialisation needed.
	Elapsed: 266729 ticks, 376 ms [20 frames, 53 fps]
	Perf   : 4357406 bytes/second

Case 7: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 313655 ticks, 442 ms [20 frames, 45 fps]
	Perf   : 3705493 bytes/second

Case 8: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Chip.
	Initialisation
	Elapsed: 268102 ticks, 377 ms [20 frames, 53 fps]
	Perf   : 4335090 bytes/second

Case 9: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Fast, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 172579 ticks, 243 ms [20 frames, 82 fps]
	Perf   : 6734576 bytes/second

Case 10: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Fast, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 177334 ticks, 249 ms [20 frames, 80 fps]
	Perf   : 6553997 bytes/second

Case 11: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Fast.
	Initialisation
	Elapsed: 248979 ticks, 350 ms [20 frames, 57 fps]
	Perf   : 4668050 bytes/second

Karlos · 03 June 2024, 12:36

Well look at that. Akiko is faster, provided you don't actually want to display anything

paraj · 03 June 2024, 17:50

Quote:

Originally Posted by Karlos

Well look at that. Akiko is faster, provided you don't actually want to display anything

If I'm interpreting the numbers correctly, it might imply that Akiko could be competitive on 030/50 if the conversion happens outside visible screen area (for example by converting some fraction of the next frame to be displayed in every vblank int routine). Would be a bit more complicated, but not much more so than a blitter assisted C2P. Probably not worth it for AB3DII though.

Karlos · 03 June 2024, 17:57

Something doesn't make sense for me here.

The fast to chip Null C2P takes 236ms (total) with 8 fast reads and 8 chip writes per "conversion".

The fast to fast Naive Akiko (CACR fixed) takes 246ms with 8 reads from fast, 8 writes to Akiko, 8 reads back from Akiko and 8 writes to fast.

That's twice the 14MHz bus access overhead, but it takes the same basic total time.

Make it make sense?!

Karlos · 03 June 2024, 17:57

There must be a bug, that can't be right.

abu_the_monkey · 03 June 2024, 19:00

maybe writes to and reads from the c2p register are not interleaved like reads and writes to chip ram are?

what speed/time would just a straight copy from fast to fast yield?

Karlos · 03 June 2024, 20:14

Quote:

Originally Posted by abu_the_monkey

maybe writes to and reads from the c2p register are not interleaved like reads and writes to chip ram are?

what speed/time would just a straight copy from fast to fast yield?

That's what the first test case is. And it's about the same as the null C2P one. Correction. No it isn't. You said Fast to Fast.

I've probably done something stupid like set up the wrong function pointer for a test case.

abu_the_monkey · 03 June 2024, 20:26

but without the conversion by akiko, if just reading from fast and writing back to fast takes less than reading from fast and writing to chip, it makes sense, no?

these both write to chip ram?

Quote:

Case 0: Copy
Vanilla Fast to Chip Copy, 8 longwords at a time.
No initialisation needed.
Elapsed: 168320 ticks, 237 ms [20 frames, 84 fps]
Perf : 6904981 bytes/second

Case 1: Null C2P
Chunky read from Fast and planar write to Chip, but no conversion.
No initialisation needed.
Elapsed: 167704 ticks, 236 ms [20 frames, 84 fps]
Perf : 6930344 bytes/second

Karlos · 03 June 2024, 20:41

What I am not grasping - and it's been a long day so maybe the penny is still in free fall on this one - is how the naive Akiko fast to fast conversion can basically be the same speed as the fast to chip copy. Both of them require writes to the 14MHz bus, but the akiko fast to fast test also requires reads from it as well.

abu_the_monkey · 03 June 2024, 20:47

but maybe it is not on the custom chip/chip ram bus? cos if it was the chipset could read it's output rather than the CPU?
this would give the CPU every available 'slot' so no bus contention?

alexh · 03 June 2024, 21:22

Quote:

Originally Posted by abu_the_monkey

but maybe it is not on the custom chip/chip ram bus?

It is not on the chip RAM bus as it is outside the 2mb address region. There should be no bus contention.

lmimmfn · 04 June 2024, 04:11

Im only just listening in here buy maybe akkiko assumes it is always dealing with chipmem-?

Thomas Richter · 04 June 2024, 06:47

Quote:

Originally Posted by lmimmfn

Im only just listening in here buy maybe akkiko assumes it is always dealing with chipmem-?

It's not dealing with any memory at all. It is just an I/O device with port registers.

Lunda · 04 June 2024, 08:37

Quote:

Originally Posted by Karlos

Something doesn't make sense for me here.

The fast to chip Null C2P takes 236ms (total) with 8 fast reads and 8 chip writes per "conversion".

The fast to fast Naive Akiko (CACR fixed) takes 246ms with 8 reads from fast, 8 writes to Akiko, 8 reads back from Akiko and 8 writes to fast.

That's twice the 14MHz bus access overhead, but it takes the same basic total time.

Make it make sense?!

I expected it to be faster. Register to Akiko to register took 180ms.

2 cache burst reads should take 6 clocks x 2 = 12 clocks(70 MHz) + some overhead.
8 fast writes 2 clocks x 8 = 16 clocks + not much overhead.

Lets say 30 cycles (70 MHz) / 5 = 6 cycles (14 MHz).

Akiko write + Akiko read ~ 6 cycles. 8 x 6 for register only. 9 x 6 for Akiko C2P + fast read write.

So 180ms x 1.125 ~ 202ms.

Edit: I just realized Data Cache Burst was off. 220ms now. That looks ok I think.

Burst on result:

Code:

Akiko Detected
Akiko verification test without CACR manipulation
C[0]: 0x80808080 P[0]: 0x01010101 E[0]: 0x0000000F FAIL
C[1]: 0x40404040 P[1]: 0x01010101 E[1]: 0x000000F0 FAIL
C[2]: 0x20202020 P[2]: 0x01010101 E[2]: 0x00000F00 FAIL
C[3]: 0x10101010 P[3]: 0x01010101 E[3]: 0x0000F000 FAIL
C[4]: 0x08080808 P[4]: 0x01010101 E[4]: 0x000F0000 FAIL
C[5]: 0x04040404 P[5]: 0x01010101 E[5]: 0x00F00000 FAIL
C[6]: 0x02020202 P[6]: 0x01010101 E[6]: 0x0F000000 FAIL
C[7]: 0x01010101 P[7]: 0x01010101 E[7]: 0xF0000000 FAIL
Akiko verification test with CACR manipulation
C[0]: 0x80808080 P[0]: 0x0000000F E[0]: 0x0000000F PASS
C[1]: 0x40404040 P[1]: 0x000000F0 E[1]: 0x000000F0 PASS
C[2]: 0x20202020 P[2]: 0x00000F00 E[2]: 0x00000F00 PASS
C[3]: 0x10101010 P[3]: 0x0000F000 E[3]: 0x0000F000 PASS
C[4]: 0x08080808 P[4]: 0x000F0000 E[4]: 0x000F0000 PASS
C[5]: 0x04040404 P[5]: 0x00F00000 E[5]: 0x00F00000 PASS
C[6]: 0x02020202 P[6]: 0x0F000000 E[6]: 0x0F000000 PASS
C[7]: 0x01010101 P[7]: 0xF0000000 E[7]: 0xF0000000 PASS
Got Timer, frequency is 709379 Hz
Running Test Cases
	Allocated aligned fast buffers at 0x513dabc0 and 0x513eebe0
	Allocated aligned chip buffer at 0x3e010
Case 0: Copy
	Vanilla Fast to Chip Copy, 8 longwords at a time.
	No initialisation needed.
	Elapsed: 168052 ticks, 236 ms [20 frames, 84 fps]
	Perf   : 6915993 bytes/second

Case 1: Null C2P
	Chunky read from Fast and planar write to Chip, but no conversion.
	No initialisation needed.
	Elapsed: 167235 ticks, 235 ms [20 frames, 85 fps]
	Perf   : 6949780 bytes/second

Case 2: Akiko C2P (Limit)
	Register to Akiko to Register throughput
	No initialisation needed.
	Elapsed: 93862 ticks, 132 ms [20 frames, 151 fps]
	Perf   : 12382503 bytes/second

Case 3: Akiko C2P (Limit)
	Register to Akiko to Register throughput, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 128092 ticks, 180 ms [20 frames, 111 fps]
	Perf   : 9073529 bytes/second

Case 4: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip.
	No initialisation needed.
	Elapsed: 237588 ticks, 334 ms [20 frames, 59 fps]
	Perf   : 4891857 bytes/second

Case 5: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 328831 ticks, 463 ms [20 frames, 43 fps]
	Perf   : 3534479 bytes/second

Case 6: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko.
	No initialisation needed.
	Elapsed: 271163 ticks, 382 ms [20 frames, 52 fps]
	Perf   : 4286154 bytes/second

Case 7: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 313476 ticks, 441 ms [20 frames, 45 fps]
	Perf   : 3707609 bytes/second

Case 8: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Chip.
	Initialisation
	Elapsed: 268881 ticks, 379 ms [20 frames, 52 fps]
	Perf   : 4322531 bytes/second

Case 9: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Fast, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 156646 ticks, 220 ms [20 frames, 90 fps]
	Perf   : 7419573 bytes/second

Case 10: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Fast, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 180304 ticks, 254 ms [20 frames, 78 fps]
	Perf   : 6446038 bytes/second

Case 11: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Fast.
	Initialisation
	Elapsed: 240479 ticks, 338 ms [20 frames, 59 fps]
	Perf   : 4833048 bytes/second

Karlos · 04 June 2024, 08:50

I think the cause of my confusion was that I thought the Akiko was subject to the same access contention as the chip memory, which is clearly not the case.

I was having a slow day lol.

Cammy · 04 June 2024, 09:19

Quote:

Originally Posted by alexh

Out of curiosity did anyone with a TF328 (SX32 non Pro) come forward to test if 020@14MHz+FastRAM+C2P is slower than 020@14MHz+FastRAM+Akiko?

I did back in 2008, here are my results (all tests were done in 320x200):

DoomAttack
A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)

ADoom
A1200 030/50Mhz 32Mb - 9133 realtics (8.2 fps)
Amiga CD32 68020/14Mhz 8Mb - 16294 realtics (4.6 fps)

I tried it again on the A1200/030, this time in Low-Detail mode, and got these results:
DoomAttack - 6525 realtics (11.4 fps)
ADoom - 7029 realtics (10.6 fps)

So as you can see, Low-Detail is faster and smoother, DoomAttack is faster than ADoom on 020 and 030, and the Akiko chip in the CD32 is actually quite useful for 3D games!

alexh · 04 June 2024, 10:19

Are you in a position to be able to re-try with the test program that Karlos has created?

Karlos · 04 June 2024, 14:08

Quote:

Originally Posted by Lunda

I expected it to be faster. Register to Akiko to register took 180ms.

2 cache burst reads should take 6 clocks x 2 = 12 clocks(70 MHz) + some overhead.
8 fast writes 2 clocks x 8 = 16 clocks + not much overhead.

Lets say 30 cycles (70 MHz) / 5 = 6 cycles (14 MHz).

Akiko write + Akiko read ~ 6 cycles. 8 x 6 for register only. 9 x 6 for Akiko C2P + fast read write.

So 180ms x 1.125 ~ 202ms.

Edit: I just realized Data Cache Burst was off. 220ms now. That looks ok I think.

Burst on result:

Code:

Akiko Detected
Akiko verification test without CACR manipulation
C[0]: 0x80808080 P[0]: 0x01010101 E[0]: 0x0000000F FAIL
C[1]: 0x40404040 P[1]: 0x01010101 E[1]: 0x000000F0 FAIL
C[2]: 0x20202020 P[2]: 0x01010101 E[2]: 0x00000F00 FAIL
C[3]: 0x10101010 P[3]: 0x01010101 E[3]: 0x0000F000 FAIL
C[4]: 0x08080808 P[4]: 0x01010101 E[4]: 0x000F0000 FAIL
C[5]: 0x04040404 P[5]: 0x01010101 E[5]: 0x00F00000 FAIL
C[6]: 0x02020202 P[6]: 0x01010101 E[6]: 0x0F000000 FAIL
C[7]: 0x01010101 P[7]: 0x01010101 E[7]: 0xF0000000 FAIL
Akiko verification test with CACR manipulation
C[0]: 0x80808080 P[0]: 0x0000000F E[0]: 0x0000000F PASS
C[1]: 0x40404040 P[1]: 0x000000F0 E[1]: 0x000000F0 PASS
C[2]: 0x20202020 P[2]: 0x00000F00 E[2]: 0x00000F00 PASS
C[3]: 0x10101010 P[3]: 0x0000F000 E[3]: 0x0000F000 PASS
C[4]: 0x08080808 P[4]: 0x000F0000 E[4]: 0x000F0000 PASS
C[5]: 0x04040404 P[5]: 0x00F00000 E[5]: 0x00F00000 PASS
C[6]: 0x02020202 P[6]: 0x0F000000 E[6]: 0x0F000000 PASS
C[7]: 0x01010101 P[7]: 0xF0000000 E[7]: 0xF0000000 PASS
Got Timer, frequency is 709379 Hz
Running Test Cases
	Allocated aligned fast buffers at 0x513dabc0 and 0x513eebe0
	Allocated aligned chip buffer at 0x3e010
Case 0: Copy
	Vanilla Fast to Chip Copy, 8 longwords at a time.
	No initialisation needed.
	Elapsed: 168052 ticks, 236 ms [20 frames, 84 fps]
	Perf   : 6915993 bytes/second

Case 1: Null C2P
	Chunky read from Fast and planar write to Chip, but no conversion.
	No initialisation needed.
	Elapsed: 167235 ticks, 235 ms [20 frames, 85 fps]
	Perf   : 6949780 bytes/second

Case 2: Akiko C2P (Limit)
	Register to Akiko to Register throughput
	No initialisation needed.
	Elapsed: 93862 ticks, 132 ms [20 frames, 151 fps]
	Perf   : 12382503 bytes/second

Case 3: Akiko C2P (Limit)
	Register to Akiko to Register throughput, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 128092 ticks, 180 ms [20 frames, 111 fps]
	Perf   : 9073529 bytes/second

Case 4: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip.
	No initialisation needed.
	Elapsed: 237588 ticks, 334 ms [20 frames, 59 fps]
	Perf   : 4891857 bytes/second

Case 5: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 328831 ticks, 463 ms [20 frames, 43 fps]
	Perf   : 3534479 bytes/second

Case 6: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko.
	No initialisation needed.
	Elapsed: 271163 ticks, 382 ms [20 frames, 52 fps]
	Perf   : 4286154 bytes/second

Case 7: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 313476 ticks, 441 ms [20 frames, 45 fps]
	Perf   : 3707609 bytes/second

Case 8: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Chip.
	Initialisation
	Elapsed: 268881 ticks, 379 ms [20 frames, 52 fps]
	Perf   : 4322531 bytes/second

Case 9: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Fast, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 156646 ticks, 220 ms [20 frames, 90 fps]
	Perf   : 7419573 bytes/second

Case 10: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Fast, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 180304 ticks, 254 ms [20 frames, 78 fps]
	Perf   : 6446038 bytes/second

Case 11: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Fast.
	Initialisation
	Elapsed: 240479 ticks, 338 ms [20 frames, 59 fps]
	Perf   : 4833048 bytes/second

What happens if you retest on an 8 bit low-res pal mode ? That's a better model when thinking of the true performance of chip writes for our use case.

03 June 2024, 19:00	#248
abu_the_monkey Registered User Join Date: Oct 2020 Location: Bicester Posts: 2,023	maybe writes to and reads from the c2p register are not interleaved like reads and writes to chip ram are? what speed/time would just a straight copy from fast to fast yield? Last edited by abu_the_monkey; 03 June 2024 at 19:54.

03 June 2024, 20:47	#252
abu_the_monkey Registered User Join Date: Oct 2020 Location: Bicester Posts: 2,023	but maybe it is not on the custom chip/chip ram bus? cos if it was the chipset could read it's output rather than the CPU? this would give the CPU every available 'slot' so no bus contention? Last edited by abu_the_monkey; 03 June 2024 at 21:00.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
C2P Performance issues	meeku	Coders. Asm / Hardware	10	09 April 2019 18:29
Alien Breed 3D CD32 - Akiko C2P?	wairnair	support.Games	9	06 July 2018 14:32
Gloom Akiko C2P?	Whitesnake	support.Games	5	23 April 2007 19:01
Blizzard 030/50 Accelerators	Parsec	Amiga scene	20	14 February 2004 17:48
Cd32 Emulator (AKIKO)	Doozy	support.WinUAE	3	06 December 2001 08:41

03 June 2024, 11:17	#241
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,470	Out of curiosity did anyone with a TF328 (SX32 non Pro) come forward to test if 020@14MHz+FastRAM+C2P is slower than 020@14MHz+FastRAM+Akiko?

03 June 2024, 12:36	#244
Karlos Alien Bleed Join Date: Aug 2022 Location: UK Posts: 4,483	Well look at that. Akiko is faster, provided you don't actually want to display anything

03 June 2024, 17:57	#246
Karlos Alien Bleed Join Date: Aug 2022 Location: UK Posts: 4,483	Something doesn't make sense for me here. The fast to chip Null C2P takes 236ms (total) with 8 fast reads and 8 chip writes per "conversion". The fast to fast Naive Akiko (CACR fixed) takes 246ms with 8 reads from fast, 8 writes to Akiko, 8 reads back from Akiko and 8 writes to fast. That's twice the 14MHz bus access overhead, but it takes the same basic total time. Make it make sense?!

03 June 2024, 17:57	#247
Karlos Alien Bleed Join Date: Aug 2022 Location: UK Posts: 4,483	There must be a bug, that can't be right.

03 June 2024, 20:41	#251
Karlos Alien Bleed Join Date: Aug 2022 Location: UK Posts: 4,483	What I am not grasping - and it's been a long day so maybe the penny is still in free fall on this one - is how the naive Akiko fast to fast conversion can basically be the same speed as the fast to chip copy. Both of them require writes to the 14MHz bus, but the akiko fast to fast test also requires reads from it as well.

04 June 2024, 04:11	#254
lmimmfn Registered User Join Date: May 2018 Location: Ireland Posts: 692	Im only just listening in here buy maybe akkiko assumes it is always dealing with chipmem-?

04 June 2024, 08:50	#257
Karlos Alien Bleed Join Date: Aug 2022 Location: UK Posts: 4,483	I think the cause of my confusion was that I thought the Akiko was subject to the same access contention as the chip memory, which is clearly not the case. I was having a slow day lol.

04 June 2024, 10:19	#259
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,470	Are you in a position to be able to re-try with the test program that Karlos has created?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)