8048 Microcomputer, ca. 1982
Sometime in the last 43 years the
processor, crystal, and EPROM have
been robbed for some other project.
Random retrospective ramblings about microcontrollers and related topics. Last updated 7 January 2026.
I started thinking about microcontrollers in high school in the very late seventies. Somewhere I have an old Radio Electronics magazine with announcements for the Intel 8048 and 8088, which sparked the very beginning of my interest in microcontrollers. I went to Northwest Nazarene College the fall of 1980 with a collection of data books from Intel and other semiconductor manufacturers. My 8086 book was already well worn the day I started college as a freshman.
At college we used the 6502 in classes, in the forms of the AIM-65 single board computer, and the Commodore Pet, which was a microcontroller pretending to be a desktop computer. I didn't care much for the 6502 because of the seemingly bizarre limitations of the instruction set.
I did quite a bit of interfacing with the AIM-65, though, because it was all we had.
During a break from college one year, I visited a couple of local manufacturers to beg for parts with Jeff, a high school electronics cobelligerent. (We two were scrounges extraordinaire and were responsible for the telephone company service center near my home moving their dumpster from just inside the gate to the farthest extreme corner of the fenced compound.) At Keytronics, somebody decided to humor us and brought out a huge pile of literal floor sweepings including a tube of Intel 8048's as well as some 2732 EPROM's. On the next Thanksgiving Day, I built my first homebrew computer, consisting of an 8048, 74LS373 latch, and a 2732 for program store.
|
8048 Microcomputer, ca. 1982 Sometime in the last 43 years the |
The instruction set of the 8048 was even more bizarre than the 6502, but again, it was what I had to work with.
I had by then persuaded my faculty advisor to buy an EPROM programmer, ostensibly for the AIM-65's which as I now hazily recall had a socket for the TI 2532 EPROM (annoyingly different from the more common Intel 2732). However, the software development tool chain presented a challenge. I didn't have one. In fact, I think I hand assembled the very first code for that very first computer to toggle its I/O lines.
In those halcyon days, when minicomputers from Digital Equipment Corporation, Hewlett Packard, Prime, and Data General ruled the roost, our school was an HP shop. Academics had an HP 3000 Series 44 (that I spend many, many happy hours on) and Administration a beefed up Series III. Periodically the HP Users Group would publish a tape of contributed software, including source code.
One of the programs we found was MIZASM, a table driven cross-assembler written in SPL to run on the HP 3000. I found it almost trivially easy to add new instruction sets to MIZASM, and over the next few years I added literally dozens of 4, 8, and a few 16 bit instruction sets as microcontroller data books came in. (By that time I had developed an extremely efficient process for obtaining electronic component data sheets and data books. At one point, my father estimated that I had over 500 pounds of data books.)
MIZASM served as my microcontroller tool chain all through my undergraduate days, including some internship work for Battelle at PNL the summers of 1983 and 1984.
During the summer of 1983 I worked as a research intern at the Accelerator Lab in the Health Physics Division of Battelle PNL at Hanford, Washington. I wore a dosimeter for the first time of my life and received a security badge (red, the lowest classification) that had to be physically touched by a guard whenever I entered or left the facility.
My task was to build some interface equipment between a VAX 11/750 minicomputer and some instrumentation. I proposed using a microcontroller (Hitachi HD63P01M1 as I remember it) connected to one of the VAX's serial ports, but this idea was nixed. In those days, PNL had a list of "approved" computer systems that included things like the VAX 11/750 and the Commodore PET, but not any single chip microcomputers. We seriously considered procuring a "Falcon" SBC-11/21 single board computer, because PDP-11 was on the list, but I wound up porting my interfacing code to a spare PDP-8. This was also my first real experience with the government bureaucracy.
The HD63P01M1 was a unique device. It was a CMOS single chip variant of the Motorola 6800. It was assembled into an oversize ceramic package with a socket on top for a 2732 or 2764 EPROM. Why Hitachi didn't just make an eraseable package like the Intel 8751, I'll never know, but it sure was convenient to work with. You could program a 2732 with the firmware and just plug it into the top of the HD63P01M1.
The 6800 instruction set was reasonably clean to work with, and you could connect the wonderful 6522 VIA (Versatile Inteface Adapter) from the 6502 family to it for more I/O.
After an abortive attempt to build an 80188 single board computer for a Senior Seminar project, I settled on the fascinating architecture of the NS16032, specifically the NS16008, the 8-bit bus member of the family. I managed to persuade a distributor to send me samples of the NS16008, NS32081 FPU, NS32201 TCU (Timing Control Unit) and NS32202 ICU (Interrupt Control Unit), all running at a whopping 6 MHz. At a count of 18 IC's, all DIP's, this remains the most complex board I've ever wire wrapped.
 |
