[Simh] DG Nova booting from another file or "device"?

Bruce Ray Bruce at Wild-Hare.com
Wed Nov 18 12:29:19 EST 2015


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 <Bruce at wild-hare.com
> <mailto:Bruce at wild-hare.com>> 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 <dsetzer at panix.com
>         <mailto:dsetzer at panix.com>
>         <mailto:dsetzer at panix.com <mailto:dsetzer at panix.com>>> 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
>         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
>
>
>
>
> --
>
> Thanks,
> -AJ
> http://MicrotechM1.blogspot.com
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


More information about the Simh mailing list