Monday, February 24, 2020

33209: Interviewing IBM

Chapter 8: Bootstrapping, or Baby Steps

Chapter 9: Interviewing IBM


I took the computer to school with my stereo cassette deck on Wednesday, borrowed a scope again, and tuned the fast cassette interface circuit. That went quickly, and I got good write and read results at 1500 baud on the stereo deck.

Then I decided to experiment, and I got my lab kits out and used the parts and breadboard to put together what I understood to be an MFM state machine for read and write, and started experimenting with recording raw bits on tape in MFM. I was able to get consistent reads from writes on text data up to over four kilobaud on the portable cassette recorder, and up to almost nine kilobaud on the stereo cassette deck.

(As with tuning the slow cassete interface, I never really bothered to do this. MFM? The fast cassette interface I put together may have used MFM recording. I apparently didn't pay enough attention, and the actual devices are not where I can dig them out to check. Anyway, the me in this story needs to experiment with misunderstood MFM at this point. I'm pretty sure MFM could have achieved four kilobaud on a reasonably good ordinary cassette recorder and eight kilobaud on a moderately high-fidelity cassette deck, with reasonably good tapes and a reasonably fast MFM state machine.)

Dr. Brown observed my work and decided it would be a good lab for the digital circuits class, and asked me to leave my breadboarded interface intact for him to work up the lab from. I complied, taking a copy of the circuit diagram with me, to add to the Micro Chroma 68 as an interface, later.

When I got home, my mother gave me a message from Ms. Bight's secretary. Ms. Bight had heard from Freddy Burns about my building the computer, and wondered if I could bring it to the interview with me. I called before I started folding newspapers and confirmed that I would.

Mom also gave me my package from TSC, but I held off on looking at it.

After delivering the newspapers and checking homework, I reviewed and revised my résumé and proposal and printed up the revisions, then unwrapped the package of official cassettes and documentation, and spent time patching and previewing the debug package, and using it to explore some of the code of the various tools I had.

I noted in the software catalog they sent me that there was a C compiler as well as a Pascal compiler.

I called it a long Wednesday about 11:00 and read my scriptures and went to bed.

*****

Mom had offered to take the route on Thursday so I wouldn't be under too much time pressure to make it to the IBM office in Midland for the interview, but the newspapers came on time. After I got them out, I took a quick shower, changed into a suit, packed the computer, display, and stereo cassette deck in the Colt, and drove to the interview. I arrived a little before the interview was scheduled, at ten to six, but was shown in when I arrived.

(Okay, I said that the institutions were pretty much as they were, as they affected me. They indeed have been, to this point, what little interaction there has been. But if my actions in this fictional version of the world had no affect on them, this story would have no point in being written.)

"Hi. Come on in and have a chair. Should I call you Marion or Joseph?"

"Hello, Ms. Bight. Most people call me Joe."

"You can call me Meg. Megabyte if you wish," she laughed. "I've been telling people for years that we need to be talking about megabytes of memory."

I chuckled at her joke. "It's a forward-looking name."

"We really haven't done student internships at this office before. We don't have an established set of procedures, so you are pioneering."

"I enjoy pioneering."

"That's good to hear. Did you bring your proposal?"

"Sure. I have it here, with my résumé."

I handed her the folder I was carrying, and she scanned it over quickly.

"Résumé looks good. Maybe a tad too much detail."

