Sunday, April 26, 2020

33209: Headwinds -- License

Chapter 11.6: Headwinds -- Project

Chapter 11.7: Headwinds -- License


"Well, I don't guess it really matters who wrote it. It's easy enough to find fault with other people's work. Even with non-optimal keyboard decoding you can still do a lot with one of these computers. But I'm going to use timers and interrupts, and I'm going to recommend that approach."

Wallace asked, "So do you think we should use a separate keyboard controller or let the main CPU read the keyboard?"

"I think that's  something we each need to figure out for ourselves. For me, I'm wanting to try keyboard decoding using several different CPUs, but I don't think I have enough time. So I haven't decided yet. But I am planning on keeping the seven-segment displays for status readout, either way."

Mike asked, "But if we don't use the best design now, it'll cost more money and more time to do it over again later, right?"

"Time is money," Dr. Brown deadpanned. Then he grinned. "But there will be lots of time later to build something better. And/or money to buy it."

I nodded my agreement. "Definitely. A lot of people don't want to accept it, but, within maybe ten years, pretty much every desk in every office will have at least one computer, and there'll be a lot of hardware turnover, too."

(What seems obvious now was far from obvious then. And the real me was not this prescient. Or maybe just not as eloquent. No, I really did not get this. I was always reaching for perfection in the first step -- I wanted a 32/64 bit 6809 running at 4 GHz to write my perfect operating system for.)

Mr. Wells cleared his throat. "I've overheard our sales engineers talk about such things at lunch, but isn't that just a little bit of exaggeration? I mean, word processors are a hard enough sell, why would so many people want plain-old microcomputers?"

"Giselle, what do you and Dad use that Color Computer for?"

"Besides learning BASIC?"

"Yeah, besides learning BASIC. "

"Well, Julia and I are typing up a lot of Dad's handouts and tests. We've got records of grades, and a BASIC program that averages them."

"So, typewriter and calculator. Do you remember when Denny bought his first programmable HP calculator?"

"The one that cost him almost a month's wages?"

 "Yeah, that one."

"He used it to study engineering. He said it replaced several big, thick, heavy, expensive books full of constants and formulas."

"Yep. And you are aware that your microcomputer can do a lot of what that calculator did, and can be programmed to do a lot more?"

"Yeah, but I haven't learned how to use it all, yet."

I turned back to Mr. Wells. "So microcomputers will quickly replace calculators and typewriters, and quite a lot more. They aren't able to do all that your word processing minicomputers do, yet, but they're cheaper, and next year's model will be more powerful. In ten years, they'll be cheap enough ordinary people will be buying new microcomputers every two to three years."

Giselle said, "That's insane!"

"I think so, too, but it will be common sense for many people. And word processing software for them will beat what our current word processors can do, hands down."

