22 Nov
2010
22 Nov
'10
4:03 p.m.
Yesterday my girlfriend and I returned from a hastily-scheduled road
trip to Maryland; we went to see a friend who is gravely ill. While we
were in town, we took the opportunity to visit a few other people.
Another friend up there is preparing to move, and he dropped a few
things in my lap since I was there with a mostly-empty car.
The first was a Data General Aviion AV300 workstation. This is one
of the few machines built around the Motorola 88K CPU. It came with its
original keyboard, mouse, monitor, and a full set of DG-UX manuals. I
don't yet know if it's functional, but according to my friend it was
running a few years ago.
The second is something I'm REALLY excited about. We went to his
garage and he pointed me at two dusty card-cages full of boards, and
told me that he picked them up from a college loading dock twenty years
ago, and that he had no idea of what they were, but there were core
memory boards in them. Oh, and there's this lights-and-switches front
panel that goes with them. (!)
Upon getting them home and digging around, it appears to be a nearly
complete Microdata 1600 CPU. I have the two backplanes with card cages
and boards, and the front panel, along with some cables. I lack the
power supply, but I can build one of those...with that, I think I have
enough to resurrect the basic CPU.
Neat stuff!
-Dave
--
Dave McGuire
Port Charlotte, FL
23 Nov
23 Nov
7:44 p.m.
On 11/22/2010 6:03 PM, Dave McGuire wrote:
Yesterday my girlfriend and I returned from a hastily-scheduled road
trip to Maryland; we went to see a friend who is gravely ill. While we
were in town, we took the opportunity to visit a few other people.
Another friend up there is preparing to move, and he dropped a few
things in my lap since I was there with a mostly-empty car.
The first was a Data General Aviion AV300 workstation. This is one of
the few machines built around the Motorola 88K CPU. It came with its
original keyboard, mouse, monitor, and a full set of DG-UX manuals. I
don't yet know if it's functional, but according to my friend it was
running a few years ago.
The second is something I'm REALLY excited about. We went to his garage
and he pointed me at two dusty card-cages full of boards, and told me
that he picked them up from a college loading dock twenty years ago, and
that he had no idea of what they were, but there were core memory boards
in them. Oh, and there's this lights-and-switches front panel that goes
with them. (!)
Upon getting them home and digging around, it appears to be a nearly
complete Microdata 1600 CPU. I have the two backplanes with card cages
and boards, and the front panel, along with some cables. I lack the
power supply, but I can build one of those...with that, I think I have
enough to resurrect the basic CPU.
Neat stuff!
-Dave
I'll be really interested to see how the 1600 restoration goes. Some
pictures would be nifty - hint, hint. :-) I keep thinking I'll dig the
820 I have out of the garage some day... I never worked with a 1600,
but I sort of assume it is in at least some ways a descendant of the 800
series.
Later,
Charlie C.
25 Nov
25 Nov
12:20 a.m.
the 800 was deemed not a good design to continue, and the 1600 was a
redesign by Ken Omohundro. The 800's DTL was a big reason to do the
redesign, as well as other problem with it.
What is the history of your 800?
Jim
On 11/23/2010 7:44 PM, Charlie Carothers wrote:
On 11/22/2010 6:03 PM, Dave McGuire wrote:
<snip>
I'll be really interested to see how the 1600 restoration goes. Some
pictures would be nifty - hint, hint. :-) I keep thinking I'll dig
the 820 I have out of the garage some day... I never worked with a
1600, but I sort of assume it is in at least some ways a descendant of
the 800 series.
Later,
Charlie C.
9:58 a.m.
On 11/25/2010 2:20 AM, jim s wrote:
the 800 was deemed not a good design to continue, and
the 1600 was a
redesign by Ken Omohundro. The 800's DTL was a big reason to do the
redesign, as well as other problem with it.
What is the history of your 800?
Jim
Because of the particular microcode, ours was called an 820. There
seemed to be some confusion at the time about that, as ISTR it was
sometimes referred to as an 822. It of course could become an 8xx where
xx is most anything just by plugging in a different microcode board.
Anyway, in the late 60's or early 70's Recognition Equipment, Inc. (REI)
in Dallas/Irving built a number of systems with the model designation
OCR/S-2000. The OCR/S meant Optical Character Reader/Sorter, and the
2000 was the maximum number of documents per minute that could be
processed. The 820 in the OCR/S-2000 was called I think the SSC meaning
SubSystem Controller, and it was interfaced to and controlled various
aspects of the document transport, control panel, etc. This system was
originally provided to the Swedish Post-Giro and was eventually used by
the Danish, Finnish, and Norwegian Post-Giros as well to optically read
and sort their various payment documents. I once knew how many of those
we built in all, but it has been too long now. I'm pretty sure it was
more than 20, which was a quite significant number for the company at
the time. These were not small systems physically! I'm trying to
remember how many sort pockets, and I'm sure at least 12, but I think
actually it was either 18 or 24 max.
After production stopped, some number of the 820's were surplussed and
acquired by one of the Field Service people who gave one to me. One of
the guys gave me several spare boards and other bits for it as well.
The last time I tried to fire one up, which was a lot of years ago, it
did not work and I never got around to finding out why. Now that I'm
semi-retired maybe I'll find the time to look into it again.
Before we did the OCR/S 2000 project some poor engineer did one with an
800. He actually wrote microcode to control some device. I say "poor"
because it was before the PROM microcode board was available, and he had
to solder/unsolder discrete diodes to "load" his code. And I thought
loading code from punched paper tape with an ASR-33 was slow!
The assembler for the 820 was written in Fortran IV, and I did quite a
lot of work on that. I used to think it was really cool to tell someone
I was going to go compile my assembler. :-)
Later,
Charlie C.
26 Nov
26 Nov
12:03 a.m.
On 11/25/2010 9:58 AM, Charlie Carothers wrote:
Because of the particular microcode, ours was called an 820. There
seemed to be some confusion at the time about that, as ISTR it was
sometimes referred to as an 822. It of course could become an 8xx
where xx is most anything just by plugging in a different microcode
board. Anyway, in the late 60's or early 70's Recognition Equipment,
Inc. (REI) in Dallas/Irving built a number of systems with the model
designation OCR/S-2000. The OCR/S meant Optical Character
Reader/Sorter, and the 2000 was the maximum number of documents per
minute that could be processed. The 820 in the OCR/S-2000 was called
I think the SSC meaning SubSystem Controller, and it was interfaced to
and controlled various aspects of the document transport, control
panel, etc. This system was originally provided to the Swedish
Post-Giro and was eventually used by the Danish, Finnish, and
Norwegian Post-Giros as well to optically read and sort their various
payment documents. I once knew how many of those we built in all, but
it has been too long now. I'm pretty sure it was more than 20, which
was a quite significant number for the company at the time. These
were not small systems physically! I'm trying to remember how many
sort pockets, and I'm sure at least 12, but I think actually it was
either 18 or 24 max.
After production stopped, some number of the 820's were surplussed and
acquired by one of the Field Service people who gave one to me. One
of the guys gave me several spare boards and other bits for it as
well. The last time I tried to fire one up, which was a lot of years
ago, it did not work and I never got around to finding out why. Now
that I'm semi-retired maybe I'll find the time to look into it again.
Before we did the OCR/S 2000 project some poor engineer did one with
an 800. He actually wrote microcode to control some device. I say
"poor" because it was before the PROM microcode board was available,
and he had to solder/unsolder discrete diodes to "load" his code. And
I thought loading code from punched paper tape with an ASR-33 was slow!
The assembler for the 820 was written in Fortran IV, and I did quite a
lot of work on that. I used to think it was really cool to tell
someone I was going to go compile my assembler. :-)
Later,
Charlie C.
Do you recall any of the people at Microdata you worked with. I can
name such as Max Malone, Al Weber, Chuck Canon.
The 821 firmware became the 1621, 1630, and later. I wrote and have a
Disk system we called MPS that was written at the University of
Missouri, Rolla for the 1621. We had a 5mb dynex drive, 2.5mb removable
over 2.5mb fixed which the system ran on. It was very similar to CPM,
but actually modeled after CPS on the IBM mainframe, and TSO.
I still have the software and firmware, and have an emulator I have been
working on to run the1621 code. I'd be interested if your friend with
the diode boards still has any notes or materials from the firmware project.
I have an 810 firmware in diodes. The diode boards run in both the 800
and the 1600.
As to your friend, the other thing that was interesting was that the
micro assember would not only give you the object tape out, but it would
give you a map of where to populate on the board, and a diode count if
you wanted it to.
I don't think I got the fortran cross assembler, or cross micro tools,
but there was also a simulator on which you could do some checkout, all
in fortran. The simulator on the mainframe was not interactive at the
time, and not very useful.
There was one written which ran on the 1600 that was interactive, and a
bit more useful. Sim1600.
Jim
10:25 a.m.
On 11/26/2010 2:03 AM, jim s wrote:
Do you recall any of the people at Microdata you worked with. I can name
such as Max Malone, Al Weber, Chuck Canon.
Hmmm, I don't think I ever actually
talked to anyone at Microdata. The
computer selection and company interface process all happened at a
higher level than I was involved with at the time.
The 821 firmware became the 1621, 1630, and later. I wrote and have a
Disk system we called MPS that was written at the University of
Missouri, Rolla for the 1621. We had a 5mb dynex drive, 2.5mb removable
over 2.5mb fixed which the system ran on. It was very similar to CPM,
but actually modeled after CPS on the IBM mainframe, and TSO.
Interesting. We
never had any "standard" peripherals interfaced to
ours. Ours was truly an "embedded" controller. If it had been a few
years later, I'm sure we would have used a Motorola 6800 or similar.
Another group in the company was already using the Fairchild F8 in a
product, but I think it was felt the F8 could not meet the processing
requirements.
I still have the software and firmware, and have an emulator I have been
working on to run the1621 code. I'd be interested if your friend with
the diode boards still has any notes or materials from the firmware
project.
I'm afraid I've completely lost touch with him, and I was not
involved
with his project at all. At the moment I can remember his first name
but not his last. Since you say 1621 emulator I'm assuming you mean the
higher level code and not the microcode. Isn't it interesting with
these machines how one must specify the code "level". I'm sure there
are other examples of this, but I've never personally encountered it
other than with the Microdata machines. BTW, I've always had a pipe
dream of replacing the 800 microcode board with one containing RAM.
That would open up some interesting possibilities I think!
I have an 810 firmware in diodes. The diode boards run in both the 800
and the 1600.
I'm pretty sure I have at least one discrete diode 820 firmware
board as
well. I did not know the 1600 would run the same microcode. I assume
from that fact that the low level architecture in the
1600 is the same
or possibly a super set of the 800's.
As to your friend, the other thing that was interesting was that the
micro assember would not only give you the object tape out, but it would
give you a map of where to populate on the board, and a diode count if
you wanted it to.
I'm guessing the micro assembler ran on a 360?
I don't think I got the fortran cross assembler, or cross micro tools,
but there was also a simulator on which you could do some checkout, all
in fortran. The simulator on the mainframe was not interactive at the
time, and not very useful.
It has been a very long time, but I seem to recall the
820 assembler I
started with was written in Fortran ?? to run on an IBM 360. For a
variety of reasons we needed it to run on a Datacraft 6024. For one
thing, though the accounting department had a 360 it did not have a
paper tape punch peripheral. (I suppose I could have "punched" to mag
tape on the 360 and then done a mag tape to paper tape copy on the 6024,
but there were other issues as well.) I really doubt that I have the
source of the 820 assembler. If I do, it is probably only on a mag tape
which has been in the garage a lot of years. I *might* possibly have a
hard copy listing of the Fortran source code. I'm sure I don't have the
punched card deck that was my working source.
There was one written which ran on the 1600 that was interactive, and a
bit more useful. Sim1600.
I never used a simulator for the 820. For development
purposes we had
an ASR33 interfaced to the 820 and a small debugger that lived at some
dedicated place in core memory. The debugger could also load the
application from a higher speed paper tape reader.
Jim
27 Nov
27 Nov
1:56 a.m.
On 11/26/2010 10:25 AM, Charlie Carothers wrote:
The simulator was for the microcode.
It was to relive some of the pain
of testing with proms, which was expensive, and also spare users the
cost of the Microdata AROM, which cost about 1/2 again as much more than
the system itself for 1k x 16 of firmware. Later the cost was brought
down to only about 4000 / 1k, but that still was a lot of course.
There are about 5 extra
instructions, which are not so interesting plus
the long jump which is a big change and helps some.
There
were cross 810 or whatever assemblers, 800 firmware assemblers and
linkers for both. There was a stab at a simulator for the 1600 as
well. All was run at Data 10 on TSO timeshare, though 99% of the stuff
was run Batch. They also did the 3200 on the same accounts, both
firmware, and early compilers.
We (the university) had purchased a
Wangco tape drive anticipating the
problem of cross software development. A fellow who worked at Bell Labs
for a long time, Bob Flandrina, wrote a tape loader which would load
cross assembled binaries, and the like from the 360. We got in some
trouble with the data center once because Bob had been using the little
DTR's which usually had PTF service on them and were only about 100' or
so of tape. His early version of a tape had 1 single record on it, and
no EOT. The mainframe read the record dutifully for a while and then
promptly tried to forward to the next record. The entire tape vanished
into the vacuum column at that time, and made quite a mess.
The other way that tapes could be made was to run them to a channel
connected Nova 1200 that the data center had.
However we solved the probem with MPS, which ran the microdata assember,
etc. on the 1600.
On 11/26/2010 2:03 AM, jim s wrote:
We had a 2950 disk controller, and a concurrent tape controller, as
well
as the console which was an ASR 33. There was also another serial port
with an LSI terminal on it.
Do you recall any of the people at Microdata you worked with. I can name
such as Max Malone, Al Weber, Chuck Canon.
Hmmm, I don't think I ever actually
talked to anyone at Microdata.
The computer selection and company interface process all happened at a
higher level than I was involved with at the time.
The 821 firmware became the 1621, 1630, and later. I wrote and have a
Disk system we called MPS that was written at the University of
Missouri, Rolla for the 1621. We had a 5mb dynex drive, 2.5mb removable
over 2.5mb fixed which the system ran on. It was very similar to CPM,
but actually modeled after CPS on the IBM mainframe, and TSO.
Interesting. We
never had any "standard" peripherals interfaced to
ours. Ours was truly an "embedded" controller. If it had been a few
years later, I'm sure we would have used a Motorola 6800 or similar.
Another group in the company was already using the Fairchild F8 in a
product, but I think it was felt the F8 could not meet the processing
requirements.
I still have the software and firmware, and have an emulator I have been
working on to run the1621 code. I'd be interested if your friend with
the diode boards still has any notes or materials from the firmware
project.
I'm afraid I've completely lost touch with him, and I was not
involved
with his project at all. At the moment I can remember his first name
but not his last. Since you say 1621 emulator I'm assuming you mean
the higher level code and not the microcode. Isn't it interesting with these machines how one
must specify the code
"level". I'm sure there are other examples of this, but I've never
personally encountered it other than with the Microdata machines.
BTW, I've always had a pipe dream of replacing the 800 microcode board
with one containing RAM. That would open up some interesting
possibilities I think!
There never was an AROM product or even a lashup in
engineering for the
800. The 1600 was the first with programmable rom. It was loaded by
running a loader program on the system when it was running the
1610/12/20/21 or whatever, then halting and reconfiguring to use the
AROM as the source of ROS for the micromachine. I think the original
810 was about 3 128 location sections of the firmware, and was gradually
expanded out as they had resources and time to develop and release the
code.
the AROM for the 1600 really allowed for much more complex emulations to
be developed. The 800 and 1600 were mostly the same, so all of the 800
stuff came across. The 800 firmware would run on the 1600 w/o changes,
as release. The 1600 firmware had a few extra firmware instructions in
them, and would not backport to the 800.
I have an 810 firmware in diodes. The diode boards run in both the 800
and the 1600.
I'm pretty sure I have at least one discrete diode 820 firmware
board
as well. I did not know the 1600 would run the same microcode. I
assume from that fact that the low level architecture in the 1600 is
the same or possibly a super set of the 800's.
As to your friend, the other thing that was interesting was that the
micro assember would not only give you the object tape out, but it would
give you a map of where to populate on the board, and a diode count if
you wanted it to.
I'm guessing the micro assembler ran on a 360?
I don't think I got the fortran cross assembler, or cross micro tools,
but there was also a simulator on which you could do some checkout, all
in fortran. The simulator on the mainframe was not interactive at the
time, and not very useful.
It has been a very long time, but I seem to recall the
820 assembler I
started with was written in Fortran ?? to run on an IBM 360. For a
variety of reasons we needed it to run on a Datacraft 6024. For one
thing, though the accounting department had a 360 it did not have a
paper tape punch peripheral. (I suppose I could have "punched" to mag
tape on the 360 and then done a mag tape to paper tape copy on the
6024, but there were other issues as well.) I really doubt that I have the source of the 820
assembler. If I do,
it is probably only on a mag tape which has been in the garage a lot
of years. I *might* possibly have a hard copy listing of the Fortran
source code. I'm sure I don't have the punched card deck that was my
working source.
there was a bit of firmware that
did that called firmware TOS as well.
I don't know if you used your own loader, or the one supplied by Microdata
There was one written which ran on the 1600 that was interactive, and a
bit more useful. Sim1600.
I never used a simulator for the 820. For development
purposes we had
an ASR33 interfaced to the 820 and a small debugger that lived at some
dedicated place in core memory. The debugger could also load the
application from a higher speed paper tape reader.
Jim
28 Nov
28 Nov
7:50 p.m.
On 11/27/2010 3:56 AM, jim s wrote:
The simulator was for the microcode.
It was to relive some of the pain
of testing with proms, which was expensive, and also spare users the
cost of the Microdata AROM, which cost about 1/2 again as much more than
the system itself for 1k x 16 of firmware. Later the cost was brought
down to only about 4000 / 1k, but that still was a lot of course. If you were doing
much microcode, I can see where that would be a real
time and money saver. I suspect it would not take long to pay for it in
reduced development time. We never had any of that AFAIK, but then we
never wrote any microcode on our project either.
I'm sure you are correct. If I try to get my 820 going again I'm
going
to have a *lot* to relearn.
There are about 5 extra
instructions, which are not so interesting plus
the long jump which is a big change and helps some.
There
were cross 810 or whatever assemblers, 800 firmware assemblers and
linkers for both. There was a stab at a simulator for the 1600 as well.
All was run at Data 10 on TSO timeshare, though 99% of the stuff was run
Batch. They also did the 3200 on the same accounts, both firmware, and
early compilers.
We (the university) had purchased a
Wangco tape drive anticipating the
problem of cross software development. A fellow who worked at Bell Labs
for a long time, Bob Flandrina, wrote a tape loader which would load
cross assembled binaries, and the like from the 360. We got in some
trouble with the data center once because Bob had been using the little
DTR's which usually had PTF service on them and were only about 100' or
so of tape. His early version of a tape had 1 single record on it, and
no EOT. The mainframe read the record dutifully for a while and then
promptly tried to forward to the next record. The entire tape vanished
into the vacuum column at that time, and made quite a mess. Sounds to me like the
mainframe OS software was not doing all the
checking it should. :-)
On 11/26/2010 10:25 AM, Charlie Carothers wrote:
That's much more than we ever had. We did use one
in a later system
called TRACE that had an attached CRT terminal, but that was it. I do
have a little 9-track tape drive with 7 inch (?) reels that I think was
interfaced to the 820 at one time for some reason. I've never even
tried to get that working again.
On 11/26/2010 2:03 AM, jim s wrote:
We had a 2950 disk controller, and a concurrent tape controller, as
well
as the console which was an ASR 33. There was also another serial port
with an LSI terminal on it.
Do you recall any of the people at Microdata you worked with. I can name
such as Max Malone, Al Weber, Chuck Canon.
Hmmm, I don't think I ever actually
talked to anyone at Microdata. The
computer selection and company interface process all happened at a
higher level than I was involved with at the time.
The 821 firmware became the 1621, 1630, and later. I wrote and have a
Disk system we called MPS that was written at the University of
Missouri, Rolla for the 1621. We had a 5mb dynex drive, 2.5mb removable
over 2.5mb fixed which the system ran on. It was very similar to CPM,
but actually modeled after CPS on the IBM mainframe, and TSO.
Interesting. We
never had any "standard" peripherals interfaced to
ours. Ours was truly an "embedded" controller. If it had been a few
years later, I'm sure we would have used a Motorola 6800 or similar.
Another group in the company was already using the Fairchild F8 in a
product, but I think it was felt the F8 could not meet the processing
requirements.
I still have the software and firmware, and have an emulator I have been
working on to run the1621 code. I'd be interested if your friend with
the diode boards still has any notes or materials from the firmware
project.
I'm afraid I've completely lost touch with him, and I was not
involved
with his project at all. At the moment I can remember his first name
but not his last. Since you say 1621 emulator I'm assuming you mean
the higher level code and not the microcode. Isn't it
interesting with these machines how one must specify the code
"level". I'm sure there are other examples of this, but I've never
personally encountered it other than with the Microdata machines. BTW,
I've always had a pipe dream of replacing the 800 microcode board with
one containing RAM. That would open up some interesting possibilities
I think!
There never was an AROM product or even a lashup in engineering for the
800. The 1600 was the first with programmable rom. It was loaded by
running a loader program on the system when it was running the
1610/12/20/21 or whatever, then halting and reconfiguring to use the
AROM as the source of ROS for the micromachine. I think the original 810
was about 3 128 location sections of the firmware, and was gradually
expanded out as they had resources and time to develop and release the
code.
the AROM for the 1600 really allowed for much more complex emulations to
be developed. The 800 and 1600 were mostly the same, so all of the 800
stuff came across. The 800 firmware would run on the 1600 w/o changes,
as release. The 1600 firmware had a few extra firmware instructions in
them, and would not backport to the 800.
That makes perfect sense, and seems a
quite reasonable approach.
I have an 810 firmware in diodes. The diode boards run in both the 800
and the 1600.
I'm pretty sure I have at least one discrete diode 820 firmware
board
as well. I did not know the 1600 would run the same microcode. I
assume from that fact that the low level architecture in the 1600 is
the same or possibly a super set of the 800's.
As to your friend, the other thing that was interesting was that the
micro assember would not only give you the object tape out, but it would
give you a map of where to populate on the board, and a diode count if
you wanted it to.
I'm guessing the micro assembler ran on a 360?
I don't think I got the fortran cross assembler, or cross micro tools,
but there was also a simulator on which you could do some checkout, all
in fortran. The simulator on the mainframe was not interactive at the
time, and not very useful.
It has been a very long time, but I seem to recall the
820 assembler I
started with was written in Fortran ?? to run on an IBM 360. For a
variety of reasons we needed it to run on a Datacraft 6024. For one
thing, though the accounting department had a 360 it did not have a
paper tape punch peripheral. (I suppose I could have "punched" to mag
tape on the 360 and then done a mag tape to paper tape copy on the
6024, but there were other issues as well.)
The other way that tapes could be made was to run them to a channel
connected Nova 1200 that the data center had.
We did a lot with just punched paper
tape. ISTR we later developed a
way to load from a mag tape drive on the Datacraft 6024 to the 820.
That would have worked well in the field since a 6024 was a part of each
system and was already interfaced (in some manner that I don't recall)
to the 820.
However we solved the probem with MPS, which ran the microdata assember,
etc. on the 1600.
I really doubt that I have the source of the 820
assembler. If I do,
it is probably only on a mag tape which has been in the garage a lot
of years. I *might* possibly have a hard copy listing of the Fortran
source code. I'm sure I don't have the punched card deck that was my
working source.
there was a bit of firmware
that did that called firmware TOS as well. I
don't know if you used your own loader, or the one supplied by Microdata
There was one written which ran on the 1600 that was interactive, and a
bit more useful. Sim1600.
I never used a simulator for the 820. For development
purposes we had
an ASR33 interfaced to the 820 and a small debugger that lived at some
dedicated place in core memory. The debugger could also load the
application from a higher speed paper tape reader.
Jim
13 Mar
13 Mar
11:39 a.m.
Hello!
You have software for Microdata computers - I was glad to read this.
I am adjusting Microdata-compatible computer (Multi-20 - based
Plurimat S). The system is looks faultless, but I have not any
software for it - even bootstraps.
So I'll be very grateful, if you'll send some of your software to me.
I am afraid, that I can not write it myself, so downloading is mine
last ray of hope.
You wrote:
I still have the software and firmware, and have an
emulator I have been
working on to run the1621 code.
Truly your, Pavel.
25 Nov
25 Nov
12:21 p.m.
We are still using our DG Aviion AV66 and AV37 computers for running Cobol
programs-- dozens of them. And Oracle. We're gradually migrating it all off
the Aviions, but our original goal of May 1 2010 has gone whooshing by.
Maybe next May...
At 07:03 PM 11/22/2010 -0500, you wrote:
Yesterday my girlfriend and I returned from a
hastily-scheduled road
trip to Maryland; we went to see a friend who is gravely ill. While we
were in town, we took the opportunity to visit a few other people.
Another friend up there is preparing to move, and he dropped a few things
in my lap since I was there with a mostly-empty car.
The first was a Data General Aviion AV300 workstation. This is one of
the few machines built around the Motorola 88K CPU. It came with its
original keyboard, mouse, monitor, and a full set of DG-UX manuals. I
don't yet know if it's functional, but according to my friend it was
running a few years ago.
The second is something I'm REALLY excited about. We went to his
garage and he pointed me at two dusty card-cages full of boards, and told
me that he picked them up from a college loading dock twenty years ago,
and that he had no idea of what they were, but there were core memory
boards in them. Oh, and there's this lights-and-switches front panel
that goes with them. (!)
Upon getting them home and digging around, it appears to be a nearly
complete Microdata 1600 CPU. I have the two backplanes with card cages
and boards, and the front panel, along with some cables. I lack the
power supply, but I can build one of those...with that, I think I have
enough to resurrect the basic CPU.
Neat stuff!
-Dave
--
Dave McGuire
Port Charlotte, FL
-----
565. [Sex] Women complain about sex more than men. Their gripes fall into two
major categories: (1) Not enough. (2) Too much. --Ann Landers (b. 1918)
--... ...-- -.. . -. ----. --.- --.- -...
tpeters at nospam.mixcom.com (remove "nospam") N9QQB (amateur radio)
"HEY YOU" (loud shouting) WEB: http://www.mixcom.com/tpeters
43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square
EN53wc
WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531
4984
days inactive
5094
days old
10 comments
6 participants
participants (6)
-
a50mhzham＠gmail.com -
adr-1＠yandex.ru -
aek＠bitsavers.org -
csquared3＠tx.rr.com -
jws＠jwsss.com -
mcguire＠neurotica.com