[Simh] DG Nova booting from another file or "device"?
Bruce Ray
Bruce at Wild-Hare.com
Wed Nov 18 15:55:14 EST 2015
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>> 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