Forty Years of Personal Computing - 16/32-bit Dreams

Back in the days when we were fooling with 8-bit computers, we dreamed about 16 or 32-bit processors. Digging through my notes and records, I found a couple of items. These projects were contemplated, but never built. 

MC68008

When Motorola introduced the MC68008 in 1982, I toyed with the idea of putting one on the SS-50 bus. In my notes, I mapped out the signals required. It might have worked, but it was an awkward fit. The MC6800/MC8609 had synchronous memory access, but the MC68008 was asynchronous. Plus, the MC68000 family really wanted a 16-bit bus.

While I never built anything -- it was more of a thought experiment -- it might have been one of the first applications of a 32-bit processor running on a bus designed solely for an 8-bit processor.

A couple of years later, I spent a lot of time programming the 68000 processor when I started doing Mac development in August of 1984.

NS16032 / NS32016

NS32016 chip set samples, plus a couple
of Dynamic RAM and Refresh Controllers

National Semiconductor (NS) got left behind in the microprocessor chip races even though they were an early entrant. In 1974, they produced a single-chip processor known as the PACE -- a 16-bit design inspired by the DataGeneral Nova. This early pMOS implementation required three power supply voltages, and the bus requirements made designs complex.

By 1976, NS introduced an 8-bit processor, the SC/MP. Compared to the Intel 8080 or the Motorola 6800, it was underpowered. While it may have been a good choice as a micro-controller, the second-generation designs such as the MC6811, MC6805, Intel 8051 and Z-8 choked the SC/MP out of that space.

In 1982, National Semiconductor introduced the NS16032 -- later re-branded as the NS32016. NS32xxx refers to the 32-bit nature of the processor, and the trailing 16 refers to the bus width. It was clearly a competitor to the Motorola 68000, which was introduced in 1979. The NS32016 family was actually a collection of five devices:

• NS32016 CPU - Central Processing Unit
• NS32081 FPU - Floating Point Unit
• NS32082 MMU - Memory Management Unit
• NS32202 ICU - Interrupt Control Unit
• NS32201 TCU - Timing Control Unit

Together, they form the processing core. Depending on the type of system, you might not need much more than the CPU and TCU, provided you didn't need floating point, memory management, or prioritized interrupts. This made for an extensible system based on a common processor core

National Semiconductor also offered a Direct Memory Access Controller -- the NS32203.

Clock speeds of 6, 8 and 10 MHz don't seem fast by today's standards, but where competitive back in 1982. This chip needed a minimum of four clock cycles to access memory -- the same as the Motorola 68000.

Architecture

National Semiconductor devoted a lot of their design work to producing a Complex Instruction Set Computer (CISC) specifically to support high-level languages. The NS32016 has a rich set of addressing modes including direct register, register relative (including the Frame Pointer, Stack Pointer or Static Base registers to which an additional displacement may be added), immediate, absolute, external (using a link table entry). Indexing by a register allowed easy access to local and global variables of high level languages. 

The NS32xxx architecture sported eight registers, a program counter, two stack registers (user and supervisor), a frame pointer and a static base register. The design specified module and interrupt tables in memory. 

Design Ideas

In late 1983, The NS32016 process inspired me to write a 20-odd page article about a "personal minicomputer" -- since I considered this design to be more of minicomputer power level that a microcomputer. It certainly was a lot more powerful than the 8-bit microcomputers of the day.

Sometime in 1984, I obtained a couple of engineering samples of this chip set. From this, I started creating hardware designs. Drawing out the basic core from the five chip set was easy. But a real computer needs memory and peripherals.

At some point, I obtained a second-hand S-100 chassis -- a BYT-8 system. Just a motherboard, power supply and front panel. The S-100 bus had a lot of interconnections and could serve as the backbone of an NS32xxx system, but it wouldn't use the same signals. I ended up scrapping the front panel and painting the cabinet flat black.

For memory, I decided to make use of other members of National's line up:

