[Simh] DG Nova booting from another file or "device"?
Microtech Dart
microtechdart at gmail.com
Thu Nov 19 22:37:36 EST 2015
Thank you, Bruce...this is absolutely fantastic information.
I'm going to try to spend a few more days attempting to correct the handful
of block errors that I have, and then send those files over. The sizes you
mention for the LU files appear to be, at first glance, exactly what I
have. This confirmation is all very good.
So, the bootable Minicom utility file must have some kind of "last backup
stored data/memory" embedded within it, right? Otherwise, how would it
know all of that stuff?
I wonder, is there a date in there anywhere that indicates the date the
backup was done?
Thanks again!
-AJ
On Wed, Nov 18, 2015 at 2:55 PM, Bruce Ray <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>> 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
>>
>
--
Thanks,
-AJ
http://MicrotechM1.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20151119/e7f21a24/attachment-0001.html>
More information about the Simh
mailing list