[Simh] DG Nova booting from another file or "device"?
Microtech Dart
microtechdart at gmail.com
Sun Nov 22 03:46:28 EST 2015
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> 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>> 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>>> 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>
>> OSID.SR <http://OSID.SR> <http://OSID.SR>
>> NSID.SR <http://NSID.SR> <http://NSID.SR>
>> PARS.SR <http://PARS.SR> <http://PARS.SR>
>> ALMSPD.SR <http://ALMSPD.SR> <http://ALMSPD.SR>
>> <etc.>
>> R
>> dump/v mt0:1 -.sv
>> BURST.SV <http://BURST.SV> <http://BURST.SV>
>> INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
>> SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV>
>> MACXR.SV <http://MACXR.SV> <http://MACXR.SV>
>> 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>
>> 10/20/83
>> OSID.SR <http://OSID.SR> <http://OSID.SR> 01/10/84
>> NSID.SR <http://NSID.SR> <http://NSID.SR> 10/20/83
>> 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>
>> 05/09/85
>> INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
>> 05/02/85
>> 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>
>> 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
>>
>>
>> _______________________________________________
>> 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/20151122/1564520a/attachment-0001.html>
More information about the Simh
mailing list