GuruROM 6.16 for 2019 Support Thread

thebajaguy

Member
Joined
May 9, 2017
Posts
491
Country
United States
Region
Rhode Island
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.
 
Last edited:
Is a [FONT=&quot]G-Force 030 (Impact A2000-030 Combo Series II) also supported[/FONT][FONT=&quot]?[/FONT]
 
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
 
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?
 
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'.
 
Good morning everyone, I joined after years of reading because I have a BIG problem and I suggested to ask you.

Years ago I bought a GVP IMPACT II HD + (http://amiga.resource.cx/exp/impact500mk2) with the original eprom (I think 3.14) and the original 40mb HD SCSI II that continued.


My configuration
A500 / +
512 KB of RAM
Swith kickrom 2.4 / 1.3
GVP with 2x4mb.
GURUROM with gvpscsi.device Not omiscsi.device . It's error?

I first turn on the GVP on "GAME SWITCH", then turn on the Amiga 500 / + and wait for the kickrom image to appear and then move the button in "GVP autoboot", reset the amiga500 / + and insert the floppy "GVP UTILITY" (which leads to the blue screen that asks me Y / N) and start reading the floppy.
With the original EPROM / HD, I do NOT encounter any problems, it identifies the HD to me, "prepares" it, "partitions" and "formats" and copies the floppies of WB 1.3.2, when requested, and on reboot it boots me and loads it correctly; but since I'm going to use the WHDLOAD, I have bought 2 HD SCSI II of 4.56Gb and a "GURUROM 6.14", so without adapter, (I have no installation floppy or other), but they started problems.
The GVP and Amiga500 / + start-up procedure gives problems; when I move the button to "Autoboot" e restart the Amiga 500 / +, the green / red LED flashes (I have an old Amiga 500 model I have put the 1.3 kickrom instead of the 1.2), and manifests several errors (GURUMEDITATION or OTHER), while if not restart, it loads correctly the "GVP UTILITY" floppy, but the 4.56gb HD is recognized as if it were only 261mb (in the top right corner there is the word "HD SIZE").
Sometimes, partitions the HD into 3 and if the digits are maximum, they correspond to the total size of the HD, but when "I prepare", "partition" and "format", every now and then gives me an error in setting the cylinders and when this error does not occur, when the Amiga restarts, it does not do the BOOT (AUTOBOOT), but the green / red LED flashes, and if I use the WB 1.3 or "GVP INSTALL" floppy disk containing a minimum of WB 1.3, to me it displays the partitions with the copy of WB1.3 or other, but does not boot (but does it with the old eprom and with 40mb HD)
I hope I was clear; can you tell me which procedure I forget or don't know or what am I wrong?
 
Last edited:
In the reply further down, I'll respond to Marco920, but I was contacted recently with regard to the A590, and much of the jumper setting detail is sketchy (I don't own one to confirm). Here is a clarification (hopefully) based on compiled info and talking to SpeedGeek and Ralph Babel at times in the past:

1 - An early reply to this thread https://www.amibay.com/showthread.php?19260-A590-14-Mhz-SCSI-Mod - on Pg1 - someone made a comment about the GVP HC8 or HD8 33C93A clocking - J2 is your 7/14Mhz 33C93A selector. If memory serves, any GVP driver after v3.12 assumes the 14Mhz 33C93A setting is set by default (pins 2/3). G-Force 030/040/A530 also default to 14Mhz with a different jumper, and no need to use 7Mhz. The GuruROM v6 also assumes 14Mhz clocking on all GVP boards that come with that capability. Some Series II boards have ID jumpers, and one of them flags for the opposite clock setting (non-default) of the ROM's default.

