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]
<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
