or... wandering around the house, finding stuff that any normal person would have thrown out decades ago.
Take a walk down memory lane with me!
Many of these photos were taken in 2010 -- so the subjects don't look quite as nice as when they were built (:>).
There was one computer for the whole county. I was a little surprised that the Board of Education let us run our programs on the one computer the county owned: the one that printed the teachers' paychecks! Once a week the class took a schoolbus to the Board of Education headquarters where we submitted our card decks and waited for our printouts (Lee reminds me that half of the class traveled every other week). Of course, this was all batch programming. At first we got back compiler error messages showing syntax errors, and then eventually we got printouts from our executables back after we made those fixes. The box of punched cards above is not generic, it is the actual box of my programs from then.
Of course we did the standard assignments, but that was mostly irrelevant. I went crazy programming on my own
(some with Lee Nackman WA3IRQ) all sorts of mathematical functions, including plotting functions that printed with asterisks,
solving quadratic equations, fitting polynomials, perfect numbers, etc., blah-blah-blah. But I was mesmerized with calculating prime numbers. The program above is my first prime number program.
Teachers along with everyday people back then weren't that computer literate, and it was commonplace to be told that computers were infinitely fast.
I hadn't really thought about it, but the output from that first prime number program was this:
That first prime number program was the most brute force one could be: it literally checked every possible pair of factors for each tested integer, even the even numbers.
Who cares about efficiency if the machine is infinitely fast? A whole new attack was necessary. I
improved my prime number programs
until I got a printout within the permitted execution time up through 32,653.
I don't think I even thought about exceeding the integer maximum, that concept was beyond my horizon at the time.
When I arrived on campus in 1972 there was a university-wide computing facility in the basement of Garland Hall (think it's still there). It offered the standard fare for the time: batch processing with card decks. I think I used it a few times for some classwork SPICE circuit simulations, but it was definitely uninteresting. However, the EE Department itself had a timeshare system running on a DEC PDP-11/45 minicomputer in Barton 120, where the student lounge is now. The computer ran the RSTS O/S, which offered BASIC. And BASIC. And BASIC. You get the idea. There was a terminal room next door which had maybe 6-10 terminals. Well, I shouldn't say terminals -- they were mostly teletypes. The bulk of them were ASR-33 teleprinters, which printed upper case only on friction-fed yellow roll paper. At an astounding 10 characters per second. While we look down on those machines from the modern perspective, they did have two redeeming factors: a built-in paper tape punch and paper tape reader. Seems crude, but in fact they were very useful. The terminal punch and reader functions were independent from the computer itself, so the user could manually turn either on or off at will. It could simultaneously punch tape as it printed; and you could activate the reader to transmit characters to the computer, to which it appeared as if they were coming from the keyboard. You didn't need special save options. There was one KSR-37 teletype which printed in upper and lower case, letter quality. It might have been 15 cps and it had sprocket feed for good paper registration. But I don't recall RSTS offering any word processing capability, so not that useful. But it was a wonder to watch it print: it moved the type apparatus (it wasn't really a ball or a wheel) and spun it around to switch case. That machine rocked across the table when printing. Later on it would become the station of choice when word processing came along. There was one CRT video terminal that I can remember: a Hazeltine. It displayed green characters on a black background (this is looong before color or graphics). I thought it was the greatest, and always strived to get that station when available. It was silent, and of course fast (all the terminals were direct connected to the PDP-11's serial ports). Much nicer than 10 cps! Of course, the computer had disk drives which you might get space on, and there was also DECtape, which was a small addressable magnetic tape system (you could buy your own tapes and try to be permitted to mount them). Yes, the paper tapes and the DECtape in the photo contain my actual files. There were also a few dial-in modem lines.
BASIC was heavily used in my Models and Simulation class (we modeled stream pollution among other things) and it was easy to program for whatever you might wish.
...and along came UNIX
I am guessing it was in the 1975 timeframe that things began to change on the department minicomputer. William Huggins (RIP, sir) made periodic drives up I-95 to Bell Labs in Holmdel, NJ. He came back with mag tapes. On those tapes was a new programming language... called C. And a new operating system... called UNIX. Eventually they switched the PDP-11 from RSTS to UNIX. That caused big excitement, because imagine you're a grad student who's spent years putting programs together... and suddenly they don't run as is! For a while, RSTS was run overnight to grandfather those still needing it.
There was a cadre of younger (than me) undergraduates heavily involved with Prof. Huggins and UNIX software development; I wasn't really involved with them, but was aware of the goings-on.
Still, UNIX was an eye-opener for me, as I'd never previously encountered the panoply of system services it offered.
I was compiling BARC member directories, and I learned enough of the system to make use of the various built-in features to accomplish that.
Mainly the sort command, but I wrote some small C programs to massage the data so I could feed it into the various utility functions.
The main new capability UNIX offered was real text processing: there was a text editor, of course, but there were some roff programs (troff, nroff) which accepted unformatted text as input and output formatted text.
No more need for simple typewriters, and a special need for that one KSR-37.
And while I joked to potential investors (I kept a 1920-era L. C. Smith & Corona manual typewriter in my Telesaver office and told people I didn't trust modern electronics), I don't believe I wrote anything of length on a regular typewriter ever again.
There was a line printer (actually just a fast dot matrix printer) in the computer room -- but it certainly wasn't letter quality.
Nothing special in this section, just an expanding knowledge of computer uses beyond number crunching.
Digital discrete time simulations now reign supreme and have relegated these devices to the dustbin of history.
In 1973 I took Roger Westgate's course on Assembly Language. There was one DEC PDP-11/20 (16-bit minicomputer) for the entire class, so we had to schedule timeslots to get access to the machine. I had no trouble doing the work, but for the first few weeks it just didn't make sense to me. Then one day something clicked, and I understood what it was all about! For newbies out there, let me tell you how we programmed this machine (we walked uphill in the snow... both ways):
The PDP-11 had core memory, which of course is nonvolatile. So if you get programs into it, they'll stay there until something alters the memory contents. But let's assume we're starting with nothing. The minicomputer had binary toggle switches and lights on the front panel. By setting the switches for the address of interest, you can see what's currently in that spot on the lamps. To change it, enter the new data on the data toggle switches and momentarily store it with another button. Change the address and start again.
Of course, that's a tedious process, but the computer was attached to an ASR-33 teletype which has a paper tape reader. So all we really needed to do was load the smallest program that could be written which could communicate with the ASR-33. That program is called the bootstrap loader. It's a very simple protocol which loads a binary byte image from the 8-bit paper tape. We had a slightly larger program called the absolute loader on paper tape, which is what we got into the machine using the bootstrap loader and ASR-33. That provided a good loader program. Next, we got out the paper tape containing the executable binary (resident) assembler program, and loaded that into the computer. It was a pretty long fanfold paper tape, and took 15-20 minutes to finish the process (10 cps). Now we can run the assembler program and text editor. So type in your program and assemble it. After you correct the reported syntax errors, you get an executable binary image in the machine.
No problem so far, but now comes crunch time... are you feeling lucky? Give the command to actually execute your assembled program. In a perfect world, it works, you're happy, and relinquish the computer with the assembler still intact to the next student in line for the machine. But when your program runs, it is in control of the computer. Utterly and totally. This is something I've never seen before. With FORTRAN, BASIC, RSTS, UNIX, etc., the new program is filtered through all sorts of protections. It might fail, but all of the other users are insulated from your foibles. Not so with assembly language. You're the boss for better or worse.
So if your program doesn't work, maybe it fails benignly and causes no damage. But it's not unlikely that it crashes and overwrites all of core memory! When that happens, start the entire process over again with the bootstrap loader. And endure the groans of derision from your classmates, who know it will be another 20 minutes or so, at best, before they can begin to try their work out.
I don't remember too much of what we did in that class, but we must have learned a lot because I had no trouble later on when I ended up doing some consulting work for a company which coincidentally had a
JHU 4004 System
Prof. Westgate (who many decades later finally got his WC2R ham license) was aware that Intel had invented the world's first microprocessor chip, the 4004 (on November 15, 1971). He proposed that we at JHU get some familiarity with it -- after all, maybe microprocessors will turn out to be something! That was my project for the summer of 1974.
I built three boxes: the MCS-4 microcontroller (MCS-4 refers to the entire chip set, the 4004 is the CPU chip); the 1702A EPROM programmer; and a paper tape reader interface.
It would be an exaggeration to say that I designed it. The Intel manual had schematic diagrams of the products that Intel sold, which included the 1702A programmer and various 4004 configurations.
I duplicated the guts of the programmer circuitry, which itself was not that simple. The 1702A was an erasable programmable read only memory. You erase the 256 x 8 bit part with exposure to an ultraviolet lamp.
Its programming algorithm requires switched 50-volt signals on all of its address and data lines, with a particular timing constraint. It took a lot of high voltage switching transistors to accomplish that.
I laid out a double-sided circuit board for the unit's electronics, using clear acetate film base with stick-on tape for the traces and component holes.
The 2:1 artwork was imaged in the department's darkroom (adjacent to the elevator on Barton Hall's fourth floor) and I ended up with 1:1 film negatives. The copper clad stock was treated with photoresist,
exposed through the negatives, developed, and the copper etched. I had made circuit boards before, but this one was more complex.
The power supply circuitry is underneath the chassis on perfboard.
We had Henry Berkley, a teenager in the Gifted and Talented program, assisting us. He wrote two BASIC programs (that ran on the RSTS timeshare PDP-11/45 system). The first took keyboard entry of hand-assembled MCS-4 code (in 1's and 0's) and output a binary tape through an ASR-33. The second was a BASIC cross assembler for the MCS-4. (I wonder where he is today, I'm sure he's done great.)
Initially I had intended to use the PDP-11/20 to control the 1702A programmer, but instead used the MCS-4 microprocessor for this task. That, in and of itself, showed the capability of these new microprocessors! My PROG.RAM program (very creative name, it programs EPROMs, haha) ran on the MCS-4 with its I/O ports hooked up simultaneously to the constructed paper tape reader and the 1702A programmer. It commanded the paper tape reader to read bytes from the tape, looked for a rubout start header, then subsequently read databytes from the tape and commanded the programmer to burn those locations in the EPROM. This continued until a rubout end marker was read. Not all that complicated, really. But it was quite impressive at the time, because here was a microprocessor controlling hardware. Prior to these new devices, industrial process control was either done with specialized pure hardware solutions, or minicomputers. Minicomputers were probably two orders of magnitude less expensive than mainframe computers, but still around $20,000 apiece. That's a lot of dough to control some equipment. Microcomputer boards were easily another two orders of magnitude cheaper. This clearly opened the door to a multitude of programmed control applications that would have been impractical previously. The significance of the revolution was not lost on this then 20-year old.
As a ham, I could not stop myself from programming the MCS-4 to generate Morse code. It seems that I repeated that task for every processor I ran into later.
There were two companies in the Baltimore area at the time that manufactured totalizing equipment for the horseracing industry: Amtote and Unitote. (The middle leg of the Triple Crown is run right here at Pimlico -- where my grandfather worked many years and eventually formed a union for his fellow employees.) The equipment to keep track of betting in realtime and recalculate odds was eating up these 4-bit processor parts voraciously. A former student (of Prof. Westgate) who was employed at one of those companies would stop into our lab occasionally and give us chips. Who else even understood what they were? We appreciated the gifts.
I wrote a paper describing our system, and presented it at an IEEE student conference of some type in Pittsburgh. (I seem to have lost my schematics of the 1702A programmer from that report, but here are the ones from Intel's Manual that I started from.) We took pictures and made up 35mm projector slides for the presentation. For some reason, Prof. Westgate thought it would be interesting for us to develop the color slides ourselves. I'd become quite proficient with black and white photographic processing in our darkroom, but color processing required many more steps -- and each timed step needed to be fairly closely temperature-controlled. Our efforts were successful. I had misplaced those slides, but finally found them 36 years later when I had them digitized for the photographs on this page. So our darkroom chemistry must have been okay for them to still be usable! But I never again did color development, I left that travail to Fotomat.
I don't remember actually using the MCS-4 for anything else. I took that knowledge to construct a repeater controller, and used the 1702A programmer a lot until the 2708 EPROM came out. The equipment was in Barton Hall for a while, and then it disappeared. From my inquiries I learned from Andreas Andreou that he last saw it in a storeroom or laboratory in Cyprus. Don't ask me how it ended up in the Mediterranean.
In all seriousness, it is accurate to say that this 1974 summer project initiated by Prof. Westgate in large part led to my career working with microcontrollers.
Microprocessors did turn out to be something, indeed!
Other JHU Microprocessors
Educational trainer boards starting coming out in the late 1970's, and we used several of them to teach classes and offer 3-day industrial training seminars (that Gerald Masson organized -- I recall one at the Mayflower Hotel in DC).
There were SDK-80 and SDK-85 (system development kit) boards from Intel, and some 6800 boards that had keypads and 7-segment LED displays on them.
Later on we moved to the CAMI Z-80 trainers. My memory was jogged when I inadvertently ran into this at a local hamfest:
My graduate research centered around characterizing and ultimately eliminating embedded microcontrollers from "crashing" their programs.
Of course there are lots of dead-ends in that endeavor. Here are a couple of pictures I found of my lab bench in the late 1970's:
The first video is a single recording which shows seven crashes; after each (except the last one) I reset both processors.
The second video is actually seven short runs strung together. Each time Controller 1 stops behaving properly, I reset both processors and took another clip.
(Graduate studies supported by NASA, the FAA, and Fairchild.)
Handbook of Software Engineering
A book comprehensively covering the field of Software Engineering was put together by experts C. R. Vick and C. V. Ramamoorthy as editors. They selected separate authors from various sub-fields to write individual chapters. I wrote Chapter 27, "Software Development for Micro/Mini Machines." The book was published in 1984 by Van Nostrand Reinhold Company, Inc. But it had taken them a long time (probably coordinating with so many authors?) to complete it. I wrote my section in 1980. Here is the chapter.
I just found a letter I had placed in the book from their Computer Science Editor, requesting that I expand my section to form an entirely new book on its own.
I never responded and forgot about it -- but it was dated January 1985, a time period when I was overloaded with work at Telesaver.
and now let's go back in time a few years...
An updated version with the same specs -- the TV Typewriter II -- was published in the February, March, and April 1975 issues of Radio-Electronics by Ed Colle. The magazine pages are here, and a product description of the SWTPC CT-1024 Terminal kitted version is here. Towards the end of 1975 a number of us bought the circuit boards and parts to assemble our own (not the SWTPC kit). I'm not sure how many actually worked, but mine did and is above. It was built into a wood paneling box. I found some really great (Ultronic) keyboards (bare keyswitches themselves, no electronics) at a hamfest. I ended up buying several and used them for a few other projects, too. I used a 25-pair telephone cable with edge card connectors to hook the keyboard to the terminal itself (no small 4-wire cable like the later IBM PC keyboards). I ended up modifying the character generator to handle lower case letters (I can see the white 1702A EPROM programmed with lower case characters below the black 2513 upper case character generator chip in the above photo), and I added cassette tape storage/playback circuits as well.
This was my computer terminal from 1975 to mid-1980. I also used it to make titling shots with a 35mm SLR camera for Kodak Carousel Projector slideshow presentations (the negative was inverted, which meant that the resulting slide consisted of black characters on a clear background). They could be standalone informational screens, or I'd put the title slide on top of a color image before mounting to superimpose captioning. This was long before the Powerpoint presentations prevalent today!
You can see by the selector switch markings that the TV Typewriter communicated at 110 through 1200 bps. Anything over 300 bps was useless for remote computing, because...
I used my modem/TV Typewriter system to dial into the JHU EE department's computer, and my little brother (who was in high school at the time) was able to do his homework (online!) before he even got to the school's computer lab (which had improved since the time I was there).
------> The MAXI micro <------
Putting this 1976 timeframe into an historical perspective, remember that the Apple I went on sale in July 1976; Radio Shack's TRS-80 first units were rolled out to the stores the third week of December 1977; and the IBM PC was introduced on August 12, 1981. I took a motorcycle ride up to Atlantic City to see the Personal Computing 1977 show (the first was in 1976) in August; here is an article I published in the BARC Modulator reporting on the event.
(The photo above shows some deterioration after decades of storage; the inward-pointing arrows have lost half an arrowhead each, it's dirty, and the front cover doesn't stay put. It looked better back in the day.) I retained the address and data LEDs, but did away with the binary data entry switches. I had used those to input the bootstrap loader on the PDP-11 minicomputer one too many times to saddle myself with that! My experience with the JHU 4004 system made it clear that I wanted EPROM nonvolatile memory to permit the base operations (nowadays we call that the boot ROM) to be via terminal. The basic system was an 8080 CPU with 60K (bytes) of RAM and up to 4K of EPROM. You don't realize how large that 60K number was in those days. The Wikipedia article shows that an Altair with that much memory would have run $4610 as a kit including the peripherals I constructed. That's in 1975 dollars, and I was a student! Here is an Altair price list I found dated April 1, 1976.
I first got the MAXI micro operational on November 2, 1976.
The memory map was tricky smart in my biased opinion. On system reset, the EPROM memory board was mapped to addresses 0000h-0FFFh. That's necessary because the 8080 begins executing code at 0000h -- nonvolatile memory has to be there. The problem with leaving it like that is that RAM must be somewhere else; where should general purpose programs be placed in memory? They have to be higher, but depending on how large they are and how much RAM is present, different starting locations are desired. The 8080 doesn't use relocatable code for the most part, so you have to assemble each program to run at a particular location. My scheme had the ROM monitor program immediately write to an I/O port to essentially "flip a switch" which re-mapped the memory architecture: after the switch, the EPROM board occupied addresses F000h-FFFFh. So the monitor program was assembled to run in that address space. After the switch, the eight 8K RAM boards (one was half populated to leave 4K for the EPROM) were placed into the memory range 0000h-EFFFh. This freed up the bottom of memory which I took advantage of when I wrote my operating system.
The front (really the top) panel let you pause program execution and single-step instructions for education or debugging.
The Main Power switch fed the RAM, and the Processor Power switch activated everything else.
So once RAM was loaded with programs, I would usually leave the Main Power switch on (always) and use the Processor Power switch to turn the computer on and off.
Because of the dense and mostly parallel interconnections, I made (double-sided) circuit boards for the EPROM and RAM boards (a flawed unused RAM board shown in the MAXI micro shot farther above right). The Molex strip IC sockets had no insulating housing and permitted soldering on the top of the circuit board in addition to the bottom -- which I needed because the homemade PCBs didn't have plated-through holes. The EPROM board (second above) had spots for sixteen 1702A 256x8 chips for a total 4Kx8 capability. This only held the (boot) monitor program, so you can see I didn't need all sixteen populated.
The RAM board (above two at right) was the reason the computer system itself could be made so productive. I started with three boards for 24K and by July 1977 had all eight complete, providing the full complement of 60K RAM. Each RAM board contained eight rows of eight 2102 1024x1 bit chips. I had used these in my Reprogrammable CW Identifier and Orbit Memory designs previously. At the Lancaster hamfest, I spotted someone peddling a bunch of pulled circuit boards from some unidentified data processing system. Nothing unusual about that, hams and computer hobbyists commonly used surplus boards to pull off chips of interest -- the boards themselves are useless. But the ones I found had arrays of 2102's! Of course, you never know if the chips are good -- after all, the boards were thrown in the trash for a reason. Recognizing that there was gold in memory on those boards, I bought a few. Unsoldering a DIP chip is time-consuming with no guarantee of success. Removing 480 of them (I needed 64 for each of my memory boards) is a daunting process. Instead of employing the standard process of solderwick, or trying to melt all pins with some type of soldering iron extension, I used a very crude (but quick) approach: (1) put board in vice; (2) light propane blowtorch; (3) with right hand, grip a 2102 with pliers; (4) with left hand, heat the *&^%$# out of the traces and chip pins; (5) keep pulling with the pliers until the chip comes off the board; and finally (6) blow out the flame when the circuit board material catches fire. I broke some, and pins sometimes weren't all included, but I developed a technique to get these parts off fast. (It turns out you can remove chips pretty quickly if you don't mind destroying the circuit board.) Clean and straighten the pins and insert into memory board sockets. Tadah! They actually worked! The rest of the 1976 summer I traveled to nearby hamfests looking for the same fellow with the 2102's (not that he necessarily knew what he had) -- I found him and bought enough additional boards to ensure I'd have enough to max out the 8080 memory architecture. I paid a total of $190 for all of those memory boards (40 cents per used 2102). Remember, the Altair price for 60K RAM was $3960. Most hobbyist computer owners at the time had 8K, or maybe even 16K in their machines if they were lucky.
The October 1977 Byte issue contained a Spacewar game.
(Here is a web-based version.)
This is one of the cleverest programs I have ever encountered.
Very sorry to learn that its author, Dave Kruglinski, tragically died in a 1997 paragliding accident.
The Spacewar game created a realtime simulation of two spacecraft and their fired missiles in orbit around a central Sun.
It used a two-dimensional lookup table to calculate the force of gravity (M*G*m/r^2) on all of those objects.
Plus, it had to paint a video screen within the human flicker detection time. On a 2 MHz 8-bit 8080!
The display could not be something like the character-based TV Typewriter; instead, two digital-to-analog converters (DAC) drove the horizontal and vertical (watch out, Outer Limits) inputs of an oscilloscope.
Outputting the two analog voltages placed a dot on the scope screen. All of the dots had to be drawn within one display frame.
The board at left contains the MAXI micro's DAC's for the game, which I implemented right after that Byte issue's arrival.
The MAXI micro photo farther above at right shows the two player boxes that went along with the game (the buttons are: clockwise; counter-clockwise; thrust; and fire).
In February 1980 I constructed another EPROM Programmer board to accommodate Intel's 8748/8749 single-chip microprocessor (now called microcontroller) chips; the 8755 EPROM+I/O part used in 8085 CPU systems; as well as the later follow-ons to the 2716 EPROM family. It's evident that one of the major functions microcomputer systems are used for is to build more microcomputer systems! Shown above right. Here are the drawings. It looks like I was going to write an article for submission (I never draw so nicely for myself), but never got around to it.
Printers. It doesn't take long to notice the need for a printer on any computer.
I bought a Friden Justowriter at a hamfest and interfaced it to the MAXI micro in February 1977.
It could print 8 characters/second and was very clunky. What was the alternative? A new ASR-33 at $1000 or used at $400, which printed 10 cps UPPER CASE ONLY?
Or a new 40-column dot matrix printer, also upper case? The Friden printed upper and lower case, proportionally spaced (I figured out how to force fixed width characters).
A science teacher might accept an upper case report, surely not an English teacher! And how ugly are dot matrix outputs (these were in simple 5x7 format in those days, not the denser modes that later appeared)?
Letter quality printers simply did not exist for less than thousands of dollars (like Daisy wheels in 1980).
I designed an all solid-state circuit with opto-couplers and HV transistors to interface with its high voltage solenoid control.
Here is an article I wrote describing it (ironically, it was printed on the Dura). Byte bought it, but never published it in the magazine.
The Friden's proportional font looked stretched out when defeated, and was a tiny font size. I found a Dura Mach 10 ($225) at a hamfest in April 1978. This machine was essentially an IBM Selectric typewriter with solenoids that could control the printing. An amazing mechanical design, it had innumerable moving parts that I managed to repair more often than I'd prefer. But I'm an EE, not a mechanical engineer! I built the interface at the right for it. For some reason, on this iteration I took the easy way out and used driver relays instead of optos and transistors. Here is the schematic. Both this printer interface and the Friden's connected to the MAXI micro's parallel I/O port card. The Mach 10 printed faster (not fast!), was a little less clunky, and you could insert different IBM Selectric type balls for different fonts! And no one could be dissatisfied with a report printed on an IBM Selectric, there was nothing better. I used this printer until I bought an HP Laserjet IIP in 1990, including printing my 295-page dissertation on it (program listings with the Centronics). It was often aggravating but it served its purpose. Sadly, I eventually forced myself to send it to the dump.
The Dura was great for letter quality printing, but slow for program printouts and drafts.
I bought a Centronics 503 dot matrix printer from Steve Kennick WA3SOR in February 1981.
It only printed upper case, but I added my own character generator EPROM to add lower case.
This was a large floor-standing machine, but it was fast. The interface was either at TTL levels, or it used a serial port (can't quite recall which).
Either way, no new interface drivers were needed. The last page of the
eprom drawings (showing the first page of the program listing) mentioned above was printed on it.
Also retired with acquisition of the Laserjet, and also sent to the dump.
I can't say why I bothered, but I built a Motorola 6800-based CPU board for the MAXI micro in December 1980 (earlier version in March 1978).
Actually, the CPU chip was the 6802 which was a 6800 variant which incorporated some internal RAM (which I disabled since I had 60K external) and a built-in clock generator.
To use it, I'd unplug the 8080 CPU card and replace it with this one.
Southwest Technical Products had come out with an M6800 system in 1976.
I might have wanted to execute code written for it, or maybe I just wanted to play with the Motorola instruction set.
In any event, my 6802 board took over the MAXI micro's memory and peripherals (I had to memory-map the Intel I/O port device addresses because the Motorola architecture doesn't support an I/O address space).
Endnote on MAXI micro hardware
(here are all of the other drawings):
I had intended to interface an 8-inch floppy disk drive to the system, but never got around to it before my work eventually gravitated to the TRS-80.
Here is an unpublished article on the hardware from July 1977.
MAXI micro Software
Monitor Program. With no data switches, the MAXI micro could do nothing without a ROM monitor. Amsat had published a great monitor program for the 8080 in the September 1976 issue of Byte. So I programmed it into the EPROM chips. Communication was through the serial port to the TV Typewriter II terminal. That gave the capability to observe and change memory, and do hex dumps and loads. I already had a cassette tape interface as part of the TV Typewriter II terminal, so the combination permitted saving and restoring programs.
I obtained an 8080 resident assembler plus a BASIC interpreter (both the IMSAI versions) from Jeff Schmidt WA3VRH. I do remember personally typing in the BASIC interpreter source code, which was 5383 lines long. Both of those, plus the Amsat monitor, were prepared on Jeff's Towson State UNIVAC 1106 mainframe (to his cross-assembler) via dialup. That was when I really learned 8080 assembly language, simply by seeing how someone else had written the BASIC program. The output was a hex file that could be loaded into RAM using the monitor program. My notes show that I had BASIC operational on the MAXI micro in December 1976. This was really amazing -- I could do with my own computer the same thing I had been doing through dialup to mainframes! The resident assembler was working in January 1977, and I had the ("Classy") text editor that had been published in the June/July 1976 issues of Dr. Dobbs Journal of Computer Calisthenics and Orthodontia working at the same time. These were the major tools: with a text editor and an assembler, along with the capability to save and retrieve programs on cassette tape, new programs could be developed.
As an aside, for fun there were lots of BASIC games published. I can remember running the game of Life overnight to see which future generations would survive. Long before SimCity! Also Hamurabi. Unrelated, there was a Chess program (Microchess) written for the 6502-based KIM-1 microcomputer. The amazing feat was it fit in 1K byte of memory! I bought the 8080 conversion which had grown to 4K bytes in 1977. I'm not a great chess player, but I could beat the MAXI micro/Microchess team every time... except when I was sleepy or sidetracked. The remarkable thing to me was that a 1K program could actually play chess, not whether it could beat Bobby Fischer.
For closure, I re-wrote my final high school FORTRAN prime number program in BASIC. Seeing it run on my very own hardware was quite satisfying!
We are all familiar with disk-based operating systems. But the MAXI micro had no disk. What it had, for its time, was a lot of memory. So I wrote an O/S from scratch which treated memory as traditional O/S's treat disk storage. The directory (stored in memory, of course) contained the filename, byte count, starting location, and executable location (if an executable program). While the O/S didn't require it, most programs were assembled to execute at address 0000h and were stored as high in memory as space permitted. Typing a "command" simply caused the O/S to search the directory for that executable file. If found, it'd check the starting and executable addresses. If different, the file (program) was copied to the specified RAM location before being executed. It was the user's responsibility to keep track of memory allocation, however. Files could be binary (executable) or marked as ASCII files. ASCII files had a file end marker which moved as the file was changed so it wasn't necessary to deal with file sizes for them.
I had come to like the UNIX O/S at JHU, so I mimicked much of its syntax and operation (including the % prompt). Not to claim my O/S was anything compared to the real UNIX or the later emergent Linux.
All I/O was routed through the O/S, and this permitted quite a few options, such as:
< inputfile (take input from inputfile instead of console) > outputfile (write to outputfile instead of console) >= outputfile (write to outputfile and console) >> outputfile (append to outputfile instead of console) >>= outputfile (append to outputfile and console) #XXXX (use hex address XXXXh instead of directory filename for nonexecutable files) ^S (start/stop processing) ^O (start/stop bypassing output) ^U (dump input line) ^D (kill current process)While separate programs, the "standard" commands (programs) were:
mm (Mini Monitor, go to the ROM Amsat monitor program) dir (display entire directory) dir file1 ... filen (display directory entries for specified files) asgn file (Assign a directory entry to file, queried for addresses) rm file1 ... filen (Remove specified files from the directory, delete) mv file1 file2 (Move file1 to file2, rename) cp file1 file2 (Copy file1 to file2) case u file1 ... filen (convert specified files to upper Case and send to standard output) case l file1 ... filen (convert specified files to lower Case and send to standard output) cat file1 ... filen (conCatenate specified files to the standard output) upd file (Update the byte count in the directory for ASCII file) cmp file1 file2 (compare binary or ASCII files) wc file (provide the byte, Word, and line Count for ASCII file) stty +/- echo (Set Teletype, turn echo on/off) stty +/- out1/2 (Set Teletype, make standard output serial port 1/2) stty +/- outp (Set Teletype, include/exclude the printer in the standard output) stty +/- in1/2 (Set Teletype, make standard input serial port 1/2) ret (Return to a program which temporarily exited to the O/S) sh < commandfile (Shell command: execute commandfile as O/S command lines) exit (Exit shell command) fmt (text Formatter) prt file1 ... filen (Print specified files in background)Here is an O/S Command Description. Some other programs were the text editor, the BASIC interpreter, a Morse code program, and Precision Calculator (from March 1977 Dr. Dobbs, arithmetic on unlimited length integers). I added the basic equivalent of a number of other utilities I encountered on the JHU UNIX system: tr (translate strings), sort, etc. I rewrote the O/S for the 6802 CPU, too! (The O/S, including all of its individual programs, was pure assembly language for either the 8080 or the 6800 for the respective CPU board.) Here is an unpublished article on the O/S and here is an unpublished article on the text formatter (both printed on the Friden with the FMT text formatter, written in July 1977). FMT was my simpler version of UNIX's nroff and troff programs. If I were a smarter man, instead of writing memory-based operating systems I would have written a BASIC interpreter for the 8088. Maybe then Warren Buffett and I would be best buddies today.
Even without a disk drive, the MAXI micro hardware/software system was remarkably reliable, rarely needing memory reload from tape.
I developed several generations of repeater controllers, much of my above graduate research programs, and the first (as well as the early second) generation of Telesaver's telephone switch controllers on it.
The MAXI micro Term
I had been using my TV Typewriter II since 1975. By 1980 it was dated, plus chips had come out with greater density and functionality; I was ready to tackle a better video terminal. I should add that Intel rep/salesman John Williams K8JW would periodically make visits. He'd show up in front of my house and beckon me out to his open trunk. There he had cases full of the latest Intel chip sets; he told me to take anything I wished. I'm sure he was supposed to be giving these samples to design engineers for real manufacturing companies in the hope of securing a mass-produced production run (called a design win). I was merely a grad student and wasn't in that position -- I felt reticent, and a bit guilty to accept his gracious offers. But he was very insistent! I'd only take a few parts that I thought I might use, and he would start filling my arms with more. Also, we might not think of chips as that expensive, but IMHO Intel had a very smart pricing policy: when they came out with parts that had functionality that their competitors didn't, they charged a lot for them. A year or two down the road, when they had become commodities, the price would be lowered significantly. The initial price for some of these chips was in excess of $50 or thereabouts. I am grateful to John for his kindness. I mention this here because this project used some of these higher integration Intel chips. As an aside, in later years I was in fact responsible for designing in Intel parts which were purchased eventually in the thousands. Not millions, and I don't know how much the company cared about design wins of that size. So I can at least say that perhaps Intel did get something out of all those "samples" I received. The truth is that I always evaluate vendors by their part functionality and vendor reliability estimates, so Intel still had to come up with the goods to convince me to use their parts. But familiarity with their line surely couldn't hurt, and all things being equal I would tip the scale in their favor. I doubt that John ever got anything whatsoever out of giving me samples, and I hope he never got into any trouble on my account!
This was a design from scratch. I used another of the Ultronic keyboards, this time mounted on top of a (metal) chassis box containing all of the circuitry. I thought there were two significant features to this new terminal.
Video System. My experience with the GLB had gotten me excited about frequency synthesizers. The video format chosen determines the frequency of the dot clock, i.e. the rate new dots are drawn horizontally across the CRT. That means that every display format requires a different one. I surely wanted a better format than 32 characters per line. But the problem is that without buying a high quality video monitor, it is difficult to know how well alphanumerics are going to appear on a television screen. I had bought a small 9-inch black-and-white transistorized TV (vacuum tubes still existed!) and modified it, providing a true external video input (vs. an RF input on say channel 3). RF modulators and the TV's tuning circuitry degrade bandwidth and consequently display crispness. If I designed a hard format, such as 25 lines of 80 characters each, who knows if it would look good enough to use on a TV monitor? Each format needs a different dot clock and other dedicated circuitry.
My video circuitry instead synthesized the dot clock using the
Integrated Computer. I also took mostly everything that was in my MAXI micro computer and included it in the terminal itself. That's why I called the device the MAXI micro Term. The user could activate the internal computer or just use the device as a terminal. I was able to fit the MAXI micro's functionality into one small chassis because denser RAM and EPROM chips had come out (of John's trunk): (8) 2732's supplied 32K bytes of EPROM; and (16) 2114's provided 8K bytes of RAM. I ported the entire memory based operating system from the MAXI micro to the MAXI micro Term's (nonvolatile) EPROM. Simply turn the power on and you have the O/S, text editor, assembler, text formatter, and BASIC!
I finished the terminal in July 1980 and retired the TV Typewriter II. I don't remember if I continued to use the MAXI micro computer, or the CPU in the new terminal.
(I probably needed the MAXI micro's larger RAM size to develop my bigger controller programs, though.)
I used the box until I switched to a TRS-80 (with hard disk and floppy disk drives) a few years later.
I never pursued turning the MAXI micro Term into a commercial product; very shortly thereafter a number of "smart" terminals came onto the scene.
Of course, by that time everybody was using IBM PC's. I finally broke down in December 1989 and put one together for myself. I hesitate to say "built" because after actually, really building computers, this doesn't amount to that. But I didn't just go to the computer store and buy one off-the-shelf. I mail ordered each of the subcomponents, i.e. the case, power supply, motherboard, drives, and all plug-in boards. Primarily to get what I wanted, maybe to save a few bucks. I think that first system was a 16 MHz 80386SX2 with MsDos 3.3. I had a lot of serial and parallel ports on it to connect with external (commercial) EPROM programmers, etc. At some point I upgraded to MsDos 5 and 6. That's the middle computer in the photo at right, above. I cringed and paid $600 for an NEC Multisync 3D 14" VGA monitor for it, too.
Internet. I know that I became a charter member of America Online as soon as they released a Dos software version. So that must have been in February 1991 or shortly thereafter. Baltimore County Public Library began offering dialup service in June 1996, so I took that. They also provided webserver accounts, so I started my webpages then too. They closed down in 2008, so I moved my servers to GoDaddy and have been pleased with their offerings. As soon as high speed cable data service became available in my neighborhood, I subscribed (March 1997).
Instead of buying new computers, I just kept changing the peripherals: memory and hard drives, then entire motherboards with their daughter cards. In July 1996 I changed the motherboard to an AMD 133 MHz 5x86 and put Windows 95 on it.
In June 2001 I put a new system together. However, the motherboard form-factors had changed from AT to ATX; so I couldn't re-use my existing case and power supply.
I put a 750 MHz AMD Duron motherboard in an ATX tower case, which is shown below at the right.
When that motherboard failed in July 2003 I simply replaced it with a nearly identical one.
I kept adding memory and putting in larger hard drives, and at some point I upgraded to Windows 98. I think I stayed with that until I put Windows XP on in January 2009 (or was it 2008?).
I had progressed through larger CRT terminals as well, and in February 2009 I switched in a 22" Video 7 LCD monitor (photo below right).
In April 2010 I finally upgraded my sluggish system to a 2.8GHz AMD Athlon II X4 630 processor, with 4 GB ram and a 320 GB SATA hard drive. I installed Windows 7 Professional.
Since the motherboard was still in the ATX form factor, I put it in the same case I had (but replaced the power supply with a heftier one).
The Duron system was still self-complete, so I transplanted it into a smaller case; that's the leftmost tower in the above photo on the right.
I have to chuckle when I realize that my current CPU's clock is 1400 times the original 2 MHz on my MAXI micro, and has 66,667 times as much RAM.
That's not even considering that the instruction set itself is so much more capable. But to type a simple letter, or assemble a control program -- there's not that much difference!
Initially I used Netscape Gold 3 as the composer for webpages. Then I started sprinkling the html with some PHP functions. Currently I use Alleycode. There are many html editors. I found that lots of them rewrite your code when you save it. I don't appreciate that, I choose to keep my own formatting. Plus, when inserting PHP commands, those html editors actually break the code. Alleycode is a very simple program; I'm really writing directly in html instead of using the drag and drop that others offer (as did Netscape). But it lets you enter anything you want and it doesn't alter it. You can click and see what it looks like. I tend to copy and paste code portions I've previously written, anyway. I have a 5-button trackball on which I've programmed the left auxiliary button as copy and the right auxiliary button as paste -- this speeds up text editing immensely.
To interface with the servers, I use WinSCP.
Newsletter Editor, Maryland Libertarian Party: 1998 -
Author, Bare Bones Web Database, 2005: written in PHP -- contact me if interested in obtaining a copy.
All content Copyright 2018 IC Engineering, Inc. This webpage last updated: July 27, 2016