Will the big ram upgrade create any DMA trouble with SCSI cards?

If "flash only" is the goal for mass-storage, why use a SCSI card with an expensive flash adapter if you can use a Buddha and a CF card?

I think we all (in this retro Amiga community) ask ourselves 'Why'? The answers are never straightforward, nor identical, between different people and the machines/expansions they have.

Sometimes it just takes a hint like "Buddha is cheaper than those SCSI-to-flash adapters" to get people thinking

On any given day, in a stock 68K system (24-bit), the DMA controllers will out-perform the CPU-driven I/O cards (SCSI or IDE). The HC8, with it's interleaved CPU/DMA 14MHz on-card memory will be the best multitasker, leaving the CPU free to run while DMA happens for I/O. Both controllers can, with Sync SCSI and a willing device, effectively saturate the Z2 bus, and the CPU-driven interfaces cannot, in terms of I/O speeds. For the record, in a best-case speed race for only I/O and no care for how much the CPU can't run, the A2091 is a hair better than the HC8 in this classic system configuration. It's 33C93A-DMAC buffer runs more optimally than the 33C93A-DPRC's does. The 33C93A technically DMA's into the receiving port on those DMA controller chips, and the 16-bit DMA transfer happens to/from the memory destination.

Move these two DMA cards up to the accelerator-driven systems with both DMA-capable Z2 AutoConfig 32-bit RAM and non-DMA-capable high RAM, and you incur all of the CPU-lockout benefits and issues inherent with Z2 bus masters plus the need to copy-up that data at times to the upper address ranges. Halving the Z2 bus performance-wise is where your I/O speed limit comes from as the data has to move twice. The argument for moving onto CPU-driven I/O gains good traction since the CPU has to be involved anyway. The 32-bit memory performance, if good and the Instruction cache is running the copy-up code, can get some good numbers off the Z2 bus (for IDE). This is where the Buddha has a suitable place in the field. There's still the 3.4-3.5MB/sec speed limit in Z2, though, and one can't hit all of the optimal access windows all the time. Sync-clocked CPU-slot cards will of course do better in that, but they are rare in the A2000 (A2620 being one, old RONIN 030 cards being another). In an odd case, the DPRC 16-bit FastRAM (when none is low-mapped on the 32-bit accessible accelerator cards - n/a to this A2630 memory configuration) doesn't do the CPU-block due to DMA, but the CPU copy loop is still tapping the slower 7MHz 16-bit RAM for DMA buffering. It's just a bit more CPU, and therefore multitasking-friendly.

Then we get into the A2000 accelerator combos with the onboard SCSI (or IDE) and DMA options. The GVP 030/040 cards with DPRC on them are admittedly more like the A2091 without the nice interleaved memory access design, but they pull 2-3MB/sec in optimal cases, and there's a hack on the GF040 in a special case where I've seen over 4.5MB/sec. Move up to the mid-1990's 040/060 class accelerators with the 53C7xx SCSI/DMA chips on them, and you are back again in favor of the DMA cards, in both I/O performance and CPU-friendly multitasking. The Blizzard and TekMagic cards are among this group, and are lightning-fast in both CPU power and I/O. I've actually been working on an A2000 system with the Buddha and the Blizzard 060 (to copy off data as I look to upgrade it from 3.1 w/some 3.5/3.9-era additions to 3.2.1 ROM/Workbench), and it's no slouch in I/O with that kind of CPU power. It's just not the most optimal. The buddha is mine in this equation, and so is just a temporary backup point, but if the guy didn't have tape, removable media, and several drives in an external tower, the Buddha might be a modern answer, too.

I left out the 68000-680x0 accelerators now showing up with IDE interfaces on them (and RAM), but must acknowledge them. They still use the CPU to effect transfers. My brother wrote back in he early 1990's, and I updated with a partner more recently, the RSCP benchmark. It helps show what impact I/O activity (DMA or CPU-driven transfers) can have on multitasking performance (CPU free time) when a system is 'under load'.

The answers, as I noted, are never straightforward

We are having the conversation for this part on the FB Amiga forum.

I'm Robert Miranda on FB. I did see the note about the interest on Amibay, too. I'm currently traveling for work, so kind of limited in my Amiga side efforts.

As far as the GuruROM, there's nothing in it that is different than the FastROM v4.x series driver when it comes to the GVP series II cards operating in Async SCSI mode. The bump to Sync SCSI will help performance if other optimal system factors (described in the Amibay thread) are present. It does help address the known 24-bit->32-bit memory transfer limitations in the C= A2091/A590 scsi.device driver, and it's iffy reselection handling (multi-device situations) to equal the GVP. Beyond that, if there are instability issues present on the SCSI bus, pushing communications speeds to Sync SCSI will trip over them even quicker.