• DP8419 - Dynamic RAM Controller
• DP84300 - Programmable Refresh timer
• DP84412 - Dynamic RAM Interface

These chips made it very easy to construct a memory array with dynamic memory chips. The designs involved 64K bit dynamic memory totaling 256 to 512 KB. It all depended what I could fit on an S-100 board.

The presence of a memory management controller made virtual memory a possibility. The rest was a small matter of software. In my initial designs, I planned to use the Pertec 8" floppies for virtual memory. Perhaps slow, but possible. In mid-1985, I mapped out the Pertec FD400 internal interface boards as part of this effort.

Other than a bunch of schematics and a painted chassis, I never built anything. A good thought experiment, perhaps. Even with working hardware, the operating system software would have taken years to get going.

And the NS32xxx series wasn't without problems. Part of the reason this chip set never caught up is it was full of defects. National went through several iterations over years to resolve the defects, missing their window to catch the MC68000 family or the Intel 8086 family.

Cycle 25 is Kicking Butt

Don't know why I didn't write about this when it happened.

August 9th, the daily Sunspot Number (SSN) was 382. That seemed enormously high. I couldn't remember a single time when the SSN was that high. So, I did some digging.

I downloaded all the SSN data, converted into an Excel spreadsheet and did some analysis. The SSN hasn't been that high since 1991. That's 33 years ago!

The SSN has only been this high a total of ten times in my lifetime (since February 1961) -- Five in 1979, Twice in 1989, and Three times in 1991. 

Of course, none of this compares with Cycle 19, where daily SSN values were well over 500 for many days. But those values all happened 1956-1959, well before I was born.

Cycle 25 is shaping up to be much better than Cycle 24, which was really lousy, and possibly better than Cycle 23.  The smoothed SSN has already exceeded the maximum value for Cycle 24, and it is far from over. 

We've already seen a huge change in the bands in the last couple of years. 20m is open 24 hours, and 15m much of that time. 12 and 10m is open every day. I'm hoping we might see some 6m F2 openings. Enjoy it while you can. We should have two more years of these conditions before the cycle starts back down.

RTTY Contest Operation and Messages

In 1985, I built a home-brew decoder and experimented with RTTY, but I never got it to work. I've since decided that I didn't know how to tune RTTY properly. Things changed in 2005 when I downloaded CocoaModem made my first RTTY contacts. 

Since I was involved in contesting, I naturally turned to RTTY contesting. Today, it is unusual to hear RTTY signals on the bands except during contests. Thirty or more years ago, RTTY was commonly heard on 80 and 20m. 

Characteristics

Several characteristics of RTTY must be understood in order to communicate effectively: 

• RTTY has no error correction or detection -- unlike AMTOR, Packet, FT4 or FT8. This means whatever that prints might be wrong. And if it is wrong, you will not know. 
• RTTY prints garbage. Without a signal, random characters print. This further complicates determining what is correct and what is not. 
• RTTY does not handle multiple signals well. When two or more stations call at the same time, RTTY will not print reliably. Certain decoders may print the strongest signal, if you are lucky.
• RTTY text comes in a continuous stream. Long lines wrap to the next, or one can force a new line by sending a carriage return / line feed combination. Wrapped lines are often difficult to read.
• RTTY has two shift states, LETTERS and FIGURES in the Baudot encoding. RTTY rests in the LETTERS state. An unprinted FIGURES character is transmitted to shift to the FIGURES state. A similar LETTERS unprinted character can be sent to shift back, or one can automatically unshift on a space character. 

Principles

For effective RTTY contest communication, several principles apply. 

• Brevity - every character sent must have a purpose. There should be no wasted characters.
• Duplication - every important element should be sent twice. This contradicts the brevity principle. Because RTTY prints incorrect characters, sending important elements twice helps ensure correct reception.
• Scrolling - each message starts a new line, but ends with a space. This technique keeps lines from wrapping, and avoids the end of message being confused by garbage characters when the signal drops. 
• Shifts - avoid needless shifts. Any sequence involving the unprinted FIGURES or LETTERS characters takes longer to send. 

