The Novels

Economics 101, a Novel (Rough Draft) -- My first sustained attempt at a novel, two-thirds finished in rough draft, and heading a little too far south.
What would you do if you and your study partner, with whom you had been seriously discussing marriage, suddenly found yourselves all alone together on a desert island? Study economics?
Sociology 500, a Romance (Second Draft) -- The first book in the Economics 101 Trilogy.(On hold.)
Karel and Dan, former American football teammates and now graduate students, meet fellow graduate students Kristie and Bobbie, and the four form a steady study group.

Featured Post

Sociology 500, a Romance, ch 1 pt 1 -- Introducing Bobbie

TOC Well, let's meet Roberta Whitmer. Bobbie entered the anthropology department office and looked around. Near the receptionis...

Tuesday, September 29, 2020

Backup: 33209: Rocks -- An Evening Together

Backup of https://joelrees-novels.blogspot.com/2020/09/33209-rocks-evening-together.html.

 Chapter 14.2 Rocks -- Moving Ahead

Chapter 14.3: Rocks -- An Evening Together

"I'm glad they had the Micro Chroma kits so we can take them home." Pat was examining the kit she was carrying as we entered the front door.

"I don't know about you guys, but I'm watching Hello Dolly tonight." Denise looked up from where she was watching TV and grinned as we came in the front door. 

I went to the kitchenette and set the bags I was carrying down.

Pat looked from her kit to the TV with a perplexed frown.

"Joe?" Julia looked over at me with a question in her eyes.

I shook my head. "No complaints from me."

Julia happily sat herself on the couch beside Denise, and I sat on the floor in front of her, leaning back against the couch beside her knees. 

Denny carried a couple of flat boxes into the kitchenette muttering something amusingly inane about TV.

Pat sat beside Julia. George and Mike took the flat boxes they were carrying into the kitchenette and returned to sit on the floor in front of her, dividing their attention between the TV and their kits.

"Somebody help me with the pizza I brought home!" Denny called out.

"Pizza?" Denise looked up from the TV hopefully. "I thought I smelled pizza. You brought some home?"

I got back up and went into the kitchen area, and George and Mike followed.

"On the company tab. Leftover from recruitment party."

We quickly had plates out and filled, and we passed them back into the living room, then passed out cups and soft drink bottles and returned to sitting on the floor.

"Tell your boss I thank him," Denise said between bites. "Very considerate, and better than the fried chicken I thought you had forgotten."

Denny grinned and joined us, giving Denise's rounding abdomen a caress before he sat down in front of her on the floor. "Kids asleep?"

"I doubt it."

The older boy peeked in through the boys' room door. I motioned to him to join us, and he came in and sat beside me. Denny stood back up and brought the younger one in, letting him lie in his lap and go back to sleep.

*****

"Money is like manure." Julia gave me a glance and look as quiet as her voice. Denny and Denise had invited us to join in their family prayers, and, that done, Julia and I had carried the boys back to their beds and were now returning to the living room.

"Horace. Prompted evidently by Dolly's late husband from the other side." I also spoke quietly. "Spread it around and make green things grow. Not a bad metaphor, in a country where the banknotes are green."

She gave that a quiet laugh. "I guess it's not quite the same metaphor if the paper money isn't green."

"Still a useful principle."

Mike and George looked into the boys' room behind us. 

"Tight squeeze with three of us," George muttered. He turned back to the living room. "In my economics class, the teacher compared money to air. Pointed out that it's a medium of communication and essential to society's functioning."

"Essential?" Pat raised an eyebrow.

"You need something that can be used to communicate about value," he replied. 

"And any medium for communicating value just ends up looking like money," I added for him. 

"Probably."

Pat asked, "Then how about blood as a metaphor, since it has to circulate, and it carries stuff with it?"

Mike suppressed a snort. "More like pus."

I glanced up at him. "Because it tends to accumulate most in the wounds of society."

He nodded. "Exactly."

"Pus?" Julia scrunched her face. "Yuck. I could hate you for that, Mike." She shook her head and chuckled.

He just grinned back.

George groaned, but Pat nodded her head appreciatively. 

"Are you guys sure you're not already all related to the Reeves clan?" Denise asked.

"What?"

"Huh?"

"Philosophizing when we should be getting ready hit the hay," I explained.

"All the Reeveses do it," she laughingly complained.

Denny and I chuckled, and Julia reached out to take my hand. I gave her a smile and hug in reply.

*****

"Joe." 

Mike's low voice from beside me broke into my pre-dream thoughts. 

George's breathing from the other side of him was deep and regular.

"Yeah?"

"Julia tell you about her and me?"

"Somewhat."

"I wish I'd known you in high school."

"Oh?"

"I think I needed better role models."

