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