NS16008 microcomputer 18 IC's including processor, glue and 8 KB each of static RAM and EPROM. |
Unfortunately, the exceedingly complex instruction set of the NS32000 family proved more than I could cram into MIZASM's table driven architecture. I had to fork out real money (something like $50) for an NS32000 cross assembler running on Z80 CP/M. The school had only just purchased 2 IBM PC jr's with MS-DOS for student use, and they were both across campus from the computer lab. Also, I believe the MS-DOS version of the cross assembler cost more.
The cross-assembler, from 2500AD Software, had at least two bugs, generating incorrect machine code for a couple of instructions. One I was able to fix by binary editing the program file; the other I just had to workaround.
After graduating from Northwest Nazarene College (now NNU) with a B.S. in Computer Science in 1985, I eventually wound up in Sunnyvale, California after a fruitless search for employment near my childhood home of Sandpoint, Idaho (a metropolis of 4500 in those days).
I stayed a few weeks in Cupertino with a high school chum who had made the exact same trek from Idaho a few months previous. Not knowing any better, I simply compiled a list of promising ads from the local paper and rode the bus system to each one to turn in resumes and applications.
A one point during one of my bus rides I noticed a company sign that was familiar. "Datura International" was on my list. (If I had known the meaning of the word datura at the time, I probably would have never given them a thought.) I got off at the next stop and walked into the building to drop off a resume.
The next thing I knew I was interviewing with V.P. of Engineering and a couple of working engineers. They were so desperate for someone with experience with the 8048 and 8051 microcontrollers that just having "8048" on my resume got me interviews on the spot and a job offer the next day. (I missed an offer the same day only because they weren't able to contact me that very afternoon.)
Datura Int'l aka DTI Security aka Arrowhead Technologies aka Scantronic USA manufactured burglar and fire alarm panels and keypads. The panels were all based on numerous 8051 variants. The older keypads contained the 8049 and the newer ones the 8052. Our products sold directly to alarm installers, big monitoring outfits like Brinks Home Security, and to remarketers like Dictograph. We also sold a huge amount of product overseas, curiously, to gun-free/crime-free paradises like Great Britain and the Netherlands.
All of these market segments were extremely cost sensitive, so we were always striving to reduce the cost of materials. We flirted with a number of interesting 8051 derivatives that promised more integration that the basic 8052, like the DS5000 from Dallas Semiconductor, and various high integration parts from Siemens. We always seemed to gravitate back to the commodity 8052 and friends, though, for unit price and especially availability.
Our code base was entirely written in hand-tuned assembly language, which made reuse and migration to new products difficult. We experimented with 8051 compilers for first Pascal and then C from Archimedes, but the generated code was too large and slow for our products.
After three years of living in California, I was desperate to escape. I began looking for graduate schools that were both far from California and did not require the GRE (Graduate Record Examination). I found UAF: University of Alaska Fairbanks. They also had an indoor smallbore rifle and pistol range, a big plus. So I began the UAF application process early 1988. Somewhat to my surprise, especially since I had not actually finshed the application process and had frankly forgotten about it, I was accepted during the summer of 1988.
After graduating from UAF with an MSEE in 1991, I reluctantly returned to the Lower 48. Soon I found a software engineering job at a company named Itron, then located in the Spokane Industrial Park. Itron, among other things, manufactured ruggedized handheld computers for electrical and water meter reading. My three years at Itron (and Itronix after the Great Split) was spent entirely working with MS-DOS, first running on the handheld computers and later on IBM PC driven manufacturing test fixtures.
 |
I developed a gag I inflicted on people, including my future father-in-law and later on a business trip, the president of Sandisk Corporation. I borrowed Itron's flagship T5000 handheld computer, a clamshell ruggedized handheld computer from work. I would show it off, emphasizing that it was a $2500 piece of equipment, then hand it to the victim and, as soon as they touched it, dropped it on their foot. While I was at Itron, we began incorporating radio modems for the ARDIS and Mobitex private wireless networks into our handheld computers. Ram Mobile Data provided a Packet Driver for their Mobitex radio modem. Using the Waterloo TCP/IP stack for MSDOS, I was able to create a rudimentary TCP/IP network using the Mobitex radio network for the physical layer. The closed ARPANET had just evolved into the public Internet, and I saw an opportunity to leverage it for our handheld computers. I appealed strongly to Itron management to use TCP/IP for both ARDIS and Mobitex products, to no avail. It would have vastly simplified the development of the backend systems necessary for making ARDIS and Mobitex radio networks successful. I drafted a specification, using a little known and AFAIK never used feature of the TFTP (Trivial File Transfer Protocol), for sending short text messages in UDP (User Datagram Protocol) packets: Almost exactly what would soon become the SMS (Short Message Service) on cell phones. |
During the three years at Itron/Itronix, I worked very little with microcontrollers. I did spend some time at home playing around with the DS5000, a fascinating device containing a reengineered 8051 compatible microcontroller, up to 32K of battery backed RAM instead of EPROM or flash, and a serial boot loader--No more EPROM programmer!), even building up a board with an Arcnet network interface, using the COM20020 Arcnet chip. I wrote a primitive UDP/IP protocol stack for the 8051 but never progressed to TCP.
After a long hiatus as a UNIX weenie, I was been assigned to write some code for a PIC microcontroller embedded in a complex Internet traffic management product. This job transformed a long abiding suspicion of the PIC into outright disdain, nay hatred. It also rekindled a desire to resume work with microcontrollers, so I began seeing what was available these days. I don't care to work with proprietary tool chains anymore, so my search has narrowed to those devices supported by gcc. To my delight I found the Atmel AVR family, which is cheap, fully supported by the gcc tool chain, and even somewhat pin compatible with the 8051.