"Heh. I was not much of a role model in high school. Two years as a missionary helped, but, ..." and I stopped, in the realization that what I was about to say might be rather painful to Mike.

"Then maybe it's just that you and Julia are a better match than I'd have been for her."

"Maybe." I guessed he'd understood -- from his point of view -- some, if not all, of what I hadn't said.

"Even if ...," he trailed off.

 I waited for him to finish.

"Even though I can't expect to win Julia back, I want to be your friend."

"I hope we can be friends. I think Julia has some unhealed wounds that could be healed if we could all be friends."

"I think we can. But that's what it is. What I want to learn from you. I want to be able to think like that."

"I think it has something to do with religion."

"I know."

I waited for him to say something more.

"Thanks for letting us come along."

"Thanks for coming."

Mike grunted an affirmative, and slowly his breathing became regular and deep.

I was reminded of listening to my missionary companions' breathing in the middle of the night. There's something companionable about sharing a room to sleep in.

*****

In the morning, we met the others at the park and spent a half hour walking and wading in the water before heading out for breakfast and to the surplus store.

John was happy to have the group of students browsing his selection of surplus, and he was happy to talk with me about the controller circuit.  He was worried about Motorola wanting to prevent him from passing the diagram and code out with the drives he sold, but Denny and assured him Motorola had agreed to keep it openly usable. 

Denny had already put copyright notice, notice of intent to patent, with notice of license and disclaimer of liability on the diagrams he passed out among his friends, and John was leaving the notices intact on the copies he kept to pass out.

About lunchtime, we went back to the park and met the other group coming in. Motorola's recruiters found us there, bringing more pizza and the remainder of the Micro Chroma 68 kits. But they kept the recruitment activities short, to leave the second group as much time at the surplus store as possible.

Julia and I spent a couple of hours with Denny and his boss at Motorola, learning how to use the test equipment to go through the reject bin and fish out parts that were functional enough, even though the batch they had come from had not qualified as product. We were able to collect a couple of rails of parts that members of our group could use in their projects.

By the time we got ready to leave, we had, in addition to the Micro Chroma 68 kits and the hardware we had purchased, something of an agreement that many of the students in our group would be working on projects for Motorola over spring break and the summer holidays.

*****

Julia wrapped my arms around her as we stood facing the moon on the sidewalk outside her house about a half hour before midnight. Neither of us spoke for maybe a couple of minutes, then she turned and gave me a kiss that must have lasted as long. It tore me up to tear myself away so we could unload her hardware.

Her mother was sitting on the couch with some knitting when we entered the front door.

"Mom, don't say a thing."

"About what?"

"About it would be faster and easier for me to stay over in Joe's spare room. 

"But that would mean Dad wouldn't be able to help you build your computer." She smiled. "We're putting enough pressure on you two. Take your time and don't mind us."

Chapter 14.4: Rocks -- what?


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

Monday, September 14, 2020

Backup: 33209: Rocks -- Moving Ahead

Backup of https://joelrees-novels.blogspot.com/2020/09/33209-rocks-moving-ahead.html.

 Chapter 14.1 Rocks -- Bit Multiply

Chapter 14.2: Rocks -- Moving Ahead

[Please pardon the layout change. Google is being the 800 pound prima donna and making all blogspot users use a buggy blog editor now.]

"Are you sure that there's nothing in what you and Julia just went over that you won't be claiming as IP?" Bill wrinkled his forehead.

I shrugged. "Trying to claim IP on this kind of thing is only one step beyond trying to claim IP on binary addition. No real circuitry to base claims on, nothing but ideas and math."

(We won't mention a very famous, wealthy corporation that did, in fact, attempt patent claims on binary addition in an ALU, buried in its claims concerning a programming language and programming environment they developed and sold. We also won't dwell too much here on the fact that, once upon a time, ideas, math, and algorithms were considered outside the domain of patents in the USA.)

"Would it be possible," I asked, pressing my own agenda, "to reduce the cycle count to one on reads and two on writes in the direct page RAM, without blowing the transistor budget on a 6805 or 6801? That alone could better than double the speed of software multiply and divide."

There was a bit of uncomfortable chuckling and clearing of throats.

"No?"

Several engineers looked at Pete. He shrugged.

Tobias tilted his head apologetically. "We'd have to fix the prefetch/decode circuit so it's a real pipeline of depth one."

"It's not a real pipeline?"

 "The eight-bit designs don't have a place to keep the instruction in its partial and fully-decoded states, so we go back and redo the prefetch if we don't use it immediately." 

"Oh."

"And then we'd have to test it. Testing is what we get stuck on budgeting time for. You should talk with your brother about that."

"Denny's not in charge of test, is he?"