Messages

(I'm using N1MM messages for my examples. Other software may have different macro names and techniques, but the same principles apply)

Every message starts with a {TX} and ends with {RX}. This transitions the software to transmit and back to receive. 

S & P

Let's say you want to answer someone's CQ. This means you need to send your call. For that, you'd use a macro like this:

{TX}{ENTERLF}{MYCALL} {MYCALL} {RX}

or

{TX}{ENTERLF}* * {RX}

(For N1MM, the asterisk and {MYCALL} macros are the same)

Notice the message starts with {TX}, performs a carriage return / line feed with {ENTERLF}, sends the call twice, ends with a space and then {RX} to go back to receive. Sending the call twice helps to ensure the recipient receives it correctly.

If you are lucky enough to get a response, you'll have to send the exchange. The exchange will vary by contest, but it could be a message like this:

{TX}{ENTERLF}! 599 GA GA DE {MYCALL} {RX}

This is what I send in the RTTY Roundup. First is the recipient's call (!). Then 599 -- don't use 5NN, because that actually takes longer to send in RTTY -- and send it only once, because it isn't important. Then the exchange is sent twice, followed by the prosign DE and my call, followed by a space. 

N1MM's authors recommend you use the ! character rather than the {CALL} macro. The reason is that {CALL} isn't subject to correction -- it sends the contents of the Call field at the start of the message. The ! character will send the Call field as it is being corrected in real time. As a practical matter, most RTTY contest contacts involve pointing and clicking on callsigns, so there's less typing, and therefore fewer corrections involved.

A couple of things here. Notice I did not use the {EXCH} macro above. When there are multiple elements to the exchange, I put the repetitions together. So, I tend put the exchange information into the macro directly. For example, here's an S & P exchange for CQWW RTTY:

{TX}{ENTERLF}! 599 GA GA 5 5 DE {MYCALL} {RX}

GA for Georgia, and 5 for zone 5. For NAQP RTTY, it would be:

{TX}{ENTERLF}! 599 BILL BILL GA GA DE {MYCALL} {RX}

Some might balk at the use of the DE prosign, particularly for exchanges that involve a state or section, since DE might be confused with Delaware. However, I think this prosign is useful, as it establishes the callsign is of the answering station, and not the CQing station.

CQing

Calling CQ in a contest is the most-used message:

{TX}{ENTERLF}CQ RU {MYCALL} {MYCALL} CQ {RX}

Note that the important information -- the callsign -- is repeated. The other curious thing is the "CQ" at the end. This indicates I finished a CQ message. This is important because one cannot tell when potential callers tune in to your signal. If they do so during the first callsign, the can't tell if you are calling or answering a CQ. Putting "CQ" at the end establishes you are calling CQ. And it is shorter than "QRZ?".

Naturally, one indicates the contest in the CQ message. Here it is "RU" for Round Up. Use whatever is appropriate for the contest, or simply "TEST".

When someone answers your call, you send an exchange message:

{TX}{ENTERLF}! 599 GA GA ! {RX}

Note that the exchange is sent twice, and if there were more than one element to the exchange, I'd send those twice as well:

{TX}{ENTERLF}! 599 BILL BILL GA GA ! {RX}

Another item to notice is there is no {MYCALL} macro in this message. Instead, the caller's callsign (!) is sent twice, once at the beginning and once at the end. There are two reasons for this. First, it follows the principle of sending important information twice. It could be the caller's callsign printed incorrectly to me, or perhaps it will print incorrectly when I send the message back. If I only send the callsign once, the caller might or might not correct it if is wrong, or they may correct it if it printed incorrectly to them. 

Unnecessary corrections are a waste of time, but necessary corrections are desired. 

Second, it may be that during the response with the exchange, other stations may also be calling. This, creates a good chance that the initial callsign in the response will print incorrectly. If you don't send the callsign again at the end, it could be unclear who you responded to. 

Once you've received the exchange from the caller, one sends an acknowledgement:

{TX}{ENTERLF}! TU DE {MYCALL} CQ {RX}

Short and simple. Two features here. One is the DE prosign, to indicate this is the transmitting station's call, and ending with "CQ" to invite new callers.

Turnaround

Occasionally, multiple callsigns will print in response to a CQ. You can only respond to one at time.  Since you can only respond to one at a time, this leaves someone waiting. Rather than have them call again, you can use a turnaround message which acknowledges a completed contact and starts a new one:

{TX}{ENTERLF}! TU {LOGTHENGRAB}NOW..{ENTERLF}{F5} 599 GA GA {F5} {RX}

This message omits {MYCALL}, and uses the {LOGTHENGRAB} macro to first log, then grab the callsign off the automatic decode stack, then it follows with the normal exchange. If you use Single Operator Call Stacking, you can use {LOGTHENPOP} instead. See the N1MM manual.

Note that instead of using the exclamation point (!), we use the {F5} macro. Both the exclamation point and the {CALL} macro won't be updated by the {LOGTHENGRAB} macro, but {F5} will.

Short

When signals are strong, and the bands are quiet, perhaps the principle of sending information twice doesn't apply. Most RTTY contests allows contacts on multiple bands, and the exchange doesn't change. In these cases, you may want to have short messages handy. Here are some examples:

{TX}{ENTERLF}! 599 BILL GA DE {MYCALL} {RX} -- short S & P exchange

{TX}{ENTERLF}! 599 BILL GA {RX} -- short exchange for S & P or CQing

{TX}{ENTERLF}599 BILL BILL GA GA {RX} -- repeat of just the exchange 

{TX}{ENTERLF}CQ RU {MYCALL} CQ {RX} -- short CQ

{TX}{ENTERLF}TU DE {MYCALL} CQ {RX} -- short acknowledgement

All these should be used when you have solid copy, want to get back to other callers quickly, or you are fairly certain the other operator already has your exchange information from a previous contact.

Tips

Some tips I've picked up over the last decade that are helpful.

• Use Slow AGC - Fast AGC can confuse decoders and introduce print errors
• Use TX Filtering on AFSK - If you are using MMTTY or similar software, use the 512 tap TX Filter. It helps transmit a cleaner signal.
• Listen with Headphones - sometimes you can hear signals that don't always print, if you listen with headphones, you can hear the stations calling you. It also helps you improve your timing in a pile.

On that last tip, turn the volume on the headphones way down. You just have to sense when signals are there, you aren't decoding them. (I believe it was the late Irv Hoff, W6FFC (SK) -- a RTTY pioneer -- who suffered hearing loss at 2125 and 2295 Hz from listening to RTTY signals)

Practical Messages 

There are a handful of other messages you may wish to have handy. Here's one I use often, when you didn't copy anything sent:

{TX}{ENTERLF}AGN AGN {RX}

Or perhaps you need a fill of one element:

{TX}{ENTERLF}STATE? STATE? {RX}

{TX}{ENTERLF}NR? NR? {RX}

{TX}{ENTERLF}NAME? NAME? {RX} 

 Before you open up with a CQ on a frequency,  this is good one:

{TX}{ENTERLF}QRL? DE {MYCALL} {RX}

 Maybe if you are not sure someone is calling you:

{TX}{ENTERLF}QRZ DE {MYCALL} {MYCALL} {RX}

Or the short version:

{TX}{ENTERLF}QRZ DE {MYCALL} {RX}

Every once and a while, directed call is useful, especially when two stations are calling CQ on top of each other:

{TX}{ENTERLF}! DE {MYCALL} {MYCALL} {RX} 

Conclusion

RTTY contests are a ton of fun. Program a set of messages and try it. You'll like it.

The Great LoTW Outage - Continues.

Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.

--

When I wrote the article back in May, I hardly thought that LoTW would be down a month later.

Sadly, the outage continues. 

My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.

Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.

I do hope it is soon. I'm really missing this service.

RealVNC Changes Terms, without Notice.

Just over three years ago, I figured out how to Remotely operate FT8 using a product called RealVNC. 

RealVNC had a Home plan that allowed up to 3 users and up to 5 devices for non-commercial use. Perfect for remotely controlled computers in a ham radio shack.

Today, without any notice, RealVNC disabled my Home plan, and I had to choose between paying each month for a plan, or adopting their Lite plan, which allows 1 user and up to 3 devices for non-commercial use.

That's fine. They allow me to use their secure remote access software without fees. I can understand they might want to change the terms.

The Lite plan fits my usage. I've only ever had two devices active anyway, and it's just me as the user. 

But, without notice - that is just damned inconvenient. Since I switched plans, I need to visit each device and re-configure them to be part of the new plan. Which means I can't remote into those computers until that is completed. 

And, of course, since I'm remote, I'm not there.

Quite inconvenient.

FT8 is supposed to make DXing easy, why is it so hard?

FT8 has been a revolution. The technology has made DXing really easy. Or has it? I continue to be amazed at how much difficulty people have working DXpeditions on FT8. 

Last year, there were DXpeditions to Bouvet (3Y0J), Crozet (FT8WW) and Sable Islands (CY0S). The most recent DXpedition to Glorioso Islands (FT4GL) has brought it all back to me.

Let's start off with a few observations on people trying to work these DXpeditions:

• Wrong Cycle - It's amazing the number of folks trying to work DX that are calling on the wrong cycle. FT8 has even and odd cycles. Even cycles start at 00 or 30 seconds, and odd cycles start on 15 and 45 seconds. You always call on the cycle the DX station is NOT transmitting. Indeed, if you double-click on a decode of the DX station, WSJT-X will set up the correct cycle. So how are people getting it wrong?

• Endless Calling - I've noticed some stations keep calling the DX after the DX station has QSYed or QRTed. A little bit of hopeful calling isn't unusual on Phone or CW, or even RTTY. But stations continue to call much later -- like an hour later, and they are still calling.

• Calling without Response - Some stations don't respond when the DX station calls them. They keep calling instead of advancing to the next step. This can get really bad. During the FT8WW expedition, I saw FT8WW keep responding to the same station for more than 10 minutes. Each response had a different signal report. This made it clear that FT8WW was heading this caller quite well, but the caller wasn't hearing FT8WW at all. Instead, that station took up a valuable response slot for 10 minutes -- denying perhaps 20-40 stations from working FT8WW.

• Confusing Fox/Hound (FH) and MSHV - Most DXpeditions using FT8 use either FH or MSHV in order to maximize the number of contacts they can make. It is easy to get confused with these two modes. They appear similar. Both allow for the DX station to transmit multiple FT8 carriers at the same time. FH imposes additional behavior to both the Fox and Hound ends of the contact. In particular, there are audio-frequency dependencies that FH enforces. But, it is perfectly possible to work a Fox station even if you are not in Hound mode. MSHV requires no special modes. And yet someone accused people of DQRM, calling FT4GL below 1000 Hz, when the DX was using MSHV, not FH.

What causes all these odd observations? I believe they all resolve to a single cause -- people are calling DX they cannot hear. That's right, people are calling DX stations they aren't decoding at all.

This is fundamentally wrong. I wrote about this years ago on how to bust a pileup. You cannot work DX if you cannot hear them. If you aren't decoding the DX station, stop calling. Yeah, that's hard, but your calls won't net you a contact, and you may be actively depriving someone who can hear the DX from making one. 

I think FT8 has made some people lazy. They hear some DX station is active on some frequency, probably through a spotting network. So they switch to that frequency, set their watchdog timers to an hour or more, and enable their transmitter. Then they go off and drink a few cool 807s while their computer works the DX for them.

Farfetched? No, it explains all the observations above.

Be a good FT8 operator -- don't call DX when you cannot decode them. Wait until you can decode them reliably, just about every cycle -- then start calling.

The Great LoTW Outage

May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.

That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error. 

So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.

Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.

But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information. 

Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.

What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.

I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.

Fixing up the Cushcraft A50-3S

A50-3S standing tall and
straight next to the house.

Last year, I moved the A50-3S out of the yard and up next to the house. I used a 19 foot mast made of two pieces of EMT. While putting it up the reflector bumped against the roof and turned askew about 15 degrees. 

Never the less, it worked well. I worked a few Europeans and several South and Central American using this antenna.

Still, it needed a bit of work. A one-piece mast would be better, and I could straighten out the reflector when I swapped masts. A bead balun at the feed point wouldn't hurt either. 

So, I researched these. You would not believe what a 20 foot piece of 1 1/2" 0.058 wall aluminum tubing goes for these days. A few years ago, I purchased a 12 foot piece of 2" diameter 1/4" wall 6061-T6 tubing for my gin pole. It was about $150, which seems right for such a substantial piece of metal. 

But 20 feet of the thinner mast? They quoted me $500! If I went with the 1/4" wall, well that was manufactured with a different process -- extruded instead of rolled, so it would be $250. Ridiculous. There had to be another solution. 

I did have 20 feet of mast in two 10 foot pieces. This was from an earlier experiment. I had an old Butternut  HF4B that I had rebuilt, and was hoping to erect in Fulton County. I bought two pieces of Rigid Metal Conduit (RMC) for this purpose. 

EMT and RMC are easily found at your local Home Depot. But it isn't exactly what you would call structural. EMT is design to bend. Easily. I have had some success using it as masting for very small, light antennas. The two pieces I used on the A50-3S lasted for over eight years, plus the several years holding up a 19 element 2m boomer Yagi. RMC is more substantial, and comes with threaded couplings to connect them together. 

Two pieces of 10 foot RMC was $30 a pop, so this wasn't a cheap experiment. Even with the coupling tightened all the way down, the 20 feet of mast had a substantial wobble in the top section. I tried inserting a solid piece of HDPE. That helped, but not enough to hold up the HF4B. 

It occurred to me that this might work with the A50-3S, even with the wobble. The A50-3S is held upright by a wall bracket at the eve of the house, well above the wobbly union. I just needed the vertical support, and not so much lateral rigidity. Besides, I already had $60 invested.

First order of business was to find the doggone things. I put them away three parsonage moves ago, and had hidden them well. They were hiding in my basement. After that, I had to locate the piece of HDPE, which I found in another box. 

It all came together this week. My youngest daughter Lauren helped me to lower the existing A50-3S and mast to the ground. Off came the antenna and the feed line, and the old mast was disassembled and put away. Then I coupled the RMC together with the HDPE stiffener and taped the coupling joints against any water intrusion. With the A50-3S mounted on the new mast, the reflector was aligned with the rest of the elements. 

For a balun, I used five snap-on ferrite beads. I measured these at about 100 ohms resistive at 50 MHz. Five conveniently fit on the 9913 coax from the driven element to the mast, so that is what I used. 

A50-3S facing South East.

Swinging the new mast up into place without bashing the antenna against the house took some patience. The RMC mast is much heavier than the two pieces of EMT. Once vertical, I positioned the mast in the eve bracket and loosely connected the u-bolt clamp. Both my daughter and I lifted the assembly to the top of the railing. From there, I tightened the bracket to eliminate play, but loose enough to allow the antenna to rotate. I used a couple of extra 1/4" nuts as jam nuts so the bracket could not tighten or loosen. 

The antenna is easily Armstrong rotated from the base. Eventually, I'll mount a rotator on the top of the railing and retire my arms.

A quick SWR check showed a 1.2:1 SWR at 50.313 MHz. The antenna is pretty broad. Minimum SWR is around 50.8 MHz at 1.07:1. I suppose I could mess with the matching network to get a better match on the FT8 frequency, but the whole bottom 2 MHz of 6m is less than 1.5:1. 

The antenna is 28 feet (8.5m) off the ground with clear shots from the North clockwise to the South West. Points to the West and North West have to pass through the house roof.

I hope Es season hasn't passed me over yet. 

How 1984 wasn't like "1984."

In 1984, I was working at Hayes Microcomputer Products. They were the premiere modem manufacturer for small computers, back in the days when modems over telephone lines were a primary means of computer to computer and user to computer communications. 

In my job, I created communications software to talk to the modems. The software dialed the modem, established connection, provided terminal emulation (my specialty), allowed for the capture of the data stream to files, printing, file transfer with the remote computer (using protocols like XMODEM and YMODEM), and other features. 

These were the early days of personal computing. IBM introduced the PC in 1981, and it had rapidly evolved into a defacto standard computer, shoving out various CP/M designs from the previous decade. Personal computers were so new, people were trying to figure out what to do with them. Word processing, spreadsheets and other office applications had just been introduced. 

Hayes was trying to stay at the forefront. We had a laboratory filled with pretty much one of every personal computer, and when new ones came out, we would buy one. In late 1983, we got an Apple Lisa. It was a very different kind of computing experience. It was a curiosity to us, and as there was no programming environment available, we didn't see how we could build software to talk to a modem. Plus, at the price point, there were few buyers.

The Macintosh

Though the Macintosh was introduced in January of 1984, I didn't get hands on one until the late spring of 1984. Yes, we brought one into the lab, and it immediately garnered a lot of attention. 

While there were similarities to the Apple Lisa, the small screen with square pixels just seemed sharper and more distinct. The whole interface was friendly and approachable. We messed with MacWrite, MacPaint, and MacDraw. We printed on an ImageWriter, making appreciably decent images unlike anything we could do on another type of computer. There were several of us hooked and enthusiastic.

It's hard to describe those days. At this point, everyone has had decades to become familiar with computers that use a graphical user interface and a mouse or other pointing device to interact. Back then, it was a revelation. It was much more approachable than the command-line interfaces of the day. 

As I described it to someone in the early 90s -- other computer interfaces required one to reach toward the computer. You had to learn the special language and commands of that computer. The Macintosh was the first computer that reached back toward you -- the user.

The Machine

The Macintosh was based on a 16-bit Motorola MC68000 processor, running at 8 MHz. This was more than competitive with the Intel-based IBM clones circulating at the time. This processor was a great choices by Apple. It had many registers and powerful instructions for manipulating the bit-mapped screen.

Biggest constraint was memory. The 128 KB in the Macintosh was shared with 24 KB used for the screen, several more KB for operating system usage, leaving about 90 KB to run your program. Most of the critical operating system routines were in the Macintosh ROMs, which saved space. Building a program of any sophistication was difficult -- It was very tight to work with.

The single 400 KB floppy disk drive was also a limitation. Trying to save a file to another diskette could produce an endless amount of swapping. It was the lack of addition storage that kept me from buying a Mac until the Mac SE/20 was introduced in 1987. 

Next Steps

By summer, Hayes hired some consultants to look into the feasibility of developing communications software for the Macintosh. In just a few weeks, they had some rudimentary software going and concluded that it was quite feasible. 

We were soon green lighted to create a product for the Macintosh.

Forty Years of Personal Computing - Gimix 256 KB Static RAM

256 KB Gimix Static RAM board, sans battery.

In 1991, my employer moved to a new building. Before the move, we cleaned out storage closets containing old equipment. Much of this was obsolete gear. Things like pairs of "twiggy" disk drives removed from early Apple Lisa systems upgraded to 3 1/2" disks in 1985.

In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a  2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s. 

By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment. 

Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler. 

Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive. 

In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte. 

I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.