[Simh] DG Nova booting from another file or "device"?
Bruce Ray
Bruce at Wild-Hare.com
Fri Nov 20 02:52:36 EST 2015
G'day AJ -
The cylinder/head/sector information was determined by monitoring the
tape-to-disk LUN backup operation disk reads - these were the actual
cyls/hds/sects actually written for the corresponding LUN backups.
I just did the following quick (hopefully correct) calculation:
Each cylinder has 81,920 bytes (5 heads * 32 sectors * 512 bytes =
81,920 bytes/cylinder), and LUN0 has 16 cylinders: 16 cylinders * 81,920
bytes/cylinder = 1,310,720.
Are the other LUN file sizes off by the same 20,480 amount?
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 11/19/2015 11:48 PM, Microtech Dart wrote:
> Bruce, I am curious about our calculations on LU0.
>
> According to your calculations: 'the LUN byte sizes can be calculated
> from the previously-provided LUN "partition"'
>
> LUN 0: 1,310,720
>
> And then when I measure all the bytes in the blocks that make up the
> second file on the backup tape (marked LU0, pos1; LU1, pos2; LU2, pos3),
> where that 2nd file must be LU0, because the first file is the bootable
> Minicom utility, then I count:
>
> 1,331,200 bytes.
>
> This is actually 20480 bytes larger than you calculate the LU0 partition
> to be, or 5 blocks of 4096 bytes.
>
> This is SO close, yet it is off by that precise amount. Can you think
> of any reason why this might be the case?
>
> I ask, because I want to be sure that I am reconstructing the file from
> the blocks correctly.
>
>
>
>
> On Wed, Nov 18, 2015 at 2:55 PM, Bruce Ray <Bruce at wild-hare.com
> <mailto:Bruce at wild-hare.com>> wrote:
>
> G'day AJ -
>
> Creating a separate disk file that contains the contents of one of
> the tape files is okay. We can figuratively 'stitch" the files
> together into a format compatible with SimH by using some of our own
> utilities.
>
> Since the DiskUtility is transfers data on a block-for-block basis,
> all tape records must be recognized even if the record contains
> errors. Otherwise, the required relative position between tape and
> disk "records" will become lost. Error records can be indicated a
> variety of ways, so
>
> According to a quick calculation, the LUN byte sizes can be
> calculated from the previously-provided LUN "partition" info as:
>
> LUN 0: 1,310,720
> LUN 1: 7,864,320
> LUN 2: 9,175,040
> LUN 3: 9,175,040
> LUN 4: 8,683,520
>
> LUN 0, 1 and 2 can fit on boot tape according to DiscUtility hints,
> LUN 3 and 4 fit on separate (2nd) backup tape.
>
>
> Bruce
>
>
> On 11/18/2015 10:40 AM, Microtech Dart wrote:
>
> "What other file(s) am I missing?" I haven't sent the other 3
> LU files
> on the tape yet. Sorry, I should have made that more clear.
> Also, I
> didn't show the filemarks I was speaking of, that is where I
> ended one
> file and started the next, when I constructed them from the bits
> on the
> tape.
>
> Please keep in mind that I wrote the program that does this, so the
> method of what I'm doing here is understandably confusing...I barely
> understand it.
>
> There are a few block errors that I'm working on correcting in
> each of
> the files.. Shall I send those over to you even with the handful of
> block errors, or shall I continue to work on correcting them?
>
> I just looked at the first paragraph of your email...I'll read
> the rest now.
>
> On Wed, Nov 18, 2015 at 11:29 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 -
>
> 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>>
> <mailto: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>>>
> <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 <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>
> <http://LITMACS.SR>
> OSID.SR <http://OSID.SR> <http://OSID.SR> <http://OSID.SR>
> <http://OSID.SR>
> NSID.SR <http://NSID.SR> <http://NSID.SR> <http://NSID.SR>
> <http://NSID.SR>
> PARS.SR <http://PARS.SR> <http://PARS.SR> <http://PARS.SR>
> <http://PARS.SR>
> ALMSPD.SR <http://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>
> <http://BURST.SV>
> INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
> <http://INITIALIZE.SV>
> <http://INITIALIZE.SV>
> SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV> <http://SEDIT.SV>
> <http://SEDIT.SV>
> MACXR.SV <http://MACXR.SV> <http://MACXR.SV> <http://MACXR.SV>
> <http://MACXR.SV>
> EDIT.SV <http://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>
> <http://LITMACS.SR>
> 10/20/83
> OSID.SR <http://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>
> <http://NSID.SR>
> 10/20/83
> PARS.SR <http://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>
> <http://BURST.SV>
> 05/09/85
> INITIALIZE.SV <http://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>
> <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>>
> <mailto: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>>
> <mailto: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>
> <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
>
>
>
>
> --
>
> 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