ReA4091: SCSI2 on Zorro III for everyone!

[reinauer]

Originally Posted by NorthWay

That looks like a lot of logic - can't those be consolidated?
Cool stuff!

Yes, as I wrote in post #1, likely a single CPLD could replace most of the logic. But the purpose of this initial revision is to create a replica of the original.

[patrik]

Do you plan to sell them? I would be very interested in one of those in original form as shown above.

[macce2]

I'm really interested, too !

[Hedeon]

Originally Posted by patrik

Do you plan to sell them? I would be very interested in one of those in original form as shown above.

Same here. Any way to make it a half zorro card so I can put it in a mediator without blocking PCI slots?

[grelbfarlk]

Keep in mind, the A4091 has really poor performance with an A3640 or a CSMK2. Usually around 5MB/s. If you have some Z3 RAM and it's promoted to highest priority it's somewhat better, closer to 7MB/s.

[Matt_H]

Originally Posted by grelbfarlk

Keep in mind, the A4091 has really poor performance with an A3640 or a CSMK2. Usually around 5MB/s. If you have some Z3 RAM and it's promoted to highest priority it's somewhat better, closer to 7MB/s.

Hey, it's better than stock IDE. And better than no SCSI at all.

[grelbfarlk]

Originally Posted by Matt_H

Hey, it's better than stock IDE. And better than no SCSI at all.

If you have a need for SCSI, sure.

[Damion]

Originally Posted by grelbfarlk

Keep in mind, the A4091 has really poor performance with an A3640 or a CSMK2. Usually around 5MB/s. If you have some Z3 RAM and it's promoted to highest priority it's somewhat better, closer to 7MB/s.

This is an interesting topic: Likely stating the obvious here, but I believe the upper end of ~5 MB/s (also with my CSMK2) is due to Buster limitations, along with how various accelerators interface with the bus. While the raw transfer rate isn't great considering the capabilities of the SCSI chip (~9 MB/s), CPU use is very low, and filesystem performance with PFS is very good--in use, the system overall "feels zippy" with the 4091, and I've found it to be very reliable/stable. (In filesystem benchmarks, my 4091 tests identical to other acclerators here with NCR SCSI, namely the TekMagic 2060 and CyberSCSI).

Prioritizing Z3 (or motherboard) RAM has the same effect on my end (~7 MB/s, IIRC). However, even if data DMA'd in this fashion were to be beneficial in some sense (very large files?), you still have the problem of much slower CPU access to Z3/mobo RAM vs accelerator RAM, therefore, IMHO the latter is still best left at highest priority.

Some devices such as the Fastlane and DENEB can work around Buster's issues and show greater raw transfer rates, but at the expense of higher CPU use and an overall more sluggish system (in fact, the Fastlane performs only slightly better than the 4091 if configured to keep the system generally useful during extended transfers).

[grelbfarlk]

Originally Posted by Damion

This is an interesting topic: Likely stating the obvious here, but I believe the upper end of ~5 MB/s (also with my CSMK2) is due to Buster limitations, along with how various accelerators interface with the bus. While the raw transfer rate isn't great considering the capabilities of the SCSI chip (~9 MB/s), CPU use is very low, and filesystem performance with PFS is very good--in use, the system overall "feels zippy" with the 4091, and I've found it to be very reliable/stable. (In filesystem benchmarks, my 4091 tests identical to other acclerators here with NCR SCSI, namely the TekMagic 2060 and CyberSCSI).

Prioritizing Z3 (or motherboard) RAM has the same effect on my end (~7 MB/s, IIRC). However, even if data DMA'd in this fashion were to be beneficial in some sense (very large files?), you still have the problem of much slower CPU access to Z3/mobo RAM vs accelerator RAM, therefore, IMHO the latter is still best left at highest priority.

Some devices such as the Fastlane and DENEB can work around Buster's issues and show greater raw transfer rates, but at the expense of higher CPU use and an overall more sluggish system (in fact, the Fastlane performs only slightly better than the 4091 if configured to keep the system generally useful during extended transfers).

