#So Simple I'm Stumped!
3 messages in this thread
Larry: (I haven't seen your reply yet as I write this)
I had a few extra minutes today, so I pulled out the A2000 with KS1.3 on it.
Using the CBM A2091 adapter with 7.0 ROMs and the HDToolBox that came with the
A2091 Installation Disk, I "simply" reformatted an MO disk suffering the two,
default partitions. There was no hitch. I did a low- level format, gave the
partitions new ID strings and saved as per the instructions. I was able to
pull off high level formats without chokes. I entered only the maximum number
of "unwarned" cylinders (3659) and turned off "Reselection." (The ICDPrepHD
advises use of 3886 cylinders.) I let the other parameters up to the Almighty.
You can guess what I'm gonna say. 😎 I took several large files and
copied them from my Quantum boot HD over to the Fuji MO without incident. It
isn't real quick, what with the 68000, but it worked! Ergo, I think I can
eliminate the Fuji MO drive itself as the cause of the large-file- copy
problem. It just did some!!
————
I then took the 1.3-formatted Fuji over to the A4000 intact. Even though it
has the 1.3 FFS, it still works perfectly with the ICD Advantage 2000 adapter,
the adsci.device library and the 4.21 ROM…..
Until I try copying a large file from the IDE to the MO.
As before, the computer gurus. 8-(
————
Please recall that my 44 Meg Syquest drive, when substituted for the Fuji
(the cable is not the same) does permit copying over files of any size from the
IDE to the Syquest (using the same ICDhost adapter and 4.21 software that
crashes the computer with the Fuji!) So I can use the Syquest here but not the
Fuji. On the A2000, I can use either.
————
Does that allow you to figure what I'm doing wrong yet? 😎 If not,
what's my next test? Thanks.
Regards Tom (via Whap!)
Well, Tom, I still tend to think that oyu have a MaxTransfer problem, thought
it may have something to do with sector sizes. Is the Fuji a 512 byts/sector
device?
For the next thing to try, grab RDB.LZH from LIB 11. It's a little thing I
wrote that allows you to save the RidgidDiskBlocks, which are what tells the
system what sort of device you have, and a lot of other things about it. With
this program, SAVE a file containing the RDB of the Fuji, and take a look at
the MaxTransfer value. This can be found in each partition table as follows…
0200: 50415254 00000040 672B05CF 00000007 PART…@g+.O….
0210: FFFFFFFF 00000000 00000000 00000000 …………….
0220: 00000000 03444831 00000000 00000000 …..DH1……..
0230: 00000000 00000000 00000000 00000000 …………….
0240: 00000000 00000000 00000000 00000000 …………….
0250: 00000000 00000000 00000000 00000000 …………….
0260: 00000000 00000000 00000000 00000000 …………….
0270: 00000000 00000000 00000000 00000000 …………….
0280: 00000011 00000080 00000000 00000001 …………….
0290: 00000001 00000046 00000002 00000000 …….F……..
02A0: 00000000 00000002 00000B6F 0000001E ………..o….
02B0: 00000000 00FFFFFF FFFFFFFC 00000000 ………..|….
02C0: 444F5301 00000000 00000000 00000000 DOS………….
The above was obtained with a 'type <file> opt h', and contains the
MaxTransfer value of 0x00FFFFFF, three longwords before the 'DOS' ID.
It might be worthwhile playing with this value to see if it makes a
difference. If not, it might be time to chat with ICD about their
device software, asking about support for the Fuji.
Have you dropped the MaxTransfer down to $1fffe on both drives?
Worth a shot…
_Should_ only be needed for _some_ IDE drives, but you never can tell.
Brian — Cruising on AutoPilot…..