Craig Lafferty taught the first computer course in our high school when I was a senior in 1971/1972. We programmed in FORTRAN IV: at first we wrote on special coding sheets which the keypunch ladies (yes, they were all women!) turned into decks of punched cards. I really did feel bad that the ladies had to do all that work for us, but that was their job and our submissions were probably a small part of their total workload. Later on we changed to mark sense cards (the ones lying on top of the card deck above); for those we used pencils to fill in character blocks (like taking the SAT exam). The computer could read those directly and the process bypassed the keypunch ladies (I hope their jobs got re-targeted). Guiltless, but those cards only held about a third as much as the real keypunch cards did, the "programming" process was slow and tedious, and your fingers got really tired.

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:







Huh? "JOB CANCELLED DUE TO EXCEEDING ALLOWED TIME"???
So computers weren't infinitely fast after all. An important lesson.

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.

That's the eighth and final page of my printout. I went on to more challenging programs, but will always remember Prime Number 179, reminding me to write efficient computer programs.

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.

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.

As a freshman, we did a few lab exercises on something you'll never run into any longer: an analog computer. It consisted of precision operational amplifiers and pre-made building blocks: gain stages, summers, integrators, and differentiators. We wired them together on a patch panel and selected the components to specify the system parameters. The output was an X/Y plotter. At left is an output I did for fun: it's just a damped simple harmonic motion simulation (well, not really a simulation -- it was the real thing). The gain was less than one, so the plotter spiraled in as the voltage decayed.

Digital discrete time simulations now reign supreme and have relegated these devices to the dustbin of history.

In 1973 I took Roger Westgate's (appointed interim Dean, RIP) 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 PDP-11 -- and I had a great line of communication with their head (well, maybe only) programmer. And even had a few tips for him. I do remember that for one of the later projects, we programmed the PDP-11 to control two stepper motors which moved a pointer (mimicking a mouse, the rodent) through an unknown maze. It was my first exposure to what would later be called embedded control computers.

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.


After erasing the EPROM, it was placed into the programmer and power applied. Then selecting the address toggle switches displays the memory contents on the LEDs. Enter the desired contents on the data switches and depress the program button. That byte is stored into the memory and is nonvolatile. Quite similar to the PDP-11 programming. I added an I/O connector so that the programmer could be controlled from a processor instead of the front panel switches.

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.

The 4004 chip might be a "microprocessor on a chip" but building a complete controller took a lot more parts than the CPU itself, as seen below. I configured a system with four RAM chips (to the right of the white 4004 in the second row from the top of the board) and the capacity for four 1702A EPROM parts (one white 24-pin part with three empty sockets to its right in the fourth row). The I/O connectors are on the four corners of the board. I laid out a circuit board for the controller in the same manner as for the programmer.

(Long before CAD software, we laid out circuit boards the old-fashioned way: here is a box of artwork supplies, including tapes of various widths for circuit traces, press-on IC footprint patterns, acetate film, etc.)

The last piece of hardware construction for the project was a paper tape reader interface. I designed a logic interface between the reader module and the PDP-11/20 (in top of photo at left), which offered additional I/O buffering for the PDP-11. (So students would burn out my interface chips instead of those inside the PDP-11.) This was a high speed paper tape reader (250 cps), so we could read the assembler program in quite rapidly in place of the much slower ASR-33 reader. While the reader unit was designed for use with the PDP-11, it could also be used with the MCS-4. After hardware completion, it was time for software to be written.

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!

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:

I recognized it as one of about a half-dozen COSMAC trainers we had built at JHU! So I bought it for sentimental reasons. We also used these in microprocessor classes. It had binary input toggle switches, but hexadecimal 7-segment displays (which we drove from fusible-link PAL chips). The RCA COSMAC was interesting for two reasons: its architecture was different with multiple registers used as accumulators; and since it was fabricated with the CMOS process, it drew very little power and was inherently resistant to noise transients. It was easier to radiation-harden, and consequently was the microprocessor of choice for satellite controllers.

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:

Apparently still using two ASR-33's. No way I was still using 1702A's, though -- probably that's in the shot only for effect! I was building duplicate controllers and injecting noise into one of them; capturing bus signals and trying to figure out what was happening. Eventually I came to the conclusion that it didn't really matter; I came up with hardware and software design rules that forced the microprocessor to continue executing code no matter what (except for physical hardware failure). This is related to, but different from, common watchdog timers (which are not provably reliable). I made presentations and had paper submissions at various Fault Tolerant Computing Symposia and in IEEE Transactions on Computers. The culmination of my work was this demonstration briefcase encapsulating my Upsets in Microprocessor Controllers (1981) dissertation:

It contains two identical microprocessor systems fed in parallel from an intentionally noisy power supply to force "upsets." On the left is Controller 1 configured as a "standard" design with "standard" firmware (software); the board on the right is Controller 2 configured with a little bit of extra hardware that monitors its operation, and firmware that has been modified to meet my stated software requirements. The small green perfboard on top of the blue perfboard of the controllers contains the special circuitry which can be enabled or disabled in various modes. I wrote the code myself first, of course. But to make it more objective, I had Brian Cuthie KA3BRZ write the sample controller code given nothing but the program specifications. Then I gave him the new "rules" and had him modify his code accordingly. I had some automated analysis software which evaluated the control software and interactively pointed out problems. In operation, as the noise strikes, the operation of the "crash-proof" processor hiccups sometimes, but valiantly continues on with its task. The standard processor sometimes simply stops running the desired program.

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.)

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...

Don Lancaster published plans for his TV Typewriter in the September 1973 issue of Radio-Electronics. Very crude by today's standards (16 lines of 32 upper-case characters), it was revolutionary at the time -- when the standard method to access computers was with 10 character per second teletypes, like the ASR-33 (which cost over $1000 new, by the way). This project let you access computers on a video screen (your television CRT)! Personal computers had yet to be invented -- only the Intel 4004 and 8008 CPU's had so far been fabricated.

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...

A Modem is needed to connect to a remote computer (Universities, Compuserve, etc.) over the telephone line. At first I constructed my own. It worked, but not that great. The acoustic coupler I constructed is above: you set the telephone handset in the coupler (there was no electrical connection to the phone line). Mine utilized a speaker to send tones to the handset microphone, and a modified phone amplifier for the hard-of-hearing to couple the incoming received tones. Eventually I swallowed my pride and bought a used commercial unit at a hamfest:


These Bell 103 modems worked at any baud rate up to 300 bps, but were typically used either at 110 bps for teletypes or 300 bps for video terminals. I intentionally put an ancient rotary dial telephone in the picture. While this was after the famous 1968 Carterphone decision, still most people had black rotary phones leased from The Phone Company. By and large people were not permitted to connect electrically to the phone wiring.

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).

There were some 8008 CPU processor designs, but when Intel released its 8080 and Motorola came out with the M6800 CPU, hobbyists were really off to the races to build their own "personal" computers. The MITS Altair 8800 commercial hobbyist computer came out in 1975 (published in Popular Electronics in the January and February 1975 issues). The IMSAI 8080 was a competitor that came out slightly later. These were quite similar to the standard minicomputer of the day: LEDs to show addresses and data, plus binary toggle switches to enter programs into memory. While some friends did, I purchased neither of those. First, I didn't want to pay as much money as they cost for the amount of capability I wanted; second, I thought I could do a better design; and third, as a budding EE of course the project would be quite educational. So I came up with the name "MAXI micro" because I thought mine gave maximum performance and versatility compared to the Altair and IMSAI boxes.

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.