I can't speak for TekMagic 2060 or CyberSCSI as I've never had them, but other NCR 53c710 devices like the WarpEngine or the GVP Trex-2 actually hit 9MB/s regularly.
However if you are using an A3000 with an 030@25MHz on the motherboard, it should deliver somewhere in the range of 7-9MB/s with motherboard RAM and and appropriate SCSI drive.

[idrougge]

Can’t the drive's bit mask be set to utilise Z3 RAM instead of a blanket priorisation of said RAM for all purposes?

[grelbfarlk]

Originally Posted by idrougge

Can’t the drive's bit mask be set to utilise Z3 RAM instead of a blanket priorisation of said RAM for all purposes?

You would think so, but I don't think that works out with 32-bit systems.
The mask setting works as you'd expect to limit to ChipRAM, 24-bit DMA, and 32-bit *anything* in say an A2000.

In an A4000 with an accelerator or motherboard RAM highest priority is all that seems to matter with the A4091 or Fastlane.

[alexh]

I think this is very cool it's being remade. Perfect for owners who have older SCSI controller's and disks they want to keep. There is however another generation of storage controllers coming along integrated into the newer CPU accelerators such as Vampire and PiSTorm which move the storage controller to the other side of the 680x0 bus. Here, closely coupled to the SDRAM controller gives performance that is medium limited (e.g. The max speed of an SD card). Only one classic storage controller did this before, Cyberstorm MK III/PPC

[idrougge]

What sets the Cyberstorm Mk III apart from the Mk I or II, SCSI-wise?

[bubbob42]

Originally Posted by idrougge

What sets the Cyberstorm Mk III apart from the Mk I or II, SCSI-wise?

It features UW-SCSI.

[grelbfarlk]

Originally Posted by alexh

I think this is very cool it's being remade. Perfect for owners who have older SCSI controller's and disks they want to keep. There is however another generation of storage controllers coming along integrated into the newer CPU accelerators such as Vampire and PiSTorm which move the storage controller to the other side of the 680x0 bus. Here, closely coupled to the SDRAM controller gives performance that is medium limited (e.g. The max speed of an SD card). Only one classic storage controller did this before, Cyberstorm MK III/PPC

I'm not sure what you are referring to here. Most of the accelerators with SCSI on them had DMA access to the 32-bit RAM on the accelerator.
There were far fewer that didn't.

[reinauer]

Originally Posted by grelbfarlk

Keep in mind, the A4091 has really poor performance with an A3640 or a CSMK2. Usually around 5MB/s. If you have some Z3 RAM and it's promoted to highest priority it's somewhat better, closer to 7MB/s.

The point of this endeavor was never to produce the fastest possible storage solution for Amigas. Of course, if you bypass Zorro-III you can get more speed by directly attaching to the CPU bus.

If you simply want a faster computer, get a Raspberry Pi for the price of the NCR chip.

But if you have something to contribute and and produce, or simply enjoy cool Amiga hardware in 2022, this project might be for you.

[grelbfarlk]

Originally Posted by reinauer

The point of this endeavor was never to produce the fastest possible storage solution for Amigas. Of course, if you bypass Zorro-III you can get more speed by directly attaching to the CPU bus.

If you simply want a faster computer, get a Raspberry Pi for the price of the NCR chip.

But if you have something to contribute and and produce, or simply enjoy cool Amiga hardware in 2022, this project might be for you.

I did not mean to imply that this project is not worth doing. I was raising an issue that the A4091 is for some reason not performing as well as it should. Is it just the A3640 slowing things down as usual with the motherboard RAM? I'm not sure. Does an A4000 with an 030 accelerator come close to matching the performance of an A3000 with an A4091? I'm not sure.

[Damion]

Originally Posted by grelbfarlk

I was raising an issue that the A4091 is for some reason not performing as well as it should.

