Thread: Emulation error
View Single Post
Old 02 February 2014, 10:19   #3
Oh, her, from BIX.

Join Date: Feb 2014
Location: Southern California, USA
Posts: 10
Erm, I am using an image of an 18 GHz disk with (cough) custom RDBs on it. (There are atrocities you can commit with RDBs. I committed most of them on this disk. {^_-} Hey, I helped WRITE the RDB specification with Randal Jesup. These days with ubiquitous Internet connections I'd resort to using signing certificates for the filesystems embedded within RDBs. Also may I suggest that uaehf.device disable interpreting the driverinit LSEGs? Simply drop them on the floor. To my knowledge only one company implemented them and by the Deathbed Vigil I believe they had abandoned them.)

DiskEd edits the raw disk. You feed it the command "DiskEd DH0:" or "DiskEd DH0", it's pleasantly agnostic about that it appears. That goes off and searches for the DH0 device information and pulls out "uae.device". And it promptly comes up empty. So you do need to patch that error if DiskEd and some other related tools are going to work right. You probably need a copy of that and of DevInf. They were in some old devcon packages. They are assuredly on the CATS CDROM, if you have it.

Speaking of SCSI - your implementation appears to be faulty. The old HardFrame RDB tool, RDPrepX, uses direct SCSI commands to probe for possible multiple SCSI buses, multiple LUNs, as well as multiple SCSI IDs. It bombs out the first time it tries to probe a second LUN. It also uses mode sense and other support commands. I'd have to dig out the source code to double check what all it uses. Personally I prefer RDPrepX to HDFoolBox given a choice. I also use the hdwrench.library and the tester tool I built for it. I get finer grade control that way. {^_-}

{^_^} Joanne "RDBs R Us"
jdow is offline  
Page generated in 0.08616 seconds with 9 queries