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]
<mailto:[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]>
<mailto:[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]>>
<mailto:[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]>>>
<mailto:[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>
<http://LITMACS.SR>
OSID.SR <http://OSID.SR> <http://OSID.SR> <http://OSID.SR>
<http://OSID.SR>
NSID.SR <http://NSID.SR> <http://NSID.SR> <http://NSID.SR>
<http://NSID.SR>
PARS.SR <http://PARS.SR> <http://PARS.SR> <http://PARS.SR>
<http://PARS.SR>
ALMSPD.SR <http://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>
<http://BURST.SV>
INITIALIZE.SV <http://INITIALIZE.SV> <http://INITIALIZE.SV>
<http://INITIALIZE.SV>
<http://INITIALIZE.SV>
SEDIT.SV <http://SEDIT.SV> <http://SEDIT.SV> <http://SEDIT.SV>
<http://SEDIT.SV>
MACXR.SV <http://MACXR.SV> <http://MACXR.SV> <http://MACXR.SV>
<http://MACXR.SV>
EDIT.SV <http://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>
<http://LITMACS.SR>
10/20/83
OSID.SR <http://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>
<http://NSID.SR>
10/20/83
PARS.SR <http://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>
<http://BURST.SV>
05/09/85
INITIALIZE.SV <http://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>
<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]>>
<mailto:[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]>>
<mailto:[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]>
<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
--
Thanks,
-AJ
http://MicrotechM1.blogspot.com
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
