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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> [email protected] >>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> >>> _______________________________________________ >> Simh mailing list >> [email protected] >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > -- > > Thanks, > -AJ > http://MicrotechM1.blogspot.com > -- Thanks, -AJ http://MicrotechM1.blogspot.com
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