2 - The GuruROM v6 code that adds support for the A2091/A590 (IIRC that's v6.11 or v6.12 and above) and expects the 33C93A controller to be in 7Mhz clock mode on these boards >unless< there is indication (a jumper) present that flags the driver that a clock mod to 14Mhz has been done.

3 - The SDTR suppression jumper/DIP switch is for situations where boot time SDTR commands hang a device (they are technically failing SCSI spec by their behavior and not responding to it). The GuruROM v6 will query the device unless the flag (jumper/DIP) tells it not to (on boards with jumper options). It's best to set any boot blocks to Async, and let the provided tool set Sync operation per device during startup.

Jumpers/DIP Settings (GuruROM):

A2091 JP5-2 open 7MHz (default)
A2091 JP5-2 closed 14MHz
A2091 JP5-4 open - SDTR boot time polling (default)
A2091 JP5-4 closed - SDTR polling supressed at boot

A590 DIP 1-3 open 7MHz (default)
A590 DIP 1-3 closed 14MHz
A590 DIP 1-4 open - SDTR boot time polling (default)
A590 DIP 1-4 closed - SDTR polling suppressed at boot

The C= ROM jumper settings for extended poll and LUN poll/ignore do not apply to GuruROM.

GVP Series II HC/HC8/HD8 (if equipped with ID jumpers) and All drivers
J10/J11 - Open (default) - Driver Default Clocking expected (GuruROM v6 and v3.14+ FastROM expect 14Mhz)

J10/J11 - Closed - Opposite of Driver Default Clocking (i.e. 7Mhz must be set by J2 in 1/2 position for above noted versions)
J12 - Open -
SDTR command at boot time polling (default)
J12 - Closed - SDTR command polling suppressed at boot

Note:Boards without ID jumpers can't invert the driver default or disable the SDTR polling.

These jumper options apply only to the board they are set on. A GuruROM on one board can drive all of these GVP and C= controllers in a system.


- - - Updated - - -

Okay, for Marco920:

The Kickstart 1.2 and the hard disk with >4GB capacity are the two main red flags to address, but there are other things to consider. I'll try to cover them and the misunderstandings:

1) Original GVP SCSI drivers of v3.x and v4.x are (marketing) FastROM drivers. gvpscsi.device is the driver name in all cases. The GuruROM v6 is a 3rd party offering (never sold new on GVP gear) and it always has a driver name of omniscsi.device, with v6.x or v1.x reported depending on the way it's obtained or observed. It's a dual-layer driver to support the different hardware (lower) and common Amiga (higher) driver interfaces, so different versions appear, although the latter revision value is always the same.

2) The 'Game Switch' merely makes the controller ROM appear or disappear from the controller's memory space, and nothing more. It seems the behavior you describe with boot up is a result of all devices not becoming 'ready' with the power on of the A500. Turn on all devices except the A500 first, then the A500's power, and the need to flip the switch and Ctrl-A-A will cease on cold boot. There is also a hack (increase a capacitor value within the A500 motherbaord) that can delay the A500's reset delay on power on sometimes enough to allow it to work all powered at once. I have documented it in other forums, but that is out of scope for this topic.

3) Both FastROM and GuruROM support native 32-bit FFS. Amiga OS 3.1 and earlier, and the matching FFS that came with it, are limited to <4GB media (drives) and <2GB FFS partitions. Going past these limits on these FFS versions will eventually cause address-wrap on the disk media, and corrupt the partition(s) at the beginning of the partition/drive at some point. OS 3.5/3.9 have patch solutions to get around this, but it's not simple to understand, and I'm not the one to cover it.

4) OS 3.1.4 (Release in 2018 ) supports >4GB media and >4GB partitions by testing for TD_64 API and HD_SCSI_CMD/SCSI_Direct compatibility. GuruROM supports both, and FastROM supports HD_SCSI_CMD/SCSI_Direct. Use the included (new) HDToolBox with 3.1.4 for partitioning the disks with either .device driver (modify icon ToolType, or add driver to the HDToolBox command line as a parameter). DO NOT use the legacy GVP FastPrep/ExpertPrep v1.x/v2.x in the case of OS 3.1.4. GVP FastPrep is only 32-bit aware, and not 64-bit aware. Support for 64-bit is needed for disk sizes >4GB, partitions >2GB.