With the CPU copy-up necessary for the high memory on the accelerator, I caution expecting any notable performance improvement with Sync SCSI. Async SCSI at it's best pushes 2.2-2.3MB/sec to it's DMA-capable buffer, but the copy-up effort will generally knock that overall performance down to ~1.5-1.7MB/sec at best (about 1/2 Zorro II bus speed).

My suggestion on the SCSI2SD is to use the erase option on ExpertPrep (or just modify the 'disk' geometry in the SCSI2SD tool) - so as to negate any saved RDB info - blank out the initial sectors. Then experiment with the speed setting and other options in the general tab of the SCSI2SD tool. I don't have any gear with me on the trip, but I had to tame the v6 series this way on the latest firmware. I haven't updated my v5's firmware in several months.

One other suggestion, on any flash-media, is to base the Amiga filesystem block size on 4K (4096) instead of the formerly native 512-bytes. I'd actually set that value in the SCSI2SD tool so the Amiga prep tool will default to that. GVP's tool doesn't have that option (yet), but HDToolBox does. This block size / sector size is a general guide for any flash media 'disk' filesystem - it reduces flash media wear.

Quote from thebajaguy

My suggestion on the SCSI2SD is to use the erase option on ExpertPrep (or just modify the 'disk' geometry in the SCSI2SD tool) - so as to negate any saved RDB info - blank out the initial sectors. Then experiment with the speed setting and other options in the general tab of the SCSI2SD tool. I don't have any gear with me on the trip, but I had to tame the v6 series this way on the latest firmware. I haven't updated my v5's firmware in several months.

One other suggestion, on any flash-media, is to base the Amiga filesystem block size on 4K (4096) instead of the formerly native 512-bytes. I'd actually set that value in the SCSI2SD tool so the Amiga prep tool will default to that. GVP's tool doesn't have that option (yet), but HDToolBox does. This block size / sector size is a general guide for any flash media 'disk' filesystem - it reduces flash media wear.

The only problem with setting block size to 4096 bytes is that you can’t mount it in Winuae - it appears to be hardcoded to 512 bytes. At least I couldn’t find the way…

There are 2 ways to go about using 4K blocksize with flash media, or any media.

The first is to make the media report a blocksize of 4096 bytes. Back in the day, most disk drives always reported 512-byte sectoring. At GVP, we tinkered with some SCSI device internal pages (documented in the device's manual) to push the Quantum HD series into 1K and 2K modes for test purposes. That was how we verified the FastPrep/ExpertPrep tools could deal with different blocksizes. One interesting side note is the Bernouli removable drives used to use 256-byte sectors. It tended to hang most other Amiga controller drivers, but ours translates it (I'd have to ask Ralph Babel again what the trick was - my memory has lost the answer to time). With the SCSI2SD tool, you can tell the flash media device to report 4096 to the SCSI media query. This is assuming the 'drive' is connected via SCSI controller.

If you are using IDE Flash, you would have to go about mounting the 'media' manually with a mountlist that preserves the boot block area, but otherwise lets you write to the legitimate partition area. I don't use emulation, so my personal experience is theoretical. I am, however, drawing from the Kickstart 1.2-era when C= used Mountlists on the A2090/A2090a for FFS. You probably would have to do that geometry conversion math to keep things straight, though.

The next method is to just go into HDToolBox and make it ignore the 512-byte sectoring on the media detection read, and push in a 4096 value. It will adjust the head/sector/cylinder 'geometry' by the appropriate math to accommodate. Save it, and then go partition the media.

This blocksize setting / solution is missing from the released GVP FastPrep/ExpertPrep tools, so you can't do it with that tool. I legitimately have the source to the old GVP tools, but I haven't yet gotten it updated to the point where I'd let it out for public consumption. One thing I have yet to get working is large media (>4GB). I haven't had time to get my head around all the places that need the special math conversion (we are talking double-longword integers - add/subtract/multiply/divide, effectively). That, and also displaying it all correctly on the screen. Another thing is that the modern HDToolBox (since 3.1.4) has taken the liberty to 'expand' the space it reserves at the beginning of the 'media' for larger filesystem and partition data blobs. Back in the day, FFS was the only thing that went there. Now, it's technically possible to stuff several filesystems in the RDB that are not in the Kickstart ROM.

Quote from part12studios

would a TF536 50mhz 030 without an FPU be as good as or better

No. Those "TFxxx" cards have the "T" for a reason: Terrible. In your case, using them in an A2000 means that you'll have all sorts of trouble using Zorro cards. The TF card is good if you don't use any Zorro cards.

Quote from part12studios

running up stairs.. (good workout)

Sounds like a good thing indeed. Not enough people talking about physical fitness and the positive effects on the immune system. Prepare for the inevitable Corona infection...