[Simh] DG Nova booting from another file or "device"?
Microtech Dart
microtechdart at gmail.com
Wed Nov 18 12:36:50 EST 2015
Sorry, that LU0 file has to be exactly *1,300KB* (Not MB, it was way too
late last night for me to do math...)
On Wed, Nov 18, 2015 at 3:21 AM, Microtech Dart <microtechdart at gmail.com>
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> 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>> 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>
>>> OSID.SR <http://OSID.SR>
>>> NSID.SR <http://NSID.SR>
>>> PARS.SR <http://PARS.SR>
>>> ALMSPD.SR <http://ALMSPD.SR>
>>> <etc.>
>>> R
>>> dump/v mt0:1 -.sv
>>> BURST.SV <http://BURST.SV>
>>> INITIALIZE.SV <http://INITIALIZE.SV>
>>> SEDIT.SV <http://SEDIT.SV>
>>> MACXR.SV <http://MACXR.SV>
>>> 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> 10/20/83
>>> OSID.SR <http://OSID.SR> 01/10/84
>>> NSID.SR <http://NSID.SR> 10/20/83
>>> PARS.SR <http://PARS.SR> 01/31/85
>>> <etc>
>>> R
>>> load/n mt0:1
>>> BURST.SV <http://BURST.SV> 05/09/85
>>> INITIALIZE.SV <http://INITIALIZE.SV> 05/02/85
>>> 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
>>> 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
>
--
Thanks,
-AJ
http://MicrotechM1.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20151118/0f51275a/attachment-0001.html>
More information about the Simh
mailing list