Guru on SCSI write (RAM help needed)

Wallbraker

New member
Joined
Sep 20, 2017
Posts
47
Country
United Kingdom
Region
Cambridge, Cambridgeshire
Greetings fellow Amiga lowers! (Solution found, see bottom of this post).

So I'm having some troubles with my Amiga 2000 Rev 6.2, in it I have a:

The problem I'm having is that with everything enabled I get Guru 8000 0004 (IIRC) every time I try to write to the SCSI drive.
Through some experimentation I have found this:
  • Removing the A2630 works!
  • Disable RAM auto-detection work!
  • Making the A2630 only have 2MB RAM does not help.
  • Removing the BigRAM does not help.
  • Removing the IOExpander does not help.
  • Disabling MC68030 caches does not help.
  • I have not tried to insert the card into the first slot Zorro slot.

Possible solutions:
  • I found this thread (from 1994!) that talks about replacing one of the ICs on the board.
  • Lower the priority of the A2630 RAM so it's not used for DMA.
  • Disable the auto-detection of the A2630 and then add the BigRAM manually.

The first is not guaranteed to work. The other two are more attractive, if I some how can get only the BigRAM
to be found I could in buy another extra 4MB for the Impact so I could have a full 8MB in the 24bit DMA space.
Problem is I do not know how to do either of these, or if it is possible. Which is why I am writing here for help,
if any of you fellow wonderful Amiga lovers have any ideas, tips or solutions please reply, thanks in advance!

Solution found:
Using the Bigram utility that you can download from icomp's wiki, you can add the memory even if the A2360
RAM auto-config is disabled. Disadvantage is that I'm now 4MB poorer if this had worked out of the box, but
that is a very small price to pay considering that the Bigram adds about 112MB.

Cheers, Jakob.
 
Last edited:
While that might solve my problems, :p I was hoping for a more soft solution that would also allow me to keep the speed of DMA transfers.

Cheers, Jakob.
 
Try to get a GURU ROM for your GVP, maybe it solves your problem...

But, all DMA controllers for Zorro II have some problems with Turbocards and RAM outside the Zorro II space...
 
It's a problem of the memory being on the Accelerator card within the 24bit ZorroII space. With or without BigRAM makes no difference.
 
I get 0,7MB/s with the current setup according to Sysinfo, I have done no performance tuning.
I did see 1MB/s at once point during my experiments, I think that was without any ram from the A2630.
 
The GVP FastROM and the GuruROM support DMA to any Zorro II space, and perform all needed copy-up to >24-bit address space. A reminder not to mess with DMA Mask values (should be 0xFFFFFFFE), as the driver handles all of that more efficiently, and internally. Only native C= ROMs in an A2091, and a Microbotics HardFrame (unless proven otherwise) will have problems with DMA >16MB space, and need the Mask hack. Leave MaxTransfer alone, too.

You should make use of 'CPU Cache FastROM' during startup. However - you have a combination that has a logistical issue or two.

One problem I will point out is this: You are a likely to have a trip to the Guru if the native OS is merging 16-bit and 32-bit FastRAM into one large block and a special case happens. In this case, the boundary of 005FFFFF/00600000 (assuming 4MB on each), is a bus error waiting to happen. If the 68030 doesn't cleanly longword read (or write) up to 0x005FFFFC->F, then start another longword access on 600000->3, the bus access across two different memory types will cause a hardware bus error to the 68030. You are safe as long as you don't end up using all of the other BigRAM memory, which I assume ends up 1st in the memory list, and don't ever get around to using that last ~4MB+ (16-bit).

Second - regarding the CPU command. Don't run the FastROM option until the BigRAM is added to the the memory list and is highest priority. If you have a merged memory list like above, the 32-bit A3640 memory (00200000-005FFFFF) merges with the GVP memory (00600000-009FFFFF), and FastROM will end up locating the OS remap in - yes - 16-bit memory on the GVP card at the end of the memory block. It picks the end to have th ebest chance of a useful memory boundary (chunk) for the MMU and to not fragment memory.

to fix that, you have a few options:

