Backup01: 33209: Rocks -- 2805

Third version backup of https://joel-rees-economics.blogspot.com/2020/08/bk-33209-rocks-2805.html.

---

Chapter 13.8 Straits -- Intellectual Property Agreements

Chapter 14.0: Rocks -- 2805

Bill grinned sardonically. "Well, I think this will work out well."

(You may want to put your BS meter away for this chapter, or at least set the threshold level pretty high.)

Bob chuckled. "Stephanie, can you get together with Carrie and see that what these three signed gets replaced with a more appropriate agreement?"

"I'd be happy to, sir."

"The same as Joe and Julia's agreements, with an addendum for their projects?" Ms. Philips asked.

Bill answered for him. "Yes, yes, of course."

And Bob nodded.

Ms. Steward, Ms. Philips, Mike, our Bob, and Jennifer got together at one end of the table.

As Julia and I connected her mainboard to one of the TVs, I whispered to her. "I thought the two guys were from Motorola's legal department."

"I did, too," she whispered back. "Must be much higher up in management."

I nodded my agreement.

(No, I never even came close to meeting Motorola's Bob and Bill in the real world.)

A number of engineers came in, bringing in pizza and liquid refreshment.

"Your friends," Motorola's Bob said to me with a grin, "are having pizza elsewhere. I think we should have some pizza in here, too." He turned to one of the engineers. "Jess, I hope there's something non-alcoholic to drink?"

The engineer named Jesse started, and looked up guiltily from the six-packs he was carrying. "Erm ...."

An engineer on the other side of the room called out, "Denny made sure we had root beer, and I made sure we had some other options." He held up two-liter bottles of soft drinks. "Not all of us are fueled by beer."

"Good job, Tobe."

Tobias gave Bob a thumbs-up.

As we ate pizza and talked, we demonstrated what we had done so far -- the ROM menus, BASIC, TSC's debug system, and Flex, and using Flex to run Motorola's assemblers.

We shared some comments and discussion of the process of getting Flex to run on the Micro Chroma 68, and I described my dynamic RAM refresh circuit, explaining how I borrowed the video scan counter of the 6847, and mentioning the problems I had run into with my original design. I also explained the simplistic bank switching that made it possible to run Flex.

Several of the engineers commented on how my refresh circuit sounded similar to a circuit the engineers who worked with Radio Shack on the Color Computer had produced before they designed the sequential address multiplexor as a separate circuit. Not yet being familiar with the SAM, I couldn't comment.

Jennifer, our Bob, and Mike had taken care of their paperwork by then. Bob knew something about the SAM already, and he discussed it a bit with the engineers.

We showed them the 6801 daughterboard on Julia's mainboard, and her keyboard, and she described the way we were using the 6805 and its timer to scan and debounce the keyboard and control the hexadecimal display, augmenting the I/O with either latch or multiplexor.

Then she loaded Forth on her computer from tape and used it to send numbers out to her keyboard's hexadecimal display.

We stopped for a few minutes while Bob, Bill, and some of the engineers discussed whether Motorola wanted to ask us for permission to use the keyboard decoder/numeric display design and code for an application note, and the upshot was that they did, and the five of us agreed to discuss that with the rest of the group.

Most of the engineers were appreciative of Julia's Forth examples, and I explained what I had done to get the drivers to work, mentioning that we hadn't solved the disk problems yet for Forth.

My disk interface was the topic of considerable discussion, and Ms. Philips and Ms. Steward quickly produced a sharing addendum to allow us to get the schematics out for everyone to look at. Before long, Julia and I had another addendum to our agreements -- an internship contract for producing several tech notes on the use of the 6801 as a floppy disk controller. The addendum allowed Motorola the option of building a semi-custom "system on a chip" SOC floppy disk controller based on my circuits.

Denny had already shared the schematics Julia had drawn up from my scrawls with some of his friends. But now the context was Motorola, so the addendum was deemed wise.

"Ah, to be an undergrad with all the time in the world again," Tobias reflected jocularly. "Do you think you could get a 6805 to handle the floppy controller functions?"

I tilted my head and thought. "That would probably limit sector size, with X being only eight bits. Come to think of it, the size of X might require enough extra code to prevent the processor from keeping up with the data."

Another engineer, Sharon, asked, "What's your general impression of the 6805?"

"It does the job for little things like the keyboard controller," our Bob volunteered.

I concurred.

There was general approval of that analysis.

"But I miss stack support," I added.

"On an eight-bitter?" Jesse queried. "You'd prefer the 6502, maybe?"

Jennifer noted, "The 6502 is a clever design, but it belongs to MOS Technologies and Commodore, doesn't it?"

(In the real world, Motorola might have been smart to use their patent agreements with MOS Technologies and second-source the 6502 in the late 1970s. They did offer to produce SOC chips with the 6502 as the CPU core in the mid-to-late 1980s. But that history is not for this story.)

"The 6502 is a good chip," I asserted. "It straddles some boundaries like the 6809, but I think the way it does so constrains compatible upgrade paths." I paused for thought and emphasis. "Every application wants room to grow. Maybe some shouldn't, but many can profitably grow in scope and function. And growing software reliably wants things like code re-use by re-entrant subroutine call, and keeping subroutines re-entrant requires something like a stack that you can push to and pop from, for parameters and local variables. There's no push or pop on the 6805."

Julia added, "Even if you aren't calling subroutines a lot, a stack helps manage RAM. Global RAM is harder to keep track of, even if you never re-use any variables."

I turned and raised my eyebrows. "You're picking this stuff up."

"A little. Dad has been explaining things you haven't."

"Oh. Sorry. I'll have to do better."

"It's okay." She smiled. "He enjoys it. He always wanted his oldest child to be an engineer."

"Now I know why he likes me so much."

We grinned at each other, then Julia coughed discreetly.

I ducked my head and turned back to the engineers, several of whom were quietly clapping their hands, rolling their eyes, or pretending to give us wolf-whistles.

"Anyway, as Julia points out, a stack you can reference makes RAM much easier to manage. Of course, you can synthesize a stack, but synthesizing is slow, and a disincentive, and the code to support the synthesized stack is a distraction."

An engineer named Pete objected. "Moving up to the 6801 is not that hard."

"But it does require reworking a lot of the code, and checking all of it for side-effects of the differences between the two," I parried. "And there are the bit manipulation instructions in the 6805 that the 6801 does not have, easy enough to synthesize on the 6801, but still requiring time and effort. Adding stack support to the 6805 ought not to be that much of a change, and it would support quite a bit of application growth. That would give the customers' engineers much more confidence in choosing the improved 6805 for small projects with the potential to become large."

(The 68HC11, an evolutionary step from the 6801 that Motorola introduced in 1984, did have bit manipulation instructions. And the 6805 itself later evolved to the confusingly named 68HC08, which did introduce more complete stack support via instruction pre-byte escape -- single stack with stack indexing, as opposed to the dual stack and index marking I suggest  below. In the real world. Several years later.)

Jesse countered, "Okay, how do you propose to add stack support with minimal change? Pre-bytes like on the 6809 are too expensive for a pure eight-bitter."

(Well, they were just a little too expensive in the early 1980s.)

"Add a second stack register. Maybe call it U for user stack, following the 6809's register naming. Add push and pop instructions that push and pop to the U stack, and transfer instructions that allow moving U to X and back. And instructions to save U and restore it using the S stack. Eight instructions should do the trick."

Julia handed me a sheet of scratch paper, and I wrote down the additional instructions:

PSHUA, PULUA
PSHUX, PULUX
PSHSU, PULSU
TUX, TXU

I drew out a map of the registers of the 6805, except for the condition codes:

6805 register	b15	b14	b13	b12	b11	b10	b9	b8	b7	b6	b5	b4	b3	b2	b1	b0
A:									A7	A6	A5	A4	A3	A2	A1	A0
X:									X7	X6	X5	X4	X3	X2	X1	X0
SP:	0	0	0	0	0	0	0	0	1	(SP6)	SP5	SP4	SP3	SP2	SP1	SP0
PC:	--	--	--	PC12	PC11	PC10	PC9	PC8	PC7	PC6	PC5	PC4	PC3	PC2	PC1	PC0

Then I drew out a modified map, including the U stack:

2805 register	b15	b14	b13	b12	b11	b10	b9	b8	b7	b6	b5	b4	b3	b2	b1	b0
A:									A7	A6	A5	A4	A3	A2	A1	A0
X:									X7	X6	X5	X4	X3	X2	X1	X0
U:	0	0	0	0	0	0	0	0	1	(U6)	U5	U4	U3	U2	U1	U0
SP:	0	0	0	0	0	0	0	1	0	0	SP5	SP4	SP3	SP2	SP1	SP0
PC:	--	--	--	PC12	PC11	PC10	PC9	PC8	PC7	PC6	PC5	PC4	PC3	PC2	PC1	PC0

"Keeping the stacks separate will allow moving the return stack out of the direct page. It could then be given its own port to the CPU, in its own address space, with separate on-chip address and data lines. That would allow proceeding to the next instruction while the call instruction stacks the return address. That way, calls should end up costing no more than jumps, and it should be possible to make the return operator faster, as well."

The comment about calls taking less time got some discussion of a nature too technical to bore you with here.

Except for the subroutine entry and exit protocol. "Subroutines," I continued, "could look like this:"

ROUTINEA
    TUX
    LDA 0,X ; 1st parameter
    LDX 1,X ; 2nd parameter
    ...
    TUX
    LDA 2,X ; 3rd parameter
    ...
    INX ; clear all parameters
    INX
    INX
    TXU
    RTS

"But X is only eight bits," an engineer named Wayne objected.

"The S register is only six or seven bits in the 6805. The return stack is so small it that it will run out of memory before it cycles through the addresses allocated to it in the direct page. But you can move it out of the direct page and no one would notice, and it could still be effectively less than eight bits to be decremented and incremented by the push and pop.

"If it weren't for wanting to sometimes directly shift local variables, and the lack of sixteen-bit index offsets for the unary instructions in the 6805, you could put the parameter stack outside the direct page, too. Putting it where the return stack is now should be no problem, at any rate, and allow access by unary instructions."

Several of the engineers started scribbling on scratch paper.

Sharon said, "This could be useful."

An engineer named Chuck intoned, "Room in the design for improvement is good engineering."

Bill asked, "Are you taking notes on this, Julia?"

"Is that okay?"

"Can we get a copy, and can we mark parts we don't want shared outside?"

"Sure."

"In that case, thank you, make sure you get Chuck's comment about room for improvement in, too, and please continue."

He and Motorola's Bob again exchanged silent words, and both nodded in agreement.

I shook my head and said quietly, "Julia, I presume upon you too much."

Julia grinned. "I'll claim my pay when we get back home."

I grinned back.

"Get a room!" There was a bit of chuckling. We had an audience again.

An engineer named Jack objected. "Isn't dedicating RAM to a second stack a waste?"

I shook my head. "RAM is easy to make and relatively easy to test, isn't it? Shouldn't it be cheap? Like candy. And the call stack doesn't have to be completely inaccessible. If it's in the extended address space, it would be accessible via extended addressing or 16-bit index offsets."

An engineer named Monty grumbled to himself. "Testing RAM is a good way to bring up new processes, too. Forcing the customer to scrimp on RAM is just a little anti-social."

Motorola's Bob chuckled at that, and asked Julia to quote Monty on it.

Jesse was also sketching something on note paper. "Separate address spaces. We could put part of the direct page RAM in its own address space and give it its own port to the ALU, and shave a cycle of access time for that area in direct page RAM," he muttered, half to himself.

Julia repeated, sub-vocalizing, "... shave a cycle for the direct page RAM access."

Jennifer overheard Jesse, and asked him, "Could that be done without making it difficult to speed the processor up?"

Jesse scratched his head. "Actually, if we're careful, it should make it easier to keep things in sync in a process shrink."

"I was thinking about overclocking."

Jesse chuckled. "Overclocking is one of those dirty secrets we don't talk about, but it can be used to predict whether certain aspects of a process shrink will work."

Our Bob joined him in chuckling.

"Is a process shrink where you make the masks smaller?" Jennifer asked.

Our Bob nodded.

Jesse answered, "It's more than that, but, yeah."

"Could that be used to improve access time to the parameter stack?" I asked.

"That would be a bit more complicated," he replied. "Might be too much beyond the concept of an eight-bit micro-controller."

"You know," I commented, "one thing I'd like to have is a way for the CPU to catch things when calls or interrupts try to push too much on the stack, and when return instructions try to pull too much off."

"How can you save state on the stack when the stack isn't valid?" Wayne asked in a tone that was almost rhetorical.

"Could you have a limit register for S that could trigger an interrupt when a call or interrupt would decrement S below it? The limit register could be set by the program, high enough to allow the stack interrupt room to save state without walking on variables."

Jesse looked up from his scratch calculations. "Shadow register sets that get switched in when handling interrupts could be a rather more elegant solution to the stack overflow conundrum."

Julia held her hand up. "Can you help me write that as a note?"

"Interrupts work like calls on our processors. They save the processor state on the call stack. That allows interrupts to nest, to a certain extent. A stack overflow interrupt would fundamentally be unable to nest anyway, so saving state somewhere else might make sense. Some processors have shadow registers --"

Our Bob cleared his throat and said, in a loud whisper, "Z-80. And the 68000's A7 system stack, although that's just one register."

"-- for fast context switches." Jesse chuckled before continuing. "Shadow registers might be one place where you could save the processor's state on stack overflow."

Julia and Ms. Philips conferred with Jesse and our Bob on this and Julia continued with her notes.

"Speaking of the interrupt stack," an engineer named Craig pointed out, "stacking the U stack on interrupts will mess with stack frame compatibility."

"That's part of the reason I call this ideal processor with conflicting specifications the 2805," I explained.

"Conflicting specifications," Motorola's Bob chuckled, and all the engineers joined him.

Julia looked at me in puzzlement.

Tobias explained with a grin: "Conflicting specifications is part of what makes engineering fun." That got more chuckles.

"Giving the processor another name would help let customers know not to expect perfect compatibility," Wayne nodded. "But it also might make sense to not automatically save the U stack pointer." He frowned in thought.

"Assume the interrupt handler routine will behave nicely with the interrupted routine's parameter space, or switch it out itself?" I asked.

"Something like that. There won't be a lot of RAM to switch the stack around in, in a 6805."

"True."

"So, while we're critiquing the 6805, is there anything else?" Motorola's Bob asked.

"Not enough I/O pins. We had to use either an external 8 bit latch or an external multiplexor to get enough I/O bits to read 64 keys and communicate with the main CPU. If we had a package with sixteen more bits of I/O, we could decode larger keyboards without external parts and still give a parallel interface to the main processor. A serial keyboard interface could be done with fewer, but it would still need more than we have."

Julia looked up as she handed Ms. Steward another page-full of notes. "Serial keyboard cables will be better for office computers anyway, right, Joe?"

I agreed.

Jesse nodded, too. "Flatpack can give 64 pins in a reasonably small package. Socketing those is expensive for now, but surface mount is cheap."

Julia stopped him for explanation, and he drew pictures for her. "Flat-pick looks more like a square black chip than a millipede. Contacts on the edges like this. Sockets for them look like cups, but they are often soldered flat on top of the circuit board."

"So separate parts might actually be a better engineering option?" I asked.

"Maybe."

"Anything else?" Motorola's Bob prompted.

"Daydreams?" I laughed.

"Sure." He grinned.

"The 6801's eight-bit multiply is useful. A pair of eight-bit divides -- integer and fractional -- might be useful, too. But I'm thinking about a complete one-bit multiply and one-bit divide."

He furrowed his brow. "Single bit? That seems like swimming against the current."

"Software multiplies spend a lot of time in branch instructions. If you could do a full single-bit multiply with one instruction and stack those instructions up, you could cut the time for a multiply to maybe a quarter of the time of a software multiply on the 6805 and 6801, without the complexity of a full multiplier circuit. You could get similar improvements with a single-bit divide."

(Again, many versions of the 6805 ended up getting a full 8-bit multiplier circuit, and the 68HC11 ended up getting both the 8-bit integer and fractional divides, in the real world.)

Craig responded. "Which algorithm, and how are the arguments addressed? Several known pits to fall into, but it might be worth looking at again."

Bill had picked up the Forth listing, and was looking at the first page.

"This is the license for using Forth?" he asked.

"For the Forth Interest Group's model interpreter," I replied

Monty explained, "There are many Forth development systems with more traditional licensing. The Forth Interest Group uses the liberal license and some of the models are known to be a little buggy in places. In some cases, it's almost as if they just threw code over the wall and abandoned it."

"How do you mean?" Bob asked.

"A liberal license requires an active development team to be useful. The development team can charge to fix bugs. But their model interpreter for our 6800 has nobody following up on it."

Bill laughed. "There's something cynical about giving code away for free and charging to fix bugs."

Monty shrugged. "On the other hand, the user is also able to look for and fix bugs himself. I saw this work at MIT. The group that works with the liberally licensed LISP interpreters only allows contributions that are liberally licensed into their code base. It's a rather elegant approach to sharing. Code that doesn't get used doesn't get fixed."

Bill's forehead wrinkled. "Elegant and efficient. Survival of the fittest. Hmm."

(I should note, I was actually as prescient as the me of this chapter -- two or three years later in my college career in the real world.

And we should also assure ourselves that the real engineers who worked for the real Motorola were aware of pretty much all of this.

Which path is best is often not clear. Motorola's management in the real world made decisions that, in hindsight, appear to have been counterproductive. Examining certain of those decisions is part of my reason for writing this story.

Hindsight does appear to be clearer than foresight, which is precisely the reason that this story is something of a waste of time, in effect, an idolatry of idealized abstract mathematical machines.

But if we are comparing ways to destructively waste time, I think it's less a waste of time than body pornography -- that's essentially an idolatry of idealized bodies. Modern pornography adds saccharin personality to the mix. Some rich person's ideal, not real, imaginary value only.

Speaking of the real world, of course you know, in the real world, Motorola's management and engineers had no reason to do blue-sky brainstorming like this with me, much less believe my ideas. But for this experiment to work, in the world of this novel, they must.)

Chapter 14.1: Rocks -- what?

TOC

---

[Backed up at https://joel-rees-economics.blogspot.com/2020/08/bk-33209-rocks-2805.html.]