I have the above drive. It was shipped to me
bolted in an enclosure. During shipping, it
was badly shocked, shearing off the mounting
bolts and damaging a couple of components
on the electronics board. A couple of resistors
and caps had their leads cut. Some creative
soldering fixed that. One diode was smashed.
It was on of those little clear (glass?) diodes.
Are those called zeeners or something that
starts with "z"? Anyway, I didn't have a
replacement, so I just removed the leads and
left it at that. Later I decided to go ahead and
try the drive, and it worked. If somebody has
the schematics, the silkscreen next to where
the diode was is "C1" (it is in one corner of the
board). Are there often nonessential components
in older hardware? Is it actually nonessential or
is some signal being compromised or some
other component being overstressed?
Bill Sudbrink
>> The dynamics of the microprocessor market is more complex than you think
<>> If MIPS was so good it would ahve pushed out x86. Alpha is a 64bit cpu
<>> targetted at high end systems and the MicroVAX (32bit) was already well
<>> established and faster than 386/486.
<
<I have to disagree with this, Allison, one of my points being: The value /
<speed / whatever of a Microprocessor means little versus the *marketing* o
<a processor / computer.
to a point that is true.
<The lowly Motorola 6809 at 2 Mhz outperforms a
<10Mhz 80286... by far. It also *smokes* the 6502. And other than Xenix 286
<(super-expensive), OS-9 is the most powerful OS available for these
<processors, and at a reasonable cost (When I bought my copy - $139.)...
the 6809 was pretty neat and close to PDP-11. It was however, slow!
Smoking a 6502 is not a contest, 16bit math and a few other things
the 6502 has trouble with impair it. Comparing it to a 286/10mhz,
sorry, no way. The 286 wasn't great but it was faster. Is OS-9 better
than DOS yes, Xenix, no. Is OS-9 better developed than most intel/ms OSs,
very likely. are there OSs for intel parts that show them better, yes.
The 6809 was still a mile behind the PDP-11 (either the T-11 chip or the
F11 cip pair and way behind the J11 chip).
Like you said marketing... who outside of us remembers OS-9 and the 6809?
Was the coco a better machine... no. It was good for it's time but the
system was still a grafted together set of pods and cables typical of many
of the trs-xx products.
People noticed the PCs and the like when they started to look competent,
complete and somewhat stable in operation. The contents of the box cpu
wise was more determined by the software development community than the
chip makers. IE: the guy in the lead for that time generally had the most
and best software widely available at low or no cost. That's why AppleIIs,
TRS-80s and PC are like house files for their respective times. No matter
how good or bad software to make them do useful work often drove them
forward.
Allison
In a message dated 12/31/98 9:42:11 PM EST, adavie(a)mad.scientist.com writes:
<< I wonder if there are other examples of
ins/outs that you oldies remember and would care to share. Things that were
ubiquitous and no longer with us. >>
how about BBSs? they are still around, but with the net catching on and
everyone getting on it, bulletin boards are all but forgotten it seems.
At 10:38 PM 12/22/98 -0600, you wrote:
> size keyboard and a 3x40 line lcd display. machine also has connections for
> rs232, telephone, and din plugs for modem and printer. machine can also run
>I tried to buy a lot of those once. I thought they were portable
>terminals, but they turn out to be "portable paging entry terminals" used
>to send pages to pagers, I assume.
> From: Tony Duell <ard(a)p850ug1.demon.co.uk>
> 25229 : This also has the 40 pin ASIC but with a totally different
> layout. C1 is a 0.1uF cap Near the power connector. CR1 is a 1N4148 a few
> components back from the middle of the front edge. There are 2 zeners,
> CR8 (12V) near the head connector and CR18 (2.4V) about halfway between
> the front edge of the board and pin 1 of the 40 pin chip
That's the one! I suck at ASCII art so lets try text. Looking
at the board component side towards me, 50 pin edge connector
up. In the upper right corner is a tin can cap aligned veritically,
silk screen seems to be "C26". To its left is the power connector.
Below it, aligned horizontally, is a clear component with bright
copper ends and fine black print which (straining my eyes) seems
to read:
104
Z
50V
The silkscreen that seems to be associated with it is "C25".
Directly below that is where the missing component was,
also aligned horizontally. The silkscreen that seems to be
associated with that position is "C1". The leads that remianed
had the same bright copper ends still attached. There were
bits of curshed clear material stuck to the board.
Before I go into the detail, let me first say that this bug likely
is as old as V5.5 (I only have looked at the V5.6 code
on a friend's system) which is when extended device drivers
were first introduced. So, we can say that the bug is about
10 years old and qualifies for this list since V5.5 of RT-11
was released in 1989.
The bug in RT-11 occurs when RT-11 has had a SYSGEN to allow
extended device drivers and a device driver which is extended
(allows more than 8 devices - in my case, I was using a DU:
MSCP device driver which allowed 64 partitions). In a test
case, the following sequence produces a crash:
SRUN KEX.SAV/LEVEL:n/NAME:KEXn for n = 1 => 6
after each do a CTRL/B to return to the background
Then do:
ABORT KEXn for n = 1 => 6
UNLOAD KEXn for n = 1 => 6
I tried this under RT11XM on V5.6 with an RL02 being
the boot device and DU: being auto-installed and not
referenced the whole time. In the actual situation,
DU: was being referenced on a magneto optical disk
drive to obtain specified files, but the DU: device
driver was not LOADed since there was insufficient
space left in low memory. So, although there are
probably a number of work arounds, the real problem
is that UNLOAD has a bug and does not work correctly
in these circumstances.
UNLOAD in KMOVLY has a bug, as far as I can understand.
In fact, possibly more than one. But, for now, just one that I can
handle. It would seem, in addition, that co-ordination between
different portions of the monitor may not have been done very
successfully since the USR does have the correct code to handle
the situation (a "Beq" instruction) while UNLOAD seems to
want to ignore the problem. Of course, if the USR had not
handled the problem correctly, there are likely going to be many
more occasions when the bug would have occurred, so in the
USR it was caught and the code is correct.
The exact description of the bug and owner tables may not be
correct. If so, please refer to the SSM. But the essential nature
of the bug is, I believe, correctly described.
THE PROBLEM, from what I can understand, is that in UNLOAD,
a system job MAY "own" a specific device (done via a LOAD
command). There is a two word owner table entry for each device
which has 4 bits allowed for each of the possible 8 drives normally
associated (DU0: => DU7:) with each device driver. When a
SYSGEN is done which includes extended device drivers, that
owner table entry of two words is too small and is used to "point"
to a 16 word (maximum size) table within the device driver ONLY
when the device driver is LOADed (I presume that a .FETCH may
also allocate the same 16 words, but they would not be used). SO
IF THE DEVICE DRIVER IS INSTALLed, BUT NOT LOADed,
the two word owner table entry can't "point" anywhere and the pointer
word is set at a default of zero. In the USR, when that word is picked
up, a "Beq" is used to detect that the device driver has not yet been
LOADed and no owner specific code is executed. BUT, UNLOAD
in KMOVLY does not have that instruction ("Beq") and merrily goes
and assumes that the extended device driver owner table entry (in the
case of an extended device driver SYSGENed system PLUS an
actual extended device driver such as DU:) is at the location starting
at zero. In the process of disconnecting the system job from a device
driver, the first 16 words in low memory are assumed to contain the
owner table entry AND the 8 vectors there (00 => 34 - which
obviously includes the EMT vector) can be "MODIFIED". Which
results in crashes in RT-11. If anyone is truly interested in this bug,
but does not understand what I have stated - the explanation I
have given is only a small portion of all the detail, please inquire
further.
Since this bug has not been encountered before - or if anyone has
but was unable to track it down - then likely the situation does not
occur very often. When DU: is resident, obviously DU: has been
LOADed. But I suspect that an extended LD: which is not LOADed
could also cause the same problem. The simple solution that I was
told about a number of years ago (when I had not yet been informed
that it was UNLOAD which was causing the problem) is to not
do the UNLOAD, but to instead do a BOOT which, of course,
does an UNLOAD of everything.
Sincerely yours,
Jerome Fine
Tim Hotze wrote:
>I agree here, too. Windows 95 really won't like a 486/20. Sure, in
>theory, it SHOULD boot, but your lifetime warranty on RAM might
>expire before you get to see a Start button.
Win95 OSR1 runs fine on my 486 33MHz. Well, good enough to run the
occasional game of multi-player Doom at any rate. Now if only I could work
out how it managed to upgrade itself from an SX to a DX whilst I was
installing Win95 ;)
-----Original Message-----
From: Hans Franke <Hans.Franke(a)mch20.sbs.de>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, 25 December 1998 2:20
Subject: Re: vaugue musings...
>
>> Merry Christmas All
>> It's after 7:30pm Xmas Eve, and it's 36C.
>> Seeya
>
>If it wasn't for Christmas, I'll hate you for teasing us
>with this ridicoulus temperatures while we have -3C :)
Want to swap? I HATE summer. My shop is not airconditioned and
I can't take computers apart while I'm dripping on to the boards.
I really like cold weather. Mind you, it never gets below 0C here,
except maybe a couple below during the mid winter nights.
>Anyway, Fr?hliche Weihnacht to all of you.
And to you all. It's 9pm on Christmas Day, we had a cool
southerly change, and the temp is now a very comfortable
22C or so. But it's still 30+ in the shop. Gonna have to get
some exhaust fans or an evaporative cooler at least......
We had Xmas Dinner outside around the BBQ, but it was
a bit warm even there.
Cheers
Geoff Roberts
Computer Room Internet Cafe
Port Pirie
South Australia.
netcafe(a)pirie.mtx.net.au
So I built the PC to 8 inch floppy converter and
got the software working (see other message).
I have tested four of the six drives I have and...
THEY ALL WORK!
Not only that, but they all agree with each other.
That is, a disk formatted and written on one drive
will read on any other drive.
Can I assume that this means they are all
properly aligned? I find this hard to believe
as two of the drives were mishandled during
shipping so badly that they sheared off their
mounting bolts and a few of the components
on one of the electronics boards were
damaged (more in next message).
Finally, where is write protection enforced?
There is a signal from the drive to the controller.
Is that just for the controllers information or
does the controller enforce the protection?
If the controller or software is bad can a drive
be forced to write to a protected disk?
Bill Sudbrink
