I have three Cumana SCSI2 (32bit) cards, two of which have been poorly for some time (and I dare not use the third in case it follows suit!).
The RiscPC will not boot, stopping with just "_" top left. No POST error from the floppy but perhaps it's not even starting POST.
Moving (or removing) the jumper on J7 or J8 allows the machine to boot, but the podule is recognised only as "extended podule" and none of its modules appear in *rommodules. The jumpers are the rightmost of the group of five along the top edge of this view, and by default set as they appear there:
I am looking for information on what J7 and J8 do (and, for that matter, J4, J5, J6 and J9). The manual is silent on this matter.
There is an unpopulated socket on the board - my guess so far is that J7/J8 are concerned with whether a ROM in the socket or flashROM is used, because I suspect the boot failure is symptom of a corrupted flashROM that prevents modules from initialising. I have the set of modules in the !SCSIflash utility (2.08 and a beta 2.09 for long filenames) but cannot use that to reset the flashROM, because either the RiscPC won't boot or, to allow booting, the flashROM is made inaccessible.
I'd happily leave the flashROM disabled if there were a way of softloading SCSIFS etc, but AIUI ROM modules differ from softloadable ones in the way they are initialised, so I cannot simply try to RMLoad the modules found in !SCSIflash.
Info / suggestions / corrections gratefully received!
UPDATE 1 - some progress
With J7 and J8 jumpered near the card edge (west, as seen from above with rear plate north), the Arc boots (less to take out for test work than the RPC!) and the podule is seen - but all modules except SCSIlog are dormant.
I could *RMReinit but after crtl-brk they are dormant again. Got as far as mounting a drive, but now *RMReinit sticks at SCSIdriver, after disconnecting the drive and setting the config back to zero drives and no SCSIFSmap. I think I have given it long enough to probe for devices and time out. However, I would only need to load the modules when using a SCSI devices so not fatal if SCSIdriver falls over without one.
So I infer that J8 seems to determine whether the podule is seen at all, and J7 controls module initialisation: west for "dormant" and east for "active", and if active the machine hangs when SCSIdriver is initialised. I could use a boot file to RMReinit the modules, but not unless I can resolve the SCSIdriver issue.
SCSIres, SCSIFS and SCSIFiler are 2.09, SCSIDriver 2.08, but that is how they came in the SCSIflash update. The podule identified itself as "2.08 (beta)".
Card is issue 3, serial 1713.
UPDATE 2 - a solution, I hope
The second card, issue 3 serial 1068, fitted in Kinetic RPC jumpered in StrongARM mode, is only seen, but works fine, if there is a drive connected and powered on. Regardless of setting SCSIFSDiscs 0 and empty SCSIFSMap.
The first card now boot ok in the Arc with no drive attached, having changed its jumpers back to default and re-enabled termination and PIO-only in SCSIFlags.
Lo and behold, enabling the termination flag on the second card also brings it back to life. If I'd worked that out when the trouble first appeared, I would not have accumulated quite so many SCSI2 cards (collection now 3 Cumana, one each of Castle, Eesox and Powertec!).
What fraction of SCSI problems are NOT termination? 1%? 0.1%? (setting aside bad drives, which also affect IDE, SATA, ST506, etc)
Still curious to know what the jumpers do!
PS my test disc on the Arc was set up with SCSIDM - weird that RISCiXFS can find vmunix but not the root partition (where vmunix lives!). Also, while I can mount and read the SCSIFS section in desktop, I would be wary of normal use, as SCSIMgr thinks there is one 1200-odd MB RISC OS partition rather than 256MB RISC OS and four RISC iX partitions. So Cumana SCSIFS might try writing to wrong areas of the disc, despite being apparently compatible with Acorn SCSIFS.
Arc/RPCs, peripherals, RISCOS operating system & ARM kit eg GP2x, BeagleBoard
2 posts • Page 1 of 1