Convergent Technologies Mightyframe anyone?

[Michael Herzog]

Hello,

I could save 2 MightyFrames from being shreddered..... and have some
tapes. I restored the Archive 5445L-3
tape drive to a working condition, but I think no tape is fully
readable. The MF talks to me on CONSOLE 0,
I regularly get messages like "read failed in middle", and it breaks/
resets.

I also tried to read the tapes on sco unix, and on a newer linux (dd)
- it wont read anything. Do those QIC drives
use a special formatting, or are those tapes just dead? I would like
to get one of those machines back in a working
state....

Any ideas greatly appreciated ;)

Regards, Michael

[Thad Floryan]

On 9/28/2011 5:04 PM, Michael Herzog wrote:
> Hello,

Ah, good, you must have received my email suggesting this venue! :-)

> I could save 2 MightyFrames from being shreddered

For those who are unaware, the MightyFrame is a big brother to
the Convergent MiniFrame which is a kissing cousin to the 3B1.
All used the same CPU; the MightyFrame and MiniFrames ran CTIX
(Convergent Tech's UNIX) vs. the "pure" AT&T UNIX on the 3B1.

I had one MightyFrame that used to be the student mainframe at
the College of San Mateo <http://www.collegeofsanmateo.edu/>.

> ..... and have some
> tapes. I restored the Archive 5445L-3
> tape drive to a working condition, but I think no tape is fully
> readable. The MF talks to me on CONSOLE 0,
> I regularly get messages like "read failed in middle", and it breaks/
> resets.
>
> I also tried to read the tapes on sco unix, and on a newer linux (dd)
> - it wont read anything. Do those QIC drives
> use a special formatting, or are those tapes just dead? I would like
> to get one of those machines back in a working
> state....
>
> Any ideas greatly appreciated ;)

I'm assuming you're talking about boot tapes. Boot tapes are "odd" as
you can read about in the docs for my tprobe program from 1992 and
archived in comp.sources.unix. The best and fastest way to retrieve it
is from here:

<http://ae-www.technion.ac.il/pkgs/g-k/in/tprobe/tprobe>

That's a shell archive; remove everything up to but NOT including the
"#! /bin/sh", resave the file, then simply "sh filename". For easy
reading, a PDF of the man page is here:

<http://thadlabs.com/FILES/tprobe.pdf>

Read all the ancillary files and text extracted from the shell archive
to note the difficulty with boot tapes. I tested tprobe using my
Miniframes and MightyFrame and also 3B1s, Sun3s, Sun4s, and 3B2, and
comments from its 1000s of users indicated it worked fine on all systems
that everything has compiled and run it on.

Give tprobe a try and report whatever errors it displays.

[Michael Herzog]

Hello Thad,

thanks for your message!

> I'm assuming you're talking about boot tapes.  Boot tapes are "odd" as
> you can read about in the docs for my tprobe program from 1992 and
> archived in comp.sources.unix.  The best and fastest way to retrieve it
> is from here:

Yes, it goes about the boot tapes (CTIX RAW, CTIX DIAGNOSTICS, CTIX
MAINTENANCE).

> Give tprobe a try and report whatever errors it displays.

I will - as soon as I got it compiled.

Thank you very much for your help!

Regards, Michael

[Michael Herzog]

> I will - as soon as I got it compiled.

I got it compiled now (on sco 3.2v4.2) - it acts like this:

# tprobe /dev/rct0
SS 0: 0 blocks, 0 bytes
Read error = 5: I/O error
GTotal: 0 blocks, 0 bytes
#

And it acts like this on several tapes that wont boot the machine.
So, obviously all my tapes are faulty ?!

Regards, Michael

[do...@94.usenet.us.com]

Michael Herzog <michael...@gmx.at> wrote:
> I also tried to read the tapes on sco unix, and on a newer linux (dd)
> - it wont read anything. Do those QIC drives
> use a special formatting, or are those tapes just dead? I would like
> to get one of those machines back in a working
> state....

MightyFrame had unique firmware for handling "EOT" which was encountered at
the end of a track, a predictable distance from the beginning.
That might have only been on the 60 MB QIC, and not the 150, but my memory
fogs.
I know I used a "standard" Archive QIC to read the tape up to that point.

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

[do...@94.usenet.us.com]

