GVP A500-HD8 slower with TerribleFire 536

[StompinSteve]

Hello,

I have a TF536 in my A500Plus. The harddisk is a GVP Impact Series II with a ZuluSCSI to replace the old spinny thing. I had hoped that the SCSI performance would improve when I replaced the stock 68000 with the TF536. Unfortunately, it's actually somewhat slower, same speed at best. Raw reads (SysInfo for example) are about 808 KB/s. With the 68000 this was 1.1 MB/s.
So somehow, the TF has a negative effect on the GVP's performance.

I had a discussion with a couple of folks on EAB (incl. TheBajaGuy, who used to work at GVP) and we couldn't really figure out how to improve disk performance. Using a certain DMA mask, disk-performance is now very close to the days of the 68000 in this machine.
Discussion: https://eab.abime.net/showthread.php?t=113167

The same ZuluSCSI in my A1200 with Blizzard 1240 @ 40Mhz and SCSI-Kit IV does 5.57 MB/s read, 4.42MB/s write (SCSI-2, Sync Mode). So I know the Zulu is not the bottleneck. Even in the slower SCSI-2 Async Mode, the Zulu still reads with 4.4 MB/s.
The GVP cannot do Sync SCSI without a GuruROM (which I'm still trying to acquire) so I'm stuck with Async for the time being. But as the CPU is so much faster than a stock 68000, I hoped to improve SCSI performance, not make it slower

In the discusion, we tried many things. One of them is to see if the GVP still does DMA with the TF as commander in chief. It does. But only via its own 8 MB FastRAM.
When I disable the GVP's FastRAM, so only the 2 MB Chip, 1.5MB Slow (in Trapdoor) and 64MB FastRAM remains, SCSI performance is terrible because it cannot do DMA anymore.
It really needs the GVP FastRAM to be usable as it enables DMA to non-chip memory.
In the end, we had the feeling that the GVP DMA's into it's own 16-bit FastRAM, then it goes the long way round to the 64MB main RAM of the TF, explaining why the GVP is a bit slower with the TF installed vs. the 68000 with just 2 MB Chip, 1.5 MB Slow and 8MB Fast (in the GVP).

Is there anything I can do to improve the GVP's SCSI performance?
Would the TF534 have been a better choice in my use case? (my reasoning: maybe a different architecture? Only 4 MB RAM, no IDE Interface, I have no idea to be honest, I'm just blabbering here).

Kind regards,
Steve

[terriblefire]

yes it will be because DMA is not possible with the TF536. you could get parity by restricting the buffer memory type to 24bit dma.

realistically just don't use that GVP and a TF536. They're not designed to work together and the slow compatibility mode you get isnt worth it.

[StompinSteve]

Ok thanks for the clear answer. Would the TF534 be a better choice in my case?

[terriblefire]

Ok thanks for the clear answer. Would the TF534 be a better choice in my case?

No it will have the same issue. Your best bet is probably an ACA card of some sort. Jen's cards support all the edge cases but come with an extra price tag for the privilege.

[alenppc]

Ok thanks for the clear answer. Would the TF534 be a better choice in my case?

No it will have the same issue. Your best bet is probably an ACA card of some sort. Jen's cards support all the edge cases but come with an extra price tag for the privilege.

I don't think an ACA card would help either. The A500 is essentially a 16-bit machine and 32-bit CPUs are very slow to access 16-bit ram. The same problem happens on the A2000 with A2091 when you plug in a 32-bit accelerator, so I don't think there is any way around the slowdown problem.

[terriblefire]

No it will have the same issue. Your best bet is probably an ACA card of some sort. Jen's cards support all the edge cases but come with an extra price tag for the privilege.

I don't think an ACA card would help either. The A500 is essentially a 16-bit machine and 32-bit CPUs are very slow to access 16-bit ram. The same problem happens on the A2000 with A2091 when you plug in a 32-bit accelerator, so I don't think there is any way around the slowdown problem.

I mean i hesitate to ask but why not use the on board IDE interface on the TF. Its specifically designed to go like poop off a stick.

[sviru]

I don't think an ACA card would help either. The A500 is essentially a 16-bit machine and 32-bit CPUs are very slow to access 16-bit ram. The same problem happens on the A2000 with A2091 when you plug in a 32-bit accelerator, so I don't think there is any way around the slowdown problem.

I mean i hesitate to ask but why not use the on board IDE interface on the TF. Its specifically designed to go like poop off a stick.

Well I see the thread is dead. But I will answser from my perspective. I have the same setup. HD8+ is one of the most awesome looking piece for A500 ever made... plus it is from THE era.

[terriblefire]

I mean i hesitate to ask but why not use the on board IDE interface on the TF. Its specifically designed to go like poop off a stick.

Well I see the thread is dead. But I will answser from my perspective. I have the same setup. HD8+ is one of the most awesome looking piece for A500 ever made... plus it is from THE era.

I understand the aesthetics but you simply cannot DMA into the TF536 fast ram. Its impossible for reasons i've gone over many times before. So with it in compatibility mode it will function but be slow. There is nothing more to say here really.

[sviru]

Well I see the thread is dead. But I will answser from my perspective. I have the same setup. HD8+ is one of the most awesome looking piece for A500 ever made... plus it is from THE era.

I understand the aesthetics but you simply cannot DMA into the TF536 fast ram. Its impossible for reasons i've gone over many times before. So with it in compatibility mode it will function but be slow. There is nothing more to say here really.

Thanks. I have bought VXL30 instead. Will test it soon enough.