A500 + derringer 030@25 8MB + A590 issues

[sviru]

Hi I have a problem with this setup. First is speed test in SYSINFO is hanging the system when DRAM is added to the system (without DRAM 1,4MB/s). MASK parameter is set correctly.

The second iritating issue is when i lunch a game lets say SECRET OF MONKEY ISLAND with WHDLOAD(preload) it takes 90sec until the game starts.

This is with 32bit dram added to system memory pool. Without it the game starts around 10sec-15sec (with 2mb from 590). Cannon Fodder 60sec of waiting.

Don't know what to do.

[thebajaguy]

The A590 / A2091 is a DMA controller (both are same design/DMA chip and SCSI interface chip, with 0-2MB RAM option). It needs memory in the 24-bit address space it can transfer it to.

I'm assuming the Derringer places it's 32-bit memory all high above $0100.0000. I have one, but it's been awhile since I put it in. I come from the GVP side (an HD8), and it's also a DMA controller, and has the same address-access issues, but it's driver doesn't need the mask-hack (buffers it more efficiently). Getting off topic, though.

The A590 (and the A2091) scsi.device cannot natively transfer directly to memory >16MB address line (It cannot reach $0100.0000 and above). It must have a mask value of 0x00FFFFFF on the partitions to make the FastFileSystem buffer the transfer to the high 32-bit RAM.

ChipRAM is a valid place to transfer through, but because of Agnus DMA, its least preferred as Agnus has first dibs (it steals from the CPU accesses, which expansion bus DMA also shares).

Next best RAM is the 16-bit A590 on-unit FastRAM. That will be RAM that goes into $0020.0000-003F.FFFF (2MB) if populated and enabled. This is preferred in your situation. Unfortunately, FFS's overall buffering design to get the data to the 32-bit RAM is very inefficient. Transfer rates are therefore not very good.

I'd push the GuruROM which does a better job of buffering through the FastRAM with the full 32-bit mask set in the FS like the GVP, but I'm well behind on the waiting list to build them (Aminet). It's also a very tight fit in the unit (height of the ROM adapter), and for best results, there is an additional 14MHz hack for the 33C93A that is preferred, but not something for the non-technical person. The A2091 has an easier time on the clock adjustment (cut and jumper a 3-pin jumper), and no physical issues with ROM hitting the drive brackets.

For yur setup, make sure some FastRAM on the A590 is enabled (even 512K), and the Mask is what is noted above, and that will be the best you can do with scsi.device v6-v7.

-----

As an alternative, you might look into one of the IDE68K (reimplementatio of the mkl design from the mid 201x's) devices that go into the CPU socket. Not sure if it will work on the top side, but should on the under side pins (I've done similar on an A1000 in the past). An IDE flash DOM module, OS 2.05 or newer, will run it like the A600's interface, and while it's not a DMA controller, it will be better.

[sviru]

Originally Posted by thebajaguy

The A590 / A2091 is a DMA controller (both are same design/DMA chip and SCSI interface chip, with 0-2MB RAM option). It needs memory in the 24-bit address space it can transfer it to.

I'm assuming the Derringer places it's 32-bit memory all high above $0100.0000. I have one, but it's been awhile since I put it in. I come from the GVP side (an HD8), and it's also a DMA controller, and has the same address-access issues, but it's driver doesn't need the mask-hack (buffers it more efficiently). Getting off topic, though.

The A590 (and the A2091) scsi.device cannot natively transfer directly to memory >16MB address line (It cannot reach $0100.0000 and above). It must have a mask value of 0x00FFFFFF on the partitions to make the FastFileSystem buffer the transfer to the high 32-bit RAM.

ChipRAM is a valid place to transfer through, but because of Agnus DMA, its least preferred as Agnus has first dibs (it steals from the CPU accesses, which expansion bus DMA also shares).

Next best RAM is the 16-bit A590 on-unit FastRAM. That will be RAM that goes into $0020.0000-003F.FFFF (2MB) if populated and enabled. This is preferred in your situation. Unfortunately, FFS's overall buffering design to get the data to the 32-bit RAM is very inefficient. Transfer rates are therefore not very good.

I'd push the GuruROM which does a better job of buffering through the FastRAM with the full 32-bit mask set in the FS like the GVP, but I'm well behind on the waiting list to build them (Aminet). It's also a very tight fit in the unit (height of the ROM adapter), and for best results, there is an additional 14MHz hack for the 33C93A that is preferred, but not something for the non-technical person. The A2091 has an easier time on the clock adjustment (cut and jumper a 3-pin jumper), and no physical issues with ROM hitting the drive brackets.

For yur setup, make sure some FastRAM on the A590 is enabled (even 512K), and the Mask is what is noted above, and that will be the best you can do with scsi.device v6-v7.

-----

As an alternative, you might look into one of the IDE68K (reimplementatio of the mkl design from the mid 201x's) devices that go into the CPU socket. Not sure if it will work on the top side, but should on the under side pins (I've done similar on an A1000 in the past). An IDE flash DOM module, OS 2.05 or newer, will run it like the A600's interface, and while it's not a DMA controller, it will be better.

Thanks for such a detailed response. I thought that this might be the double edge sword here... I don't know how much improvement would there be from GURU roms.

So the best solution would be to sell derringer and a590 and buy TF536 I guess?

[thebajaguy]

I outline the best-case performance for the GuruROM in the Aminet thread. It's certainly better than default, more optimized than what FFS does, but no magic pill for top-end performance. DMA + CPU copy-up to the 32-bit memory space is limited to ~1/2 the Zorro II bus speed, with the accelerator speed and it's RAM being the varying factor off that base.

The TF would be a viable solution. With the IDE on the card, it will benefit from the faster CPU access to that interface and it's RAM. Get an IDE Flash DOM, and you get effectively 0-latency (vs spinning media) on access, and the power draw is likely less overall.