Thad Floryan <th...@thadlabs.com> wrote:
> For those who are unaware, the MightyFrame is a big brother to
> the Convergent MiniFrame which is a kissing cousin to the 3B1.
> All used the same CPU; the MightyFrame and MiniFrames ran CTIX
> (Convergent Tech's UNIX) vs. the "pure" AT&T UNIX on the 3B1.

I have a MiniFrame that needs to find a home.
It probably hasn't been turned on in over 10 years, so the twin Maxtor 190's
may or may not spin. I also have a box of QIC tapes of various sorts,
which may or may not be stuck together.
I have the ethernet-16 serial port board that has never been powered up.

[DoN. Nichols]

Or are the heads of the tape drive needing cleaning? Usually
you use Isopropyl alcohol -- the higher the concentration the better.
Probably 91% for drug store purchased, not the 70%.

And if the heads get dirty as soon as you try another tape in
the drive, then the tapes are shedding. Keep cleaning and trying the
next tape to see if some of them are workable.

I don't know about the MiniFrame and MightyFrame tape drives,
but the "Floppy Tape" for the 7300/3B1/unix-pc are a weird format.
Actually formatted by a floppy tape controller, and they can't be read
by another system using normal tape formats. And it is the slowest
format for such tapes -- and gets all of 23 MB on a 60 MB tape and
drive, so very inefficient.

But if Thad suggested his tprobe, that suggests that the tapes
used on the newer machines are really a standard format. But beware
that each newer QIC tape drive can *read* perhaps one or two generations
older, but can't write them. perhaps your tape drive is too new? (What
is the SCO 3.2v4.2 running on, and what vintage?)

I know that I've used tprobe a lot with Sun 3 and Sun-2 tapes.
Sun-4 would use a QIC-150 tape drive, the Sun-3 a QIC-60 (or whatever
the 60 MB format: was called), and Sun-2 something even less capable.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

[Michael Herzog]

Hello DoN,

>         Or are the heads of the tape drive needing cleaning?  Usually
> you use Isopropyl alcohol -- the higher the concentration the better.
> Probably 91% for drug store purchased, not the 70%.

thanks for your suggestion - I already cleaned the heads before I
started
to test about. Also, the capstan wheels are new, I want to avoid a
mess
in my tape drive.

>         But if Thad suggested his tprobe, that suggests that the tapes
> used on the newer machines are really a standard format.  But beware
> that each newer QIC tape drive can *read* perhaps one or two generations
> older, but can't write them.  perhaps your tape drive is too new?  (What
> is the SCO 3.2v4.2 running on, and what vintage?)

I tried on 3 different tape drives: Wangtek 5150ES, Archive 2150S and
Wangtek
5099EN24. No at all. The SCO is running on a 386sx25, ISA-bus only
system :)

Regards, Michael

[Michael Herzog]

Hello Clarence,

> I have a MiniFrame that needs to find a home.
> It probably hasn't been turned on in over 10 years, so the twin Maxtor 190's
> may or may not spin.  I also have a box of QIC tapes of various sorts,
> which may or may not be stuck together.
> I have the ethernet-16 serial port board that has never been powered up.

pity I live in Europe, so I cant pick it up at yours :-( Or do you
have any other
ideas :-)

Regards, Michael

[DoN. Nichols]

On 2011-10-01, Michael Herzog <michael...@gmx.at> wrote:
> Hello DoN,
>
>>         Or are the heads of the tape drive needing cleaning?  Usually
>> you use Isopropyl alcohol -- the higher the concentration the better.
>> Probably 91% for drug store purchased, not the 70%.
>
> thanks for your suggestion - I already cleaned the heads before I
> started
> to test about. Also, the capstan wheels are new, I want to avoid a
> mess
> in my tape drive.

O.K. It was worth mentioning, just in case. I presume that you
tried cleaning the heads again later? If there is a lot to clean off
after just one tape, the tape is deteriorating, and you should give up
on it. (Or perhaps try baking the tape for about ten hours at a low
temperature (something like 150 F IIRC), as is done with old audio
master tapes -- good for only *one* play after that, so you copy it to
new media immediately after the backing.

>>         But if Thad suggested his tprobe, that suggests that the tapes
>> used on the newer machines are really a standard format.  But beware
>> that each newer QIC tape drive can *read* perhaps one or two generations
>> older, but can't write them.  perhaps your tape drive is too new?  (What
>> is the SCO 3.2v4.2 running on, and what vintage?)
>
> I tried on 3 different tape drives:

Wangtek 5150ES QIC-150 -- 150 MB tapes.
Archive 2150S and QIC-150 also -- same family, different maker.
Wangtek 5099EN24 QIC-36 (60MB tapes)

And what is the drive actually in the MightyFrame? (Or is it external?)

> . No at all. The SCO is running on a 386sx25, ISA-bus only
> system :)

O.K. Are all of these drives SCSI interface, or some other
interface?

[Michael Herzog]

>  Wangtek 5150ES         QIC-150 -- 150 MB tapes.
>  Archive 2150S and      QIC-150 also -- same family, different maker.
>  Wangtek 5099EN24       QIC-36 (60MB tapes)
>
> And what is the drive actually in the MightyFrame?  (Or is it external?)