"No, but he could tell you something about the backlog."

Our Bob spoke up, "Could interns help with the grunt work?"

Motorola's Bob exchanged glances with Bill, then turned to Jesse. "Should we look at that?"

"Maybe we should," Jesse frowned. "I'll discuss it with my group on Monday, see if we can separate something out that a non-engineering tech could handle."

"Remember that these guys seem to have a bit more of a handle on the tech than our usual crop of interns."

"We'll take that into consideration."

I ventured a bit further. "I'm not just thinking of fast direct-page RAM, though. The 6809 and the 68000 have enough index registers to support separating the parameter stack from the return pointer stack, and that means one might profitably attach a hysteric cache to both pointers, with the appropriate control signals."

That got me looks of confusion and amusement.

"A cache that tracks the stack pointer with hysteresis." I borrowed Julia's notepad again and sketched out something like this:

Ms. Philips reached over and lifted the notepad and waved it at me. "I am sure this is IP."

"It's just a lousy diagram of spill-fill cache tied to a stack pointer. Calling it hysteric is a bit of a pun, is all. Not even a really good pun, at that."

Jesse started chuckling. "If it works," he commented, "it'd be more appropriate to call it an anti-histrionic stack cache." 

A number of other engineers echoed his chuckles of appreciation.

Ms. Philips and Ms. Steward put their heads together and started working on something. Bill and Motorola's Bob refrained from comment, keeping an unobtrusive eye on what they were working out.

I added, "If the cache could also be accessed in single-cycle reads and two-cycle writes, local variables would be almost as good as registers."

Bill leaned forward. "We've taken a lot of your time on this blue-sky brainstorming, but Bob and I wanted to get your opinion on something."

I let the amusing, but perhaps meaningful mixed metaphor pass and nodded.

"If you were designing a mass-market personal computer using an existing CPU, would you use Intel's 8086 or 8088?"

It was my turn to be confused. "Sloppy segments. Instruction set is an improvement over the 8080, but not much. No. I'd use the 6809 for the instruction set and register set before I'd use the 8088, even though it's a bit slower on multiplies and a lot slower on divides, and would require bank-switching or the 6844 MMU for a PC. 

(PC? I had become familiar with the abbreviation in Japan while I was there as a missionary. How quickly people forgot, in our real world, that there was more than half a decade of PCs before the IBM PC.)

"And I'd use the 68000 over the 8086 even though the 68000 costs significantly more, because the 8086 just doesn't make sense. It requires 16 bit wide memory, but it still gives only 16 bit addresses without playing bad programming practice games with your code. Sloppy segments are a security booby-trap, and a bug generator."

Bob nodded. "Are you sure your antipathies are not colored by family loyalties? Tech doesn't forgive misplaced family loyalties."

"Family loyalties may induce some of the heat, but, really, if they want to map 16-bit logical addresses into a 20-bit physical address space, they should make the segments fully 20 bits wide. 24 or 32 bits wide would make more sense, even if the top four or twelve bits aren't brought out of the package or don't even physically exist. And the segments should have limit registers, as well, if they're going to mean anything besides crude bank-switching with the improvement of being able to tie specific banks of memory to specific index registers, including the instruction pointer. Half-baked MMU."

"But potentially useful, no?"

"With extreme caution."

"How about segment registers for the 6809 or 68000?"

"You can use the 68000's address registers for segmentation if you want, although the segment limit problem remains, and there is a memory cycle penalty if you don't handle the segments well."

I stopped to think my next words through.

"If I were adding segmentation to the 6809, I'd want full 32-bit segment registers. The limit registers would be as wide as the index registers, so if you had a derivative with only 16-bit wide index registers, the limit registers would also be 16-bit. Instead of a segment override prefix like the 8086, I'd just have the register-to-register transfer instructions move the segment and limit registers, as well."

Bill and Bob were both nodding. Bill asked, "You've taken a look at the 68008, haven't you?"

"Yeah. But I'm letting Mike be the one to have fun with it."

Mike snickered.

"If it were available in, say, three months, in small lots, would you use it?"

"There are a lot of things that a 4 megahertz 68000 is going to be no faster doing than a 1 megahertz 6809, because of the memory cycle speed, the extra width of instructions, and other things. Many of those things are precisely what a personal computer is going to be used for. A 4 megahertz  68008 is going to be about half to two thirds of the speed of the 68000, I think. The only advantage is the megabyte address space, which really won't be quite enough in the near future."

Bill and Bob both frowned.

I continued, "Now, if we had a further evolution of the 6801 with an additional 8 bits on the top of the index register and program counter, a long jump, and either a long load of X or a transfer A to XHi or some such, at a price not too much higher than the 6801, that would make a good cheap personal computer. Or that evolved 6809 with PC, X, Y, U, and S extended by 16 bits, and new load effective address modes to make the long addresses accessible, again, at a price not much higher than the 6809, that would be ideal for the current market."

