[Simh] DEC floppy disk interleave questions

[Howard M. Harte]

Thanks Christian, very interesting.  I just ordered one.

 

From: Christian Brunschen [mailto:christian at brunschen.com] 
Sent: Sunday, March 8, 2015 3:14 AM
To: Howard M. Harte
Cc: Alan Frisbie; SIMH at trailing-edge.com
Subject: Re: [Simh] DEC floppy disk interleave questions

 

Potentially interesting for reading floppy disks at a low level: Kryoflyx <http://kryoflux.com/> . 

 

// Christian

 

On 8 March 2015 at 02:14, Howard M. Harte <hharte at hartetechnologies.com <mailto:hharte at hartetechnologies.com> > wrote:

Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk metadata.  He has some DEC disk images in this format on his site:
http://www.classiccmp.org/dunfield/img/index.htm

When I implemented several floppy disk controllers for the SIMH/AltairZ80 simulator several years ago, I wrote a module for SIMH called sim_imd which can utilize the ImageDisk format within SIMH.  At that time, I had a patch to make it work as an alternate to the flat file format that is normally used for SIMH for the pdp_rx disk controller.  I tested sim_imd with the PDP-11 RT11 disk image from Dave's site, and it worked fine.

I may be incorrect, but if I remember correctly, the RX02 disks have the sector header in single-density and the data field in double-density.  In that case, I don't think ImageDisk will be able to handle it.  If you hook up an 8" floppy drive to a semi-modern PC motherboard with the right disk controller, then you may be able to read at least RX01 disks with ImageDisk.  Last time I tried this was around 2008, and I believe I used an Intel Desktop Board with Pentium 4 CPU and Shugart 800 drives.

Only certain PC floppy controllers can read single-density, and even fewer can write it.

Preserving the sector headers is fairly important in my opinion.  It allows the image to be written back to a physical disk and used on real hardware.  That said, just getting the data off the disk in a flat file is still very useful for most purposes.

-Howard


-----Original Message-----
From: Simh [mailto:simh-bounces at trailing-edge.com <mailto:simh-bounces at trailing-edge.com> ] On Behalf Of Johnny Billquist
Sent: Saturday, March 7, 2015 4:52 PM
To: Alan Frisbie; SIMH at trailing-edge.com <mailto:SIMH at trailing-edge.com> 
Subject: Re: [Simh] DEC floppy disk interleave questions

Hi, Alan.

On 2015-03-08 00:47, Alan Frisbie wrote:
> I have a large quantity of disks that I wish to copy to files that can
> be directly used by the SIMH PDP-11 emulator and by the
> E11 emulator.   They include 8" floppies (both RX01 and RX02),
> RL01, and RL02.
>
> The issue is that the disks have sector sizes that differ from the
> usual 512 bytes, as well as having interesting interleave
> and stagger factors.   RX50 (and RX33?) disks have (I think)
> 512-byte sectors, but some odd track usage.   I also believe
> that RX02 disks have the first track in single-density mode, just to
> complicate things, but it isn't used by most DEC O/S
> software.   RL01 and RL02 disks also have bad-block sectors
> at the end of the disk.
>
> I am assuming that SIMH and E11 emulate the device faithfully enough
> that programs which are aware of the interleaving and
> small sector sizes will work properly.   If this assumption is
> wrong, please enlighten me.
>
> If my assumption is correct, what is the best way to copy the raw
> disks (which are in a variety of O/S formats) to files which the
> emulators will be happy with.   I can bring up a real PDP-11 with
> RX02, but will probably be using a microVAX-II with an Andromeda
> FDC11-B controller and Shugart 800 drives.   I don't mind writing
> my own code with QIOs.
>
> I have a bunch more questions related to this, but this will
> do for now.   :-)
>
> All of this is related to cleaning out my storage units and
> de-cluttering my life.

Hmm, I believe this is not absolutely straight forward. The problem is that simh (or E11) do not emulate the physical layer, but the logical one.
As such, the image files of disks are assumed to always be containing sequential blocks, and no block headers are in the image file.
So, it will work, in that, if you can dump out an image from a disk, where block #1 is block #1 on the image file, then things will just work fine.
If you dump out the physical blocks raw, including block headers, then they are not usable by the emulators.
Logical rearranging of blocks will work fine, though. So, the trick you normally see with RX01/RX02, where they remap block numbers to other blocks numbers in the device driver, is just fine. You just want the actual physical blocks, in the order they are on the disk. )As indicated by the disk block headers.) The actual layout, as created when formatting the disk, will not carry over, but it is also not important.
(I hope I'm making sense here, I feel I might be overcomplicating my
text...)

Bad blocks, as described by the RL01/RL02 bad block tables, are totally under the device drivers and system software, so that is just fine.
Systems will avoid those blocks, even on a dumped image of the disk, assuming you copy all blocks, including the bad block list.

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se>              ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh at trailing-edge.com <mailto:Simh at trailing-edge.com> 
http://mailman.trailing-edge.com/mailman/listinfo/simh

_______________________________________________
Simh mailing list
Simh at trailing-edge.com <mailto:Simh at trailing-edge.com> 
http://mailman.trailing-edge.com/mailman/listinfo/simh

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150308/df56a451/attachment-0001.html>