Backup: 33209: Rocks -- 2805

Backup of https://joelrees-novels.blogspot.com/2020/08/33209-rocks-2805.html.

---

Chapter 13.8 Straits -- Intellectual Property Agreements

Chapter 14.0: Rocks -- 2805

[202008262244 -- 2nd edit, with register maps:]

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. "Jeff, I hope there's something non-alcoholic to drink?"

The engineer named Jeff 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 managing 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 an addendum to our agreement, 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?" Jeff 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 idea 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.)

Jeff 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 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 also be given its own port to the CPU, in its own address space, with separate 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 attention and discussion.

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

"S 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 that bit about room for improvement in, and please continue."

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

I shook my head and said quietly, "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.

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

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

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

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

Jeff 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 the condition 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."

Jeff looked up from his scratch calculations. "Shadow register sets that get switched in when handling interrupts could be a rather 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, 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. Shadow registers might be one place where you could save the processor's state on stack overflow."

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

"Speaking of the interrupt stack," an engineer named Greg 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.

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

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

Jeff nodded. "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 the circuit board."

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

"Maybe."

"Anything else?" Motorola's Bob prompted.

"Daydreaming time?" 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.)

Greg 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 for our 6800 has nobody following up on it."

Bill laughed. "There's something cynical about that."

Monty shrugged. "On the other hand, the user is also able to look for and fix bugs. 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 novel -- 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 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. Ideal, not real, imaginary value only.

Speaking of the real world, of course you know that, 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.)

[202008262244 -- 2nd edit, with register maps.]

[202008242104 -- original edit:]
Bill grinned sardonically. "Well, I think this will work well."

(You may want to put your BS meter away for this chapter.)

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, 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 Bob and Bill in the real world.)

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

"Your friends," 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. "Jeff, I hope there's something non-alcoholic to drink?"

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

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.

Bob, Jennifer, and Mike had taken care of their paperwork by then. Bob knew something about the SAM already, and he asked the engineers some questions about it.

We showed them the 6801 daughterboard on Julia's mainboard, and her keyboard, and she described the how 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 managing engineers discussed whether Motorola wanted to ask us for the keyboard decoder code and design for an application note, and the upshot was that they did, and we agreed to discuss that with the rest of the group.

Most of the engineers were appreciative of the 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 an addendum to our agreement, a 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 the context was now Motorola, so the addendum was deemed wise.

"Ah, to be an undergrad with all the time in the world again. Do you think you could get a 6805 to handle that?" an engineer named Tobias asked.

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, named Sharon, asked, "What's your general impression of the 6805?"

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

I concurred.

There was general approval of that analysis.

"But I miss stack support," I added.

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

Jennifer noted, "The 6502 is a clever design, but it belongs to MOS Technologies and Commodore."

(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 idea is not for this story.)

"The 6502 is a good chip. It straddles some boundaries like the 6809, but the way it does so constrains compatible upgrade paths," I asserted. 

"Every application wants room to grow," I continued. "Maybe some shouldn't, but some should, and growth wants things like code re-use by 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. And there are the bit instructions in the 6805 that the 6801 does not have," I parried. "Adding stack support to the 6805 ought not to be that much of a change, and it would support quite a bit of project growth. That would give the customers' engineers much more confidence in choosing the 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 instructions. And the 6805 itself later evolved to the confusingly named 68HC08, which did introduce more complete stack support --  single stack with stack indexing via pre-byte, as opposed to the ideas I present below. In the real world. Years later.)

Jeff countered, "Okay, how do you propose to add stack support with minimal change? Prebytes like on the 6809 are too expensive."

(Well, they were 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

"Keeping the stacks separate will allow moving the return stack out of the direct page. It could also be given its own port to the CPU, its own address space, with separate address and data lines. That would allow proceeding to the next instruction while the call stacks the return address. It should cost no more than jumps, and it should enable faster returns."

The comment about calls taking less time got some attention and discussion.

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

"S is only eight bits in the 6805. The return stack is so small it that it will run out of memory before it cycles through the addresses in the direct page. But you can move it out of the direct page and no one would notice, and it would still be effectively less than eight bits that would change.

"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 code out on scratch paper.

Sharon said, "This could be useful."

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

Bob 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, and please continue."

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

She 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. But it doesn't have to be completely inaccessible. It might be accessible via extended addressing or 16-bit index offsets."

An engineer named Monty grumbled, "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."

Jeff 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 shave a cycle of access time for that RAM," he muttered, half to himself.

"One thing I'd like to see in CPUs in general is a way 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.

"I've thought about limit registers that can be set to trigger when any further push will leave no more room for an interrupt to save full state without walking on variables."

Jeff looked up from his sketching. "Shadow register sets that get switched in when handling interrupts are a rather elegant solution to the stack overflow conundrum."

"Speaking of the interrupt stack," an engineer named Greg said, "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."

This drew chuckles from the engineers.

"Maybe it makes sense to not stack the parameter stack pointer automatically, or maybe you need to use another name so the developers know they need to make changes," Wayne nodded.

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

"Not enough I/O pins. We had to use either an external 8 bit latch or an external multiplexor to read 64 keys. 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. Eight more would work if the interface is serial."

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

"Separate parts might be preferred?" I asked.

"Maybe."

"Anything else?" Bob prompted.

"Daydreaming time?" I laughed.

"Sure." He grinned.

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

Bob 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 in maybe a quarter of the time of a software multiply, without the complexity of a full multiplier circuit."

Greg 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 fig 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."

Bill laughed. "There's something cynical about that."

Monty shrugged. "On the other hand, the user is also able to look for and fix bugs. 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. Hmm."

(I should note, I was actually this prescient -- two or three years later in my college career. And we must also assure ourselves that the real engineers who worked for the real Motorola were aware of pretty much all of this. Which path was not clear. Management made decisions that, in hindsight, were counterproductive.

Motorola's management and engineers had no reason to talk with me like this in the real world, much less believe me. But for this experiment to work, in the world of this novel, they must.

Hindsight does seem to be clearer than foresight, which is precisely the reason that this story is something of a waste of time. But I think it's less a waste of time than certain very popular classes of fiction that a lot of people waste a lot of money on. Idolatry of idealized bodies and saccharin personalities can't be more healthy than idolatry of idealized abstract mathematical machines.)
[202008242104 -- original edit.]

Chapter 14.1: Rocks -- what?

TOC

---

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