"One megabyte is too tight?" Bob asked.

"64 kilobytes is too tight?" Bill asked.

"Look at the 6847. Julia and I and my sister write reports using that because we are patient with the narrow window on the text, and we like the ability to type, think, erase, and type again. But my mom just gets frustrated, and my dad barely avoids going to sleep. People with no reason to be patient won't get it, and they are the ones who will be buying most of the personal computers sold. A personal computer has to be able to show the equivalent of a typewritten page on its screen, at minimum, or at least have a clear upgrade path to get there. That's what's stalling Radio Shack's Color Computer in the market right now. Besides lack of MMU."

Pete said, "But that would only be a 2 kilobyte screen buffer. I've seen the Japanese personal computers, and they're pretty functional with only 16 bits of address."

"How functional?"

 "All the useful characters."

"Not by a long shot. Less than two thousand. The real count for a good newspaper is estimated at over 3,000 characters, but they aren't taking into account that what will be included in that 3000 will vary from month to month. And even newspapers will use really oddball characters regularly, when they need something more precise in meaning, and if you include the ability to display all the oddball characters, you're well into 9,000 characters or more. Add historical characters and you easily triple that count. Chinese is on the order of a hundred thousand characters. Sixteen bits doesn't cut it, except for very limited purposes like cash register receipts and utility bills."

"You can't be serious."

"I've lived over there. I know the hype they give the current crop of PCs and the sell-job they give the new student of the language, and I know the reality when you start reading serious literature."

"How does anyone remember them all?"

"They don't, but that's going to be one of the things a real personal computer will be good for, helping them find and use the ones that they have trouble remembering. The personal computers they have now are very limited in scope relative to what they need, and what they will have in the future. They sell because they don't have anything better."

I continued after a moments' thought, "If the characters are to have decently defined glyphs, you want bit-mapped characters that are 32 by 32 pixels, not 16 by 16. 10,000 characters at 128 bytes per glyph is going to eat up a megabyte of address spaced pretty quickly." (Vector glyphs were still a bit exotic for a conversation like this, that year.)

"And graphics." I pointed at the TV. "How many kilobytes is the graphics mode screen buffer on the 6847, for just fuzzy monochrome on a color TV?"

"Six."

"How would the same resolution graphics in four colors be, if the 6847 supported it, or if you modified the output and added the RAM?"

"An extra bit per pixel, so twelve."

"That takes 12K out of the program space on the 6801 or 6809, just for four colors, and everyone will want a much bigger gamut of color. And resolution at least double what the 6847 offers. 64K was tight to start with, and a megabyte will soon be tight for color graphics. One advantage, I guess, to the 68008 is the implicit upgrade path to the 68000, but 24 bits of address will shortly be too few, also."

"16 megabytes too tight? RAM is expensive," Sharon pointed out.

"If you don't want to be a foundry for other companies' designs, you have to have a base technology where you develop your testing and manufacturing techniques. That's RAM. It pays for itself without even being on the market by helping you get your other products right, faster."

"That kind of thinking'll push the price of RAM right through the floor," Motorola's Bob said with a frown.

"But you won't care, because RAM pays for itself in shortening your development cycles for your profitability products. RAM should be like candy, anyway."

"RAM should be like candy." Bill harrumphed. "I think you've said that before." He reached into his briefcase and pulled out an advanced information datasheet and handed it to me. "Has Denny shown you this?"

The datasheet described the 68010. I scanned it quickly. "No. Can Julia and Mike also take a look at this?"

"Sure. And anyone else in this room, really."

I showed Julia the changes in the addressing mode, allowing 32 bit constant offsets, and the short loop cache mode. 

She tilted her head grinned apologetically. "I guess it's an improvement?"

"Definitely. And the exception frame looks more manageable."

I passed it to Mike, and Bob and Jennifer looked over his shoulder. 

After a quick scan, he looked up. "Why isn't the 68008 based on this? The short loop execution mode would be especially useful when memory's only eight bits wide."

"Timing. Market and management." Bob shrugged.

"If I were you guys, I'd hold the 68008 off until I could make it an 8-bit version of the 68010. In spite of the fact that I personally really want to get my hands on one."

I nodded my agreement with Mike. "Or, if you just have to have an eight-bit 68000 now and this allows testing to complete more quickly, plan and advertise a 68018 that will be an 8-bit 68010."

"What if we have plans for adding more addressing modes and wider math, and dropping the loop mode for a small general cache, in a CPU in the early planning stages?" Bill's face was unreadable. "Not saying we do, but what if?"

