G'day AJ -

There is only one program on the 'MinicomDiskUtility.bin' file - there is no data beyond the 8KB (the file size is only). There is no "filemark" or other pseudo-/meta- data that I detect in the file, just a single stream of 4096 words (as appropriate for the DG word-oriented architecture [big-endian]). What other file(s) am I missing?


Regardless, dissecting and running the utility reveals further program assumptions:

The 40 MB disk drive has a geometry of 442 cylinders, 5 heads, 32 sectors/track (head).

The IRIS logical unit to physical disk address assignments are:


LUN     CYL   HD  SEC
----    ---   --  ---

LUN 0:    0,   0,   0    disk start address
         15,   4,  31    disk end   address

LUN 1:   15,   0,   0
        111,   4,  31

LUN 2:  112,   0,   0
        223,   4,  31

LUN3:   224,   0,   0
        335,   4,  31

LUN4:   336,   0,   0
        441,   4,  31


Total disk formatted size:  36,308,640 bytes

Data is transferred to/from the disk to the tape drive in 4KB records during backup/restore operations.

Only logical units 0, 1 and 2 can fit on a tape; a second tape was required for backing up logical units 3 and 4.

Next step: obtain data files that contain the LUNx information...


Bruce



On 11/18/2015 2:21 AM, Microtech Dart wrote:
Bruce!  This is very exciting...you actually RAN the file!  I'm so
excited to know that this is possible.

I received the screen shots in my MightyFrame email, thank you for those.

Most of what you are talking about is still Greek to me, but I'll catch up.

"The tape file itself needs to be created in the SimH tape if it is to
be used with the default SimH tape driver. The QIC format may exist as a
single large data record of 16,384 bytes, or of multiple 512-byte
records followed by a file mark. (I can not tell its original format
given only the .bin file to work with.)"