5) The GuruROM v6 always requires the matching adapter module, and the ROM only can not replace a v3/v4 FastROM. The v6 omniscsi.device driver is too big for the ROM code space provided by the boards (Both C= and GVP).

6) Kickstart 1.2 ROM does not support standard Autoboot ROMs on any controller, and it results in a guru-crash. It is an OS bug, and Kickstart 1.3 (or newer) is needed.

As you don't seem to have anything newer than OS 1.3 in your problem description, boot from the GVP floppy, use the ExpertPrep tool/mode. Erase all partitions (Erase RDB). Then re-read the media, and give yourself 4 partitions of sizes 768MB, 1024MB, 1024MB, and 1024MB. This will use about 3.75GB of the disk space, and keep the partition/disk limitations at bay.

I'd suggest using one of the later versions of FastPrep or ExpertPrep if you have means to transfer a DMS to physical Amiga media or other image format (like ADF). The v2.51 of the disk (DMS) file, or ExpertPrep tool is on the gvp-m.com website is available if you can transfer files and convert over.

In either case, use manual mode, and punch in the size values in the column that provide the matching MB/partition, and let it pick the cylinder start and stop values (hit enter until it wraps to the new partition line). Write the settings, format the partitions, and let the copy files function transfer 1) the GVP disk, 2) The Workbench Disk, and 3) Extras disks (in that order) to the first (DH0: ) partition. Later, in a shell, copy the DH0: partition to one of the others (i.e - copy DH0: DH3: all clone) as a backup if you mess up something and need an original install to start over with.

I hope this helps.

Robert



Good morning everyone, I joined after years of reading because I have a BIG problem and I suggested to ask you.

Years ago I bought a GVP IMPACT II HD + (http://amiga.resource.cx/exp/impact500mk2) with the original eprom (I think 3.14) and the original 40mb HD SCSI II that continued.


My configuration
A500 / +
512 KB of RAM
Swith kickrom 2.4 / 1.3
GVP with 2x4mb.
GURUROM with gvpscsi.device Not omiscsi.device . It's error?

I first turn on the GVP on "GAME SWITCH", then turn on the Amiga 500 / + and wait for the kickrom image to appear and then move the button in "GVP autoboot", reset the amiga500 / + and insert the floppy "GVP UTILITY" (which leads to the blue screen that asks me Y / N) and start reading the floppy.
With the original EPROM / HD, I do NOT encounter any problems, it identifies the HD to me, "prepares" it, "partitions" and "formats" and copies the floppies of WB 1.3.2, when requested, and on reboot it boots me and loads it correctly; but since I'm going to use the WHDLOAD, I have bought 2 HD SCSI II of 4.56Gb and a "GURUROM 6.14", so without adapter, (I have no installation floppy or other), but they started problems.
The GVP and Amiga500 / + start-up procedure gives problems; when I move the button to "Autoboot" e restart the Amiga 500 / +, the green / red LED flashes (I have an old Amiga 500 model I have put the 1.3 kickrom instead of the 1.2), and manifests several errors (GURUMEDITATION or OTHER), while if not restart, it loads correctly the "GVP UTILITY" floppy, but the 4.56gb HD is recognized as if it were only 261mb (in the top right corner there is the word "HD SIZE").
Sometimes, partitions the HD into 3 and if the digits are maximum, they correspond to the total size of the HD, but when "I prepare", "partition" and "format", every now and then gives me an error in setting the cylinders and when this error does not occur, when the Amiga restarts, it does not do the BOOT (AUTOBOOT), but the green / red LED flashes, and if I use the WB 1.3 or "GVP INSTALL" floppy disk containing a minimum of WB 1.3, to me it displays the partitions with the copy of WB1.3 or other, but does not boot (but does it with the old eprom and with 40mb HD)
I hope I was clear; can you tell me which procedure I forget or don't know or what am I wrong?
 
Last edited:
Gururom 6.16 software utils update.

Gururom 6.16 software utils update.

Hi. I bought the gururom6.16 a long time ago. I would also like to have the software updated. Any download link?
Regards.




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'.
 
The most recent tools I have from Ralph are here: https://www.dropbox.com/s/rxwpm78f1irys62/Guru616Tools.zip?dl=0

I have not made a more recent disk or archive (and sorry it's ZIP format), but they are the latest tools plus the older ones.

Text files have the related info in there. I don't claim to have tested the RDBCtrl tool - I suggest using the command line tools to enhance the disk speed and protocol settings early in startup.

Thanks,

Robert
 
Last edited:
Hi All,

Really silly question I know, (i have web searched extensively) but how does one install this in the A590 with 2 ROM sockets?
I've had the adaptor for ages but the A590 has been in a friends loft since then and I never got round to fitting it at the time!
I assume take them both out and install the guru in socket U13?
 
Hiya, thanks for the reply, but sadly the info is not there, I am looking for how to physically fit it in the A590, and the link he has to the faq on it doesn't cover which socket it goes into either?

***Answered my own question through testing and for anyone else that's interested in the A590 guru rom installation:

Remove both original roms.
place the guru rom in socket U13
I had to remove the machine pin socket the guru came in and clean the sockets before it worked though.

http://imgur.com/a/tukwcuJ
 
Last edited:
Thanks for your info and update.
At least we know now how to fit it in an A590.
I am only after them for my 2 GVP scsi controllers; 1 the Impact 2 series A500 HD 8+ and the GeForce 040/40.
Anyway we just keep waiting and hoping that we may get them someday.
 
@Apex - As I mentioned in the main thread reply (I was tardy to look here until today), the MuLibs patch for omniscsi.device is intended to give the driver awareness to MuLibs being used for Virtual Memory activities. For normal Amiga activity, there is no need for it.

@Rave - Thanks for the research/testing and details. U13 it is. Machine-pin socket is to guarantee pin depth or provide a fresh socket if the existing socket is worn.

I've updated what happened in my world of late in a post on page 21.
 
If you have any 16-bit Zorro II FastRAM card in your system, with a 68040/68060 CPU, this technical topic maybe for you.


An item of technical note has recently come to light with the use of several 68040/68060 cards and using 16-bit RAM. I've looped in both Thor (MuLibs) and Ralph Babel (GuruROM, 68060.library) on the topic. It's been reproduced on all of the GVP/TekMagic 68040/68060 accelerator cards I have tested (so far) in an A2000 and A4000T (inventory not complete) with both A2091 or HC2/HC8 16-bit RAM. Thor has reproduced it on his A2000 TekMagic 2060 card and an HC8. It may extend to others (not yet made it to the test bed - stay tuned). This makes it possible that a 68040/68060 CPU may require the entire Z2 8M space marked as non-cache in order to tame the CPU from hitting a 16-bit memory region with it's default 4-longword transfer read/write (if caching is enabled). Running BusTest (Aminet) against z2 16-bit RAM from these cards results in 1) horrible <1MB/sec bus performance, or complete bus lockups. Disable caching for the range results in full theoretical bandwidth performance (if it's clocking is fast enough). For use of 16-bit RAM as an I/O buffer for copy-up work (as GuruROM and FastROM do), there is no call for caching that buffer space anyway. With the 16-bit memory being the last system FastRAM used, you are unlikely to ever hit it for most program activity anyway. As of this writing, the immediate solution is to make use of MuLibs' CPU and MMU library, and use MuSetCacheMode and the to mark the address 0x00200000 and size 0x00800000 as cacheinhibit or notserialized <- If the 16-bit memory in this space is all 16-bit. You may need to chose a different start address, and size, (i.e. if there is legitimate 32-bit AutoConfig memory in z2 AutoConfig space, like the PP&S 040/28). The current opinion is to set notserial mode.


Thor is considering options to detect expansion products and push the setting via the install script. Ralph (Babel 68060.library) has not made a decision or expressed any comments either way (yet). SpeedGeek is preferring to leave his current/updated 68060.library offering as-is, and it marks z2 space as Copyback, so it's not recommended in a copy-up buffer situation (otherwise it's fine to use). The P5 libraries for 68040/68060 some use are untested at this time (and likewise the boards), so no info (yet). The original C= v37.4 68040.library interestingly does not mark the range as cacheable, and therefore does not experience the problem, but it is known to be a bit buggy. The C= 37.30 and OS 3.9 v44.2 68040.library has the z2 range set to CopyBack, and will experience the issue.