I took a deep breath. "You know, extended mode was added to the index post-byte for doing memory indirect on absolute addresses. I'm wondering how much more it would have cost to included direct page in the index post-byte, as well. That would allow using the load effective address instruction to get the address of a direct page variable without using the accumulator. But adding much more would get into negative trade-offs."

"You're not talking about the 6809?"

"Exactly. The 6502 needs two kinds of memory indirect because it's so register poor. And those two kinds were a very strategic choice. The 68000 already effectively has both kinds, because it has lots of indexable registers. It doesn't need more, not considering how much it will cost to test and get right. And it especially doesn't need addressing modes that can be as quickly executed using existing instructions and a register or two. Sure, eight address registers is a shade tight for some uses, but you don't want to clutter the upgrade path to a 64-bit CPU with a bunch of untestable addressing mode."

There was a chorus of cleared throats and exchanged glances.

"Instead, would it cost too much to somehow allow engineers to experiment with variations of your primary designs, to push the envelope?"

"What do you mean?" asked Bill.

"Like a skunkworks, but officially supported."

Motorola's Bob leaned forward. "Assuming we dare put our fab facilities at risk, where are we going to get the manpower?"

"Just let your engineers take up to eight hours a week on blue-sky projects on company time, no questions asked."

Sharon shook her head. "We're already short of time."

"Blue-sky projects give you a chance to figure out better ways to do things. You'll end up being more efficient and closer to on-schedule."

"Hard to believe," Pete complained.

I shrugged. "Well, you guys have the experience, not me. I've said my opinion."

"Okay, we have another addendum." Ms. Philips and Ms. Steward looked up from their writing and interrupted, and Ms. Philips showed Bill what they had. He passed the addendum to Bob, and Bob looked it over and passed it to me.

It consisted of mutual permission to use ideas and concepts we had talked about over the course of a couple of hours that night with a promise of best effort to offer each other consideration. The five of us figured that was more than agreeable, and added it to our agreement contracts.

As we wrapped up, Jesse asked me, "Could you put a Forth interpreter on a 6805?"

"Self-hosted?"

"Of course."

Julia looked up from the notes she and Ms. Steward were arranging to make copies of. 

"Self-hosted?" she asked. "That's where the language runs on the same processor that compiles the code, kind of the opposite of the cross-assembler that runs on the 6800 but produces code for the 6805?"

I nodded. "Yeah. Maybe self-hosted could be done, if you have enough ROM and RAM. The virtual instruction pointer needs more than 8 bits, but self-modifying code might work -- using an extended mode jump where the code writes over the jump address before executing the jump. Cheating, but it might work."

Jesse smirked and I chuckled.

Julia asked, "Can you show me an example?"

She handed me her pad again, and I wrote out some code:

NEXTIP
   LDA IP+1
   STA SELFMO+2 ; direct-threaded
   LDA IP
   STA SELFMO+1
SELFMO
   JMP $EEEE ; provisional target address
* The 16 bit address $EEEE just got overwritten by the target address. 

She looked at it with a frown. "What's the purpose in this?"

"It's the part of the virtual machine emulator where the CPU calls the code to emulate each virtual instruction. And each emulation routine ends in a jump back to NEXT."

She tilted her head. "Sorry. I'm totally lost."

"For example, the routine to add two numbers on the stack would look something like this:

PLUS
   LDX USP ; parameter stack
   LDA 3,X ; low bytes
   ADDA 1,X
   STA 3,X
   LDA 2,X ; high bytes
   ADCA ,X
   STA 2,X
   INX ; drop argument
   INX
   STX USP ; update the stack pointer
   JMP NEXT
"The routine for a jump would look something like this:"
BRANCH
   LDX IP ; IP is pointing at the in-line offset.
   LDA IP+1
   ADDA #2 ; bump past offset
   BCC BRANC0
   INC IP
BRANC0
   ADDA 1,X ; add the low byte of the offset
   STA IP+1
   LDA IP
   ADCA ,X ; and the high byte
   STA IP
   JMP NEXT

"And the routine for nesting calls would look something like this:"

CALL
   LDX RSP ; return address stack
   DEX ; room for old IP
   DEX
   STX RSP
   LDA IP+1
   ADDA #2 ; bump past call address
   BCC CALL0
   INC IP
CALL0
   STA 1,X ; tuck the address to return to away
   LDA IP
   STA ,X

And then I was stuck. 

 "Wait. This isn't going to work."

Jesse chuckled again.

I went back to the NEXT routine. "Yep. I'm forgetting to actually get the jump address in the NEXT routine, and maybe a bit more."

Jesse agreed with a grunt. 

I shook my head and laughed. After staring at the code for NEXTIP for a minute or two while Jesse smirked and Julia looked puzzled, I shook my head. "Not having a sixteen-bit pointer is a real pain." 