Just a guess, but it may not be the 4091 at all, but the way that the third party accelerator has to handle DMA to its own memory via the Zorro interface. (Keeping in mind the intended typical use scenario the 4091 was designed for, where CPU and controller were optimized to share the same local memory space.) The Fastlane and DENEB exhibit similar traits in this case with the MK2 Cyberstorm.

Originally Posted by idrougge

Can’t the drive's bit mask be set to utilise Z3 RAM instead of a blanket priorisation of said RAM for all purposes?

This idea tripped me up a little a few years ago. You'd have accelerator RAM prioritized, yet restricting the buffer to a lower priority region where the CPU has much slower access. (Even if a generic test showed a slightly greater transfer rate without the CPU being much involved, overall performance is worse, plus you introduce other weird problems.) You could prioritize the slower RAM, or remove the RAM from the accelerator (obviously neither of those are good ideas).

The case of the overclocked Cyberstorm MK2 is a bit of an outlier (since most popular accelerators had their own disk interface of course), but even so, the 4091 is a good reliable performer, and certainly a frackload better than internal IDE.

[patrik]

Originally Posted by idrougge

Can’t the drive's bit mask be set to utilise Z3 RAM instead of a blanket priorisation of said RAM for all purposes?

You can unfortunately not use the mask to prioritize certain types of ram. It will only work as a whitelist for range and alignment allowed for direct transfers. If a transfer address doesn't match the mask, the filesystem will have to do the transfer via some memory region it deemes safe (for example chipmem), perhaps in smaller blocks - very slow.

The thing is that it is the applications that allocates the memory used to transfer data to/from a file on a filesystem. This will normally be allocated from the highest priority/fastest memory available, without any idea about which mask the partition the filesystem has mounted, containing the file to read/write from/to has.

This is not because the programmer is lazy, it is just not practical to find out, plus if you are to do processing on that data, you don't want it in slower memory anyway.

If some memory is beneficial for transfers with a specific controller, you would as said need to specifically allocate it in an application to get the increased transfer rate, but then again, if you are doing anything with the data later, you most likely don't want it there anyway.

Setting the mask to anything more restrictive than what your storage controller hardware+software can manage without bugs will only hurt performance and never increase transfer speed. The whole idea with the mask is also just this - to be able to work around controller hardware/software bugs in a pinch.

The same goes for the alignment part of the mask. Say you have a DMA controller which cannot do better than even longword alignment, like the A3000 onboard SCSI unless you have latest DMAC + Ramsey, then you would still want your mask to be 0xFFFFFFFF instead of 0xFFFFFFFC, so transfers to/from word-aligned addresses are handled by scsi.device via fast instead of getting the chipmem+small block treatment of FFS. This part can easily be tested with diskspeed.

[grelbfarlk]

Originally Posted by Damion

Just a guess, but it may not be the 4091 at all, but the way that the third party accelerator has to handle DMA to its own memory via the Zorro interface. (Keeping in mind the intended typical use scenario the 4091 was designed for, where CPU and controller were optimized to share the same local memory space.) The Fastlane and DENEB exhibit similar traits in this case with the MK2 Cyberstorm.



This idea tripped me up a little a few years ago. You'd have accelerator RAM prioritized, yet restricting the buffer to a lower priority region where the CPU has much slower access. (Even if a generic test showed a slightly greater transfer rate without the CPU being much involved, overall performance is worse, plus you introduce other weird problems.) You could prioritize the slower RAM, or remove the RAM from the accelerator (obviously neither of those are good ideas).

The case of the overclocked Cyberstorm MK2 is a bit of an outlier (since most popular accelerators had their own disk interface of course), but even so, the 4091 is a good reliable performer, and certainly a frackload better than internal IDE.

The Fastlane yes acts in much the same way an an A4091 in that the HDD performance will increase when you force the Fastlane RAM to highest priority, though I guess if you used the absolute slowest RAM configuration on the Fastlane maybe it could be slower than motherboard or accelerator RAM.

The GVP Trexx 040 gave the fastest result with the Fastlane at one point, above a CS MK2.