[Simh] DG Nova booting from another file or "device"?
Microtech Dart
microtechdart at gmail.com
Sat Nov 21 00:44:07 EST 2015
"Are the other LUN file sizes off by the same 20,480 amount?"
Bruce, that is an excellent question! I'm going to go through them and
figure that out.
On Fri, Nov 20, 2015 at 1:52 AM, Bruce Ray <Bruce at wild-hare.com> wrote:
> 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
>>
>> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Thanks,
-AJ
http://MicrotechM1.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20151120/c8ba4226/attachment-0001.html>
More information about the Simh
mailing list