Julia met my eyes and sighed. "Don't worry about it. I don't think the eight kilobyte maximum address space is going to leave much room for a program to run in, anyway."

"Yeah, but they're going to eventually make a chip with a full sixteen-bit wide CPU. I want to convince myself of this."

Her forehead creased.

"We need to grab two bytes pointed at by the sixteen bit IP in the direct page."

NEXTIP
   CLR NXADD1+1
   LDA IP+1
   STA NXADD1+2
   INCA
   STA NXADD2+2
   BNE NEXT00
   INC NXADD2+1
NEXT00
   LDA IP
   STA NXADD1+1
   ADDA NXADD2+1
   STA NXADD2+1
NXADD1
   LDA #$EEEE
   STA NXJMP+1
NXADD2
   LDA #$EEEE
   STA NXJMP+2
NXJMP
   JMP $EEEE ; provisional target address
* Had to overwrite lots of addresses.
I sighed. "And that's going to run us out of RAM."

Jesse let out a horse laugh.

"I guess this needs to be done a bit more simply."

"No. I think you nailed it. But put the code up to NXADD1 in ROM, followed by a jump to NXADD1 in RAM." He continued to chuckle.

Julia said, "It's okay. I don't care. We're all tired. Let's go home, or, well, back to your brother's place."

"But I want to work the rest of this out. Borrow from ..." 

She took the Forth listing I had picked back up and her pencil and the sheet of paper I was trying to work on out of my hands while Jesse laughed. 

"You got a real jewel there, Joe," he said. "You better listen to her. And don't worry about the Forth on the 6805. That's about as good as it gets, and as Julia says, it's not much use until we have a 6805 MPU with fourteen bits of address. And I look forward to working with you as an intern, and having you join us when you graduate. I like the way you think. I think we all do." He looked around at the engineers and his managers, and everyone nodded in agreement.

I suddenly turned Japanese and ducked my head. "Sorry. I mean, thanks."

Chapter 14.3: Rocks -- what?


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

Tuesday, September 8, 2020

Backup: 33209: Rocks -- Bit Multiply

Backup of https://joelrees-novels.blogspot.com/2020/09/33209-rocks-bit-multiply.html.

Chapter 14.0 Rocks -- 2805

Chapter 14.1: Rocks -- Bit Multiply


Julia caught my eye with a puzzled look.

"Gotta question?"

She nodded. "The 6805 doesn't have a multiply instruction."

"True."

"Neither does the 6800."

"Right."

"Tiny BASIC and Forth don't multiply 12 by 10 by adding twelve up ten times, do they?"

"No, ..."

"Does it have something to do with that bit multiply you were talking about?"

I looked around at the group of engineers, managers, legal staff, and students, and asked, "Can we take a detour?"

Bill leaned back with has hands behind his head, and an expectant smile, and nodded.

Motorola's Bob said, "Go ahead."

"Can I borrow that Forth listing back?"

Bill picked it up and handed it to me without comment.

I opened it up and leafed through it until I found the USTARS routine on page 17 (SCR 23). I read through the routine, thought for a moment, then set it back down, reaching for a pencil that wasn't there in my shirt pocket.

Julia turned her notepad to a blank page and handed it and her pencil to me.

"Thanks. Say we want to multiply two eight-bit numbers. I'm going to arbitrarily pick eleven and five." I wrote the two numbers down in binary and decimal, vertically, for multiplying by hand, then proceeded to work the product out. "I'll use the method we usually use for decimal, multiplying the multiplicand on top by each column of the multiplier on bottom, and adding them up:

            00001011 => 11 (8+2+1)
          x 00000101 =>  5 (4+1)
-- -------- --------   ---
               c
            00001011 => 11
          0 00000000 =>  0
         00 00101100 => 44 (32+8+4)
(Abbreviating the zeroes.)
-- -------- --------   ---
 0 00000000 00110111 => 55 (32+16+4+2+1)

Julia held her hand out and I gave her back her notepad and pencil.

She proceeded to write out a decimal product:

     5678
   x 4321
---------

     5678
   113560
  1703400
 22712000
---------
 24534638

Mike grumbled, "Grade school."

Julia gave him a glare. "Looking at the fundamentals so I can understand what the computer has to do, Mike!"

He shrugged.

She turned back to me. "Okay, I think I can see how you're doing basically the same thing both ways. So multiplying each column in binary is what you are calling a bit multiply?"

"Sort-of. Maybe. Perhaps more a bit multiply-and-accumulate instruction."

She shook her head with a blank look and handed me back her notepad and pencil.