This issue is not present on the 68030 as the caches operate a bit differently than the 68040/68060, with their pipelining and more advanced caching. HW Burst-Transfer Inhibit signaling only breaks up the access to memory into 4 specific longword accesses, but doesn't restrict them to one longword. It's necessary to use the xTTx registers or MMU to halt the 4-longword retrieval from memory. <- This is being further researched, but was interpreted veribage based upon the MC68040UM.pdf document, p87 / or section 4.1 Cache Operation.


Test / Requirements: Any Zorro II 16-bit AutoConfig RAM card in a Zorro slot, a 68040/68060 accelerator*, any Native Amiga host.


Action: Locate BusTest off of Aminet, and identify your Zorro II RAM card memory range. ShowConfig, GVPInfo, SysInfo all have memory-range info, and it will get tagged '24-bit DMA' in some way, and be within 0x00200000-0x009FFFFF. For my command, I will assume you have 32-bit RAM mapped high on your accelerator (and most boot-time data is in it) and a 2MB Zorro II card at $00200000. I am using an address in the middle of the card range on a 2MB board that should be unused.


Command: bustest addr 0030000 size 16384


I chose size 16384 because if the issue is present, the test will run long with the 256K default. You can omit the parameter if you choose.


If your results are between 1.7MB/sec to ~3.5MB/sec for all read and write operations, you are running (good*) without Copyback or WriteThrough cache mode active on z2 RAM space. If you see results in the 0.4-0.9MBsec range, then one of the 040/060 cache modes is active, and the problem is present. To understand what this does to DMA copy-up buffering on disk read/write, your I/O performance will be in the toilet if you test with RSCP or SysInfo's disk tests (when the destination memory is >16MB) against the A2091 or GVP Series II cards, and a 2MB 16-bit board - which is a recommended inclusion.


*This is making a broad assumption that all 68040/68060 cards are suceptable to this issue <-this may not be the case after further testing. How to check your library's cache setting for z2: You will need the MuLibs package, only the mmu.library file in Libs:, and run the MuScan tool. Locate the entry(s) for 00200000-[some address including or above 009FFFFF] in the output list. If it is ending in '21', this is Copyback mode. ChipRAM (excluding the bottom 4K which may be uniquely marked) <001FFFFF is an example address range ('61') where caching can not happen, and would be a setting that prevents burst access.




A note that this 'issue' shouldn't affect any 68040/68060 card 32-bit memory that auto-configs to z2-space and is located on it's board. It presumably can handle the CPU's burst access. It's also faster (clocked) and not 16-bit (i.e. - two accesses needed for each 32-bit access).


Presumably, the following cards have the problem, or likely do:
A3000 G-Force 040 (no SCSI interface)
A2000 G-Force 68040/33 - Confirmed by
A2000 TekMagic 68040/060 - Confirmed by Thor and TheBajaGuy
T-Rex I (A3040)
T-Rex II (A4040/A4060/Ultrasound) - Confirmed by TheBajaGuy
QuikPak 060 (seen in the Amiga Technologies A4000T/060, relative of the T-Rex II)


On my upcoming test list will be a P5 Cyberstorm 060/PPC, A3640(060), and a T-Rex II/060 on an A4000D when I get the hardware all in one place.

Consider this tangent an investigation in progress. To keep the thread as 'tech support for GuruROM', please engage me in PM if you have any test results to report, or open a new thread on the message boards for the topic, and the discussion can continue there.
 
Last edited:
Back
Top Bottom