Hi,
I have some old memory boards that use the EMM SEMI 4200 Chip (the same
as the Altair 16K Static RAM 16-MCS Board uses). They have TRI-DATA etched
into the copper. They also have "MCI 1" in white silk screen on the card.
They have a strange configuration: 6 Bit colum X 4 Bit row. They also
have an EPROM on board.
Does any one know where they came from, what they are used for and if
they are worth anything.
If they are worth something, I would be willing to exchange them for a
fair price. If they aren't worth anything, I'll just scrap them and sell
the memory for use with an Altair.
At any rate, if anyone knows anything about them, I would appreciate
knowing about them.
Thanks,
Neil.
On Dec 31, 20:07, Zane H. Healy wrote:
> As for the function keys, until recently I think the only thing I'd ever
> used them for was WordPerfect. Now I use them all the time on VT420's,
and
> wish I knew how to set them on a RS/6000. They would probably be used a
> LOT more if people knew how, or if there was some nice UNIX/Mac/Windoz
Apps
> for setting them to do stuff (of course there probably is, but I can't
> think of any).
I use them a lot too, partly because on my Unix box there's a little
utility called 'bindkey' to assign arbitrary strings to keys. It works for
any keys, but generally I find it more useful to assign command strings to
function keys, and I'm used to programming strings into function keys on
other micros (BBC Micro, Archimedes, mostly).
The insert() and string(string) functions in xterm should allow you to
program your function keys, but it's a bit tedious by hand, I expect.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
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.
In a message dated 12/31/98 10:14:47 PM EST, sinasohn(a)ricochet.net writes:
<< > 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 my research into alphapaging standards (I was working on a program for
the RS m100 to use it as an alphapaging station) I believe that is exactly
what it is. A tech from airtouch recommended I just buy one of those
instead of writing my own program. (Probably shoulda listened; the pgm
isn't done yet.) >>
well, if anyone wants this alphamate, just let me know. i dont want it.
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