"Hmm. Let's look at  how the Forth multiply routine works. It says it multiplies the top two 16-bit words on the stack, and puts the low 16 bits of the result back on the stack, keeping the high 16 bits in A and B." I picked the Forth Listing back up and copied the routine out, modifying the comments:


USTARS
    LDA A    #16    ; bits in a word
    PSH A    ; counter in temporary on stack
    CLR A    ; ready to accumulate the product
    CLR B    ; clears carry
    TSX    ; point X to the parameter stack
USTAR2     ; top of loop
    ROR    5,X   ;  shift multiplier, pull last carry in from result
    ROR    6,X   ; leaves low bit of multiplier in carry
    DEC    0,X   ; count down, leaves carry alone
    BMI    USTAR4   ; counted out?
    BCC    USTAR3   ; skip add if low bit is 0
    ADD B    4,X   ; low bit is 1, add
    ADC A    3,X   ; now carry is carry from add
USTAR3 
    ROR A    ; shifts carry from add into result
    ROR B    ; shifts low bit in accumulator into carry
    BRA    USTAR2   ; next bit
USTAR4    ; counted out
    INS    ; remove counter from stack
    RTS


Julia shook her head.

I grinned. "Yeah, it looks like it's out of phase with itself, but that's because it's reusing the multiplier variable to pick up the low bits of the result. Saves space on stack and saves some shifting instructions."

"Out of phase?" Now she gave me a moue.

"Like the loop starts part-way through, because it kind of does. Hmm. Let's write a loop that would look more like what we do on paper." I stopped to think, then started to write and erase and rewrite.

"To avoid confusion, let's not use any tricks. In fact, let's not use the S stack for parameters, either. But there will be one sort-of-trick, shifting the value down in the accumulator is the same as shifting the calculation window up."

"Oh-kay ..." But she looked even more perplexed.

Here's what I ended up with:


* Multiplicand at 2,X:3,X
* Multiplier at 0,X:1,X
USTAR
    LDX PSP ; parameter stack
    DEX ; allocate work space
    DEX
    DEX
    DEX
    DEX
    STX PSP ; just in case
* Multiplicand at 7,X:8,X
* Multiplier at 5,X:6,X
    LDAA #15
    STAA 4,X ; bit count
    CLR 3,X
    CLR 2,X ; result low word
    CLR 1,X
    CLR 0,X ; accumulator, result high word
USTARL
    CLC ; known state
    LDAA #1
    BITA 6,X ; low bit of multiplier
    BEQ USTARN
    LDAB 1,X
    ADDB 8,X ; multiplicand low byte
    STAB 1,X
    LDAB 0,X
    ADCB 7,X ; multiplicand high byte
    STAB 0,X
USTARN
    DEC 4,X
    BMI USTARD
* Relativity --
* shifting the contents right is same as
* shifting the calculation window left.
    ROR 0,X ; moves carry into accumulator
    ROR 1,X
    ROR 2,X ; shift into low word
    ROR 3,X
    LSR 5,X ; shift multiplier down
    ROR 6,X ; for next bit test (relative shift)
    BRA USTARL
USTARD
    LDAA #3 ; 4 bytes to copy
USTARC ; copy result back into stack
    LDAB 0,X
    STAB 5,X
    INX
    DECA
    BPL USTARC
    INX ; drop count from stack
    STX PSP ; restore parameter stack pointer
    RTS


She looked the code over. "Do you have to save and load accumulator B every time through? Nothing else seems to be happening to it and it would save instructions and time."

"Yep."

"And," she paused, "could you use an ANDA instead of a TSTA to test the low bit of the multiplier, since you reload it each time through?"

"Sure."

"Hmmm. In the Forth code, shifting the multiplier right and testing the carry is another way of testing the lowest bit, isn't it?"

"That's right, and it does save a few more instructions."

"On the 6805, you could use a branch if set instruction, couldn't you?"

"I was afraid you were going to ask that."

"It wouldn't work?"

"Well, the multiplier has to be addressed as a direct page variable if you use the BRSET or BRCLR instruction. I assume you would use BRCLR. Other than that, it should work."

She thought for a minute. "Well, using global parameters, ...," and started writing.


    ORG $80
MCAND RMB 2
MPLIER RMB 2
BITCT RMB 1
ACCM RMB 4
*
    ORG $200
USTAR 
    LDA  #15
    STA  BITCT
    CLR ACCM
    CLR ACCM+1
    CLR ACCM+2
    CLR ACCM+3
USTARL
    CLC ; known state
    BRCLR #0,MPLIER,USTARN
    LDA ACCM+1
    ADD MCAND+1
    STA ACCM+1
    LDA ACCM
    ADC MCAND
    STA ACCM
