Bruce, I am curious about our calculations on LU0. According to your calculations: 'the LUN byte sizes can be calculated from the previously-provided LUN "partition"'
LUN 0: 1,310,720 And then when I measure all the bytes in the blocks that make up the second file on the backup tape (marked LU0, pos1; LU1, pos2; LU2, pos3), where that 2nd file must be LU0, because the first file is the bootable Minicom utility, then I count: 1,331,200 bytes. This is actually 20480 bytes larger than you calculate the LU0 partition to be, or 5 blocks of 4096 bytes. This is SO close, yet it is off by that precise amount. Can you think of any reason why this might be the case? I ask, because I want to be sure that I am reconstructing the file from the blocks correctly. On Wed, Nov 18, 2015 at 2:55 PM, Bruce Ray <[email protected]> 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 <[email protected] >> <mailto:[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]> >> <mailto:[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]>> >> <mailto:[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> >> <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 >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> _______________________________________________ >> Simh mailing list >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> >> >> >> -- >> >> 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 >> > -- Thanks, -AJ http://MicrotechM1.blogspot.com
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