(More things that could have been, had a certain very large software company not been fixated on social engineering via virtual monopoly, but I guess that's water under the bridge now, as well.)

Ms. Philips shook her head. "Buying a new computer every other year? But if they're built well, they should last much longer."

"You know, we really don't know how to build a computer well. We focus on what we understand, but computers can do so much more than we presently understand that we focus on the wrong things when we design them. And the hardware improves. It's not so much that they wear out as it is that the new models can do so much more so much better, and, since people will often be using them to compete in the marketplace, they'll have to keep buying the latest models just to keep competitive."

"That is just insane." Giselle repeated herself. "Why would computers have to change so much?"

"Look at design of the 6800 and the 6801. I think the team that designed it did a good job, but look at all the opportunities they missed."

Both Ms. Philips and Ms. Steward just gave me blank looks.

"Let's look at the 6800 op-code map in the datasheet," I borrowed one for a minute and held it up, "the binary operators follow a pattern." I turned to the chalkboard. "The high bit is 1 for binary ops. The next bit, bit 6, is 0 for accumulator A, and 1 for accumulator B. BIts 5 and 4 encode the target like this,
UAMMXXXX, where U==1 for binary, A=1 for accumulator B, XXXX is the operator, and MM is the mode:
  1. 1A00: Immediate
  2. 1A01: Direct page (page 0) address ($00nn)
  3. 1A10: Index mode address (nn,X)
  4. 1A11: Extended (absolute) address ($nnnn)
(Refer to "A Little about the 6800" for the maps.)

"Well, except for the call instructions, JSR. And the instructions that target the stack and index registers. They don't have the accumulators as operands."

I stopped to think, then commented, partly to myself, "Stack register, index register, program counter. PC is the instruction pointer. Jump subroutine is the call. Essentially, pointer registers."

Nodding to myself, I continued: "I think the design engineers were worried they would need more op-codes, so they didn't follow the same pattern on the unary instructions. Or they were looking at the accumulator targets instead of the operands in memory for their patterns, and saw what I think is a less important pattern.

"Anyway, for unary operators, the high bit is 0 and bit 6 is 1, and bit 5 is 0 for accumulators, bit 4 selecting A or B, and bit 5 is 1 for the memory operands, bit 4 selecting indexed or extended mode,
U1MMXXXX, where U==0 for unary, XXXX is the operator, and MM is the mode:
  1. 0100: Accumulator A
  2. 0101: Accumulator B
  3. 0110: Index mode address (nn,X)
  4. 0111: Extended (absolute) address ($nnnn)
"Note the '01' at the left. That 0 on the top partially selects unary over binary, and the 1 fcompletes the selection, so to speak."

Everyone but Mark and Jeff, Dr. Brown, Dave, Jayne, and the contingent from IBM were giving my blank looks. Dr. Brown was giving me an eye-roll.

"Uhm, let's look at the negate and subtract operators, as examples. This is what we have:

OP mode(operation):6800 op-code($80)J3800 op-code
SUBA immediate(A-#$xx=>A):10000000 ($80)same
SUBA direct(A-@($xx)=>A):10010000 ($90)same
SUBA indexed(A-@($xx,X)=>A):10000000 ($A0)same
SUBA extended(A-@($xxxx)=>A):10010000 ($B0)same
SUBB immediate(B-#$xx=>B):11000000 ($C0)same
SUBB direct(B-@($xx)=>B):11010000 ($D0)same
SUBB indexed(B-@($xx,X)=>B):10000000 ($E0)same
SUBB extended(B-@($xxxx)=>B):10010000 ($F0)same
NEGA($100-A=>A):01000000 ($40)00000000 ($00)
NEGB($100-B=>B):01010000 ($50)01000000 ($40)
NEG direct($100-@($xx)=>@($xx)):--------01010000 ($50)
NEG indexed($100-@($xx,X)=>@($xx,X)):10000000 ($60)same
NEG extended($100-@($xxxx)=>@($xxxx)):10010000 ($70)same

This took me a little bit of time to write on the chalkboard, but, when I turned around, I thought I was getting glimmers of recognition.

"They fit the direct mode unary instructions into the 6809, but they made a number of other changes when they did so. I think, by moving the ranks around, it would have been possible to fit op-codes for direct-mode unary operators into the op-code map of the 6800. I don't have the experience, so I can't say so for sure, but I think it should have made the instruction decode circuits simpler, which might have at least partially made up for the circuitry for the extra op-codes."

Mr. Wells stopped me. "What's the J3800?"

"I've given my theoretical revisions to the 6800 a couple of names. This one, that is object code incompatible, I call the J3800. Heh. 'J' because Rockwell is putting R on the heads of some of their part numbers."

He blinked. "It seems to me," he paused here for emphasis, "like you're going to a lot of trouble to work out  something that might, theoretically, have saved a little bit of circuitry on the wafer, but is now water under the bridge. Why?"

"Bear with me for a minute, please. If Motorola had encoded the instructions this other way, the first pattern would have partially decoded most of the instruction set, where now it only decodes about half:
UAMMXXXX, where
  • U==1: binary
  • U==0: unary
  • A==1: B accumulator
  • A==0: A accumulator
  • MM==00: immediate
  • MM==01: direct
  • MM==10: indexed
  • MM==11: extended
Terry  stood up. "But in the unary, there's no immediate mode."

"Uhm, what I'm seeing is that the unary operators mostly imply an implicit immediate, well, buried-in-the-instruction value of one. Negate implies an immediate hexadecimal $100, complement implies an immediate hex $FF, and clear and test imply an immediate zero. So maybe not immediate in the sense of an explicit value immediately following the first byte of the op-code, but immediate in the sense that it is part of the instruction that gets decoded."

Terry tilted his head and squinted, frowning.

"So, ...," Mr. Wells prompted.

"So, it's not just that the instructions would have been more uniform. I've been looking at the internal RAM on the 6801 SOCs, and thinking things like 'Lack of direct mode addressing on the unaries costs precious time in tight loops.' And it demotivates putting certain globals there. What's more, if the unary instructions included direct mode, for a lot of programs the direct page could be selected as a separate memory space, if the processor version supported it."

Terry looked back at Mr. Wells and shrugged. Mr. Goldwater was suppressing a smirk. Ms. Bight was looking embarrassed. Dave and Jayne looked up from the notes they were taking. Ms. Steward and Ms. Philips were still quietly discussing something and writing down notes.

"One of the less impressive aspects of the 6800 is that it often feels tight to be facing the 64K address limit and trying to stuff code, data, and I/O into it. Splitting the code out from the data is a fairly straightforward concept, and could be done with a status bit that gets set to 1 on instruction fetches and cleared to zero on data fetches.

"Splitting the stack out is a great idea for optimizing calls and returns and making them closer to plain jumps in cycle count cost. It's also a possible route for protecting the return pointer from coding errors and deliberate attacks, but ordinary stack frame handling creates issues with that.

"Splitting the direct page out would allow the creation of a bunch of pseudo-registers-- faster to access, less traffic on the external buses, global in scope. You could fill the data space with RAM without reserving port space in many hardware application designs. Bank switching could be achieved without the ports for the bank switching being in the space being switched in and out."

(I'll admit that the real me sensed these things early on, but he sure couldn't put them into words this way until much later.)

Terry looked back again. Mr. Wells raised his eyebrows, and Terry nodded and sat down.

Ms. Steward looked up. "So you're talking about an incompatible revision."

"Uhm, ..."

"Do you think you could do something similar and keep it compatible?"

"I think so. It would require a bit of complexity in the decode circuitry, but there is room in rank 1 for most of the missing op-codes. Give me a minute, here." I turned back to the chalkboard, found an empty space, and put up another table. While I was working on this table, Ms. Steward went to her camera and took close-ups of my work on the chalkboard.

*(Reserved, undefined; **6801; *+2801 extensions)
J2801
Inherent
Operators
Ranks 0-3

Status, XAccumulator,
 Direct Unary
BranchStack, et. al.
$0X$1X$2X$3X
0000XXXX0001XXXX0010XXXX0011XXXX
$X000XX:
0000
*(HCF=$00)SBA=$10BRA=$20TSX=$30
$X100XX:
0001
NOP=$01CBA=$11**BRN=$21INS=$31
$X200XX:
0010
*+NEGd=($02)*+RORd=$12BHI=$22PULA=$32
$X300XX:
0011
*+ASRd=($03)*+COMd=$13BLS=$23PULB=$33
$X400XX:
0100
**LSRD=$04*+LSRd=$14BCC=$24DES=$34
$X500XX:
0101
**ASLD=$05*+ROLd=$15BCS=$25TXS=$35
$X600XX:
0110
TAP=$06TAB=$16BNE=$26PSHA=$36
$X700XX:
0111
TPA=$07TBA=$17BEQ=$27PSHB=$37
$X800XX:
1000
INX=$08*+ASLd=$18BVC=$28**PULX=$38
$X900XX:
1001
DEX=$09DAA=$19BVS=$29RTS=$39
$XA00XX:
1010
CLV=$0A*+DECd=$1ABPL=$2A **ABX=$3A
$XB00XX:
1011
SEV=$0BABA=$1BBMI=$2BRTI=$3B
$XC00XX:
1100
CLC=$0C*+INCd=$1CBGE=$2C**PSHX=$3C
$XD00XX:
1101
SEC=$0D*+TSTd=$1DBLT=$2D**MUL=$3D
$XE00XX:
1110
CLI=$0E*+JMPd=$1EBGT=$2EWAI=$3E
$XF00XX:
1111
SEI=$0F*+CLRd=$1FBLE=$2FSWI=$3F

Ms Bight was no longer looking embarrassed.

Mr. Goldwater leaned forward. "So, I/O instructions, a-la the 8080, and you're also implying segments, a-la the 8086."

"Heaven help us." I looked down and scratched my head. "This is basically for SOCs, so I'm thinking it would be possible to separate the segmentation from the CPU itself in the design tools, as God intended -- I mean, according to good design practices."

I grinned and waited for the snickering to die down. "Well, a good God would intend good design practices more than bad, I think. Sorry. That wasn't called for. Every step that leads forward is not to be regretted too much. Uhm, yeah. I'd rather not clutter the instruction map with segment register instructions that would tempt the programmer to make evil things like non-linear pointers.

The IBM contingent chuckled again, and Mr. Goldwater rolled his eyes.

"Evil." I cleared my throat and grinned an embarrassed grin again. "Anyway, evil or not, with the direct page separable, all the bits to control the address space could potentially be addressed as port I/O bits in the direct page, and there would be no need for special I/O instructions. Provide enough signals to separate the segments in the architecture, and the rest of memory management could be done in I/O -- several options, including nothing but address space separation, or simple bank switching, or a full MMU like the 6829."

Ms. Bight was nodding in agreement. "Helping expand the address space. So, say, what happens if the stack overflows?"

I took a deep breath. "I'm thinking that could be part of the SOC, too, at least for this kind of processor. If you have a signal that says 'this is STACK space', you can have a set of registers in I/O space that set current process limits, including limits on the stack.

"When the stack pointer pushes or pops past the limit, an interrupt occurs, and either the processor goes to superviser state, so the memory map switches to supervisor mode before trying to save on a no-longer completely valid stack, or the limit is set a little in from the actual end, so that there is always room to save the registers on a stack overflow.

"Or something like that.

"Another option might be a small-ish stack cache that automatically spills into and fills from main memory when the top gets within range of the ends of the cache, but that might be overkill on a small 8-bit processor like this.

"Anyway ... the point is that we still have a lot of room for progress before we can or should start thinking that we can build microcomputers well. So we have to be expecting that what we build now will be superseded.

"Once we know more about what works well with the most common applications for a processor, we might start baking the MMU details into the architecture at the CPU instruction level, but, especially with a controller CPU intended for a wide range of SOCs, port I/O can do the job, especially if there is support like this in the instruction set."

Mr. Goldwater was nodding in some level of satisfaction. "Separate I/O instructions like the 8080, but not like the 8080, because it's an actual address segment. Although the Z-80 heads this direction, too, in its own way."

"Something like that."

Jennifer raised her hand. "I'm not complaining, but it seems hard to believe that computers will change as fast as you're saying. How can we even be sure our computers are working if they keep that kind of pace of innovation?"

"That's an important question, and it's actually a good reason for us to be building our own. Simply stated, a if you build a simple computer yourself, it's easier to make sure it's running right than a more powerful computer. Then the simpler computer gives you something to build on -- including tools to make sure a more powerful computer is working right. Other people will throw their computers away, but I'm going to keep mine around, as steppingstones to get me safely back to the next level when the next level doesn't work right the first time."

George said, "If that's true, I guess starting small makes sense.

Now Dr. Brown spoke up. "So, Joe, you're running a bit far down that road. Are you suggesting that you'll be able to use an old computer to make sure there are no bugs in a new computer?"

"No, not by myself. Shoot, the Micro Chroma 68 over there is more complicated than I'd be able to test by myself in a year of working full-time at it.

"We'll have to help each other, but we'll definitely need to use the older computers to check the new ones, or we'll be unable to prevent friends, enemies, corporate spies, organized crime, sales-crews, and government agents from having access to the computers we put on the communications networks.

"Helping each other is part of the reason we are here now."

Mike was leaning back with arms tightly folded. "Well, that's all well and good, but, since you bring up helping each other, what I really want to know is who owns all the intellectual property?"

"Intellectual property?" I mugged ignorance.

"Yeah. Intellectual property. Patents. Copyrights. Trademarks. Intellectual property."

I shrugged. "Motorola owns their batwing M. All trademarks are property of the company that owns them. Likewise copyrights and patents. We aren't going to engage in printing and distributing datasheets for profit, are we?"

"That's not what I mean."

"Uhm, we aren't planning on using our computers to record and share music illegally, are we?"

"Definitely not what I'm talking about."

"Patents? I suppose we'll need to check with the companies that supply us, if we decide to put something we make here into commercial production. But I'm pretty sure we won't be stepping on any toes just to build one-offs for our own education."

"Now you're getting warm."

"What do you think, Ms. Philips? Do you think we can operate within the bounds of common sense and keep from infringing patents?"

"That will be somewhat up to you guys."

"Should we all stand and raise our right hands and promise to try to act within the bounds of law and common sense relative to patents? Serious question."

President Flyer spoke up. "The boards of both colleges have been discussing this, but haven't come to proper conclusions yet about what kinds of commitments we should ask for. We probably will, relative to the project class this may turn into, decide on something. In the meantime, we should probably just ask all of you students who are participating to be careful, and ask questions if you think something you do might get close to infringing."

"But what about stuff we make?" Mike insisted

"Don't share what you want to claim patents on," I said. "If you share, let the person you share with know where you got it, and how far you feel comfortable letting them share. And don't claim to own things you don't own. Common sense."

Ms. Philips sighed. "Regretfully, such common sense is a rarity in the industry. We'll contact your school board and see if we can help. Maybe TI and IBM can also."

Mr. Wells said, "My boss is arranging for that."

Jayne concurred. "We'll be in contact, as well. In the meantime, Joe, can you write down what you just said about sharing, copy it, and get all the students who participate to at least acknowledge the intent?"

"Sure."

"I've got it written down," Julia lifted her notes. "You want to check it?"

"Thanks." I moved over to the desk and read her notes out loud. "That's what I said."
  
Mike had another complaint. "It seems to me like you just shared something without saying how much others in this room can share it."

"J2800? J3800? Half-baked ideas that might have limited use to Motorola and maybe one of their second-sources, none of whom are here today?"

Ms. Philips tilted her head and raised an eyebrow. "Joe, Mike has a point. Give us some time to talk with you about that later, okay?"

Jayne added, "Dave and I'll want to have a similar discussion with you on that."

"Sure. But ... Oh ... well, yeah. Sure."


[Backed up at https://joel-rees-economics.blogspot.com/2020/04/bk-33209-headwinds-license.html.
Some notes in https://joel-rees-economics.blogspot.com/2020/04/notes-33209-headwinds-license.html.]


No comments:

Post a Comment

33209: Discovering the 6800 -- Parents and Polygamy

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