USTARN    DEC BITCT
    BMI USTARD
    ROR MCAND
    ROR MCAND+1
    ROR MCAND+2
    ROR MCAND+3
    LSR MPLIER
    ROR MPLIER+1
    BRA USTARLUSTARD
    RTS


"And an 8-bit multiply probably wouldn't have to save and load the accumulator?"

"I think it wouldn't. Looks good, let's test it later."

She thought some more and started writing again.


USTAR    LDX PSP ; parameter stack
    DEX ; allocate work space
    DEX    DEX
* Multiplicand at 5,X:6,X* Multiplier at 3,X:4,X
    LDAA  #15
    STAA  2,X ; bit count
    LDD #0
    STD 2,X ; result low word
    STD 0,X ; accumulator, result high word
USTARL
    LSR  MPLIER
    ROR  MPLIER+1
    BCC  USTARN
    BEQ  USTARN
    ADDD  7,X
USTARN    DEC 4,X
    BMI USTARD
    RORA ; moves carry into accumulator    RORB
    ROR 0,X ; shift into low word
    ROR 1,X
    BRA USTARLUSTARD
    STD  3,X
    LDD 0,X
    STD 5,X
    INX
    INX
    INX ; drop count from stack
    RTS


"Did I get that right?"

"I think so. Pretty close if not."

"So, would an instruction that adds the source to the accumulator if the carry is set be your bit multiply?"

"Yes and no. If you want to extend the multiply to 32 bits, I'm pretty sure you'll have conflicting uses of the carry."

"Oh. Adding the multiplicand is going to set the carry and overwrite the state of bit 0, so it would only work once."

"Myep. The bit multiply would need to be based on the branch if bit 0 clear or bit test immediate 1 instruction, instead of testing the carry. And we'd want to be able to specify both the multiplier and multiplicand independently, too, if it's going to be extendable."

"And it'd replace just the branch and the add, so it wouldn't really speed things up that much."

"Right. If it's going to speed things up, it also has to shift the multiplier and the accumulator. And the carry out of the bottom bit of the accumulator has to go somewhere, so there's a third memory argument. And shifting into low-order fields after the low-order fields have already been added and shifted is going to double-shift the low-order fields, so I guess trying to make it extendable is just not going to work."

"What if you don't shift the accumulator fields in memory?"

"That's going to make it hard to do one bit at a time."

Ms. Philips cleared her throat. "Bob, have these two just shared things that should have been trade secrets?"

I looked up. "I'm sure your engineers have been down this road before."

Greg nodded. "We have. I must admit, it took me longer, but I was working by myself and making sure I had enough notes to explain what would happen to my manager."

"Gate counts, power dissipation, that kind of thing?"

"Right."

Jesse leaned forward with a grin. "Dang. And you two do this kind of thing for fun."

I grinned back.

Julia sighed. "He does." And she smirked. "Oh, it's kind of fun watching him go down the rabbit holes, and sometimes going down there with him."

That got more whistles and some "Hey, hey, hey!" comments.





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


Monday, August 24, 2020

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 b15b14b13b12 b11b10b9b8 b7b6b5b4 b3b2b1b0
A:
A7A6A5A4 A3A2A1A0
X:
X7X6X5X4 X3X2X1X0
SP:00000000 1(SP6)SP5SP4 SP3SP2SP1SP0
PC: ------PC12 PC11PC10PC9PC8 PC7PC6PC5PC4 PC3PC2PC1PC0

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

2805 register b15b14b13b12 b11b10b9b8 b7b6b5b4 b3b2b1b0
A:
A7A6A5A4 A3A2A1A0
X:
X7X6X5X4 X3X2X1X0
U:00000000 1(U6)U5U4 U3U2U1U0
SP:00000001 00SP5SP4 SP3SP2SP1SP0
PC: ------PC12 PC11PC10PC9PC8 PC7PC6PC5PC4 PC3PC2PC1PC0

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

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


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 b15b14b13b12 b11b10b9b8 b7b6b5b4 b3b2b1b0
A:
A7A6A5A4 A3A2A1A0
X:
X7X6X5X4 X3X2X1X0
SP:00000000 1(SP6)SP5SP4 SP3SP2SP1SP0
PC: ------PC12 PC11PC10PC9PC8 PC7PC6PC5PC4 PC3PC2PC1PC0

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

2805 register b15b14b13b12 b11b10b9b8 b7b6b5b4 b3b2b1b0
A:
A7A6A5A4 A3A2A1A0
X:
X7X6X5X4 X3X2X1X0
U:00000000 1(U6)U5U4 U3U2U1U0
SP:00000001 00SP5SP4 SP3SP2SP1SP0
PC: ------PC12 PC11PC10PC9PC8 PC7PC6PC5PC4 PC3PC2PC1PC0

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

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