The Altair and IMSAI units used the S-100 bus, which used 100-pin backplane connectors. Mine was similar (both busses simply paralleled the pins across all slots), except I used a 44-pin (2 sided x 22 pins) backplane instead. Radio Shack sold a cheap protoboard in that format as seen in the CPU board above left. I found a cage assembly with those connector sockets at a hamfest to match. I used Molex strip IC pins and point-to-point wiring on the circuit boards (except for the memory) instead of wire-wrap, because wire-wrap boards cannot be placed close together. Intel, bless its collective corporate heart, at the time offered University Kits of cosmetic reject chips for something like $20 a set, which was a real bargain. I bought two (inset above right). I think several other friends were pursuing this same path -- I recall Jeff Schmidt WA3VRH and maybe Carroll Van Ness K3HZU were included in the group.

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 board at left serviced the front panel LEDs and switches, and provided parallel I/O ports (which operated various printers along the way). The board at right housed two serial ports.

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).

Here is an unpublished article I wrote on a simple display program I wrote for use with the DAC's and scope (if my students see this there will be consequences -- there aren't any comments!).

The 1702A EPROMs were very difficult to program -- they required switched 50v signals on virtually all of its pins. I was lucky to be able to use the JHU programmer I had constructed in 1974 to program the MAXI micro EPROM board with the monitor program. When Intel came out with their 2708 1Kx8 EPROMs, besides being four times as large, it became much easier to program EPROMs: it was only necessary to switch under program control one 12v line and one 26v line. I developed the 2708 Programmer (above left) in November 1977. Byte published my article in the April 1980 issue.

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 (neat story here) 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.

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)

      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)

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.

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 60 Hz AC line frequency (to prevent screen rolls) as a reference. Moreover, instead of using fixed digital dividers, I used programmable dividers (8253's) in the video chain. Thus, everything, including the dot clock, was determined by the control CPU -- which was an 8085. This gave display flexibility, plus I was hedging my bets on what would look good enough on the TV monitor. The control program ended up offering 12, 13, 14, 15, 16, 18, 20, 22, 25 and 29 lines per page; and 22, 32, 66, and 80 characters per line. These formats are user selectable. It turns out that the TV did work at 80 characters per line, but was a bit fuzzy; so most of the time I configured it for 25x66. I still liked having the 22 and 32 character per line options for titling shots.

I had never seen any other terminal in which the video could be configured like this. DEC's VT100 terminal offered 80 or 132 character lines; it came out in August 1978, and I encountered them a few years later. It offered blinking, bold, reverse video, and underlining -- which my design handled as well. I can't take too much credit for those features, as they were handled by Intel's 8275 CRT controller chip which fell out of John's trunk.

I built in a serial port, cassette tape interface, and a crossbar switch which let each of the various inputs and outputs be connected any way the user wished. The user configurability came from the microprocessor controlling all aspects of the hardware, which was the path blazed by the lowly 4004.

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.

I was pleased with the MAXI micro Term and wasn't looking to replace it. But Motorola came out with its MC6847 Video Display Generator (VDG), and it mated with their MC1372 color TV video modulator. I thought it would be quite difficult to design a color output, and moreover get it to transmit via RF to a standard color television; but those two chips do all of the heavy lifting. I was intrigued. It looked pretty simple to design a color terminal with these two chips, so I thought I'd have a go at it. Of course, Motorola expected designs to incorporate their M6800 CPU. But I'd already mixed and matched between Intel and Motorola chips before (the 6800 CPU on the MAXI micro). On the Color Computer I married the VDG to an 8085 processor and its associated peripherals. With only a total of 15 chips on a single perfboard I could fit the entire thing inside yet another Ultronic keyboard. This project spanned the time period from June 1980 to January 1981. I can't remember exactly what happened with it, but I know it was never completely finished. I think I was having some problems with the color TV interface. I can only postulate that I let it drop because this time frame was an extremely busy one for me (I was finishing up my graduate work, finally -- and immediately started full bore at Telesaver after that). So maybe that's why it's in the "unfinished" pile. Or maybe I was stumped with some technical problem. I see the code listing shows over 2000 lines of code, I don't know why I would have written that much if it wasn't working somewhat. I should give it another look just to see what was going on with it (:>).

I used the MAXI micro at home to develop software for the Telesaver switches beginning in the fall of 1981. In the office we started using Radio Shack Model III TRS-80's. We later switched to Model 4's, but that must have been after their release date of April 1983. Time had passed; these Radio Shack computers all had 5.25 inch floppy disk drives (180K capacity); plus we had installed external hard drives on each as well (10 and 20 MB). So sometime in mid 1983 I moved my switch development platform (8080 assembly language) from the MAXI micro to the TRS-80 in my office. I ran LDOS and a Z-80 assembler for which I had created a macro file to accept the Intel mnemonics I was using instead of the Zilog ones which were native to the TRS-80 (it was a Zilog Z-80 based machine, which runs all 8080/8085 code without alteration). I was at the office all of the time anyway, so I'm not sure when I moved one of the Model 4's to my home office. I definitely did by the beginning of 1986. In addition to using it for all of the assembly language work, it had a word processing program (Scripsit), and we had a bunch of Epson dot matrix printers -- so I had that at my home office, too. I'm not sure, I might have attached my Dura Mach 10 to the TRS-80 for letter quality printing. My prime computer from 1986 through 1989 was the TRS-80 Model 4 (above left photo).

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. I intentionally chose the 32-bit version because I've learned that older 16-bit programs will run in 32-bit Windows, but not in 64-bit Windows. Unless one goes to the trouble to run them in a virtual XP machine inside the 64-bit O/S. I don't want the aggravation of fixing or trying to upgrade older programs that I might use rarely -- but immediately! 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. The Athlon system is shown in the photo below at the far right.

Some time in 2018 I had been experiencing occasional Windows crashes, with Firefox crashing tabs increasingly. I finally realized I had to investigate and ran a memory test. Errors at Axxxxxxx addresses! Found that with msconfig one can set the maximum amount of memory allocated to Windows, so set that to 2560 MB to prevent it from using the bad area. That worked, but I did notice some slowdown with the reduced memory. First, expecting a computer system to still be usable nine years later seems ridiculous, but this one still is reasonably fast. My biggest temptation is to switch to a 64-bit O/S (obviously Windows 10) but backwards incompatibility with 16-bit software remains. Greater memory pool availability with 64 bit addressing I think is the biggest advantage. Anyway, I decided to just fix what I had. However, I was (and am still) a bit perplexed about the DRAM DIMMs: swapping the two memory modules did not alter the address or word bits in error! Or using an alternate pair of slots. So I wasn't entirely sure that the DIMMs were in fact the problem, though that seemed most likely. But in 2019 I could purchase a pair of DIMMS (even though I needed only one they are sold in pairs) for $20 (I paid $105 for the original pair), so I bought them and that corrected the fault. Now I can stop unjustly cursing Firefox (I guess it uses lots of memory that other programs don't).

Printers. In October 1989 I took a major step and spent $1000 for an HP Laserjet IIP. This was a gigantic outlay, but the IIP was a giant step forward: it was two printers in one. It provided letter quality output (even better than an impact printer without variation from keystrikes); plus it provided high speed. I used it on my TRS-80 for a couple of months before connecting it to the PC's that followed. It finally died (I had performed some minor repairs) and I replaced it in September 2000 with a Brother HL1240 laser. That lasted until April 2008 when I replaced it with a Brother HL5240 laser. All of those laser printers are black and white only. For occasional color printing, I went through inkjets: an NEC150c and a Canon BJC-2110. I had neverending ink clogging problems, maybe because I used them so infrequently. So I bought a Samsung CLP-300 color laser printer in November 2007. I only use it for color jobs; opting for the HL5240 most of the time. Both of those lasers are in the above left photo (CLP-300 on left side). I know I don't need that stack of 5.25" floppies on the table -- I don't even have a drive that will accept them in my current machine!

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!

Webmaster, IC Engineering: 1997-
Webmaster, Maryland Libertarian Party: 1998 - 2014

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: December 1998 - April 2022
(three issues per year)

Author, Bare Bones Web Database, 2005: written in PHP -- contact me if interested in obtaining a copy.