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