OK, so I know exactly how the data format was written to this tape.
  (For detail on the format itself, I outline it in exhaustive detail on
this page: http://bit.ly/1RhcdK2  )  The format is neither QIC-11 nor
QIC-24, but some very weird format that I've traced back to a specific
model of Kennedy QIC tape drive.

The Minicom Disk Utility file that you ran was in one single block of
data, which was 8192 bytes long.  It was, as you indicate, the very
first block of data on the tape.  This block was followed by a filemark.

The next block after the filemark was also 8192 bytes (with nearly, but
not exactly the same content as this Minicom utility file), but
thereafter, every other block on the tape was only 4096 bytes long, as
was all of the other blocks on the entire tape. (Notice that this is
either 8 or 16 times the length of a "normal" QIC-11 or QIC-24 512-byte
data block).

This tape was marked "LU0, position 1; LU1, position 2; LU2, position
3", so I expect this tape to have those 3 logical units on it.

It seems that there are 3 more filemarks on this tape (if I counted
correctly), so then this tape has 4 files, one file for the Minicom Disk
Utility, and one file for each of the Logical Units.

I can tell you right now that the LU0 file (if that is really what it
is), is 1,331,200 bytes, or exactly 1,300 Mb (if I did the math right).
The other 2 files I need to study more deeply to tell for sure, as they
span the tape tracks, and are more complicated for me to assemble.

Would it be best to just work with those as files, or do they need to be
kept in their original "Kennedy" block formation, or another block
formation or format?

Bruce, it is my goal to restore these tapes, and get a machine to run
again as close as possible to the way it would have when these backups
were made.  With your ability to run the Minicom file, it gives me great
hope that this is possible.

What would be my next steps to get myself working on a system that has
the capability of doing this?  I'm open to whether that is SimH,
reNOVAte, or other.

Thank you again, Bruce, this is very exciting news!

-AJ





On Wed, Nov 18, 2015 at 1:42 AM, Bruce Ray <[email protected]
<mailto:[email protected]>> wrote:

    G'day AJ -

    Briefly...

    The tape contains a disk/tape backup/restore utility that is
    somewhat representative of those used with Point 4, and other
    3rd-party DG lookalike systems. It is a stand-alone utility that is
    bootable if it exists as the first record of the first file of a mag
    tape or cartridge.

    The usual procedure is to bootstrap the tape using the Nova APL
    function (or just toggling in simple 2-instruction 'fat-finger'
    program).  Once the program is read into memory, it starts execution
    and displays its introductory message.  At this point another
    tape/cartridge may be loaded onto the tape drive for backup or
    restore purposes.

    I used our reNOVAte software for doing my investigations rather than
    SimH due to convenience, and was able to run the program and
    exercise its various functions. (Screen shots are attached.)

    This particular utility is very specific regarding the type of disk
    drive and IRIS logical units it supports.

    The utility assumes two devices exist: a tape controller using
    device code <022> and a disk controller using device code <027>. The
    tape controller may or may not perform QIC to DG-style file handling
    emulation since the original tape is not available to me.
    The disk controller appears to use the standard DG "Zebra"
    controller (Model 6060/6061/6067) programming model. However, it
    assumes a non-standard disk geometry of 16 cylinders, 5 heads, and
    32 sectors.

    The tape file itself needs to be created in the SimH tape if it is
    to be used with the default SimH tape driver. The QIC format may
    exist as a single large data record of 16,384 bytes, or of multiple
    512-byte records followed by a file mark. (I can not tell its
    original format given only the .bin file to work with.)

    The utility also makes assumptions about tape read timing and CPU
    instruction execution speed. Horrible programming technique, but
    unfortunately not uncommon practice.  Any such timing dependencies
    must be found and compensated for in the device driver or
    instruction emulation.

    Since there is no disk backup tape to load onto the disk, I used
    dummy disk data for testing the disk-to-tape and tape-to-disk
    functions.  Real backup tape(s) would obviously be needed to restore
    the original system.


    Bruce



    On 11/14/2015 3:35 PM, Microtech Dart wrote:

        Thank you, Dell, and Sandy Strain, both of your responses were
        EXTREMELY
        helpful to me, and these all worked!

        Do either of you have any additional thoughts about how I could make
        what I believe to be a bootable file (extracted from a
        Microtech/Point4
        QIC tape) into a bootable device for the Nova?

        I'll start with the Minicom Disk To Tape Utility:

        
http://microtechm1.blogspot.com/2015/09/minicom-disk-to-tape-copy-utility.html

        I've attached a .zip of the binary file that I extracted from
        this tape
        for reference.  It's very small, so I zipped it up only so that the
        emailing process didn't interfere with or reject it.

        Thanks, all!

        -AJ

        On Sat, Nov 14, 2015 at 7:23 AM, Dell Setzer <[email protected]
        <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>> wrote:

             It's actually pretty easy. After booting RDOS, press ^E to
        return to
             the sim> prompt. Then, attach a host file to the MTA0 unit.
        If you
             give a host filename that doesn't yet exist, SIMH will
        create an
             empty tape file and attach it to MTA0:

             sim> attach mta0 testtape.tap
             MTA: creating new file
             sim>

             Then, give the simh G command to return to RDOS and init/f
        the MT0
             tape unit. Note that at the sim> prompt, the unit is called
        "MTA0"
             (or MTA1, MTA2, etc), while in RDOS the unit is called
        "MT0" (or
             MT1, MT2, etc):

             sim> g
             <presss return to get the RDOS prompt again>
             R
             init/f mt0
             CONFIRM? <press Y to confirm>
             R

             Now you can dump or copy files to the MT0 device:
             dump/v mt0:0 -.sr
        LITMACS.SR <http://LITMACS.SR> <http://LITMACS.SR>
        OSID.SR <http://OSID.SR> <http://OSID.SR>
        NSID.SR <http://NSID.SR> <http://NSID.SR>
        PARS.SR <http://PARS.SR> <http://PARS.SR>
        ALMSPD.SR <http://ALMSPD.SR> <http://ALMSPD.SR>
                <etc.>
             R
             dump/v mt0:1 -.sv
        BURST.SV <http://BURST.SV> <http://BURST.SV>
        INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
        SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV>
        MACXR.SV <http://MACXR.SV> <http://MACXR.SV>
        EDIT.SV <http://EDIT.SV> <http://EDIT.SV>
                <etc.>
             R
             release mt0
             R

             After releaseing the tape, press ^E again to get to the
        sim> prompt
             and detach the tape file:
             ^E
             sim> detach mta0
             sim>
             Now you can inspect the testtape.tap tape image.

             Attaching an existing tape file is similar, except that at
        the RDOS
             prompt you'd do INIT rather than INIT/F:

             sim> attach mta0 testtape.tap
             sim> g
             R
             init mt0
             R
             load/n mt0:0
        LITMACS.SR <http://LITMACS.SR> <http://LITMACS.SR>
        10/20/83
        OSID.SR <http://OSID.SR> <http://OSID.SR>               01/10/84
        NSID.SR <http://NSID.SR> <http://NSID.SR>               10/20/83
        PARS.SR <http://PARS.SR> <http://PARS.SR>               01/31/85
                <etc>
             R
             load/n mt0:1
        BURST.SV <http://BURST.SV> <http://BURST.SV>              05/09/85
        INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
            05/02/85
        SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV>              05/02/85
                <etc>
             R
             release mt0
             R

             Hope this helps,
             ...dell

             On Sat, 14 Nov 2015, Microtech Dart wrote:

                 Hi, I am completely new here, although I recognize the
        names of
                 several who
                 post here.

                 I am trying to resurrect an extinct Microtech machine
        from 1982,
                 which
                 likely used the Point 4 processor, and the SimH DG Nova
                 simulator *should*
                 be compatible with the Point 4.

                 I'm running the NOVA simulator now, with:

                 NOVA simulator V4.0-0 Beta        git commit id: 3be5125d
                 sim> ATTACH DKP0 *rdos_d31.dsk*
                 sim> set tti dasher
                 sim> boot DKP0

                 I'm teaching myself RDOS now with the
                 RDOS_Command_Line_Interpreter Manual.

        
<http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dg/software/rdos/093-000109-01_RDOS_Command_Line_Interpreter.pdf>

                 Would anybody here be able to suggest some methods by
        which I could
                 *create* a magnetic tape device on this SimH Nova
        simulator, and
                 how I
                 might write some files to that?

                 I think that would be an excellent experiment for me to
                 attempt.  Then I
                 can inspect the binary file in a hex editor, and see
        what it
                 looks like,
                 then compare to the binaries I've pulled off my
        Microtech/Point
                 4 tapes.

                 --

                 Thanks,
                 -AJ
        http://MicrotechM1.blogspot.com




        --

        Thanks,
        -AJ
        http://MicrotechM1.blogspot.com


        _______________________________________________
        Simh mailing list
        [email protected] <mailto:[email protected]>
        http://mailman.trailing-edge.com/mailman/listinfo/simh

    _______________________________________________
    Simh mailing list
    [email protected] <mailto:[email protected]>
    http://mailman.trailing-edge.com/mailman/listinfo/simh




--

Thanks,
-AJ
http://MicrotechM1.blogspot.com


_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to