On 11/27/2010 3:56 AM, jim s wrote:
On 11/26/2010 10:25 AM, Charlie Carothers wrote:
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.
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.
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.
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.
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.
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.
I'm sure you are correct. If I try to get my 820 going again I'm
going
to have a *lot* to relearn.
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.
There are about 5 extra
instructions, which are not so interesting plus
the long jump which is a big change and helps some.
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?
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.
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.)
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. :-)
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 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.
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