1) Disable the GVP's 4MB. It's the last 4MB that you would ever want (16-bit) to use, speed wise. FastROM will then grab only 32-bit RAM when invoked (ideally, in this case, the 4MB on the A2630, so as to give you the largest amount later on the BigRAM)
2) Ensure the BigRAM is in the memory list at a higher priority than the other FastRAM, then call the FastROM option. It will locate in 32-bit RAM there.
3) Use another MMU-based remap tool (prior to BigRAM addition), and force the 'head' option. By this, going to the head of the memory list for remap memory. The A3640 memory, having merged with the GVP 4MB, will be at the front of that memory pool. Most MMU (like SetCPU and CPU) tools take from the back end of the first or largest memory pool, and that is not best.
4) (a longshot, but I'll mention it) Get a retargetable graphics card (if this HW is on your shopping list) that sits between the A2630 and the GVP HC8 (and set for 2MB). It will allocate a 2MB chunk of Zorro II space between them, and the OS will never merge them.
 
Last edited:
I have a similar problem but I use Hardframe with A2630 without bigram and with scsi2sd.

With only 2MB in A2630 (extra 2MB removed) it occasionally hangs on disk access, but I have to do some extensive disk access to get it.

What is weird is when I install extra 2MB in A2630 - just install the chips, keep the jumper at 2MB total - the hang happens almost immediately on auto booting or on driver load from fdd with auto boot off.

The total 4MB ram tests pass if I do not initialize hardframe drivers.

Maybe this his is similar to the issue described here. Any hints on what could cause such behavior?
Thanks
 
Last edited:
If you don't have a mixture of memory (16-bit and 32-bit), then my comment above yours doesn't apply, however...

You describe adding memory (circuit) load to the bus. The additional chips' load adjust some signal timing enough to push it past some needed spec. As the Hardframe is a DMA bus master, you may want to check some motherboard revision info that has been collected over the years:

There are some older v4.x motherboards that have some modifications to bring them up to v4.5 in relation to the expansion bus. The 6.0 and 6.1 motherboards need to be updated to 6.2 to be stable (all modifications above 6.2 are not problem fixes, only shipping spec updates to Kickstart, Denise, or the minor adjustment needs of the last rev 1MB 8375 Agnus). Do note that many paper rev stickers have since failed their adhesive and may be lost. Of the 4.x/6.x B2000 series motherboards, I know I have seen 4.1 and the 4.4 silkscreen values (large version.small rev ), & paper labels may show 4.2-4.5. All Rev 6 updates were paper labels, and not always up to date (i.e. - there are 6.1's that were updated to 6.2 but not stickered).

The Rev 4.x details are listed here along with some v6.x info further down the page: http://www.bigbookofamigahardware.com/bboah/product.aspx?id=17

I also have this detail from an old UseNet troubleshooting posting (has some of the above noted v4.x fixes, and some more info, parenthesis is my addition):
Rev 4.1:
First shipping B2000 (West Chester) Amiga 2000 CR 2-layer motherboard. (3.8/3.9 are demo, and German Rev 4 (4-layer) is an ancestor to the West Chester 3.8/3.9/4.1)
Rev 4.2:
The A2000's needed to have the keyboard data and clock line capacitors removed (this is the Rev 4.2 mod, FCC mod undo)
Rev 4.3:
A 3300 ohm resistor should be installed between pin #20 and pin #11 on chip U605's address strobe (This is the BBoAH vague tweaking comment with the Gary Chip part source change).
The original Toshiba Gary chip was a gate grray, and the later MOS Gary is a custom chip part. There was some note of the newer/latter being preferred as the older might cause some contention in some circumstances, although no specific examples have been spoken of.
Rev 4.4:
All the Eltek power supplies needed to be checked that a .01 MFD capacitor was installed across R65 to suppress noise and a "00" with a line through it written on the power supply label (may not apply if different PSU maker).
Rev 4.5:
Add 1K pullups on U605 pins 11 and 20 if the U605 and U602 are 74LS245 (buffers between the 86-pin and 100 pin slots) type (the BBoAH description), (or go with slightly faster 74ALS245 buffer parts described in other notes - it appears to have made it into the last Rev 4.5 production in some cases. Dave H. notes this was the only significant problem addressed in the v4.x sub-revisions. As you have a busmaster controller, it may be of note to check on an older Rev 4.x.)

The Rev 6.x updates are described here: http://www.thule.no/haynie/systems/amiga2k/docs/rev6_fix.txt

I have a similar problem but I use Hardframe with A2630 without bigram and with scsi2sd.

With only 2MB in A2630 (extra 2MB removed) it occasionally hangs on disk access, but I have to do some extensive disk access to get it.

What is weird is when I install extra 2MB in A2630 - just install the chips, keep the jumper at 2MB total - the hang happens almost immediately on auto booting or on driver load from fdd with auto boot off.

The total 4MB ram tests pass if I do not initialize hardframe drivers.

Maybe this his is similar to the issue described here. Any hints on what could cause such behavior?
Thanks
 
Thanks a lot for your response. I do have 6.2 motherboard with a sticker.
I got myself a real SCSI drive and the problem disappeared. Looks like it occurs with SCSI2SD only. I tried experimenting with various settings of the SCSI2SD but no better.

- - - Updated - - -

Too early for the success - although it boots every time and previously never booted - it happens occasionally that it hangs under workbench with a window suspend/reboot.
Switching to 68000 mode makes the hangs go away at all.

Thanks a lot for your response. I do have 6.2 motherboard with a sticker.
I got myself a real SCSI drive and the problem disappeared. Looks like it occurs with SCSI2SD only. I tried experimenting with various settings of the SCSI2SD but no better.
 
SCSI2SD will be slightly higher performance in some cases (No seek/spin latency, and fragmentation won't slow it down, as with physical spinning media) so it may push things closer to a marginal timing threshold on transfers.

This may seem odd, but try the DMA controller in both slot 1 and slot 5 and see if there's any +/- in the behavior with the 68030. The added distance could make it worse or better.

Another thing to try is boot a memory tester from floppy (no startup, and let it run overnight in the 4MB setting. See if something pops up. Leave the data cache setting off.

It also occurred to me that maybe a termination pack on the expansion bus is cracked or bad. Make sure all address lines and data lines each measure the same ohms to vcc and gnd. One would believe they should all measure the same within their group.

Grasping at possibilities, as it shouldn't be giving you grief.
 
There is not difference between the controller slot.
I checked all the terminators on ZORRO address lines and they are correct and connected to the pins through capacitors which seems fine too.
Also I checked the terminators on 2630 address and data lines, behind the bus transceivers and they are ok.
I remain puzzled. This happens only in 68030 mode. I think I will try to find another controller and check.

Also, I would try to experiment with the DMA mask on the RDB - are there any RDB editors that would allow me to change that without reformatting drive?

Thanks for the ideas!
 
DMA mask would force all DMA transfers through ChipRAM. A band-aid that doesn't fix the underlying problem, and kills any kind of performance.

Have you looked into the possibility of a later driver (ROM) for the card? I don't know what versions were released, or issues they addressed.

Your original prep tools should have an option to set the mask, if that's what you want to try.

If you get GVP ExpertPrep 2.x, feed it the SCSI driver name on the command line, it should read the RDB info. In the main screen, menu option - make a mountlist (placed in RAM:) - copy it/print so you have it handy - it's a backup - knowing the Heads/Sectors/Cylinder values of the current partitions.

You could use that mountlist to manually connect to the partition. You can test this with: Workbench disk stripped down to basics, hardframe driver (in Expansion folder), binddrivers, L:fastFileSystem (just in case), and some basic C:/L:/Libs:/Devs: files to get around. Disable the board's ROM, boot from this floppy. This is a good way to test an updated driver (if one can be found) before committing to an upgrade ROM.

Note that binddrivers loads the driver in Expansion on the floppy, and it might auto-mount the detected RDB info. Add an 'a' or something on the mountlist device entry to work around the device name. We want to validate the mountlist info can mount the partitions safely. Once you can read things okay, reboot and put the floppy aside.


As for the boot block:

Safest method from here (to write an updated boot block) is to run through the original prep tool (but not format!) - manually - and re-write the boot block with the modified values you want. I don't know the tools they used anymore. It's been too long.

ExpertPrep can also be tried, as can HDToolBox, to alter the existing settings, but both run the highest risk of saving back something that isn't quite right. I have minimal experience tinkering with HardFrame environments. Always have full backups first.

You might try securing another disk or flash media unit to test with first, or make the backups to, before you try any partition-altering options.
 
Last edited:
So I got myself A2091 controller, installed V7 firmware on it and found out it behaves similarly to hardframe. It is able to boot, however I was not able to install WB, if sometimes it passed, it always crashed before finishing installation of magicwb.
I concluded there is nothing wrong with the controllers, but something is wrong with the A2630 or the motherboard. I did some research and found very old threads from the 90s about similar issue.
Apparently the guys found out, that the resistor packs on the address and data lines on A2630 are connected to the ground (pull-down) and if you turn them 180 degrees, they will be connected to +5V and become pull-up resistors for the lines.
I did so and re-soldered them only for the address lines (RP100-103) and to my surprise, it solved my problem! Maybe with that many ram chips, there was a problem with stability of the high signal level. I don't know.

Now hardframe and A2091 are able to boot correctly from the HDD.
I still have issues with scsi2sd, but I thing the progress is pretty good anyway!

If you look at the resistor packs, they are originally connected on one end (common pin) to the ground, but the opposite last pin is connected to +5V. This makes it possible to reverse it to make it pull-up resistor, but I am wondering, why, because this leaves 1K resistor permanently between power and ground. There are more than 8 such packs, making a resulting resistance between +5V zorro pin and GND pin 100 ohms. This is 50mA drain for no reason. Any idea why?
 
The data bits terminators were even more interesting on my A2630. 3 of them were soldered in the pull-down configuration but one in pull-up. I changed them all to pull-up. A2091 seems to work pretty stable now. hardframe is much better, but it happens it hangs on data write.
 
Glad you got it (mostly) sorted. No, I have no idea why they needed to be reversed, or what was being thought of regarding the drain (assuming it was thought of). I do know that C= has been known to have put devices in reverse during manufacture, and occasional PCBs to have markings for pin 1 wrong, and the like. Many boards like yours were sold with 2MB, the passed QA (worked in the test jig), and out the door they went. One wouldn't trip over the problem until years later adding RAM, if it was ever done.

I saw these posts that has mention of both the possible terminators issue, and one of the signals maybe needing some help in DMA situations:


http://www.verycomputer.com/2_3ec763d9253a292a_1.htm

[url]https://groups.google.com/forum/#!msg/comp.sys.amiga.hardware/-acTIBqR_Nk/AAC2nGaXBNEJ

[/URL]
 
Last edited:
I tripped over this while wandering Aminet - Read the document - your concerns on the terminator packs and the power draw are noted in there. Also, some speed up hacks if you are adventurous.

http://aminet.net/package/docs/hard/A2630SpeedFix

I'm pretty sure the guy that posted it is one of the regulars here posting other 680x0 performance enhancement modifications.
 
Back
Top Bottom