(Putting too much detail in my résumés is a habit I've always never quite fixed.)

"And your proposal looks good, too. Do I get to see your computer?"

"It's in the car. Figured I'd tell your secretary I was here first, before I brought it in."

"I could read this while you go get it."

"Sure."

It took three trips to bring in the whole setup.

She raised her eyebrows as she examined the circuit boards. "Clean work, but very much not ready for marketing."

"It's not really intended for marketing. Old 8-bit CPU. Just using it in my classes. Later it'll be my ROM burner when I start playing with other processors."

"Old processor?"

"The eight-bit sixty-eight hundred. Well, actually, sixty-eight oh-two, but still specified by Motorola as not intended for new stuff."

"Oh." She sounded disappointed. "Not the sixty-eight thousand."

"The 68000 is a much bigger package -- sixty-four pins. Motorola doesn't seem to be into multiplexing address and data, except for their SOCs."

"Never seen one up close. Come to think of it, when Freddy mentioned it, I think he did say it was the 8-bit 6800, and I only heard the sixty-eight. So what can you do with a 6800?"

"Wrote the résumé and the proposal both on this, using a text editor and a text processor."

"Text editor plus text processor. Screen doesn't look like what is printed, then?"

"True. No preview mode on this. But this is running Tiny BASIC from ROM, so I can use it as a nice programmable calculator. My electronics prof sometimes has me demonstrating what we're working on in the AC and digital logic classes on days when I borrow a 'scope at school. And of course I plan on using this for the microprocessors class."

"Then I guess it works pretty well for you. Have you had any problems while building it?"

"Not really. According to my electronics teacher, not nearly enough."

She laughed and I shrugged.

Then she gave me a sharp look. "You're not joking."

"He says people learn more from mistakes. I think he has a point."

"But you seem to already understand quite a lot of this. Do you need to even take the microprocessors class?"

"There are some topics I need to cover still. And, of course, I gotta give them a good reason to give me the piece of paper that says I graduated."

"Are you sure? Two Steves come to mind."

"True, Jobs and Wozniak never graduated, but they had a lot more experience than I do when they started making computers."

"Several of my employees don't have degrees."

"Neither does my brother. He says he's the only non-degreed engineer in his division at Motorola. But they keep nagging him about it, and he goes back to school only to have them drop emergency projects in his lap before courses are complete."

"Good point. I've done the same thing to my employees."

I refrained from mentioning that my dad and I had an agreement about my working on a degree and staying rent-free at home. (In the real world, I remembering mentioning the agreement to the boss at IBM, which was probably not strategic.)

"So show me what you can do with this."

I showed her the loan amortization program and the Newton-Raphson program, loading them from the fast cassette and letting her examine my source code.

"Very readable source code, even with the gotos."

"Thanks. Readability is something I work at, even for small programs like these."

"And you're using your stereo cassette deck to store programs."

"I have an interface that runs faster than 300 baud in here, and it works with a mid-to-hi-fi deck."

"Did you invent it?"

"No, it was a circuit one of my brother's friends put together. Yesterday I played around with MFM recording techniques, though. It looks like I could add an MFM circuit that runs at between four and eight kilobaud, which would give more than a half a megabyte of storage per side on a 30 minute tape."

"Stereo. Using both channels?"

"Ran into crosstalk problems yesterday. It'd need a bit more careful design in the write and read circuits. Just using one channel now."

"Do you plan to put an operating system on it?"

"Yeah, once I get floppy drives working on it, I plan to put an OS called Flex on it."

"Floppy drives?"

"Going to Austin to look for possibilities in a surplus electronics store down there."

She raised her eyebrows. "Surplus likely means a raw drive."

"Yeah. Save a bit of money and have the fun of designing the electronics for it. Maybe."

She shook her head. "You like DIY projects, don't you?"

"If I do it myself, I have only myself to blame when something goes wrong, and it's a lot easier to negotiate for bug fixes."

"Really?"

I laughed. "Okay, time limits can overrule intentions."

"Good. Well, promise not to make that kind of decision with company time, okay?"

I chuckled and nodded. "Yeah. Different priorities there."

"Programming languages?"

"Flex has Pascal and ForTran available."

"That's good to hear. You mentioned other processors. Intel?"

"Maybe. But I don't really have much access to them. I'll work on the 8080 at school. But I get a lot of free parts from my brother, with company permission."

Her expression sharpened.

"It's an engineering incentive program. They're allowed to pull parts from the reject bin and test them, and use any that are good enough for personal projects."

"Ah." She nodded doubtfully. "Encouraging skunkworks projects." Her expression was barely readable, but reminded me of someone testing the air for a disagreeable odor.

"So I'm doing a lot of the grunt work for him."

She gave a quiet snort. "Just don't do that without permission here."

"Of course. Never without permission."

"So this computer does what you need. I guess you don't need to build one with a 68000?"

"Well," I chuckled. "I want to be able to work with Japanese. Less than 256 characters works okay on an 8-bit computer, but, for thousands of characters, you need more address space than a typical 8-bit has."

"Oh, that's right." She glanced down at my résumé. "You just got back from two years over there, like, a few months ago?"

"Yeah."

"And you speak Japanese?"

"Nan-to-ka."

She chuckled. "And what does that mean?"

"It means 'Sort-of'. Some people said I was speaking pretty well. But I still make a lot of mistakes."

"Oh. So what did you do as a missionary?"

"Found a few people who were interested in learning about what we believe. Taught free English classes. Looked for opportunities to be of service to people."

"I've heard that your missionary program is like a sales training program."

"Some people treat it that way, but my mission presidents did not. They asked us to deepen our understanding of our religion instead of focusing on sales techniques."

"Interesting. So how would you summarize your religion?

"Depends. What do you think about religion?"

"I'm agnostic, or maybe atheistic. Grew up Methodist, but I really have a hard time believing in the God people preach."

"Well, one thing I believe is that, even though there are dangers, the universe is not out to get me."

"Heh. Not out to get us. That's nice to now."

"Most people don't really quite grasp what I mean when I say God wants us to be happy, so I try different points of view on it, and this is one."

"I guess I could see that. Is that all?"

"Well, if you can believe that paranoia is not a universal truth, then it does make it easier to believe that it's worth trying to be a better person. And that kind of ties into what the electronics professor says about mistakes. We do learn more when things go wrong, and learning makes us happier than having nothing go wrong."

"Nicely put." She laughed "Backhanded persuasion. I'll have to be careful around you if I don't want to lose my agnostic attitude." She nodded with a bemused grin. "So, I can take what you said in your proposal seriously, that you would like to learn what it's like to work at an IBM sales office?"

"Yeah."

"Can I mention your computer building ambitions in my analysis, since you didn't really mention them in either?"

"Sure."

"What are your plans?"

"Well, I'm thinking first I'll rework this design to include the 6801 instead of the 6802."

"Not familiar with the part numbers, but that sounds like a step backwards."

"It's actually a step forward. Small, but important compatible improvements to the instruction set, SOC-style built-in RAM and I/O. I'm thinking to build a trainer with maybe three chips, with a header than allows attaching a 6847 video controller like this, more RAM, I/O, etc."

"Making this computer obsolete immediately?"

"I think I'll keep this one for ROM burning, if for nothing else."

"How about the 68000?"

"After I get comfortable with the 6809."

"6809? It's better than the 6801 or something?"

"More like a crossover 16-bit CPU. Lots of index registers, compared to the 6800."

"Index registers are useful."

"Yep. I want to build a 6845-based video controller for the 6809 first, so I can output more resolution than what a TV is capable of. Then I'll know what I'm doing when I build something similar for the 68000."

"Good plan, but it will take a while. How do you plan on bringing all the hardware up?"

"I've recently heard about a language called Forth that's good for bringing hardware up. I'm planning on putting that on this computer after I get the floppies running, along with the Flex software."

She nodded thoughtfully. "Sounds like you have a plan."

"Then I want to try writing my own OS and programming language. And I want to compare code for the 6800, the 6809, and the 68000."

"Now that's getting pretty ambitious."

"Yeah, I'll have to adjust my plans as I go, since I'm planning on finishing school, as well, and holding down a job in the industry while I'm at it."

She laughed. "Stars in your eyes, but a touch of realism in there somewhere. I wouldn't hire you yet as a regular, but let's see if some experience helps you. I'll recommend we accept you for an internship."

"Thank you."

"Thanks for coming in and showing me your computer. Very interesting. There'll be some discussion with my managers, and I'll let you know the results within a few weeks."

"I appreciate the opportunity, and I look forward to it."

"Give my secretary a call every now and then to keep me informed when things move forward with your computers."

"I'd love to."

*****

When I got home, I called TSC on the hope that somebody would still be in the office out there in the eastern time zone, so I could check about ordering Flex. I was in luck, or, rather, they had someone staying late for customers in the western time zones. When they heard I wanted the OS and the Pascal and C compilers, they said they'd throw in a copy of their games collection and some utilities for free.

I asked about system hardware requirements, and they told me that Mini Flex (MFlex) would only need 32K of RAM, from address zero to $7FFF, but Flex version 2 would need to reside in RAM from $A000 to $BFFF, and so would need 48K of RAM.

After I hung up, I wrote up an order for the Flex operating system and the Pascal and C compilers, wrote up a check, and put it in an envelope to put in the mail Friday before classes.

Giselle came into the kitchen where I was writing up the order.

"I want to go to Institute."

I checked the time. "We could almost make it by the time they start if we grab something to eat in the car."

"There's broccoli and beans on the stove and bread on the table," Mom called in from the living room.

We shoveled food into bowls, grabbed some bread, picked up our scriptures and the Institute manual, and left. I drove and Giselle held my bowl for me. We both ate on the highway, after we left the city traffic behind.

The lesson was a fairly normal lesson, which is to say that the fellowship was probably more important than the doctrinal presentation.

Back home, after making sure my homework was ready for Friday, I doodled out some possible redesigns for the RAM circuits to fit the address map of Flex before heading for bed.

And I fell asleep dreaming I was a 74LS138 chip decoding addresses for empty static RAM sockets.

Chapter 10: Parameters

[Backed up at https://joel-rees-economics.blogspot.com/2020/02/bk-33209-interviewing-ibm.html.]

Tuesday, February 11, 2020

33209: Bootstrapping, or Baby Steps

Chapter 7.5: A little about the 6800 (and Others)

Chapter 8: Bootstrapping, or Baby Steps


After delivering the Saturday morning edition, I lined the inside of the box with sheet metal and installed the fan and the power supply, mounted the mainboard horizontally on offsets, grounded the board to the Faraday cage made by the sheet metal, mounted the keyboard, and tested that it still worked when everything was assembled.

Then, while I worked on designing the dynamic RAM circuitry and the ROM circuitry, Giselle played with the computer, using Tiny BASIC and asking me how to do things as she experimented.

Departing drastically from the example refresh circuit in the Micro Chroma 68's manual, I decided to borrow the video display generator's scan for the refresh strobe.

You may be thinking that the video scan works on the wrong part of the address for refresh. If so, you're right. Dynamic RAM refresh strobes have to count through the row addresses several hundred times per second. The VDG's lower address lines continuously count, completing their count tens of times per second as necessary for refresh, but if you attach the address lines in the usual way, the lines that count end up being column addresses, not row addresses.

That means only two pages in text mode, and not many more in graphics mode, get refreshed. And all the pages that don't get refreshed forget their data.

However, contrary to ROM, RAM doesn't really care about the order it is addressed in. Where you write the data is where it reads back from, and if the address lines don't change between write and read, the readback succeeds without any notice that the lines don't match the labels.

Well, many dynamic RAMs have row burst mode for speed, and if you use row burst access, the row must be an actual row. Otherwise, you'd be burst accessing with gaps, which is generally not useful. Row burst wouldn't allow what I did at all. But the Micro Chroma 68 would definitely not need row burst mode. Adding cache RAM and seeing how far beyond 2 Megahertz I could overclock it was not part of the plan.

(Row burst mode might well be used for high-resolution video, but the TVs of those days were not particularly high-resolution.)

So, if I swapped the usual rank of row and column, I could borrow the low order address scan count for refresh strobe, by addressing the dRAM rows instead of the columns with the VDG low address lines. Doing this, the row refresh would be completed within the required timing of once every ten or so milliseconds.

I was a little worried that changing VDG modes would cause problems, but it looked like the switch would occur quickly enough for the RAMs I was using, even if the VDG stopped to start over again almost at the end of a frame. So I decided to wire it up and see if it would work.

Using the VDG had the additional advantage that the refresh would be occurring in the same phase of the memory clock as video refresh, opposite from and not interfering with CPU accesses.

I added a whole 6821 PIA for an extra bit of output to switch between the lower 32K and the upper 32K. That was a waste of a PIA, but I thought I could use the extra bits elsewhere, and I quickly found use for them.

With a bit of additional logic, I was able to decode the selected 32K bank starting just above static RAM, at addresses $2000 to $9FFF, giving 40K of contiguous addressable RAM.

I quickly had enough of a circuit design put together to walk to Radio Shack and pick up perfboards, a bunch of headers and sockets for them, some 74LS series bus buffer latches, and some other parts, and start wiring the dRAM refresh circuit up on one of the perfboards, using point-to-point soldering on the low-profile socket pins. I wasn't able to finish wiring the board before bedtime.

*****

At church on Sunday, Br. Burns gave me the name and contact information of the manager at the local IBM office, Margaret Bight, and told me she would be expecting to hear from me. I invited him to come take a look at the Micro Chroma 68, and he brought his family over to visit after church meetings.

"Not sure what to say. It looks like a very capable toy. Games, maybe?" was his impression.

Hard to argue with.

I spent, as was becoming customary, Sunday evening at a young adult home evening activity, where we had a gospel-oriented discussion and played Uno after.

*****

Monday evening, I finished wiring up the dynamic RAM and wrote some code for testing it. It worked for both banks of 32 kilobytes, keeping memory contents even when switching between VDG modes.

However, when I tried using one bank as a high-speed substitute for mass storage, I discovered that switching banks to write each byte would corrupt  the bank switched out. It wouldn't be a problem to buffer the data in the static RAM, but I didn't see why it should be losing the data when switching for every byte.

While I analyzed the schematic, Giselle tried out the newly added RAM, quite happy at being able to type in and run some of the larger BASIC programs she had found in a book at the library.

I couldn't find the problem by just analysis.

*****

Tuesday, I dropped by Dr. Brown's office to ask if I could borrow a scope again to analyze the problem. He said I could.

That evening, after homework and before scriptures, I looked more carefully at the 6844 direct memory access controller. I wanted to see if there were some way to squeeze it into the Micro Chroma 68, to reduce the I/O burden on the CPU if I added a floppy disk controller. It was clear I'd have to perform an extensive bit of surgery on the Micro Chroma 68's printed circuit board in order to hook it in.

So I set that idea aside and started working out the EPROM programmer from the EPROM application notes. Realizing I needed more than the 5 volts that the simple power supplies Denny and I had built provided, I dug through the spec sheets and application notes that Denny had given me and looked at a switched mode power supply controller's application notes, trying to get an idea of what it would take to get one working.

Wednesday, with Dr. Brown and the classes observing, I determined that the 6821 was drawing more power than I was giving it when I switched the banks that fast, which took power away from the dRAMs. Adding decoupling capacitors on the memory board, and running an additional power and ground pair of wires to the RAM board solved the problem.

(The real me was satisfied with 32K of RAM that he was not thinking he would ever fully use, and never put a scope on the problem. He seems to have preferred to spend his time on painfully slow progress reading Tera he, and on daydreaming -- about CPUs, memory, peripherals, and code -- over generating actual code and hardware.

Daydreaming.

Speaking of which,  the timing on getting the real world Giselle involved with computers was much later, and involved a different CPU. And didn't get as good traction.

So it might have been power problems, or it might have been timing, or I may have gotten the strobe and the bank switch line tangled up somehow. Until I can un-mothball the old Micro Chroma 68 I built up in the real world, I have no way of knowing.)

At the library, I made a copy of the dRAM circuit diagram for Denny, with notes on the power requirements and the necessity of the decoupling capacitors.

When I got home, I called the IBM office, and the receptionist set me up with an appointment for the next week, instructing me to prepare something written about what I would like to accomplish during the internship. She didn't give me any clues about what kind of goals might be appropriate, said that was part of what they would be judging my application on.

With the RAM circuit settled, I added ROM sockets to the same perfboard, using more of the 6821's output bits and some logic to select the ROM socket to enable. Since the EPROMs I had were 4K, I wired the sockets to be addressed as 4K EPROMs.

While I was at it, I moved the BASIC ROM to the memory board so that it would be close to the circuitry I was using to switch ROMs in and out. 

I considered combining four exclusive-or gates on A14, A13, A12, and A11, with four bits of parallel port, to allow switching between the two banks of RAM 2 kilobytes at a time. It wouldn't allow moving the 2 KB segments around in the memory map like the 6829 would, but it would give me more flexibility in using what was there.

Ultimately, I decided I didn't know what I would be using it for, and adding the XOR gates to the addressing would be simple enough to do later, if I wanted.

*****

On Thursday, after I delivered the papers, Mom and I were in the kitchen together. I was waiting for some toast to pop up, cutting a slice of cheese, for a snack to fuel my work on the EPROM burner design. Mom was working on Dad's and her income tax records on the kitchen table.

Giselle snuck in through the living room, with a suspicious expression on her face and a squarish load in a plain brown paper grocery sack under her arm, and went straight to her room. She returned to the living room, sans load, and announced that she was not, under any circumstances, to be disturbed, then returned to her room and shut the door.

"What do you think is in the box in the bag?"

"Looks about the right size to be a Color Computer," I guessed, semi-randomly.

Mom nodded and went back to her bookkeeping.

Twenty minutes later, I was back in my room sketching out a tentative design and writing out a parts list, when Giselle came in looking frustrated.

"I need your help. But you have to promise not to tell Mom and Dad."

"Sure. I'm sure you'll tell them yourself anyway, and I'm sure whatever it is can wait until you do. But, just so you know, Mom and I already guessed it looked about the right size for a Color Computer."

"Well!" She stood, arms akimbo, angrily staring at me.

"It was just a guess. Giselle, we know you're not going to do anything bad, so you can take your time, and if we guessed right just pretend we didn't. Okay?"

She turned without answering and left. From the hall, she called. "Are you coming?"

"Coming."

Spread out on her bed were a Color Computer with only 4 KB RAM, manuals, a program pack cartridge, and a 64 K RAM upgrade kit. "It was on sale," she explained.

"You want me to install the RAM upgrade."

"I want you to make sure I turn it on right."

"Okay."

"Then install the upgrade."

I hid my grin and obliged, fetching my tools and my TV from my room. After letting her check that it turned on okay, I carefully removed the "NO USER SERVICEABLE PARTS INSIDE!" sticker over the middle screw in the base, without tearing it, and opened the case up. I may not have been a Tandy service technician, but I sure wasn't just an ordinary user.

Pretty soon we had the 64 K RAMs swapped in, the circuit board modified as necessary, and BASIC showing its welcome message once again on my TV screen. Giselle checked how much RAM she had:
PRINT MEM
24871
"That's not 64 K!"

"True. But that's what half of 64 K looks like after BASIC reserves the RAM it needs and the display RAM. The top half of the RAM shadows the ROMs and ports. To use the full 64 K, you'll need to copy the BASIC ROM into RAM, or you'll need to use OS-9. And you'll still be unable to access something like 8K of it, I think."

"OS-9 needs floppy disks."

"Yes, it does."

"So what do I do? I don't have any more savings I dare spend."

"Good question. But you can always use the RAM you do have for whatever you were going to do with it."

"I bought a word processing cart."

"Sounds good."

"I want to run a business typing. How do I print?"

"I don't know much about business, but you need a printer, and your own TV for display, too. I think it's time to consult with Mom and Dad."

She looked at me with a thoughtful face.

"Okay."

She went in to get Mom.

I watched for a few minutes while she and Mom used my TV and cassette recorder to get familiar with the new computer and word processing cart.

Her word processing cart used the Color Computer's highest density graphics to produce true lower case letters on the screen, and to make preview modes available, where you couldn't see the actual text, but you could see how the text would spread across the page.

Mom asked questions as Giselle tried things, and Giselle let Mom take her turn. Shortly, Giselle had the basics of the word processing cart mastered, and had typed in and saved some sample documents. I went back to my room to work some more on the power requirements of the EPROM burner. Shortly, Dad came home, and came into my room.

"Hi, son."

"Hey, Dad. What's up?"

"I need your help. Wheres our Mommy?"

"She and Giselle are ... in her bedroom discussing some things."

Dad ducked out of my room, and in a moment I heard him start chuckling quietly in the hallway. Then he came back in my room. "Looks like one of my questions is settled. Can you come give me a hand?"

"Give me a minute to complete my notes and I can."

"What're working on?"

"Need a different power supply than what Denny and I built, different voltages for all the stuff I want to hook up."

"Will you need it for a printer?"

"Depends on what kind of port the printer has. Are you thinking of buying a printer?"

"There was a, I think you called it a dot matrix printer on sale at Radio Shack."

"Oh."

I finished the line I was drawing and went with Dad to the living room.

"Three hundred on sale." Dad frowned. "If it won't work, I can take it back today."

I looked at the box and saw that it was one of the printers that had both a standard parallel interface and a serial interface specifically designed for the Color Computer and several other of Radio Shack's small computers.

"This will definitely work with Giselle's new tools."

"Well, that's good to know."

"I'll need to wire up a port for it, to use it with the Micro Chroma 68, but it should work okay with that, too."

"Then we'll keep it."

"If you think the family finances are up to it."

Three hundred dollars in 1981 was about twice what I brought in on a good month with the newspapers, or about what I make at a good job in electronics repair. It was more than Dad and Mom's monthly payments for the house loan, but that was because they took the loan out in the mid-1960s. A new house loan at the time would start about three hundred, as I recall.

 "We'll be okay."

"I upgraded Giselle's computer to 64 K, but she still needs a TV monitor and cassette recorder of her own before she can start using it for real."

"Ah. Yes. I should talk to your mother. He left my room and called through Giselle's open door. "Max? Can I have a word with you?"

Giselle started and turned around, and, leaning so I could see through the hallway, I could see the guilty look on her face.

I could see the muscles in the back of Dad's jaw pulled up in a grin. "Hi, Zed."

"Uh, hi, Dad?" She swallowed.

"Nice day for new tools, isn't it?"

"Uhh ..."

"What do you need, Ted? Giselle and I were exploring her word processor program."

"Won't take long." Dad nodded toward the living room with his head.

"Just a minute, Giselle."

I went back into my room, to allow Mom and Dad to consult in private. I didn't have time to remember what I was doing before Dad called me into Giselle's room to help hook the printer up.

Giselle's test documents printed nicely, and we were all pleased.

"But I understand you need a TV monitor and a cassette recorder of your own."

"Well, ... yeah. I do."

"If I bought them, would you mind sharing? Letting me work on my class handouts and tests when you aren't busy?"

Giselle's face lit up. "I could do that!"

So we went back to Radio Shack and picked out a TV and cassette recorder, checking the demo units to see that they worked well with the demo Color Computer.

Back home again, I called Denny.

"Now what?"

"Got the dynamic RAM working pretty cheap."

"Oh, yeah?"

"Used the VDG for the refresh counter."

"Heh. Send me the diagram?"

"Yeah. Tomorrow. I'm looking at the EPROM burner and other I/O, and we need power at more than just 5 volts. So I'm looking at building a switcher."

"Are you sure you want to do that? Why not just do a voltage doubler?"

"Voltage doubler, switch mode, similar stuff happening, .... Hadn't thought of that. Would be a bit less of a reach than a new power supply."

"Well, yeah. That's the point. Get this built so you can use it to help build your real computer."

I thought for a moment more. "I guess I'll look at it. So, what I'm really calling for, I'm thinking your surplus store is going to be the best place to get the EPROM eraser and a raw disk drive."

"You're wanting to come down for the three-day weekend ...?"

"Was thinking next week or the week after, actually."

"Why not jump on it now? Worried about tomorrow being the 13th?"

I ignored his joke. "Giselle has bought herself a Color Computer, and Dad and Mom have bought a TV monitor and cassette recorder for her and a printer for the family, and they're all going to be wanting help this weekend."

"She's what? No, no, she's supposed to wait until we've built our super-duper computers and use them!"

"Heh."

"Well, ..., okay, tell her I forgive her. This time. And to have fun with it."

"So, ..."

"So next week will be better for me than the week after. Date?"

"Date."

(As noted previously, this whole episode did not happen at all in the real world. I don't know if Giselle would have taken to the Color Computer as readily as this, if it had. Giselle got her first computer -- of a different type -- while I was on my six-year break from BYU, and Dad and Mom got their first computer after Chika and I moved to Japan. I also got my first printer during that six-year break. And left it behind for Giselle when we left.)

*****

Over Friday, Saturday, and Monday, I got voltage doubler circuits working for RS-232C and the EPROM, and I wired the fast cassette interface, a parallel printer port, and a couple of serial ports on one perfboard. The parallel and serial ports worked fine for the printer, with a cable adapter for the serial port. The fast cassette interface also seemed to work fine, but I wanted to take it in for tuning the next week.

I used the Micro Chroma 68's text editor and text processor to write up a résumé and a proposal for the internship, focusing on my experience in electronics to that point, my progress on the Micro Chroma 68, my interest in using Japanese on computers, and on my interest in how things were done at IBM, saved them on both slow cassette and fast, and printed it all out on the new printer. It was visibly dot matrix, but still quite legible.

And Dad and Giselle took turns on her computer, Dad getting some class handouts worked up, Giselle putting samples together for showing potential clients.

*****

I somehow made time to go to the Valentine's Day dance on Saturday and play softball with the church young adult group on Monday.

Neil's little sister, Niki, with encouragement from her brother by mail and promises of help from me and Br. Orange, was handling the sound for the dance. Br. Orange and I spelled her at the turntable so she could go dance, and she enjoyed it and decided she could start doing the sound regularly.

Of course, I danced three or four with her. You know, five years' age difference seems like a lot when you're twenty-one or sixteen.

There was a young woman named Brandy there who had come to earn college money working in the oilfield support for a year. She claimed a few dances with me and spent some time hanging out around the turntable when I was on it. Very interesting person, very strong personality. You had to have your wits ready when talking with her. But she was friendly and her looks were agreeable.

She came to play softball on Monday, too, and when she hit a homer with two on in the eleventh inning and our side won, I cheered with a "That's my woman!"

She politely but firmly informed me she was not my woman when she came in to home plate, and I filed that particular cheer away as one not to use without considering how the woman I was cheering might perceive my interests.

Maybe "That's our woman!" would have been better, but I somehow doubted it.

*****

"That's a computer?" Mike's face showed his doubt.

I had brought the Micro Chroma 68 to Tuesday's BASIC class, to pass off the previous week's assignment of an amortization table, and most of the students were gathered around where I had set it up before class started. It was showing the TVBUG monitor ROM prompt on the screen.

"No, it's a wooden box with a computer inside it," Pat rolled her eyes and shook her head. "Of course it's a computer."

I chuckled. "It's a work in progress, but, yeah, it does have a microcomputer in there."

"No operating system?" she asked.

"Not yet, not unless you can call a debugging monitor an operating system."

Don looked puzzled. "What's an operating system?"

Prof. Bright cleared his throat behind us. He had come in to get a look at the Micro Chroma 68.

Prof. Crane chuckled. "Don, do I need to put that question on the final?"

"No! Wait. Is it the thing where we log in on the Univac and then give it the command to run BASIC?"

"By me, I think he's got it," George intoned in a British accent cobbed from Monty Python or Dr. Who.

Prof. Bright nodded. "Very good, Don." He turned to me. "That's the boot ROM giving you some kind of prompt, right, Joe?" He was clearly prompting.

"Yeah. It's a debugging monitor, so it accepts debugger commands. I have Tiny BASIC in a ROM, there," I lifted the cover and pointed at the ROM, visible on the memory board. "So I can just give it the command to jump into the ROM at the right place, and it will boot BASIC." I demonstrated, as I had for my family, and the Tiny BASIC prompt came up. "Although, really, considering the amount of ROM in the thing, it's hard to call this little guy's startup process bootstrapping."

Prof. Crane tilted his head. "Why would you say that?"

"The monitor, tape interface, and the BASIC interpreter are all already resident in ROM, not read into RAM from tape or disk or some persistent storage device. There's no sense of the computer 'raising itself by its own bootstraps to a usable state'. All it is does is initialize some variables so code that's already there can run."

Prof. Bright nodded. "But initializing the variables is something it does for itself, right?"

"Well, I guess I can give you that."

"So," Prof. Crane asked, "can you fix it so it goes from the monitor to BASIC without typing that monitor command in?"

I had to think for a moment. "I don't recall seeing code where the monitor checks for a other ROMs to execute, but I couldn't swear it's not there. If not, it would take some hardware changes. There are a couple of diagrams, I think, for circuits to change the reset vector."

"Doesn't the reset process do some bootstrapping inside the CPU itself?"

"I'm sure it does, but Motorola hides that pretty well. It's a black box." I thought for a minute. "I am planning on getting floppy disks and purchasing or writing an operating system for this computer. When I do, I'll have to write drivers for the floppy disks, at least. Initializing the drivers before reading the OS from the floppy will make starting it up a bootstrap process."

"Something like this?" Prof. Bright draw a state transition diagram on the whiteboard:
reset -> monitor (operator call)-> driver init (automatic boot)-> OS
I nodded in agreement. "Something like that."

"So," Pat asked, "What OS are you thinking of? CPM? Unix? Unix is cool. It has pipes."

"Pipes sound cool. What do they do?"

"You can hook the output of one program into the input of another."

The conversation stopped for maybe a full half a minute while everyone looked for someone with clues.

"It sounds useful, but I'm not seeing how it would work," Don dared say it.

"Like when a compiler outputs an assembly language file, you don't have to store it in an actual file, just pipe the compiler output to the assembler."

"Oh-kay, if you say so." I shrugged. "I don't really know much about CPM or Unix, but I haven't seen either available for the 6800. I've been looking around, and it looks like the best suspect is an operating system called Flex."

"I've been using both at work. Unix comes with source code, and lots of people are implementing CPM from the specifications and documentation."

"Source code? What's the CPU?"

"The computers are PDP-11s, but the source code is in C."

I looked at Pat expectantly.

She didn't add anything.

"See what?"

 "C language. The programming language, 'C'."

The words I heard were "See language. The programming language, see?" But the intonation was not "see" as an imperative, but as a name. I had to process that.

"It's not in PDP-whatever assembly language? The name of the language is 'See'?"

"Right. 'C'. But some of it is in PDP-11 assembler."

More questions came to mind. "What is the PDP-11's CPU?"

"Uhm, PDP-11?"

The professors were listening to the exchange in amusement, but Prof. Bright took pity on me about the processor. "PDP-11 is a mini. I understand the 6800 register model and assembler are modeled after the PDP series somewhat."

"So a PDP series minicomputer processor." I nodded. And most of the operating system is written in a high level language called 'See'."

Prof. Crane took further pity on me and wrote the letter 'C' on the whiteboard. "'C', see?"

I chuckled at the joke. "Now I see."

Pat nodded and some of the other students laughed nervously.

"Ah, time to start today's lesson. Past time, even. Let's get our textbooks out." Prof. Crane asked if there were any questions, then started us discussing roots of equations in preparation for the Newton-Raphson project.

After class, he checked my program and the output. "You know, it would be easier to grade this if I had a printout of the source to look over after you take the computer home."

"Ah. Yeah. We bought a printer." I dug the two-page printout out of my backpack and handed it to him.

"Oh. Great. Thanks."

"So that's the famous sixty-eight thousand, huh?" Mike lifted his nose at my computer. "Doesn't seem too impressive to me."

Mike was among the several students who were still hanging around, interested in the computer and how I was using it.

"Well, it's not designed to be impressive, and it isn't the sixty-eight thousand. It's the sixty-eight hundred."

"What's the difference?"

"The 68000 is a sixteen-bit CPU with lots of 32 bit registers and addressing. This 6800 is an eight-bit CPU with just a few eight bit accumulators, one sixteen bit index, and sixteen bit addresses."

"Hmm? So? What's the difference? I'm unimpressed."

"Ignore him. He doesn't understand a bit." Pat was also waiting around, very interested in the computer.

Mike snorted, not sure exactly how he had been insulted.

"This is intended to be a small computer." I tilted my head. "It's for learning in small bytes at a time."

Pat and a couple of other students snickered. Prof. Crane groaned. Mike looked at me like he was waiting for the follow-through punch, but I was leaving bad enough alone.

"So," Pat asked, "are you going to put C on it?"

"I haven't seen any advertisements for a C compiler for this. Pascal, yes. C, no."

"Oh." She seemed disappointed. "I guess you're not interested in writing a compiler yourself?"

"I've seen those railroad track syntax diagrams for Pascal, but I haven't even seen a programmers manual for this C language. And I guess I need something fairly easy to start on, to bootstrap my understanding of how to write such things."

Prof. Bright had just come back in, and was listening. "Do you think you might like to write a compiler?"

I thought about that. "Sure. Maybe. But it has to be something that doesn't require tools I don't have."

He and Prof. Crane exchanged glances.

"What would you suggest, Rusty?"

"Languages built on list processing can be easier to bootstrap when you don't have tools. LISP has a bit of a steep learning curve. Snobol was fun, but I have no idea how to get information on it any more. Forth is a bit easier, and there's the fig -- the Forth Interest Group -- giving information out for the cost of copying it."

"Ah, Forth. That's stacks and RPN. You were saying you like Hewlett Packard calculators, weren't you, Joe?"

I had said such a thing, and my interest was piqued.

On the way home, I dropped by the library to see if I could find information on Forth or the Forth Interest Group, and again I found an ad, this one in Dr. Dobb's Journal, from Mountain View Press. Again I took a copy of the ad home with me.

At home, I delivered the newspapers first, because Mountain View Press was in California and I could call after six o'clock local time and get cheaper phone rates. I got the information I needed from the call, and wrote out an order and a check for hardcopy of the 6800 model source code and the installation manual, and for a copy of the source code on cassette tape in Kansas City format. I did not want to spend time typing the source in by hand.

(The real me only got the hard copy, had to hand-assemble a lot of code, and type in machine code by hand. Learned a bit by osmosis in doing so, but it was not efficient use of time.)

That done, I spent a couple of hours disassembling the assembler's object code and exploring it for ideas. Also played with the timer. Out of curiosity, I worked out the distance light could travel in the shortest tick of the timer clock, four CPU cycles. If my memory serves me, it was something on the order of the length of a football field.

(Checking the math now, either the length was three football fields or the timer could count on the crystal clock and it was around three quarters of a football field. My memory doesn't give me enough information to say which, without the manuals.)

Chapter 9: Interviewing IBM

[Backed up at https://joel-rees-economics.blogspot.com/2020/02/bk-33209-bootstrapping-or-baby-steps.html.]

33209: A little about the 6800 (and Others) (note on MDP 1000 while Google fixes the blogger editors)

Chapter 7: Wandering Eyes

Chapter 7.5: A Little about the 6800 (and Others)


This chapter is for the geek in you. It's also important background information, to motivate the directions taken by various people in the story.

The 6800 had the primary binary operators that could be implemented for its two accumulators (A and B) in integrated circuits of the early 1970s:

  • Addition (ADD) and subtraction (SUB)
  • ADD and SUB taking previous carries into account (ADC and SBC)
  • Compare (CMP -- subtract without storing the result, only setting condition code flags.)
  • Data movement (LDA and STA -- load and store accumulator)
  • Bit logic: AND, OR, and XOR (exclusive-or)
  • Bit test (BIT -- bit AND without storing the result, only setting condition code flags.) 
  • Compare index register (CPX -- the index as one operand instead of an accumulator)
  • Load and store index and stack register (LDX, STX, LDS, STS -- also one operand index or stack pointer instead of accumulators)

*(Reserved, undefined); **6801 only; ***CPX has full flags on 6801
6800/6801
Binary
Operators
Ranks 8-B
Accumulator A,  D, X, or SP
ImmediateDirectIndexedAbsolute
$8X$9X$AX$BX
1000XXXX1001XXXX1010XXXX1011XXXX
SUBA10XX0000$80$90$A0$B0
CMPA10XX0001$81$91$A1$B1
SBCA10XX0010$82$92$A2$B2
**SUBD10XX0011**$83**$93**$A3**$B3
ANDA10XX0100$84$94$A4$B4
BITA10XX0101$85$95$A5$B5
LDAA10XX0110$86$96$A6$B6
STAA10XX0111*($87)$97$A7$B7
EORA10XX1000$88$98$A8$B8
ADCA10XX1001$89$99$A9$B9
ORAA10XX1010$8A$9A$AA $BA
ADDA10XX1011$8B$9B$AB$BB
***CPX10XX1100$8C$9C$AC$BC
JSR10XX1101**BSR=$8D**$9D$AD$BD
LDS10XX1110$8E$9E$AE$BE
STS10XX1111*($8F)$9F$AF$BF

*(Reserved, undefined); **6801 only
6800/6801
Binary
Operators
Ranks C-F
Accumulator A,  D, X
ImmediateDirectIndexedAbsolute
$CX$DX$EX$FX
1100XXXX1101XXXX1110XXXX1111XXXX
SUBB11XX0000$C0$D0$E0$F0
CMPB11XX0001$C1$D1$E1$F1
SBCB11XX0010$C2$D2$E2$F2
**ADDD11XX0011**$C3**$D3**$E3**$F3
ANDB11XX0100$C4$D4$E4$F4
BITB11XX0101$C5$D5$E5$F5
LDAB11XX0110$C6$D6$E6$F6
STAB11XX0111*($C7)$D7$E7$F7
EORB11XX1000$C8$D8$E8$F8
ADCB11XX1001$C9$D9$E9$F9
ORAB 11XX1010$CA$DA$EA $FA
ADDB11XX1011$CB$DB$EB$FB
**LDD11XX1100**$CC**$DC**$EC**$FC
**STD11XX1101*($CD)**$DD**$ED**$FD
LDX11XX1110$CE$DE$EE$FE
STX11XX1111*($CF)$DF$EF$FF

The 6800 also had several unary operators. (Unary operators are binary operators with one of the operands implicit):

  • Increment and decrement (INC, DEC -- add and subtract 1)
  • shift and rotate left and right 1:
    • "Arithmetic" Shift Left (ASL -- equivalent to adding operand to itself. Ignores sign, or, in other words, the previous sign disappears.)
    • "Arithmetic" and "Logical" Shift Right (ASR  and LSR -- equivalent to dividing by 2. ASR preserves the high bit as a sign bit, LSR clears the high bit.)
    • Bit rotate left and right (ROL, ROR --  shifts, but the previous carry bit gets shifted in to replace the vacated bit.)
    All shifts and rotates save the bit shifted out in the carry bit, so the rotates are nine-bit rotations.
    Note that shifting n times is multiplying or dividing by 2n.
  • Clear (CLR -- load or store 0)
  • Bit Complement (COM: invert the bits, equivalent to subtracting the operand from 255 or bit XOR-ing with $FF. $FF == 255, or eight bits set to 1s.)
  • Negate (NEG: subtract the operand from 256. 256 == $100, one more than fits in eight bits. Equivalently, complement and add 1 would do the same, even though 256 is too big for eight bits.)
  • Value test (TST -- subtract zero from operand. Tells the program whether the operand is zero or negative, without altering the operand.)

*(Reserved, undefined)
6800/6801
Unary
Operators
Ranks 4-7
AccumulatorMemory
ABIndexedAbsolute
$4X$5X$6X$7X
0100XXXX0101XXXX0110XXXX0111XXXX
NEG01XX0000$40$50$60$70
---01XX0001*($41)*($51)*($61)*($71)
---01XX0010*($42)*($52)*($62)*($72)
COM01XX0011$43$53$63$73
LSR01XX0100$44$54$64$74
---01XX0101*($45)*($55)*($65)*($75)
ROR01XX0110$46$56$66$76
ASR01XX0111$47$57$67$77
ASL01XX1000$48$58$68$78
ROL01XX1001$49$59$69$79
DEC01XX1010$4A$5A$6A $7A
---01XX1011*($4B)*($5B)*($6B)*($7B)
INC01XX1100$4C$5C$6C$7C
TST01XX1101$4D$5D$6D$7D
JMP01XX1110*($4E)*($5E)$6E$7E
CLR01XX1111$4F$5F$6F$7F

Of the unary operators, the right shifts and the bit rotates are the only operators that can't be synthesized easily from one or more binary operators.

(Can't be synthesized easily. Nine-bit rotates can be synthesized from shifts by saving the carry bit, shifting the argument, then moving the carry bit in. And right shifts are synthesized by left rotates followed by setting the upper bits appropriately. Right shifts are probably the most especially useful of unary operators.)

However, all the 6800 unary operators can operate directly on memory, which can save a lot of code that would otherwise have to save the accumulator, do the math, and then restore the accumulator.

Hopefully, you are wondering how the operands are specified. This is the strength of the 6800, what sets it apart from the 8080. But it is also one of the places the engineers missed a bet.

Each of the binary operators (or instructions) has a version for each accumulator.  The other operand, and the single operand for unary operators, is specified as

  • the value of a byte of memory at an absolute sixteen-bit address ("Extended", or absolute mode)
  • the value of the byte of memory immediately  following the instruction (immediate mode, marked by '#')
  • or the value pointed at by the index register offset by the value of the byte following the instruction (indexed mode, marked by ',X')
  • ... or the value at one of the first 256 locations in memory ("Direct", or page 0 absolute mode, optionally marked by '<').
The direct mode saves a byte, and the time of a memory cycle, somewhat softening the cost of saving registers to memory and then restoring them.

A quick example:

DSAVE EQU $70 ; Variable locations in memory
ACCM32 EQU $72 ; (Not normal way to declare.)
PSP EQU $76
*
ADD32 LDX PSP ; parameter stack
* Note: LDX <PSP also works
    STD DSAVE
    LDD 2,X ; 1st addend low word
    ADDD 6,X ; 2nd addend low word    STD ACCM32+2 ; save intermediate
    LDD ,X ; 1st addend high word
* Note: LDD 0,X also works
    ADCB 5,X ; 2nd addend high word
    ADCA 4,X ; the rest of it
    INX ; deallocate 1st addend location
    INX ; Increment X four times.
    INX ; See inherent operators below.
    INX
    STD ,X ; reuse 2nd addend location
    LDD ACCM32+2
    STD 2,X
    STX PSP ; update parameter stack
    RTS ; go home
*
* Note: Call it like this:
    JSR ADD32 ; probably a 16 bit Extended mode address

***** Kibbitzing aside: *****

Unfortunately, while the unary operators/instructions have both the indexed and extended mode versions -- operating directly on memory, and a version for each accumulator, there is not a direct mode version. Perhaps the designers thought they were running out of space in the 8-bit op-code map.

Kibitzing is free and you can always say things shoulda-been, and there is always the problem of hypothesis contrary to fact when you do, but I think if I had been on the design team I'd have agitated for moving the inherent operators which I mention below out of one of the lower four ranks, to clear space for a direct mode version.

This is not a serious problem in any of the existing implementations of the 6800 that I know of, because, other than saving an operation cycle and a byte of code, direct is exactly the same in effect as extended with the high byte of the address equal to zero.

But if there were a direct mode version of the unary operators, the intent that the direct page be used to overcome the scarcity of registers would have been more clear, and much of the false information that circulated about the limits of the 6800 instruction set could have been avoided.

Also, thinking about extensions of the 6800 architecture that have never been implemented, if you wanted to put the direct page in its own address space, the lack of direct address mode unary op-codes would be a problem, which is something to keep in mind.

***** End kibbitzing aside. *****

In addition, there are several instructions that are called "inherent" mode, where the operands are all implicit in the instruction. These include
  • manipulating result flag bits (TPA, TAP -- transfer Processor flags to/from A accumulator -- carry, zero, minus, overflow, interrupts)
  • incrementing and decrementing the index and stack pointers (INX, DEX, INS, DES)
  • moving and adding/subtracting between accumulators (ABA, SBA, TBA TAB)
  • pushing and popping the accumulators to/from the stack (PSH, PUL. Note that the "pop from stack" operator in Motorola mnemonics is "PUL".)
  • moving the stack pointer to/from the index register to get at parameters (TSX, TXS)
  • returning from subroutines and interrupts (RTS, RTI)
  • waiting for interrupts (WAI)
  • Software interrupt (SWI -- useful for debugging and/or system calls)
Then there are the flow of control instructions which operate on the program counter (PC -- called instruction pointer or IP in many other CPUs):
  • Jump and call/jump-to-subroutine (JMP and JSR -- only indexed and extended modes.)
  • Near branch and call (BRA, BSR -- one byte of signed offset is added to program counter.)
  • Conditional branches (Bcc -- condition encoded in the instruction.):
    • BEQ, BNE (zero bit -- equal or not equal after subtract or compare.)
    • BPL, BMI (negative bit -- plus or minus.)
    • BCC, BCS (carry bit -- clear or set, complemented in unsigned compare in BHI and BLS.)
    • BHI, BLS (combination carry and zero for unsigned comparison, high and low-or-same.)
    • BVC, BVS (overflow bit -- used in signed comparisons.)
    • BGT, BGE, BLE, BLT (combination overflow, zero, and negative bits for signed compares -- greater than, greater than or equal, less than or equal, less than)

*(Reserved, undefined; **6801 only)
6800/6801
Inherent
Operators
Ranks 0-3

Status, XAccumulatorBranchStack, et. al.
$0X$1X$2X$3X
0000XXXX0001XXXX0010XXXX0011XXXX
$X000XX0000*(HCF=$00)SBA=$10BRA=$20TSX=$30
$X100XX0001NOP=$01CBA=$11**BRN=$21INS=$31
$X200XX0010*($02)*($12)BHI=$22PULA=$32
$X300XX0011*($03)*($13)BLS=$23PULB=$33
$X400XX0100**LSRD=$04*($14)BCC=$24DES=$34
$X500XX0101**ASLD=$05*($15)BCS=$25TXS=$35
$X600XX0110TAP=$06TAB=$16BNE=$26PSHA=$36
$X700XX0111TPA=$07TBA=$17BEQ=$27PSHB=$37
$X800XX1000INX=$08*($18)BVC=$28**PULX=$38
$X900XX1001DEX=$09DAA=$19BVS=$29RTS=$39
$XA00XX1010CLV=$0A*($1A)BPL=$2A **ABX=$3A
$XB00XX1011SEV=$0BABA=$1BBMI=$2BRTI=$3B
$XC00XX1100CLC=$0C*($1C)BGE=$2C**PSHX=$3C
$XD00XX1101SEC=$0D*($1D)BLT=$2D**MUL=$3D
$XE00XX1110CLI=$0E*($1E)BGT=$2EWAI=$3E
$XF00XX1111SEI=$0F*($1F)BLE=$2FSWI=$3F

I think that pretty much covers the instruction set of the 6800, so I'll offer the following unbalanced summary chart:

*6801 only, **varies from 6800
6800/6801
Op-codes
Outline
Ranks
InhBRccInhUnaryBinary
A/B
$0X$1X$2X$3X$4X-$7X$8X-$FX
0000:0001:0010:0011:01MM:1AMM:
$R0:0000(HCF)SBABRATSXNEGSUB
$R1:0001NOPCBA*BRNINS$R1CMP
$R2:0010$02$12BHIPULA$R2SRC
$R3:0011$03$13BLSPULBCOM*SUBD
*ADDD
$R4:0100*LSRD$14BCCDESLSRAND
$R5:0101*ASLD$15BCSTXS$R5BIT
$R6:0110TAPTABBNEPSHARORLDA
$R7:0111TPATBABEQPSHBASRSTA
$R8:1000INX$18BVC*PULXASLEOR
$R9:1001DEXDAABVSRTSROLADC
$RA:1010CLV$1ABPL*ABXDECORA
$RB:1011SEVABABMIRTI$RBADD
$RC:1100CLC$1CBGE*PSHXINC**CPX
*LDD
$RD:1101SEC$1DBLT*MULTST*BSR/**JSR
*STD
$RE:1110CLI$1EBGTWAIJMPLDS
LDX
$RF:1111SEI$1FBLESWICLRSTS
STX

All of this is done with relatively few transistors, about 4000 to 5000 gates, less than ten thousand individual transistors, making it possible to manufacture the part using the technology available in the early- to mid-1970s.

In the process of building these, however, they developed new technology that enabled building more complex CPUs that could multiply and divide and such without having to add and subtract repeatedly.

When you design a computer's central processing unit, you may not realize it, but you use a mathematical technique of reducing the abstract general computing machine to real hardware.

Each CPU design reflects the what the engineers were focusing on when they performed the reduction.

RISC, "Reduced Instruction Set Computer", is therefore something of a pun, overloading the word "reduced" in a somewhat confusing way. The mathematical reduction in RISC architecture is performed with a focus on simplifying the instruction set -- reducing the number of instructions. (Didn't I say engineers love puns?)

When the 4004 was designed, the focus was on the functionality of a single accumulator in an absolute, incomplete reduction of the general computing model. It had to be that way, to fit a functional calculator controller into the available space on an integrated circuit using the technologies available and techniques understood at the beginning of the seventies. The 8080 inherited that focus, through the 8008, adding separate index functionality in the form of index registers.

Intel's engineers were aware of the importance of indexing, so they designed it in a way that a base index address could be saved in one pair of eight bit registers, to be copied to the index register pair where offsets could be added as necessary. Each register had a purpose, and you moved data to the necessary register to operate on it.

According to one story I've heard, Motorola's engineers started with an eight-bit implementation (reduction) of a minicomputer that they had built for their internal use, internally called the 680. Also, the dual accumulator model is thought to be derived from their MDP 1000 minicomputer from the previous decade. According to yet another story, the 6800 was a reduction of the PDP-11 architecture. Either way, they focused on a pair of general-purpose accumulators, adding a full-address-width  index register used in an addressing mode that performed explicit offsets.

Lack of generalization in the 8080 was a bottleneck, and the Z-80 was developed as an extension to the 8080, to get around that lack. The Z-80 was the source of the "80" in Tandy Radio Shack TRS-80 brand name (making the TRS-80 Color Computer a bit ironically named).

The 6800's generalizations also had some lacks. Having only one index register can be clumsy. Constant offsets are not the only math you want to do on index addresses. And math between the two accumulators was severely limited, with no direct math between accumulator and index.

The 6502 was developed in no small part as a response to those lacks. It allows variables in page zero (6502 equivalent of the 6800 direct page) to be used directly as pointers, which helps it keep in the same ballpark, performance-wise, as the Z-80, and gives it advantages over the 8080.

Motorola developed the 6801 to address the worst of the lacks in the 6800 while keeping the transistor count low, to save room for other functions in systems-on-a-chip (SOC) applications.

  • The 6801 adds instructions which pair the A and B accumulators, A as the high byte, to load, store, add, subtract, and shift sixteen bit values. This significantly simplifies manipulating pointers.
  • It also adds an instruction to directly add the B accumulator to the index register, directly supporting small variable offsets.
  • CPX, the comparison for the index register, is generalized in effect on the flags. Again, this improves index handling.
  • It adds a hardware multiply instruction, 8 bit by 8 bit, yielding sixteen bits, useful for many things, including speeding array index math and a sixteen bit multiply more than four times as fast as the 6800 multiplying one bit at a time.
  • It adds a JSR call into the direct page, which might seem odd, but it makes it less costly to implement a small number of short convenience subroutines.
  • It adds Pushing and PUL-ing (popping) the index register, which corrects what seems like an odd omission in the 6800.)
  • It adds an officially documented BRN "branch never" bookend to branch always. This was actually an undocumented operator in the 6800, but the 6801 makes it official, allowing its use as a No-op that balances branch instructions, which can be useful for timing and as a debugging marker.   
These improvements bring the 6801 up to the same class of performance as the 6502 and the Z-80 -- in overall performance, an engineer skilled in programming the 6502, Z-80, and 6801 could get similar performance from each in many general applications, although each had niches they were better for. The companies that produced them also produced a variety of special purpose microcontrollers based on or similar to them, for specific classes of applications, as the market moved forward in the 1980s.

*****

That's too much tech for one chapter, but I'll add a little more arithmetic, for background.

The smallest bit of information in a binary computer is called a "bit". You may think this is a pun, and it is, but it is also an acronym: "Binary digIT".
A bit can take two values, but the values can be interpreted in many ways, for example:

Values of a Bit
Values:OnOff
Numeric:10
Logic:TrueFalse
Sign:MinusPlus
Gender:Non-traditionalTraditional

are some possible ways of interpreting the values of a bit. Note, in particular, that the actual assignments are arbitrary. "On" could also be interpreted as "plus", for instance.

Two bits together can take four values. Some example interpretations might be

Values of Two Bits Strung Together
Values:On-OnOn-OffOff-OnOff-Off
Unsigned Numeric:3210
Signed Numeric:-1-210
Logic:TrueTheoreticalFantasyFalse
Sign:Plus-RealPlus-ImaginaryMinus-RealMinus-Imaginary
Vegetable:PotatoOnionCabbageCarrot

The fundamental size of a piece of information for a computer has been traditionally called a "byte".  Yes, this is a pun, pure and simple.

It's also good advice:

Work on a problem a byte at a time!

(Sorry. Don't know what gets into me.)

Most modern computers use an eight bit byte, which allows 28, or 256 possible values. (And most modern computers usually actually work on problems four or eight bytes at a time.)

Numeric interpretations quickly spring to mind, such as 0 (00000000) to 255 (11111111), or -128 (10000000) to 127 (01111111). Other interpretations are not just possible, but are quite often used. For example, one might imagine an encoding in which male, female, and 254 other genders are encoded in an eight-bit byte. Or a byte could show the state of eight on-off switches on the control panel of some machine.

More typical is the US ASCII encoding, which actually only uses seven bits. Uppercase 'A', for instance, is encoded as decimal 65, and lowercase 'z' as decimal 122. '0' through '9' are decimal 48 through 57, which may seem confusing until you consider carefully the difference between numerals and numbers, or between the names of numbers and the value of numbers. The period, '.', is decimal 46.

(Unicode uses more bits, but it's a messy topic that would suck all the steam out of the story to cover here.)

So we can use numbers as codes for letters and words and symbols, and all sorts of ideas, which means we can also store and work symbolically on text and many kinds of data.

And we can use numbers to specify the color of a dot on a screen or a piece of paper, so we can also store pictures.

This provides us with ways to store and manipulate pretty much any information we could want. Sort of.

Interpretations are arbitrary. The binary number

01101101011000010110100101101100
could easily be read as binary equivalent of the decimal number
1,835,100,524
But If you put the most significant byte last, as Intel has been influencing the world more and more to do, it would be  
swap order: 01101100 01101001 01101101 01100001
compress:  01101100011010010110110101100001
decimal: 1,818,848,609
Or it could be the text string
mail
Of if the Intel byte order played tricks on you, it could be
liam
Or it could be interpreted as a floating point number under several different standards. Depending on the standard, it could be very large or very small.

Even as integers unsullied by byte order issues, the numbers have limits.

As mentioned before, a byte in a 6800 or 6502 or about any microprocessor you'll see is eight bits. (In some other computer CPUs, especially older mainframes, a byte will be a different size -- nine, six, seven, twelve, etc.)

Again, as mentioned before, an 8-bit register or memory cell can store a number between 0 and 255, inclusive. That's not a lot, but you can string several together. Two 8-bit registers treated together can store a number between 0 and 65,535, inclusive.

Unsigned Integer Sizes vs. Bit Length
SizebitsMinimumMaximumas Power of 2
1 bit1 bit0121-1
2 bits2 bits0322-1
1 nibble4 bits01524-1
1 byte8 bits025528-1
2 bytes16 bits065,535216-1
4 bytes32 bits04,294,967,295232-1
8 bytes64 bits018,446,744,073,709,551,615264-1

(Nibble is also sometimes spelled "nybble".)

The same numbers can be read as signed numbers, in various ways. Two's complement is currently the most common method:

Signed Integers vs. Bit Length (Two's Complement)
SizebitsMinimumMaximumas Power of 2
1 bit1 bitplusminus--
2 bits2 bits-21-21 ~ 21-1
1 nibble4 bits-87-23 ~ 23-1
1 byte8 bits-128127-27 ~ 27-1
2 bytes16 bits-3276832767-215 ~ 215-1
4 bytes32 bits-2,147,483,6482,147,483,647-231 ~ 231-1
8 bytes64 bits-9,223,372,036,854,775,8089,223,372,036,854,775,807-263 ~ 263-1

It's tempting to show some limits for the current most common standard floating point numbers, but this really is probably enough tech for this chapter.

*****

Well, wait. I need to mention the 6809.

Some people think the 68000 was Motorola's answer to Intel's 8086.

That isn't really a good comparison, and it isn't accurate.

The 68000 was Motorola's answer to the ARM, almost ten years too early. Or it was Motorola's answer to AMD's x86-64, about twenty years too early and 32 bits short. More to the point, it was Motorola's answer to Intel's iAPX 432, which was another architecture that was a lot too much, too far ahead of its time.

That the 68000 was successful so far ahead of its time is something to think about, but I want to point to what was actually Motorola's answer to the 8086: the 6809. (Perhaps it would be more clear if I said it was the answer to the 8088.)

The 6809 is often mistaken for a stepping stone between the 6800 and the 68000. But they were developed simultaneously, with different but similar design goals.

The 6801, by the way, is thought to have been influenced by the design work on the 6809.

The 6809 was targeted more towards extending the 6800's reach into the sixteen-bit controller market, which it did quite well.

For various reasons (including the ever-mistaken "Must not compete with ourselves!" mantra), Motorola's SOC offerings split between the true-8-bit 6805 series and the half-16-bit 6801 series for half a decade, then moved ahead building on the 6801 instead of the 6809.

Although some see the 68HC11 as a stripped-down 6809, the indexed modes tells the tale. The 68HC11 is simply a 6801 with an additional index register and hardware divide, and appropriate instruction extensions. The 68HC12 and 68HC16 continued building on the 6801, neither fully offering the advanced programming model that the 6809 offered, although the 68HC16 offered a twenty bit address space and three index registers, with an indexable stack.

This advanced programming model could almost be achieved in the 8086, but Intel designed that for the mis-engineered stack frame approach to nested local context. BP and SP are in the same segment unless overridden. (We won't yet mention the half-baked nature of the segments up until the 80386, since everyone knows about that.)

The 68000 could be used to implement the model, but no one did because Intel was busy pushing stack frames. And IBM, ...

But that gets way ahead of my story.


[Backed up at https://joel-rees-economics.blogspot.com/2020/02/bk-33209-little-about-6800-and-others.html.]

33209: A little about the 6800 (and Others)

Chapter 7: Wandering Eyes

Chapter 7.5: A Little about the 6800 (and Others)


This chapter is for the geek in you. It's also important background information, to motivate the directions taken by various people in the story.

The 6800 had the primary binary operators that could be implemented for its two accumulators (A and B) in integrated circuits of the early 1970s:
  • Addition (ADD) and subtraction (SUB)
  • ADD and SUB taking previous carries into account (ADC and SBC)
  • Compare (CMP -- subtract without storing the result, only setting condition code flags.)
  • Data movement (LDA and STA -- load and store accumulator)
  • Bit logic: AND, OR, and XOR (exclusive-or)
  • Bit test (BIT -- bit AND without storing the result, only setting condition code flags.) 
  • Compare index register (CPX -- the index as one operand instead of an accumulator)
  • Load and store index and stack register (LDX, STX, LDS, STS -- also one operand index or stack pointer instead of accumulators)

*(Reserved, undefined); **6801 only; ***CPX has full flags on 6801
6800/6801
Binary
Operators
Ranks 8-B
Accumulator A,  D, X, or SP
ImmediateDirectIndexedAbsolute
$8X$9X$AX$BX
1000XXXX1001XXXX1010XXXX1011XXXX
SUBA10XX0000$80$90$A0$B0
CMPA10XX0001$81$91$A1$B1
SBCA10XX0010$82$92$A2$B2
**SUBD10XX0011**$83**$93**$A3**$B3
ANDA10XX0100$84$94$A4$B4
BITA10XX0101$85$95$A5$B5
LDAA10XX0110$86$96$A6$B6
STAA10XX0111*($87)$97$A7$B7
EORA10XX1000$88$98$A8$B8
ADCA10XX1001$89$99$A9$B9
ORAA10XX1010$8A$9A$AA $BA
ADDA10XX1011$8B$9B$AB$BB
***CPX10XX1100$8C$9C$AC$BC
JSR10XX1101**BSR=$8D**$9D$AD$BD
LDS10XX1110$8E$9E$AE$BE
STS10XX1111*($8F)$9F$AF$BF

*(Reserved, undefined); **6801 only
6800/6801
Binary
Operators
Ranks C-F
Accumulator A,  D, X
ImmediateDirectIndexedAbsolute
$CX$DX$EX$FX
1100XXXX1101XXXX1110XXXX1111XXXX
SUBB11XX0000$C0$D0$E0$F0
CMPB11XX0001$C1$D1$E1$F1
SBCB11XX0010$C2$D2$E2$F2
**ADDD11XX0011**$C3**$D3**$E3**$F3
ANDB11XX0100$C4$D4$E4$F4
BITB11XX0101$C5$D5$E5$F5
LDAB11XX0110$C6$D6$E6$F6
STAB11XX0111*($C7)$D7$E7$F7
EORB11XX1000$C8$D8$E8$F8
ADCB11XX1001$C9$D9$E9$F9
ORAB 11XX1010$CA$DA$EA $FA
ADDB11XX1011$CB$DB$EB$FB
**LDD11XX1100**$CC**$DC**$EC**$FC
**STD11XX1101*($CD)**$DD**$ED**$FD
LDX11XX1110$CE$DE$EE$FE
STX11XX1111*($CF)$DF$EF$FF


The 6800 also had several unary operators. (Unary operators are binary operators with one of the operands implicit):
  • Increment and decrement (INC, DEC -- add and subtract 1)
  • shift and rotate left and right 1:
    • "Arithmetic" Shift Left (ASL -- equivalent to adding operand to itself. Ignores sign, or, in other words, the previous sign disappears.)
    • "Arithmetic" and "Logical" Shift Right (ASR  and LSR -- equivalent to dividing by 2. ASR preserves the high bit as a sign bit, LSR clears the high bit.)
    • Bit rotate left and right (ROL, ROR --  shifts, but the previous carry bit gets shifted in to replace the vacated bit.)
    All shifts and rotates save the bit shifted out in the carry bit, so the rotates are nine-bit rotations.
    Note that shifting n times is multiplying or dividing by 2n.
  • Clear (CLR -- load or store 0)
  • Bit Complement (COM: invert the bits, equivalent to subtracting the operand from 255 or bit XOR-ing with $FF. $FF == 255, or eight bits set to 1s.)
  • Negate (NEG: subtract the operand from 256. 256 == $100, one more than fits in eight bits. Equivalently, complement and add 1 would do the same, even though 256 is too big for eight bits.)
  • Value test (TST -- subtract zero from operand. Tells the program whether the operand is zero or negative, without altering the operand.)

*(Reserved, undefined)
6800/6801
Unary
Operators
Ranks 4-7
AccumulatorMemory
ABIndexedAbsolute
$4X$5X$6X$7X
0100XXXX0101XXXX0110XXXX0111XXXX
NEG01XX0000$40$50$60$70
---01XX0001*($41)*($51)*($61)*($71)
---01XX0010*($42)*($52)*($62)*($72)
COM01XX0011$43$53$63$73
LSR01XX0100$44$54$64$74
---01XX0101*($45)*($55)*($65)*($75)
ROR01XX0110$46$56$66$76
ASR01XX0111$47$57$67$77
ASL01XX1000$48$58$68$78
ROL01XX1001$49$59$69$79
DEC01XX1010$4A$5A$6A $7A
---01XX1011*($4B)*($5B)*($6B)*($7B)
INC01XX1100$4C$5C$6C$7C
TST01XX1101$4D$5D$6D$7D
JMP01XX1110*($4E)*($5E)$6E$7E
CLR01XX1111$4F$5F$6F$7F


Of the unary operators, the right shifts and the bit rotates are the only operators that can't be synthesized easily from one or more binary operators.

(Can't be synthesized easily. Nine-bit rotates can be synthesized from shifts by saving the carry bit, shifting the argument, then moving the carry bit in. And right shifts are synthesized by left rotates followed by setting the upper bits appropriately. Right shifts are probably the most especially useful of unary operators.)

However, all the 6800 unary operators can operate directly on memory, which can save a lot of code that would otherwise have to save the accumulator, do the math, and then restore the accumulator.

Hopefully, you are wondering how the operands are specified. This is the strength of the 6800, what sets it apart from the 8080. But it is also one of the places the engineers missed a bet.

Each of the binary operators (or instructions) has a version for each accumulator.  The other operand, and the single operand for unary operators, is specified as
  • the value of a byte of memory at an absolute sixteen-bit address ("Extended", or absolute mode)
  • the value of the byte of memory immediately  following the instruction (immediate mode, marked by '#')
  • or the value pointed at by the index register offset by the value of the byte following the instruction (indexed mode, marked by ',X')
  • ... or the value at one of the first 256 locations in memory ("Direct", or page 0 absolute mode, optionally marked by '<').
The direct mode saves a byte, and the time of a memory cycle, somewhat softening the cost of saving registers to memory and then restoring them.

A quick example:
DSAVE EQU $70 ; Variable locations in memory
ACCM32 EQU $72 ; (Not normal way to declare.)
PSP EQU $76
*
ADD32 LDX PSP ; parameter stack
* Note: LDX <PSP also works
    STD DSAVE
    LDD 2,X ; 1st addend low word
    ADDD 6,X ; 2nd addend low word    STD ACCM32+2 ; save intermediate
    LDD ,X ; 1st addend high word
* Note: LDD 0,X also works
    ADCB 5,X ; 2nd addend high word
    ADCA 4,X ; the rest of it
    INX ; deallocate 1st addend location
    INX ; Increment X four times.
    INX ; See inherent operators below.
    INX
    STD ,X ; reuse 2nd addend location
    LDD ACCM32+2
    STD 2,X
    STX PSP ; update parameter stack
    RTS ; go home
*
* Note: Call it like this:
    JSR ADD32 ; probably a 16 bit Extended mode address

***** Kibbitzing aside: *****

Unfortunately, while the unary operators/instructions have both the indexed and extended mode versions -- operating directly on memory, and a version for each accumulator, there is not a direct mode version. Perhaps the designers thought they were running out of space in the 8-bit op-code map.

Kibitzing is free and you can always say things shoulda-been, and there is always the problem of hypothesis contrary to fact when you do, but I think if I had been on the design team I'd have agitated for moving the inherent operators which I mention below out of one of the lower four ranks, to clear space for a direct mode version.

This is not a serious problem in any of the existing implementations of the 6800 that I know of, because, other than saving an operation cycle and a byte of code, direct is exactly the same in effect as extended with the high byte of the address equal to zero.

But if there were a direct mode version of the unary operators, the intent that the direct page be used to overcome the scarcity of registers would have been more clear, and much of the false information that circulated about the limits of the 6800 instruction set could have been avoided.

Also, thinking about extensions of the 6800 architecture that have never been implemented, if you wanted to put the direct page in its own address space, the lack of direct address mode unary op-codes would be a problem, which is something to keep in mind.

***** End kibbitzing aside. *****

In addition, there are several instructions that are called "inherent" mode, where the operands are all implicit in the instruction. These include
  • manipulating result flag bits (TPA, TAP -- transfer Processor flags to/from A accumulator -- carry, zero, minus, overflow, interrupts)
  • incrementing and decrementing the index and stack pointers (INX, DEX, INS, DES)
  • moving and adding/subtracting between accumulators (ABA, SBA, TBA TAB)
  • pushing and popping the accumulators to/from the stack (PSH, PUL. Note that the "pop from stack" operator in Motorola mnemonics is "PUL".)
  • moving the stack pointer to/from the index register to get at parameters (TSX, TXS)
  • returning from subroutines and interrupts (RTS, RTI)
  • waiting for interrupts (WAI)
  • Software interrupt (SWI -- useful for debugging and/or system calls)
Then there are the flow of control instructions which operate on the program counter (PC -- called instruction pointer or IP in many other CPUs):
  • Jump and call/jump-to-subroutine (JMP and JSR -- only indexed and extended modes.)
  • Near branch and call (BRA, BSR -- one byte of signed offset is added to program counter.)
  • Conditional branches (Bcc -- condition encoded in the instruction.):
    • BEQ, BNE (zero bit -- equal or not equal after subtract or compare.)
    • BPL, BMI (negative bit -- plus or minus.)
    • BCC, BCS (carry bit -- clear or set, complemented in unsigned compare in BHI and BLS.)
    • BHI, BLS (combination carry and zero for unsigned comparison, high and low-or-same.)
    • BVC, BVS (overflow bit -- used in signed comparisons.)
    • BGT, BGE, BLE, BLT (combination overflow, zero, and negative bits for signed compares -- greater than, greater than or equal, less than or equal, less than)

*(Reserved, undefined; **6801 only)
6800/6801
Inherent
Operators
Ranks 0-3

Status, XAccumulatorBranchStack, et. al.
$0X$1X$2X$3X
0000XXXX0001XXXX0010XXXX0011XXXX
$X000XX0000*(HCF=$00)SBA=$10BRA=$20TSX=$30
$X100XX0001NOP=$01CBA=$11**BRN=$21INS=$31
$X200XX0010*($02)*($12)BHI=$22PULA=$32
$X300XX0011*($03)*($13)BLS=$23PULB=$33
$X400XX0100**LSRD=$04*($14)BCC=$24DES=$34
$X500XX0101**ASLD=$05*($15)BCS=$25TXS=$35
$X600XX0110TAP=$06TAB=$16BNE=$26PSHA=$36
$X700XX0111TPA=$07TBA=$17BEQ=$27PSHB=$37
$X800XX1000INX=$08*($18)BVC=$28**PULX=$38
$X900XX1001DEX=$09DAA=$19BVS=$29RTS=$39
$XA00XX1010CLV=$0A*($1A)BPL=$2A **ABX=$3A
$XB00XX1011SEV=$0BABA=$1BBMI=$2BRTI=$3B
$XC00XX1100CLC=$0C*($1C)BGE=$2C**PSHX=$3C
$XD00XX1101SEC=$0D*($1D)BLT=$2D**MUL=$3D
$XE00XX1110CLI=$0E*($1E)BGT=$2EWAI=$3E
$XF00XX1111SEI=$0F*($1F)BLE=$2FSWI=$3F


I think that pretty much covers the instruction set of the 6800, so I'll offer the following unbalanced summary chart:

*6801 only, **varies from 6800
6800/6801
Op-codes
Outline
Ranks
InhBRccInhUnaryBinary
A/B
$0X$1X$2X$3X$4X-$7X$8X-$FX
0000:0001:0010:0011:01MM:1AMM:
$R0:0000(HCF)SBABRATSXNEGSUB
$R1:0001NOPCBA*BRNINS$R1CMP
$R2:0010$02$12BHIPULA$R2SRC
$R3:0011$03$13BLSPULBCOM*SUBD
*ADDD
$R4:0100*LSRD$14BCCDESLSRAND
$R5:0101*ASLD$15BCSTXS$R5BIT
$R6:0110TAPTABBNEPSHARORLDA
$R7:0111TPATBABEQPSHBASRSTA
$R8:1000INX$18BVC*PULXASLEOR
$R9:1001DEXDAABVSRTSROLADC
$RA:1010CLV$1ABPL*ABXDECORA
$RB:1011SEVABABMIRTI$RBADD
$RC:1100CLC$1CBGE*PSHXINC**CPX
*LDD
$RD:1101SEC$1DBLT*MULTST*BSR/**JSR
*STD
$RE:1110CLI$1EBGTWAIJMPLDS
LDX
$RF:1111SEI$1FBLESWICLRSTS
STX

All of this is done with relatively few transistors, about 4000 to 5000 gates, less than ten thousand individual transistors, making it possible to manufacture the part using the technology available in the early- to mid-1970s.

In the process of building these, however, they developed new technology that enabled building more complex CPUs that could multiply and divide and such without having to add and subtract repeatedly.

When you design a computer's central processing unit, you may not realize it, but you use a mathematical technique of reducing the abstract general computing machine to real hardware.

Each CPU design reflects the what the engineers were focusing on when they performed the reduction.

RISC, "Reduced Instruction Set Computer", is therefore something of a pun, overloading the word "reduced" in a somewhat confusing way. The mathematical reduction in RISC architecture is performed with a focus on simplifying the instruction set -- reducing the number of instructions. (Didn't I say engineers love puns?)

When the 4004 was designed, the focus was on the functionality of a single accumulator in an absolute, incomplete reduction of the general computing model. It had to be that way, to fit a functional calculator controller into the available space on an integrated circuit using the technologies available and techniques understood at the beginning of the seventies. The 8080 inherited that focus, through the 8008, adding separate index functionality in the form of index registers.

Intel's engineers were aware of the importance of indexing, so they designed it in a way that a base index address could be saved in one pair of eight bit registers, to be copied to the index register pair where offsets could be added as necessary. Each register had a purpose, and you moved data to the necessary register to operate on it.

According to one story I've heard, Motorola's engineers started with an eight-bit implementation (reduction) of a minicomputer that they had built for their internal use, internally called the 680. According to another, the 6800 was a reduction of the PDP-11 architecture. Either way, they focused on a pair of general-purpose accumulators, adding an index register that implicitly performed offsets.

Lack of generalization in the 8080 was a bottleneck, and the Z-80 was developed as an extension to the 8080, to get around that lack. The Z-80 was the source of the "80" in Tandy Radio Shack TRS-80 brand name (making the TRS-80 Color Computer a bit ironically named).

The 6800's generalizations also had some lacks. Having only one index register can be clumsy. Constant offsets are not the only math you want to do on index addresses. And math between the two accumulators was severely limited, with no direct math between accumulator and index.

The 6502 was developed in no small part as a response to those lacks. It allows variables in page zero (6502 equivalent of the 6800 direct page) to be used directly as pointers, which helps it keep in the same ballpark, performance-wise, as the Z-80, and gives it advantages over the 8080.

Motorola developed the 6801 to address the worst of the lacks in the 6800 while keeping the transistor count low, to save room for other functions in systems-on-a-chip (SOC) applications.
  • The 6801 adds instructions which pair the A and B accumulators, A as the high byte, to load, store, add, subtract, and shift sixteen bit values. This significantly simplifies manipulating pointers.
  • It also adds an instruction to directly add the B accumulator to the index register, directly supporting small variable offsets.
  • CPX, the comparison for the index register, is generalized in effect on the flags. Again, this improves index handling.
  • It adds a hardware multiply instruction, 8 bit by 8 bit, yielding sixteen bits, useful for many things, including speeding array index math and a sixteen bit multiply more than four times as fast as the 6800 multiplying one bit at a time.
  • It adds a JSR call into the direct page, which might seem odd, but it makes it less costly to implement a small number of short convenience subroutines.
  • It adds Pushing and PUL-ing (popping) the index register, which corrects what seems like an odd omission in the 6800.)
  • It adds an officially documented BRN "branch never" bookend to branch always. This was actually an undocumented operator in the 6800, but the 6801 makes it official, allowing its use as a No-op that balances branch instructions, which can be useful for timing and as a debugging marker.   
These improvements bring the 6801 up to the same class of performance as the 6502 and the Z-80 -- in overall performance, an engineer skilled in programming the 6502, Z-80, and 6801 could get similar performance from each in many general applications, although each had niches they were better for. The companies that produced them also produced a variety of special purpose microcontrollers based on or similar to them, for specific classes of applications, as the market moved forward in the 1980s.



*****

That's too much tech for one chapter, but I'll add a little more arithmetic, for background.

The smallest bit of information in a binary computer is called a "bit". You may think this is a pun, and it is, but it is also an acronym: "Binary digIT".
A bit can take two values, but the values can be interpreted in many ways, for example:

Values of a Bit
Values:OnOff
Numeric:10
Logic:TrueFalse
Sign:MinusPlus
Gender:Non-traditionalTraditional

are some possible ways of interpreting the values of a bit. Note, in particular, that the actual assignments are arbitrary. "On" could also be interpreted as "plus", for instance.

Two bits together can take four values. Some example interpretations might be

Values of Two Bits Strung Together
Values:On-OnOn-OffOff-OnOff-Off
Unsigned Numeric:3210
Signed Numeric:-1-210
Logic:TrueTheoreticalFantasyFalse
Sign:Plus-RealPlus-ImaginaryMinus-RealMinus-Imaginary
Vegetable:PotatoOnionCabbageCarrot

The fundamental size of a piece of information for a computer has been traditionally called a "byte".  Yes, this is a pun, pure and simple.

It's also good advice:
Work on a problem a byte at a time!

(Sorry. Don't know what gets into me.)

Most modern computers use an eight bit byte, which allows 28, or 256 possible values. (And most modern computers usually actually work on problems four or eight bytes at a time.)

Numeric interpretations quickly spring to mind, such as 0 (00000000) to 255 (11111111), or -128 (10000000) to 127 (01111111). Other interpretations are not just possible, but are quite often used. For example, one might imagine an encoding in which male, female, and 254 other genders are encoded in an eight-bit byte. Or a byte could show the state of eight on-off switches on the control panel of some machine.

More typical is the US ASCII encoding, which actually only uses seven bits. Uppercase 'A', for instance, is encoded as decimal 65, and lowercase 'z' as decimal 122. '0' through '9' are decimal 48 through 57, which may seem confusing until you consider carefully the difference between numerals and numbers, or between the names of numbers and the value of numbers. The period, '.', is decimal 46.

(Unicode uses more bits, but it's a messy topic that would suck all the steam out of the story to cover here.)

So we can use numbers as codes for letters and words and symbols, and all sorts of ideas, which means we can also store and work symbolically on text and many kinds of data.

And we can use numbers to specify the color of a dot on a screen or a piece of paper, so we can also store pictures.

This provides us with ways to store and manipulate pretty much any information we could want. Sort of.

Interpretations are arbitrary. The binary number
01101101011000010110100101101100
could easily be read as binary equivalent of the decimal number
1,835,100,524
But If you put the most significant byte last, as Intel has been influencing the world more and more to do, it would be  
swap order: 01101100 01101001 01101101 01100001
compress:  01101100011010010110110101100001
decimal: 1,818,848,609
Or it could be the text string
mail
Of if the Intel byte order played tricks on you, it could be
liam
Or it could be interpreted as a floating point number under several different standards. Depending on the standard, it could be very large or very small.

Even as integers unsullied by byte order issues, the numbers have limits.

As mentioned before, a byte in a 6800 or 6502 or about any microprocessor you'll see is eight bits. (In some other computer CPUs, especially older mainframes, a byte will be a different size -- nine, six, seven, twelve, etc.)

Again, as mentioned before, an 8-bit register or memory cell can store a number between 0 and 255, inclusive. That's not a lot, but you can string several together. Two 8-bit registers treated together can store a number between 0 and 65,535, inclusive.

Unsigned Integer Sizes vs. Bit Length
SizebitsMinimumMaximumas Power of 2
1 bit1 bit0121-1
2 bits2 bits0322-1
1 nibble4 bits01524-1
1 byte8 bits025528-1
2 bytes16 bits065,535216-1
4 bytes32 bits04,294,967,295232-1
8 bytes64 bits018,446,744,073,709,551,615264-1

(Nibble is also sometimes spelled "nybble".)

The same numbers can be read as signed numbers, in various ways. Two's complement is currently the most common method:

Signed Integers vs. Bit Length (Two's Complement)
SizebitsMinimumMaximumas Power of 2
1 bit1 bitplusminus--
2 bits2 bits-21-21 ~ 21-1
1 nibble4 bits-87-23 ~ 23-1
1 byte8 bits-128127-27 ~ 27-1
2 bytes16 bits-3276832767-215 ~ 215-1
4 bytes32 bits-2,147,483,6482,147,483,647-231 ~ 231-1
8 bytes64 bits-9,223,372,036,854,775,8089,223,372,036,854,775,807-263 ~ 263-1


It's tempting to show some limits for the current most common standard floating point numbers, but this really is probably enough tech for this chapter.

*****

Well, wait. I need to mention the 6809.

Some people think the 68000 was Motorola's answer to Intel's 8086.

That isn't really a good comparison, and it isn't accurate.

The 68000 was Motorola's answer to the ARM, almost ten years too early. Or it was Motorola's answer to AMD's x86-64, about twenty years too early and 32 bits short. More to the point, it was Motorola's answer to Intel's iAPX 432, which was another architecture that was a lot too much, too far ahead of its time.

That the 68000 was successful so far ahead of its time is something to think about, but I want to point to what was actually Motorola's answer to the 8086: the 6809. (Perhaps it would be more clear if I said it was the answer to the 8088.)

The 6809 is often mistaken for a stepping stone between the 6800 and the 68000. But they were developed simultaneously, with different but similar design goals.

The 6801, by the way, is thought to have been influenced by the design work on the 6809.

The 6809 was targeted more towards extending the 6800's reach into the sixteen-bit controller market, which it did quite well.

For various reasons (including the ever-mistaken "Must not compete with ourselves!" mantra), Motorola's SOC offerings split between the true-8-bit 6805 series and the half-16-bit 6801 series for half a decade, then moved ahead building on the 6801 instead of the 6809.

Although some see the 68HC11 as a stripped-down 6809, the indexed modes tells the tale. The 68HC11 is simply a 6801 with an additional index register and hardware divide, and appropriate instruction extensions. The 68HC12 and 68HC16 continued building on the 6801, neither fully offering the advanced programming model that the 6809 offered, although the 68HC16 offered a twenty bit address space and three index registers, with an indexable stack.

This advanced programming model could almost be achieved in the 8086, but Intel designed that for the mis-engineered stack frame approach to nested local context. BP and SP are in the same segment unless overridden. (We won't yet mention the half-baked nature of the segments up until the 80386, since everyone knows about that.)

The 68000 could be used to implement the model, but no one did because Intel was busy pushing stack frames. And IBM, ...

But that gets way ahead of my story.


[Backed up at https://joel-rees-economics.blogspot.com/2020/02/bk-33209-little-about-6800-and-others.html.]

33209: Discovering the 6800 -- Parents and Polygamy

A Look at the 8080/TOC "Whoa, Merry, look who's here!" Jim said, sotto voce. He, Roderick, and I were at our lab table ...