The one in the MF is by Archive, Model 5945L-3. The 5150ES/2150S
should
be able to read QIC-24 (say the specs)....

>         O.K.  Are all of these drives SCSI interface, or some other
> interface?

All SCSI, yes. The 5945L-3 is equipped with an additional board (like
Emulex 02),
and this board has QIC connector.

Regards, Michael

[DoN. Nichols]

On 2011-10-01, Michael Herzog <michael...@gmx.at> wrote:

>>  Wangtek 5150ES         QIC-150 -- 150 MB tapes.
>>  Archive 2150S and      QIC-150 also -- same family, different maker.
>>  Wangtek 5099EN24       QIC-36 (60MB tapes)
>>
>> And what is the drive actually in the MightyFrame?  (Or is it external?)
>
> The one in the MF is by Archive, Model 5945L-3. The 5150ES/2150S
> should
> be able to read QIC-24 (say the specs)....

Good enough, then.

>>         O.K.  Are all of these drives SCSI interface, or some other
>> interface?
>
> All SCSI, yes. The 5945L-3 is equipped with an additional board (like
> Emulex 02),
> and this board has QIC connector.

O.K. Like the 60MB drives in Sun-3 machines. (Often sharing a
bootbox (a bigger box holding the tape in the center on a bridge above
the adaptor card, and the disk drive over against one wall, while the
power supply was against the other wall) with an ESDI disk drive with a
similar type of adaptor board to make both act as SCSI.

And with those, you *should* have normal formatting, not Floppy
Tape format. So I guess that the tapes are just plain unreadable.

Sorry,

[Michael Herzog]

Hello Don,

>         And with those, you *should* have normal formatting, not Floppy
> Tape format.  So I guess that the tapes are just plain unreadable.
>
>         Sorry,
>                 DoN.
>

thats what I was hoping not to hear. Do you know anyone that has those
tapes archived, or any source where those tapes could be -downloaded?

Regards, Michael

[DoN. Nichols]

I don't, but I hope that someone else does. Ideally, they
should make tprobe images of the tapes, and save those to CD-ROM so ne
tapes can be made when needed -- at least as long as the QIC blanks can
be purchased.

If I had ever had a MightyFrame, I would probably have made such
images of my tapes -- once Thad made the tprobe program available.

If I *did* have such tapes or images of them, I would not be
offering them in public, because I don't know who would assert copyright
on them. But, since I don't I don't have to worry about the decision.

Good Luck,

[Michael Herzog]

Hello Clarence,

> MightyFrame had unique firmware for handling "EOT" which was encountered at
> the end of a track, a predictable distance from the beginning.  
> That might have only been on the 60 MB QIC, and not the 150, but my memory
> fogs.
> I know I used a "standard" Archive QIC to read the tape up to that point.

did you use any special tool for this?

[do...@94.usenet.us.com]

DoN. Nichols <BPdnic...@d-and-d.com> wrote:
> If I *did* have such tapes or images of them, I would not be
> offering them in public, because I don't know who would assert copyright
> on them. But, since I don't I don't have to worry about the decision.

That's a fine question.
convergent.com was allowed to slip away, and Unisys never cared about the
MightyFrame.

Does anyone even care about the One True Unix, AT&T SVR-something?

I thought there was some official movement about the 3B1, but I don't know
about the "Convergent" stuff.

I have made copies of boot-install media from time to time for people that
needed something. One of those was a problem with a replacement QIC.

[davidca...@gmail.com]

I had a lot of Convergent stuff. I can check and see if I still have any QIC tapes.


On Tuesday, October 4, 2011 5:34:15 PM UTC-7, (unknown) wrote:
> DoN. Nichols &lt;BPdnic...@d-and-d.com&gt; wrote:
> &gt; If I *did* have such tapes or images of them, I would not be
> &gt; offering them in public, because I don&#39;t know who would assert copyright
> &gt; on them. But, since I don&#39;t I don&#39;t have to worry about the decision.
>
> That&#39;s a fine question.

> convergent.com was allowed to slip away, and Unisys never cared about the
> MightyFrame.
>

> Does anyone even care about the One True Unix, AT&amp;T SVR-something?
>
> I thought there was some official movement about the 3B1, but I don&#39;t know
> about the &quot;Convergent&quot; stuff.

[do...@94.usenet.us.com]

Michael Herzog <michael...@gmx.at> wrote:
> Hello Clarence,

> > MightyFrame had unique firmware for handling "EOT" which was encountered at

> > the end of a track, a predictable distance from the beginning. B

> > That might have only been on the 60 MB QIC, and not the 150, but my memory
> > fogs.
> > I know I used a "standard" Archive QIC to read the tape up to that point.

> did you use any special tool for this?

No special tools. dd or tar or whatever would work until it hit the end of
the first serpentine track and reversed. The last partially read block was
discarded and rewrittten/reread as the first block on the next track on
one version of the firmware. The other version of the firmware would use
the partial block and continue on the next track.

[marsde...@gmail.com]

On Sunday, 2 October 2011 23:48:55 UTC-4, DoN. Nichols wrote:
> On 2011-10-03, Michael Herzog <michael...@gmx.at> wrote:
> > Hello Don,
> >

> >> � � � � And with those, you *should* have normal formatting, not Floppy
> >> Tape format. �So I guess that the tapes are just plain unreadable.
> >>
> >> � � � � Sorry,
> >> � � � � � � � � DoN.

> >>
> > thats what I was hoping not to hear. Do you know anyone that has those
> > tapes archived, or any source where those tapes could be -downloaded?
>
> I don't, but I hope that someone else does. Ideally, they
> should make tprobe images of the tapes, and save those to CD-ROM so ne
> tapes can be made when needed -- at least as long as the QIC blanks can
> be purchased.
>
> If I had ever had a MightyFrame, I would probably have made such
> images of my tapes -- once Thad made the tprobe program available.
>
> If I *did* have such tapes or images of them, I would not be
> offering them in public, because I don't know who would assert copyright
> on them. But, since I don't I don't have to worry about the decision.
>
> Good Luck,
> DoN.
>
> --
> Remove oil spill source from e-mail
> Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564
> (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
> --- Black Holes are where God is dividing by zero ---

===
In case anyone wants them, I have boxes of old Convergent tapes in my basement from a Cdn support centre I worked at. When they closed it I couldn't bear to dumpster them.
I also have an S80 that I think works and an S120 or two as well -- but the wife is getting antsy to clear the basement, so any takers speak up soon...

Cheers, Larry.

[Convergent MightyFrame]

I want to thank everyone who has contributed to this post, and especially those who have taken the time to converse me on email and other posts about the MightyFrame. You all are very kind and generous with your time and resources.

This thread has been my most linked and most viewed, and has been a great teaching resource for me!

I have 2 of these Convergent Technologies MightyFrames that I am very committed to getting to run once again.

I've dedicated a website/blog to this effort and the MightyFrame at http://MightyFrame.com

Come by for a visit!

Thanks for keeping this stuff alive!

-AJ
http://MightyFrame.com

[DoN. Nichols]

On 2014-05-11, Convergent MightyFrame <mighty...@gmail.com> wrote:

> I want to thank everyone who has contributed to this post, and
> especially those who have taken the time to converse me on email and
> other posts about the MightyFrame. You all are very kind and generous
> with your time and resources.

> This thread has been my most linked and most viewed, and has been a
> great teaching resource for me!

> I have 2 of these Convergent Technologies MightyFrames that I am very
> committed to getting to run once again.

> I've dedicated a website/blog to this effort and the MightyFrame at
> http://MightyFrame.com

> Come by for a visit!

Looking at this, I see questions about the BIOS. Doesn't the
MightyFrame use a 68000 series CPU (68020 perhaps)?

The BIOS was started (to my knowledge) with CP/M for the 8080 CPU
(you had to assemble one specific for your hardware), and grew from
there through CP/M 86 (for the 8086 and 8088), and up through the MS-DOS
and Windows machines -- all depending on the Intel CPU families.

I've never heard of one for the 68K families. Certainly the
Unix-PC/7300/3B1 and the Sun-2 and Sun-3 machines depended on booting
from an install floppy or tape. That put enough of an OS into the swap
partition (in the case of the Suns) to allow configuring everything else.

And -- I have no idea how the MightyFrame migh taddress ISA
slots if it uses a 68K family CPU. Certainly the interrupt structure is
very different.

As for how to find the password (assuming the pervious owner set
a rather poor password), what I would suggest is first:

See whether there is a "guest" account. If so, it may have no
password, or a password of 'guest". With that, you can look at the
/etc/passwd file (not likely to be shadow protected with a system this
old), and copy all the lines which have passwords to another (more
modern and much faster system), and then run something like "crack" or
John-the-ripper on it to find any other passwords. If the passwords are
really poor, one of these on a modern fast machine should find the
password in very little time. The better the password, the longer it
will take, and a really good one will not be found at all.

I used this approach on a Tektronix 6130 (NS 32016 CPU), except
that there was not a version of crack available then. So, I wrote a
program to run that one password through the crypt(2) function and
compare with the one in the file for everything in /usr/dict/words -- on
three systems with combined /usr/dict/words files. It still took
a while, but the password was "gnome", which was in /usr/dict/words.

Another system, a Intergraph Interact/32C, had no gust account,
but the SCSI disk could be mounted on another system, and I was able to
finally find where the /etc/passwd file was, copy it elsewhere, and then
replace the hashed password with one which I knew, one byte at a time.
(Note that I could not mount the filesystem -- a difference between SysV
and BSD -- so I had to dig through the raw disk looking for the root
password entry. (Which should be something like:

======================================================================
root:XXXXXXXXXXXXXX:0:0:some-text:/:/bin/sh
======================================================================

Where the part shown as 'XXXXXXXXXXXXXX' is the hashed root password.

The length of the password (in those days) was always 14 bytes, so a
byte-for-byte replacement worked. Put the drive back in the system, and
I could log in.

Unless you can trace back to who owned the system, *and* they
can remember the root password, this would be the way you would have to
go. (Or, find someone with the install disks or tapes and do a fresh
install.)

The 3B1/7300/Unix-PC had a number of security holes which made
it easier to break into, unless closed by a knowledgeable administrator. :-)

Good Luck,
DoN.

--
Remove oil spill source from e-mail

Email: <BPdnic...@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564

[Convergent MightyFrame]

On Monday, May 12, 2014 10:29:54 PM UTC-5, DoN. Nichols wrote:
>
> Looking at this, I see questions about the BIOS. Doesn't the
>
> MightyFrame use a 68000 series CPU (68020 perhaps)?
>

Don, first let me thank you for your response...everyone here seems to be the world experts on these machines, because of your knowledge of the 7300/3b1. I'm glad that this newsgroup still gets some traffic and posts, and I'm thrilled to have a conversation with you on this thread.

Yes, this uses a 68020 chip...the motherboard pics are visible here: http://bit.ly/RQL1sa

> The BIOS was started (to my knowledge) with CP/M for the 8080 CPU
>
> (you had to assemble one specific for your hardware), and grew from
>
> there through CP/M 86 (for the 8086 and 8088), and up through the MS-DOS
>
> and Windows machines -- all depending on the Intel CPU families.
>
>
>
> I've never heard of one for the 68K families. Certainly the
>
> Unix-PC/7300/3B1 and the Sun-2 and Sun-3 machines depended on booting
>
> from an install floppy or tape. That put enough of an OS into the swap
>
> partition (in the case of the Suns) to allow configuring everything else.
>

This is very helpful. I'm not sure what a 68k family is yet, but I'm retro-learning here. It's great to know about the AT&T & Sun machine boot method...I think the MightyFrame is most similar to those, although different enough to keep this challenging.

> And -- I have no idea how the MightyFrame migh taddress ISA
>
> slots if it uses a 68K family CPU. Certainly the interrupt structure is
>
> very different.
>

I think my post on my site about the Compaq 386 has caused confusion here. I don't think the MightyFrame has any ISA slots at all, and pictured in that lengthy post is a PC, where I'm tring to get an Archive 5945 Tape drive to work in that machine, since I can at least get it to boot, and know how to use the OS. I want to do this, because the MightyFrame uses the same tape drive hardware, and I want to get the feel of how these tapes read files independent of operating systems. My post may not make this very clear, and confuse my questions about the 2 machines. The ARchive Tape Drive is the only common factor, and not even the controller board for it...even they are different.

> As for how to find the password (assuming the pervious owner set
>
> a rather poor password), what I would suggest is first:
>

Believe it or not, I do know the previous owner/user...they may or may not remember, but getting to a password is not anything I'm seeing in the MightyFRame yet...I may have again confused you by talking about XENIX password running on this 386 PC again. This is another thing I am trying to play with just to get used to using a Unix-style OS, in order to learn about the MightyFrame, again on a PC, not the MightyFrame, because I am familiar with the PC from this era....but your thoughts again are very helpful for that chapter of my meandering project =-)

I need to design this blog better so the first thing one sees is actually MightyFrame stuff! Ug...

Don, would you mind taking a look at the boot screens from our MightyFrames?

http://bit.ly/1lXOlfR

You might recognize some similarity with the 7300/3b1 or one of the Sun systems you are proficient in..

Any pointers with this will certainly help, no matter how random they might be.

Thanks again, and all the best!
-AJ

[DoN. Nichols]

On 2014-05-20, Convergent MightyFrame <mighty...@gmail.com> wrote:
> On Monday, May 12, 2014 10:29:54 PM UTC-5, DoN. Nichols wrote:
>>
>> Looking at this, I see questions about the BIOS. Doesn't the
>>
>> MightyFrame use a 68000 series CPU (68020 perhaps)?
>>

> Don, first let me thank you for your response...everyone here seems to
> be the world experts on these machines, because of your knowledge of the
> 7300/3b1. I'm glad that this newsgroup still gets some traffic and
> posts, and I'm thrilled to have a conversation with you on this thread.

> Yes, this uses a 68020 chip...the motherboard pics are visible here:
> http://bit.ly/RQL1sa

O.K. Those I was able to see.

I did not see one item which was a weak point on the
Unix-PC/7300/3B1. There was a coin cell soldered onto the system board
which kept the clock running -- or didn't when it eventually died. On
mine, I replaced the solder-in cell with a holder for a similar sized
coin cell so it could be replaced every few years at need without having
to dig out a soldering iron each time.

[ ... BIOS ... ]

>> I've never heard of one for the 68K families. Certainly the
>>
>> Unix-PC/7300/3B1 and the Sun-2 and Sun-3 machines depended on booting
>>
>> from an install floppy or tape. That put enough of an OS into the swap
>>
>> partition (in the case of the Suns) to allow configuring everything else.
>>

> This is very helpful. I'm not sure what a 68k family is yet, but I'm

68K family refers to all the Motorola 68000 series CPUs (68K
being shorthand for 68000), starting with the MC68000 itself (which was
in my first unix machine, a COSMOS CMS-16/UNX which had an 8 MHz MC68000
CPU. This had a 16-bit data bus, and (IIRC) a 24-bit address bus.
(Maximum address space of 16 MB.)

The 3B1/7300/Unix-PC used the MC68010 -- the first which had the
proper features to handle virtual memory, but was still a 16 bit data
bus and 24-bit address bus. This computer had only a maximum of 4 MB of
memory and virtual memory, thanks to limitations in the memory
management hardware. This same CPU chip was also used in the Sun-2
family of computers.

Your MightyFrame, and the Sun 3 series of computers used the
MC68020 -- 32-bit data bus and 32-bit address bus. (And an increased
instruction set, too.) Motorola rolled their own memory management
hardware too -- but designed for more address space.

There were a very few Sun machines which used the MC68040.
Similar data and address bus size, but it had its own memory management
built into the CPU, along with the floating point hardware. (You have
the MC68881 (floating point co-processor) the smaller chip beside the
68010 CPU chip. Because the 68030 had a different form of memory
management hardware (built into the CPU, the OS had to be different too,
because it controls the memory management hardware.

All of these chips (and some others which I've forgotten) make
up the 68K series of chips (families). (One other for my first machine
was the 68451, which was an external memory management chip which
allowed swapping, but did not allow virtual memory -- that needed the
68010 or later, and the 68882 (I believe) if not roll-your-own memory
management hardware.

> retro-learning here. It's great to know about the AT&T &Sun machine

> boot method...I think the MightyFrame is most similar to those, although
> different enough to keep this challenging.

Of course. So, you need to find the right boot tape or
floppies. (I didn't notice a floppy drive, or the tape drive, in the
photos of the CPU board -- but there are enough cables going off for
both plus hard disk drives.

>> And -- I have no idea how the MightyFrame migh taddress ISA
>>
>> slots if it uses a 68K family CPU. Certainly the interrupt structure is
>>
>> very different.
>>

> I think my post on my site about the Compaq 386 has caused confusion
> here. I don't think the MightyFrame has any ISA slots at all, and
> pictured in that lengthy post is a PC, where I'm tring to get an Archive
> 5945 Tape drive to work in that machine, since I can at least get it to
> boot, and know how to use the OS.

O.K.

> I want to do this, because the
> MightyFrame uses the same tape drive hardware, and I want to get the
> feel of how these tapes read files independent of operating systems. My
> post may not make this very clear, and confuse my questions about the 2
> machines. The ARchive Tape Drive is the only common factor, and not
> even the controller board for it...even they are different.

Tape drive operation can be very different, even with the same
drive hardware. The 3B1 used (as an option) what they called a "Floppy
Tape system". It used a tape drive of that family, though maybe not the
same tape drive. But it used to control it a floppy disk controller
chip, which forced it to rewind after each block was written -- very
slow, resulting in what I called "shoe shining" by moving the tape back
and forth over the head a lot more than is normally necessary.

I would hope that the MightFrame used a more reasonable way of
controlling the tape drive.

The Sun-3 systems used SCSI to talk to a controller board
mounted with the tape drive -- and to talk to the disk drives as well.

And depending on how the tape was written, one system can't read
something written by another system, even on the same drive.
(Especially different between the floppy tape and the SCSI interface.
No bets what a PC would use -- depends on the interface card plugged
into it.

>> As for how to find the password (assuming the pervious owner set
>>
>> a rather poor password), what I would suggest is first:
>>

> Believe it or not, I do know the previous owner/user...they may or may
> not remember, but getting to a password is not anything I'm seeing in
> the MightyFRame yet...I may have again confused you by talking about
> XENIX password running on this 386 PC again.

O.K. But get the old password from him before he forgets it, if
it is not already too late. But if there are no disk drives which came
with the system, the old password will be lost anyway. When installing
the OS on new disks, the system prompts you to set a password for the
root account sometime during the installation process.

> This is another thing I am
> trying to play with just to get used to using a Unix-style OS, in order
> to learn about the MightyFrame, again on a PC, not the MightyFrame,
> because I am familiar with the PC from this era....but your thoughts
> again are very helpful for that chapter of my meandering project =-)

Hmmm ... a 3B1 will make more sense to learn from, I think.
Xenix ran on PC style hardware, and required a different kind of disk
format than the 3B1 or Sun used. The primary difference is that I
believe the MightyFrame to work with a serial terminal connected as the
console, while the 3B1 makes its own terminal and has to boot to a
certain level before it can even put text onto the screen.

> I need to design this blog better so the first thing one sees is
> actually MightyFrame stuff! Ug...

Indeed so.

> Don, would you mind taking a look at the boot screens from our MightyFrames?
>
> http://bit.ly/1lXOlfR

> You might recognize some similarity with the 7300/3b1 or one of the
> Sun systems you are proficient in..

I can't get to it. That URL takes me to a point which wants me
to log into a Google account. I have been resisting getting a Google
account, because I don't particularly like them. :-) So, I can't get in
far enough to see the screen shots.

> Any pointers with this will certainly help, no matter how random they might be.

I'm afraid that I can't give any from that source. Not until I
can actually see the images.

Good luck,

[Convergent MightyFrame]

Don,

Thank you again for your in-depth explanations...these are ALL extremely, extremely helpful! I will follow your advice on all points, and see if I can direct my efforts to learning with a AT&T 7300 instead.... (I'd like a 3B1, but I think a 7300 is all I can find right now). I'll keep you posted on this, as I am sure that I will need 3B1 help once I get some system hardware put together.

On Tuesday, May 20, 2014 11:15:37 PM UTC-5, DoN. Nichols wrote:
> I can't get to it. That URL takes me to a point which wants me
>
> to log into a Google account. I have been resisting getting a Google
>
> account, because I don't particularly like them. :-) So, I can't get in
>
> far enough to see the screen shots.
>
>
>
> > Any pointers with this will certainly help, no matter how random they might be.
>
>
>
> I'm afraid that I can't give any from that source. Not until I
>
> can actually see the images.
>

Don, I totally respect your decision not to use or have a Google account. With that in mind, I have created a new post, displayed at the top of my blog at:

http://MightyFrame.com

Which should show all of the boot screens that I was referring to...no login required!

Clicking on each image should cause it to display large enough to read the text captured within each image.

Any feedback you could give on these boot screens is much appreciated!

Thanks,
-AJ

[DoN. Nichols]

On 2014-05-22, Convergent MightyFrame <mighty...@gmail.com> wrote:
> Don,

> Thank you again for your in-depth explanations...these are ALL
> extremely, extremely helpful! I will follow your advice on all points,
> and see if I can direct my efforts to learning with a AT&T 7300
> instead.... (I'd like a 3B1, but I think a 7300 is all I can find right
> now).

The primary differences between them are:

1) The hump under the monitor stem to hold a full-height drive
instead of the half-height that the 7300 had. (You can find a
half-height Miniscribe drive which with the proper WD controller
chip will offer the same capacity as the largest drive offered
in the 3B1 (67 MB).

> I'll keep you posted on this, as I am sure that I will need 3B1
> help once I get some system hardware put together.

And there will likely be others popping in for that.

> On Tuesday, May 20, 2014 11:15:37 PM UTC-5, DoN. Nichols wrote:
>> I can't get to it. That URL takes me to a point which wants me
>>
>> to log into a Google account. I have been resisting getting a Google
>> account, because I don't particularly like them. :-) So, I can't get in
>> far enough to see the screen shots.

[ ... ]

> Don, I totally respect your decision not to use or have a Google
> account. With that in mind, I have created a new post, displayed at the
> top of my blog at:

> http://MightyFrame.com

O.K. I can see them now.

> Which should show all of the boot screens that I was referring to...no login required!

> Clicking on each image should cause it to display large enough to read
> the text captured within each image.

Actually, I get better results zooming in with FireFox instead
of clicking on the screeen shots.

A lot of duplicated information, which could be snipped after a
few cycles, and a note in a caption saying "there were N lines just like
this" without losing any information.

> Any feedback you could give on these boot screens is much appreciated!

Many of the first screen shots are simply the system attempting
to boot from tape and reporting that the drive doesn't have a tape in it.

Some of the later screens apparently show a tape being present,
but blank, so it can't read anything. It is looking for a "VHB" (Volume
Home Block, I think) which contains the first level of bootstrap. It
loads that and transfers control into that and that does the later
stages of booting. This after discovering that there is no bootable
disk.

The "memory frames" complaints probably represent empty memory
sockets -- or totally missing extra memory boards.

It looks like you *do* have about 5 MB of memory in the system,
which should have been enough in those days.

The "CITX not running" means that it had not been able to boot
to the OS, so there is no point in making a core dump to be analyzed to
know what had gone wrong. :-)

The "Tape Status: " is followed by a long hex number, most of
which is zeros (indicating that there is no tape cartridge present,
which it also translates with the "WP NOCART".

The "Tape Status: BOM" with the shorter number says that the
tape has been rewound to the beginning of media, and then it tries to
boot -- but does not find the VHB because you don't have the right tape
for it -- the boot tape for installing the OS.

It looks to me as though you removed and re-installed the tape a
few times -- or swapped in other tapes.

But what is currently controlling the machine is rather
single-minded and wont be happy unless it finds a tape with the proper
VHB written on it.

There may be a switch somewhere which chooses between booting
from the tape, form an internal disk, or perhaps from a floppy, if the
VHB is small enough to fit a floppy, or the system is smart enough to
read multiple floppies to get a full VHB read in.

I don't know enough about the MightyFrame to really know. And I
don't think that I saw photos of switches in all of those pages before.
It is too late to go through tat again -- I've got a hamfest to get up
for tomorrow morning. :-)

But mostly -- you need the right tape -- written with the VHB at
the start, and then a sequence of other things (on likely multiple
tapes) to install the whole OS onto disks in the system.

But look for swtiches somewhere which might change the behavior.
Or jumper blocks on the system board where they can be changed without
having to pull the board out.

Good Luck,

[do...@94.usenet.us.com]

Convergent MightyFrame <mighty...@gmail.com> wrote:

> in that lengthy post is a PC, where I'm tring to get an Archive 5945 Tape
> drive to work in that machine, since I can at least get it to boot, and
> know how to use the OS. I want to do this, because the MightyFrame uses
> the same tape drive hardware, and I want to get the feel of how these tapes

The Mightyframe and MiniFrame used a different firmware chip on the Archive
tape drives from industry standard.
The difference was how it handled end-of-track partial blocks.

That wouldn't affect boot files, but does affect the install, or maybe the
ram boot, somewhere right around where "/bin/cpio" resides.

This is just a tape drive, and is not formatted in that odd shoe-shining
floppy emulator used in the 3B1, although it might be the identical drive.
I have some foggy recollections about whether the MightyFrame gained the
ability to read the floppy tapes, or the 3B1 gained the ability to read
regular tapes.

The boot sequence attempts to read anything for a boot block, in scsi ID
order. You might try unplugging the tape drive to see if the disk is
bootable.

If you can get a boot tape, it is a disk-image-on-tape, copied to RAM, from
which you can perform some of the password recovery that Don mentions.

[jlrca...@gmail.com]

Don, Clarence & all here:

I am still taking time out from time to time to process the fantastic information that you are sharing in your previous post here about my MightyFrame screens, system boot and CTIX. Always appreciated, and I am working to catch up to this language and way of thinking/understanding of this era of UNIX systems that are slightly before my time.

Meanwhile, I just thought I would share a recent "event" here, which has made quite a positive impact on my inspiration for this project:

Al Kossow of bitsavers.org and The Computer History Museum...
http://bitsavers.org
http://www.computerhistory.org/staff/Al,Kossow/

has made a great contribution to my MightyFrame project, our first manual! Writing MightyFrame Device Drivers - March 1986
http://bit.ly/1qDKY35

Now, I confess, I am not quite sure exactly how to understand it or use it yet, since I have yet to boot the OS one of these MightyFrame machines, but I'm still excited.

Al has also shared many 4-page pamphlets providing technical and high-level overviews of the MightyFrame http://bit.ly/1zbokjc

CTIX
http://mightyframe.blogspot.com/p/ctix.html

and The MiniFrame Plus
http://bit.ly/1olY7uF

I have re-posted all of these on new posts or pages on my blog,
http://MightyFrame.com

I just thought I would share all of these here in case it inspires anyone else, and/or gets more discussion going on the MightyFrame. I will be studying all of these in the coming days & weeks.

Thanks, Don, Clarence & all, for your continued help on the MightyFrame and related UNIX systems!
-AJ