Results 1 to 7 of 7

Thread: GuruROM 6.16 for 2019 Support Thread

  1. #1
    Jack of Many Trades, Semi-Master of Some thebajaguy's Avatar
    Join Date
    May 2017
    Country
    United States
    Region:
    Rhode Island
    Posts
    343
    Feedback
    34 (100%)

    Default GuruROM 6.16 for 2019 Support Thread

    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: http://www.amibay.com/showthread.php...mniscsi-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 by thebajaguy; 20th July 2019 at 19:47.
    A500(2x)/A1000/A1200/A2000(4x)/A3000D(2x)/A4000D(under repair)/A4000T (all loaded....Toys...Toys...Toys...)
    Former GVP Tech Support 1989-93 - The beatings will continue until morale improves...

  2. #2
    MumPitz's Avatar
    Join Date
    May 2019
    Country
    Germany
    Region:
    RLP
    Age
    46
    Posts
    17
    Feedback
    0

    Default

    Is a G-Force 030 (Impact A2000-030 Combo Series II) also supported?

  3. #3
    Dancing with bridgeboards Amibayer! BlindGerMan's Avatar
    Join Date
    Nov 2011
    Country
    Germany
    Region:
    Bavaria
    Age
    45
    Posts
    3,383
    Feedback
    314 (100%)

    Default

    Yes, tested and working!
    A2000 2/128/-MB-OS3.9-DKB Wildfire-Picasso IV+Concierto+PabloII+Paloma-Deneb-A2386@TI486SLC2/66-ATI Mach64-Tekram DC600T
    A2500/30 2/112/6MB-OS3.1-A2630+BigRAM2630-A2091-A2410-A2065-A2286-A2320
    A1200 2/256/-MB-OS3.9-Blizzard 1230IV/SCSI-IDEfix Express-Indi AGA MkIIcr


  4. #4
    Morphfrog's Avatar
    Join Date
    Feb 2018
    Country
    Sweden
    Region:
    Sweden
    Posts
    4
    Feedback
    0

    Default

    Hi
    I got the chip and its installed and working fine, I just looking for where I can obtain the OmniSCSI utils?

    thanks in advance
    /mats

  5. #5
    Finger lickin' good Amibayer! matt020's Avatar
    Join Date
    Dec 2009
    Country
    Western Australia
    Region:
    Western Australia
    Posts
    403
    Feedback
    4 (100%)

    Default

    I have an A2091 with 6.6 ROM's. I have a single CDROM drive on the chain. It takes 2 minutes, 45 seconds for the A2091 to scan the SCSI bus for devices, and in that time, the A2000 just waits and waits. The card has standard terminators onboard, and the CDROM has termination activated.

    Once the SCSI bus is scanned and the CDROM drive found, everything resumes and continues to load Workbench. CD0 is mounted and it all works great!!

    Will the GURU ROM correct this rather large delay time while the SCSI bus is scanned for devices?
    Amiga 500 - 030/25 - 1mb chip - 2mb fast - 2GB HDD
    Amiga 2000 - 030/40 - 1mb chip - 5mb fast - 2GB HDD
    Amiga 1200 - 030/40 - 2mb chip - 32mb fast - 4GB HDD
    Amiga CD32 - 2mb chip - 8mb fast - TF328 - 8GB HDD


  6. #6
    Jack of Many Trades, Semi-Master of Some thebajaguy's Avatar
    Join Date
    May 2017
    Country
    United States
    Region:
    Rhode Island
    Posts
    343
    Feedback
    34 (100%)

    Default

    Morphfrog - I'll have a link for you in 1:1 for the 3 basic tools (OmniSCSICtrl, GVPSCSICtrl and GVPCPUCtrl). I don't have the 'full' archive image put together and posted anywhere.

    Matt020 - The scan timeout is about 20 seconds for GuruROM with no devices present (from power on), so it should be faster than the classic ROM default. Note that one of the A2091 JP5 jumpers, when shorted, actually increases boot time. Make sure they are all 'open'.
    A500(2x)/A1000/A1200/A2000(4x)/A3000D(2x)/A4000D(under repair)/A4000T (all loaded....Toys...Toys...Toys...)
    Former GVP Tech Support 1989-93 - The beatings will continue until morale improves...

  7. #7
    Morphfrog's Avatar
    Join Date
    Feb 2018
    Country
    Sweden
    Region:
    Sweden
    Posts
    4
    Feedback
    0

    Default

    thebajaguy: I got it thanks.

Similar Threads

  1. Retr0bright Support Thread
    By gazcbm in forum AmiOracle
    Replies: 1048
    Last Post: 24th September 2018, 11:49
  2. Replies: 20
    Last Post: 5th July 2018, 20:29
  3. Replies: 0
    Last Post: 16th June 2017, 21:13
  4. Closed A1200 Floppy disk support, HD support and Metallic shield.
    By Marmes in forum Found Archive
    Replies: 3
    Last Post: 15th July 2012, 23:03

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •