[Simh] 8" Floppy disk image getting HALT error

Tue Jul 11 15:50:10 EDT 2017

If you're interested in WPS8 RX50 format, I have a program to READ rX50 images and convert the files to Wordperfect format.  Http://github.com/khandy21yo/emutools.git.  There's other stuff in there, but one of the subdirectories contains the source.
It's been some time since I wrote it, so I don't really remember the details.

Sent from my Galaxy Tab® A
-------- Original message --------From: Timothe Litt <litt at ieee.org> Date: 7/11/17  1:09 PM  (GMT-07:00) To: simh at trailing-edge.com Subject: Re: [Simh] 8" Floppy disk image getting HALT error 

    VMS mount /over=id /foreign is the quickest way to identify
      files-11 and RT disks.  FILES-11 can be read directly; use
      EXCHANGE for RT-11.  Once you have the disk mounted on VMS, you
      can network it to wherever you like.
    If you insist on doing things the hard way, there is low-level
      detail to worry about.

    The first  track on DEC 8" floppies is reserved for boot (but not
      used) in the standard RX01/2 formats.  It's not used by any DEC
      OS.  Not even for booting (the DEC boot block is the first LBN
      following the reserved track.)

    Both are 77 tracks, 1 sided, 26 sectors/track.  The rx01 is 128
      bytes/sector; the rx02 256.  So an RX01 image will be about 251KB,
      an RX02 about 501KB.

    Logical blocks are 512 bytes; meaning that an LBN consists of 4
      or 2 physical sectors.  The physical sectors are interleaved.  If
      you have a physical dump of the disk (and your tools haven't
      outsmarted you), the easiest thing to do is to de-interleave it.
    Use the attached utility, which documents the format & will
      interleave/deinterleave a floppy image using the usual interleave
      rules.

    19D0(16) is close to 26 * 256 (short by 48 bytes), so I'd guess
      you have an rx02 and are seeing the empty boot track.  (Although
      not guaranteed, the track was usually written with all zeroes).

    The 48 bytes may be left over from formatting, or an artifact of
      how you're reading the medium.  Or an indication that your
      recovery dropped something.  Hopefully it checks the CRCs..

    The E5 is probably left over from formatting.  I think it was
      part of the sync pattern, and that the formatter wrote 

    If you see 8-bit data, it's probably RT11 or Files-11.  These are
      self-identifying - block 1 (the second block) will have a
      filesystem name in starting at byte 760(8).  Will be DECFILE11A
      for ODS1 or DECFILE11B for ODS2, DECRT11A for RT11.  RSTS is also
      possible - I don't remember it's code, probably DECRSTS11A.  Given
      that, data (deinterleaved), humans can easily tell what you have.

    RT11 files are contiguous, so recovery is easy.  FILES-11 files
      can be, but probably aren't.  You have to read mapping pointers. 
      There are tools that will do that (one of these daze I do intend
      to release mine.)
    But it's much easier to just run EXCHANGE and say "COPY" by filename
    :-)

    As for WPS-8  - yes, it's packed into 12 bits - but it's also
    encoded (I vaguely remember it as a 6-bit code with shift &
    formatting - but I'd have to look up the code I wrote to translate
    it.)  In any case, it would not look like text to a "modern"
    filesystem.

    Have fun.

    On 11-Jul-17 13:26, Walker Sampson
      wrote:

      Hi everyone,

Many thanks for this feedback. A fair amount to chew on here. I’ve sent a request to the donor to share the disk image, if I get a positive I’ll be happy to throw up a Dropbox link to it for others to examine.

This may mean a problematic read of the disk itself, but addresses 00000 – 019D0 are all zeroed out, or about bytes 0 – 6655. 

Data begins at byte 6657, and that is the document I mentioned. Last byte of the document is 73080 and then just blocks of either zero or E5E5E5E5 till the end of the disk. 

To Paul’s point of mounting a RK05 drive – which drive should I be mounting here, assuming it is the RX02 disk it seems to be? “AT RX01 <disk_image>” still gets a HALT error. Of course, as you all point out, perhaps this isn’t a bootable disk, period. “SH RX01” gives “RX1, 256KB, attached to test-decrx01.img, write enabled”

FYI as well, on a modern HFS+ system, the disk image file is coming in at 256 KB.

Any thoughts on the run of zeroes and E5E5E5E5? 

Thanks again,

Walker

 On 7/11/17, 6:29 AM, "Simh on behalf of Johnny Billquist" <simh-bounces at trailing-edge.com on behalf of bqt at softjar.se> wrote:

    Hi.

    On 2017-07-10 22:10, Walker Sampson wrote:
    > Hi everyone,
    > 
    > Let me preface this by saying that I’m unfamiliar with the original PDP 
    > machines. I work as a digital archivist and have received 8” floppy 
    > disks from which I need to recover data.
    > 
    > I believe I have recovered at least partial data from these disks; I’ve 
    > connected a Y-E Data 8” floppy drive to a KryoFlux floppy disk 
    > controller and gotten positive sector results setting the format to a 
    > DEC RX02 sector image. When I investigate the resulting disk image in a 
    > hex editor, I am seeing clearly a report document, so I don’t believe I 
    > have a false positive.
    > 
    > Outside of observing in a hex editor however, I don’t know how to access 
    > the disk or its contents. Using SIMH, I haven’t gotten the virtual 
    > machine to boot the floppy disk image.
    > 
    > Commands “AT RK01 <disk_image>” and then “BOOT RK01” give me a “HALT 
    > instruction, PC: 000002 (HALT)” message for the PDP-11 program. The 
    > PDP-8 stalls indefinitely and the PDP-10 outputs “Non-existent device” 
    > as well.
    > 
    > I can’t go back to the donors and ask what machines these 8” floppies 
    > were used with, so I’m not sure how to begin troubleshooting.
    > 
    > Any advice in that area is much appreciated!
    > 
    > Thanks,
    > 
    > 
    > Walker

    To sum things up. You can probably ignore all the questions about if 
    this really is some DEC floppy, what kind of format it has, and so on. 
    If kryoflux managed to extract data that looks valid with RX02 parameter 
    settings, then I'd say we can be sure it is an RX02 disk. And this 
    format was unique to DEC, so it can't be anything else.

    Which also means, you already have managed to exact all the bits, and 
    most probably correct. The next question is just about restoring the 
    data in a more coherent form, which means getting it in the form of 
    files, and understanding the format of the files.

    For this, we need to know what system the floppy was written on. Paul 
    Koning gave the most useful advice. The first few blocks will usually be 
    enough to find out what system the floppy was written on.

    RX02 floppies could certainly be bootable, but most are not. OS/8 (and 
    derivatives) for the PDP-8, and RT-11 for the PDP-11 were the ones that 
    supported RX02 as a bootable system. Other systems supported the 
    floppes, but only as a way of carrying bits around, so not being able to 
    boot from the floppy is probably to be expected.

    So, if you could give us just the first few blocks, it should be 
    possible to tell what file system it has, and that gives us OS, file 
    structure and probably the ability to work out the rest in quick order.

    	Johnny

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

_______________________________________________
Simh mailing list
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/20170711/fa991423/attachment.html>