[Simh] DG Nova booting from another file or "device"?
Bruce Ray
Bruce at Wild-Hare.com
Sun Nov 22 15:28:41 EST 2015
You are probably correct, starting at cylinder 16 rather than an
incorrectly-transcribed cylinder 15. I am traveling and can not confirm
this for a few days, though...
On 11/22/2015 1:46 AM, Microtech Dart wrote:
> Bruce,
>
> I am going over the LUN files in great detail, and I'm finding a
> pattern, with some discrepancy.
>
> Could you confirm one thing for me before I continue, please?
>
> According to the chart you sent below, it appears that LUN0 and LUN1
> overlap. If LUN0 ends on *15,4,31 *and LU0 begins on *15,0,0 *isn't
> this overlapping? Could it be that LU1 begins on 16,0,0 ?
>
> Could there be any other anomalies in this table? I just want to
> confirm before I hunt too much further. Going through these files
> block-by-block is fairly arduous.
>
> Thanks for all your help on this!
> -AJ
>
> *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*
> *
> *
> *
> *
>
> On Wed, Nov 18, 2015 at 11:29 AM, Bruce Ray <Bruce at wild-hare.com
> <mailto:Bruce at wild-hare.com>> wrote:
>
> 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>
> <mailto: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>>
> <mailto: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>
> <http://LITMACS.SR>
> OSID.SR <http://OSID.SR> <http://OSID.SR> <http://OSID.SR>
> NSID.SR <http://NSID.SR> <http://NSID.SR> <http://NSID.SR>
> PARS.SR <http://PARS.SR> <http://PARS.SR> <http://PARS.SR>
> ALMSPD.SR <http://ALMSPD.SR> <http://ALMSPD.SR> <http://ALMSPD.SR>
> <etc.>
> R
> dump/v mt0:1 -.sv
> BURST.SV <http://BURST.SV> <http://BURST.SV> <http://BURST.SV>
> INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
> <http://INITIALIZE.SV>
> SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV> <http://SEDIT.SV>
> MACXR.SV <http://MACXR.SV> <http://MACXR.SV> <http://MACXR.SV>
> EDIT.SV <http://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>
> <http://LITMACS.SR>
> 10/20/83
> OSID.SR <http://OSID.SR> <http://OSID.SR> <http://OSID.SR>
> 01/10/84
> NSID.SR <http://NSID.SR> <http://NSID.SR> <http://NSID.SR>
> 10/20/83
> PARS.SR <http://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> <http://BURST.SV>
> 05/09/85
> INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
> <http://INITIALIZE.SV>
> 05/02/85
> SEDIT.SV <http://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>
> <mailto: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>
> <mailto: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 <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
More information about the Simh
mailing list