thebajaguy
Member
This will be the Support anchor post for the GuruROM v6.16 + Adapter ROM pieces I have started to ship as of mid-March 2019.
The sale interest thread is here: https://www.amibay.com/showthread.p...ies-II-and-C-A2091-A590-v6-16-omniscsi-device
I'd prefer it if the sales thread is not clouded with questions and tech issues that might come up, so please come here.
I realize there is lots of documentation written in the main thread, and I have a manual almost ready. A good amount of it should at least be reviewed as it applies to your SCSI controller board. Below is a quick set of things to cover, as several were topics that came up even back in 1993 during GVP Tech Support days.
As I have had a chance to test lots of combinations and come to understand where plenty of bottlenecks in systems occur, I will reiterate: Not all combinations of hardware will see performance improvements. If you are at the speed limit of your SCSI drive's media-head transfer rate (or it's interface design), it won't go faster. If you have one of the boards where you can't clock the 33C93A to 14MHz, you will hit another speed limiter. C= controllers which have DMA copy-up to >16MB RAM on a 32-bit accelerator situation may improve over the classic C= ROMs, but both them and GVP FastROM (with HD8/HC8/HC Series II) environments are then limited by the CPU copy-up process, which leaves you somewhere around 1/2 of the Zorro II bus speed as a limiter, and then whatever CPU/32-bit memory combination you have to figure in that mix. What you do get is a more versatile tool set (GVPSCSICtrl, OmniSCSICtrl, etc) for unique environments, better multi-tasking of the SCSI bus (DC/RC is stable even at 7MHz SCSI clock for C= controllers), and no need to track down an updated -08 33C93A SCSI chip if you have an older one on a C= controller (any 'A' variant should be good, with -04 seen on many). In some optimal situations, the speed limit is raised a good amount into the 2MB-3MB/sec environments.
A refresher on SCSI Termination:
TD---D---D---DT
T=Terminator, D=Device, --- is cable/bus. Two terminators, one at each distant end.
Pitfalls: Most GVP cards, and C= cards, except the GVP 68040/33, have soldered in terminator packs. By using the internal 50 and external 25, you are breaking SCSI termination spec if you use both interface connectors. You might get away with just a 1"-2" cable inside on a hard card (w/drive that has no terminators) and something actively terminated external, but Sync speeds could be a problem where Async previously was not. Technically, the SCSI controller card is a Device, and it shouldn't have terminators if it's in the middle. I can't fix the shortsightedness/cost control efforts of C=/GVP from back then. I just know the issues it can cause.
When experimenting with Sync transfers on a device, use the "OmniSCSICtrl <ID#> Synchronous" command. HDToolBox defaults to not setting the Synchronous flag, and it is not an option to set on the 3.1.4 release HDToolBox. I am trying to get the next update to OS 3.1.4 to gain that flag somewhere, but no info is available if it will make it. Using the software tool method to enable Sync is the safe way, and is recommended.
Note the jumpers/dip switch settings on C= controllers. GuruROM 6.16 expects them to be in a default unmodified (7MHz) clock setting unless the correct jumper is added after physical clock modifications are done. Just know that 7MHz clocking and Sync operation is iffy with the 33C93A (on either maker's board), and it really needs 14MHz in order to do it within SCSI Sync spec. GVP boards, where settable, are expected to be in 14MHz mode if they have the option, and later products had 14MHz as the default.
Legacy C= HDToolBox controller setup may have needed Disconnect/Reconnect turned off in the boot block(s) to address bus hangs. Use OmniSCSICtrl <ID#> Disconnect to override (enable) a boot block DC/RC disable setting for testing. This is also the recommended method.
Use the tools to test settings before going to the effort of updating boot blocks with permanent settings. In most cases, the command early in S:Startup-Sequence to turn on the improved function is sufficient.
DMAMask and MaxTransfer values are unfortunate kludges that have been propagated by support tools making up for past driver limitations. When they are wielded by those that don't understand what they do, performance suffers.
The omniscsi.device is aware of every environment possible in the last 30+ years of Amiga 680x0 classic hardware. It expects any RAM <16MB (24-bit address space) to be DMA-accessible (a C= spec). It knows about any GVP hardware that can DMA into it's own >16MB 32-bit RAM (and any problem hardware within that lot). It knows about possible bus bugs in A3000/A4000 24-bit DMA to ChipRAM environments (and has an override if your system is stable doing DMA to that memory/wish to test). It knows how to handle Copy-Up to >16MB RAM ranges where the 24-bit addressing DMA processors can't get to for all other situations. It also handles device MaxTransfer values internally at device-optimal values. Therefore: FileSystem DMAMask should be 0XFFFFFFFE, and MaxTransfer should be 0x7FFFFFFF, for any media that will remain on a GuruROM-driven SCSI controller, or a GVP FastROM-driven interface. If the media will end up on other controllers at some point, you may have to make adjustments to those values for their needs, and accept the performance hit if it impacts your configuration. Note: A Mask of 0xFFFFFFFF will not adversely affect communications with GuruROM/omniscsi.device, as odd-boundary transfers are supported.
GVPCPUCtrl v2.6
- v2.6 is the latest version, and has an error code now displayed (for the next bullet point, if encountered), but v2.3 otherwise works fine. No system performance changes apply.
- Mixing the previous v2.3 GVPCPUCtrl tool with the older FastROM 4.x gvpscsi.device present may function (for a FastROM remap), but will produce a return code (20) that differs from the standard success (0), breaking scripts with low/default FailAt values. Use the proper tool from the GVP/GVP-M disks if you are on a configuration using the older FastROM driver for some reason. Use the version with the GuruROM Support tools with omniscsi.device active in the system.
- The GVP version of the tool, vs Ralph's GuruROM version of the tool, has a slightly different communications structure with the boards & OS. The latest versions of the GuruROM tool also avoids an obscure glitch in the FastROM activation. It was discovered years later that writing a 16-bit word to the enabling register - something that should have been legal, could cause a lockup. Writing a 32-bit longword to the register addresses the issue.
- The tool's 'MoveSSP' option will work with any 32-bit CPU accelerator board with FastRAM, moving the system table from ChipRAM to first available FastRAM. Very minor CPU benchmark improvements are seen, but it's benefit comes more into play while the system is under multitasking and I/O load (the System Stack resides in faster memory after this is run). This kind of tool is recommended for any accelerator configuration where the 32-bit FastRAM is software-added (non-AutoConfig) by a driver or a manual AddMem. Other packages, like MuTools, may perform this function (with an MMU) in one of it's tool options, and may avoid warnings from AV packages - just noting it here so that duplication of the function by two different tools is not done.
(I'll add more to this section as additional wisdom bubbles up)
I still owe everyone my docs and the latest tools. The sale thread has plenty of detail, and HDToolBox will get the basics done for new installations.
The sale interest thread is here: https://www.amibay.com/showthread.p...ies-II-and-C-A2091-A590-v6-16-omniscsi-device
I'd prefer it if the sales thread is not clouded with questions and tech issues that might come up, so please come here.
I realize there is lots of documentation written in the main thread, and I have a manual almost ready. A good amount of it should at least be reviewed as it applies to your SCSI controller board. Below is a quick set of things to cover, as several were topics that came up even back in 1993 during GVP Tech Support days.
As I have had a chance to test lots of combinations and come to understand where plenty of bottlenecks in systems occur, I will reiterate: Not all combinations of hardware will see performance improvements. If you are at the speed limit of your SCSI drive's media-head transfer rate (or it's interface design), it won't go faster. If you have one of the boards where you can't clock the 33C93A to 14MHz, you will hit another speed limiter. C= controllers which have DMA copy-up to >16MB RAM on a 32-bit accelerator situation may improve over the classic C= ROMs, but both them and GVP FastROM (with HD8/HC8/HC Series II) environments are then limited by the CPU copy-up process, which leaves you somewhere around 1/2 of the Zorro II bus speed as a limiter, and then whatever CPU/32-bit memory combination you have to figure in that mix. What you do get is a more versatile tool set (GVPSCSICtrl, OmniSCSICtrl, etc) for unique environments, better multi-tasking of the SCSI bus (DC/RC is stable even at 7MHz SCSI clock for C= controllers), and no need to track down an updated -08 33C93A SCSI chip if you have an older one on a C= controller (any 'A' variant should be good, with -04 seen on many). In some optimal situations, the speed limit is raised a good amount into the 2MB-3MB/sec environments.
A refresher on SCSI Termination:
TD---D---D---DT
T=Terminator, D=Device, --- is cable/bus. Two terminators, one at each distant end.
Pitfalls: Most GVP cards, and C= cards, except the GVP 68040/33, have soldered in terminator packs. By using the internal 50 and external 25, you are breaking SCSI termination spec if you use both interface connectors. You might get away with just a 1"-2" cable inside on a hard card (w/drive that has no terminators) and something actively terminated external, but Sync speeds could be a problem where Async previously was not. Technically, the SCSI controller card is a Device, and it shouldn't have terminators if it's in the middle. I can't fix the shortsightedness/cost control efforts of C=/GVP from back then. I just know the issues it can cause.
When experimenting with Sync transfers on a device, use the "OmniSCSICtrl <ID#> Synchronous" command. HDToolBox defaults to not setting the Synchronous flag, and it is not an option to set on the 3.1.4 release HDToolBox. I am trying to get the next update to OS 3.1.4 to gain that flag somewhere, but no info is available if it will make it. Using the software tool method to enable Sync is the safe way, and is recommended.
Note the jumpers/dip switch settings on C= controllers. GuruROM 6.16 expects them to be in a default unmodified (7MHz) clock setting unless the correct jumper is added after physical clock modifications are done. Just know that 7MHz clocking and Sync operation is iffy with the 33C93A (on either maker's board), and it really needs 14MHz in order to do it within SCSI Sync spec. GVP boards, where settable, are expected to be in 14MHz mode if they have the option, and later products had 14MHz as the default.
Legacy C= HDToolBox controller setup may have needed Disconnect/Reconnect turned off in the boot block(s) to address bus hangs. Use OmniSCSICtrl <ID#> Disconnect to override (enable) a boot block DC/RC disable setting for testing. This is also the recommended method.
Use the tools to test settings before going to the effort of updating boot blocks with permanent settings. In most cases, the command early in S:Startup-Sequence to turn on the improved function is sufficient.
DMAMask and MaxTransfer values are unfortunate kludges that have been propagated by support tools making up for past driver limitations. When they are wielded by those that don't understand what they do, performance suffers.
The omniscsi.device is aware of every environment possible in the last 30+ years of Amiga 680x0 classic hardware. It expects any RAM <16MB (24-bit address space) to be DMA-accessible (a C= spec). It knows about any GVP hardware that can DMA into it's own >16MB 32-bit RAM (and any problem hardware within that lot). It knows about possible bus bugs in A3000/A4000 24-bit DMA to ChipRAM environments (and has an override if your system is stable doing DMA to that memory/wish to test). It knows how to handle Copy-Up to >16MB RAM ranges where the 24-bit addressing DMA processors can't get to for all other situations. It also handles device MaxTransfer values internally at device-optimal values. Therefore: FileSystem DMAMask should be 0XFFFFFFFE, and MaxTransfer should be 0x7FFFFFFF, for any media that will remain on a GuruROM-driven SCSI controller, or a GVP FastROM-driven interface. If the media will end up on other controllers at some point, you may have to make adjustments to those values for their needs, and accept the performance hit if it impacts your configuration. Note: A Mask of 0xFFFFFFFF will not adversely affect communications with GuruROM/omniscsi.device, as odd-boundary transfers are supported.
GVPCPUCtrl v2.6
- v2.6 is the latest version, and has an error code now displayed (for the next bullet point, if encountered), but v2.3 otherwise works fine. No system performance changes apply.
- Mixing the previous v2.3 GVPCPUCtrl tool with the older FastROM 4.x gvpscsi.device present may function (for a FastROM remap), but will produce a return code (20) that differs from the standard success (0), breaking scripts with low/default FailAt values. Use the proper tool from the GVP/GVP-M disks if you are on a configuration using the older FastROM driver for some reason. Use the version with the GuruROM Support tools with omniscsi.device active in the system.
- The GVP version of the tool, vs Ralph's GuruROM version of the tool, has a slightly different communications structure with the boards & OS. The latest versions of the GuruROM tool also avoids an obscure glitch in the FastROM activation. It was discovered years later that writing a 16-bit word to the enabling register - something that should have been legal, could cause a lockup. Writing a 32-bit longword to the register addresses the issue.
- The tool's 'MoveSSP' option will work with any 32-bit CPU accelerator board with FastRAM, moving the system table from ChipRAM to first available FastRAM. Very minor CPU benchmark improvements are seen, but it's benefit comes more into play while the system is under multitasking and I/O load (the System Stack resides in faster memory after this is run). This kind of tool is recommended for any accelerator configuration where the 32-bit FastRAM is software-added (non-AutoConfig) by a driver or a manual AddMem. Other packages, like MuTools, may perform this function (with an MMU) in one of it's tool options, and may avoid warnings from AV packages - just noting it here so that duplication of the function by two different tools is not done.
(I'll add more to this section as additional wisdom bubbles up)
I still owe everyone my docs and the latest tools. The sale thread has plenty of detail, and HDToolBox will get the basics done for new installations.
Last edited: