Chapter 13.3: Straits -- Status Display
Chapter 13.4: Straits -- Keyboard Decoding
"Much improved last night." Julia's mom gave me an approving smile as she met me at their front door.
I grinned lopsidedly and bussed her cheek as I ducked in. "Somebody must have been peeking through the blinds?"
The smile she gave me in answer might have been a little smug.
Julia came into the living room carrying her backpack on a shoulder. "I threatened to do all our kissing somewhere else, and Mom didn't even bat an eyelash," she complained.
"You two belong together. You can kiss anywhere." Mrs. Cisneros gave her daughter a quick hug and a kiss and sent us off with a "Have a good time studying together today."
I held the passenger-side front door of the Colt open and Julia climbed in.
She leaned her seat back and put her backpack in the back seat as I walked around and climbed in the driver's seat.
"How about if I drive tomorrow?"
"Your folks won't need your car?"
The radio came on as I started the engine.
"I can usually, I just want to drive. tomorrow."
"Okay. I'll be waiting for you."
DJ talk and music played in the background as I drove and we talked about the day's schedule and other things.
"I don't particularly like this song," Julia said as the radio played the chorus of Mary MacGregor's hit rendition of "Torn between Two Lovers".
"Mmmyeah. It does kind of get stuck in the head, and the lyrics aren't all that great"
Julia was silent for a moment, then asked, "Do you think it would be breaking rules to love two people?"
I thought for a minute. "My automatic reaction is that's not the right kind of love if it's breaking any real rules."
"Platonic okay, Plutonic no." She gave me a shy-sly grin as she reached over to the radio to change stations.
"Heh."
The station she picked was playing Boston's "More Than a Feeling", and we listened to it in silence for a bit, holding hands on the gearshift lever.
"Hey. I'm going to make everyone rewire their keyboard controllers today. I hope they won't be too mad."
"Why's that?"
"Not enough port bits. Need to add a buffer and share one port between the keyboard and display, to free up a port to talk with the main CPU."
"I might be a little put out, too."
She tickled my palm, and I missed a downshift, letting the engine lug for a moment while I returned the tickle.
*****
In the lab after classes, I was going to ask first off if anyone in our group had ideas about how to shorten the interrupt handling routines for the displays, and ask after that if anyone had noticed that 32 pins of parallel I/O wasn't really enough. But, when Julia and I arrived, a group was gathered around Winston. He was testing his keyboard and seven-segment displays, and when he held a key down, it would interfere with the display, causing it to show stray segments.
He looked up at me. "I don't think we have enough output lines."
"Yeah, ...," I hedged.
Bob had a suggestion. "I'm thinking we could add two 'LS138s and control them both from one parallel port to do the scanning -- one for the display anodes and one for one side of the keyboard matrix."
"Oh. That could work." I nodded absently. "Can we get a look at the problem before we go looking for solutions?"
"Then it is a bug." Winston half-asserted, half-asked.
"Oh, yeah. I was planning on looking at it first or second thing today when everyone comes. Can you explain it to everyone, Winston?"
"Why me?" he complained, half-joking, half-resigned, as he picked up his schematics and went to the chalkboard. He started by putting up the working diagram from the day before while we waited for more of the group to come.
When he was done with that, and most of our group had arrived, he gave me a nod, and I nodded to Doctor Brown, and Doctor Brown said, "Any time you're ready."
Winston went back to his lab table and picked up his keyboard and controller, and announced, "Ground control, we have a problem."
Several of us chuckled as Winston proceeded to demonstrate how holding keys down would change a number shown on the display to some unintended shape.
"That's cool!" Carlos enthused.
"Solution one," Doctor Brown intoned with raised eyebrows. "It's not a bug, it's a feature."
Everyone laughed except Winston, who rolled his eyes before grinning lopsidedly. "That is one way of looking at it," he grudgingly admitted.
"Yeah," Doctor Brown grinned, "but I guess let's not use that solution this time."
"So, why does this happen?" I asked. "Show us what your circuit looks like."
Winston erased and redrew part of the circuit:
"So, we could ask Winston why he added another buffer," I pointed out, semi-rhetorically. "Or we could ask everyone if we all understand why. Suzanne, can you tell us why?"
She hesitated, than suggested, "If we don't have that, how does the computer know what key the controller decoded?"
"Exactly. Thanks. So, Winston, now what's the problem?"
"We don't have enough bits of I/O, and I have used one of the ports for the displays as one of the ports for the keyboard matrix." He erased and redrew another part of the diagram to show what he had.
"I was hoping that the scan could be done quickly enough to not interfere, but just holding the keys down messes things up."
"Yeah. So, Bob, you had a suggestion, right?"
"Jennifer thinks we should be able to do it without any additional LSI chips, but I think we need two 74LS138s."
"Can you diagram that?"
"Well, first, I think we need another bit for the main CPU interface."
"Why's that?"
Jennifer replied, "Main CPU has to be able to tell the controller what it's supposed to do, so it needs at least one bit of control."
Bob and Jennifer worked together to quickly put the following diagram up:
"Hmm. Let's keep that in mind. So, what about the 'LS138 one-of-eight demultiplexors?"
Bob modified parts of the diagram, to add the two demultiplexors:
"This would allow both the keyboard and the display to be addressed at the same time," Bob explained. "But if I shut down the displays for a hundred microseconds or so for the keyboard scan, I can share the select lines for the 'LS138s, and save a couple more port bits."
"Great. Thanks. Now I think Jennifer is right that, with a bit of really careful timing, and a bit of care in how we set up the ports for the matrix and displays, we could reduce the interference so that you could hardly tell that holding a key down is causing stray LEDs to light. But it would be kind of sensitive to pull-up or pull-down resistor values, and cheap parts might not work. And we might need to add diodes, as well."
Jennifer looked a little put-out at my conjecture.
"I'm not saying she shouldn't do it, just that that there are trade-offs, and I'm not prepared to dig into that right now. Back to the 'LS138s, how will they affect our code? Bob and Jennifer, let someone else answer."
Bob and Jennifer both nodded in agreement.
Javier finally spoke up. "Instead of shifting the matrix strobe bit and the display select bit on their ports, we count them?"
"Good. What does the counting look like?"
Everyone thought for a bit, and then Javier answered: "Counting for one of those can be just an INC instruction. He stood up and wrote in a blank space on the chalkboard,
COLSTB
INC PORTC ; STROBE NEXT
But the other is going to be adding sixteen or something, depending on the bits used, right?" He wrote, to the side of the first,
COLSTB
LDA PORTC ; GET STROBE
ADD #$10 ; NEXT COLUMN
STA PORTC ; NEW STROBE
I nodded. "Exactly. Or, if, as Bob mentioned, he shared select lines between the two 'LS138s, both could be increments. So we'll look at that, too, but anyone have another way to do this? Jeff? Mark?"
"We're kind of with Mike on this," Jeff replied.
I turned to Mike, and he responded, "I'm planning on sharing a port between the keyboard and the displays, but I'll use a single eight-bit buffer to disable the keyboard input lines most of the time. There are only seven digits, so only seven anode selects, and I can use the extra bit from the display select port to shut off the keyboard matrix except when I'm reading it."
"How about the control line for the main CPU to read the keyboard?"
"The Micro Chroma 68 keyboard interface only uses seven bits of data, so the high bit can be the key input strobe, like the Micro Chroma 68 documentation shows. I think that'll be enough." Mike stood up at a blank panel and sketched out his idea.
"Very good. Now we have at least a couple of different approaches that might
work."
Larry asked, "Would it work to use two 6805s?"
"What do you think?"
"I guess we'd need a way for the main CPU to talk to the second controller."
"Sure. And that may have some advantages, as well."
Kyle laughed. "So we wouldn't need to bother with the timer and interrupts."
"We got 'em," Tim replied. "Might as well use 'em."
Terry asked, "How about using a serial port for talking to the main CPU?"
"The Micro Chroma 68 design is looking for the keyboard on a parallel port," I pointed out. "But if we modify the design and the monitor ROM, we should be able to get a serial interface to work, as well."
Chuck objected, "The 6805 doesn't have a serial port."
"True."
After a moment of thought, he said, "But I guess a single bit of a parallel port could work, the way it's done on the Color Computer."
"Bit-banging. We could put the 6805's bit operators to good use there, I think."
Chuck nodded.
Carlos asked, "Which are you going to use?"
"I'll ask Julia later."
Several of the group chuckled.
"Because it's her keyboard and computer, not mine."
I turned and grinned at Julia, and she creased her brow and gave me a quizzical look.
Lupe raised a question -- "Does the Micro Chroma 68 use this status display we're adding?"
"Not with the current software, but, again, we can modify the software to use it, if we want to."
"Then maybe we don't really want the display on the keyboard controllers we're building now?"
"That
is definitely a design option," I concurred. "Or, if you want the display but want to do it another way, you could add a 6821 to the mainboard and have the mainboard
CPU control it directly."
Tanya complained, "So, basically, for the last three days, we've been on a wild goose chase."
"Make that, we've been exploring
options," I reinterpreted. "And learning how to use a timer interrupt,
so we can use timed samples instead of riding the port to debounce the keyboard
matrix. And looking deeper into what we might want to build."
Larry said, "Okay, so can we get back to debouncing the keyboard now? I'm kind of interested in that. Can we use the same timer setup that we're using for the display to sample the keyboard
matrix and debounce it?"
"Explain."
"The whole point of the debounce is to be sure we read one keypress as one keypress? We could remember which key we saw in a variable, and check it on the next timer interrupt?"
"How long do we wait to accept a keypress?"
Julia dug into her notes and recited, "300 words per minute is five words per second. At six letters per word, that's thirty keys pressed a second, or one thirtieth of a second."
I reached over and squeezed her hand, and she gave me a lopsided smile and a sigh.
Terry added, "That's about thirty-three milliseconds, so it's about thirty-three interrupts, the way we've set up the timer for the displays."
Freddie asked, "Can a key bounce take more than a millisecond to settle?"
Suzanne suggested, "We can count interrupts to time a keypress. Maybe sixteen interrupts is good to call it debounced."
I added, "Counting interrupts is good, and we can experiment with the duration, and we might even want to add keyboard repeat function based on counting timer interrupts."
"Don't make things too complicated," Doctor Brown warned me.
"Hmm. Maybe we should try to describe the steps the interrupt handler routine is going to go through before we talk about keyboard repeat and rollover."
"Flowchart?" Tanya asked.
"How about you draw it?"
"I don't know what to draw."
"We can figure that out as a class."
Pat suggested, "How about pseudo-code?"
"Okay, you write pseudo-code while Tanya draws the flow-chart."
George laughed. "If you keep making people who suggest things work, everybody'll quit suggesting things."
I tilted my head. "I think we're all here to work, and helping with the notes is an opportunity for work, like any other."
I don't know if that was a very good sales pitch, but Tanya and Pat both stood up and cleaned up panes of the chalkboard to work on.
"What's the first thing our interrupt response routine does?"
"Clear the interrupt mask?" Larry suggested.
"What happens if the next interrupt comes before we're done?"
Everyone thought for a bit.
"Should I try to answer that?" Bob asked.
"Sure, go ahead."
"We lose track of part of the start of what the first interrupt was trying to work on."
"That's the underlying problem. What does the user see happening?"
"Uhm, I think there would be missed keys. And the display might lose digits."
"I think you're on target."
"So when should we enable interrupts?" Suzanne asked. "If we keep them disabled too long, that will also cause missed interrupts and missed keys."
Mike responded, "Missed interrupts, but keys can still be caught and display digits are less likely to be dropped, I think. So, enabling should be just before we return, I guess."
I agreed.
"And," he continued, we need to keep the interrupt routine as short as possible."
"Exactly."
"If that's the case, I guess we probably don't want to be translating the display digits to segment images at interrupt time."
"Okay."
"What did Mike just say?" Julia asked.
"Thank you again, Julia," Tanya applauded.
Bob replied, "SEGTBL has the segment images. I think Mike is suggesting that, instead of keeping a buffer full of the numeric values to display, we should keep a buffer full of the corresponding element of SEGTBL."
"Yeah," Mike confirmed. Although, I think it's just one or two instructions saved."
I added, "I think it also makes the display more flexible, but we'll talk about that later. Right now, it's the principle of the thing. Do we want to take time in the interrupt response to decode the keyboard?"
Pat hesitantly raised her hand, and Mike said, "Just ask, Pat."
"No? But how do we remember what key we're trying to debounce?"
I looked at Doctor Brown, and he shrugged.
I hesitated. "Well, maybe we don't exactly want to remember which key."
*~*~*~*~*
Again, just how prescient should I imply, or claim, that I might have been?
Sure, the real me was prescient. I understood far more than the limited exposure I had in high school and during my time at Radio Shack might explain. I'm sure I brought a lot of that knowledge with me from the pre-existence -- from the world before birth -- into this world. But would I really have been able to work this one out in this world's technology without more experience?
Experience wins over theory any time you want to make something that actually works, and what I had in the previous world
would have been more theory and principle, not so much application and
experience, and definitely not experience colored and transmorgrified by the
real-world reductions into -- implementations of -- real technology that
were invented in this world since the time I was born.
Even
had I been one of the in-crowd there which prepped the individuals who
would be leaders of the industry in our present world, things changed
drastically when the tech was implemented here. If you've ever worked on a systems development team, you know things always change in implementation.
And I suspect I was a rebel there, too.
I
always had trouble in school with the question of how much I wanted to
sully my understanding of principle with the details of real-world
implementations. I knew my hesitance was worrying too much about what I would ultimately find relevant,
but without experience who knows what is irrelevant?
Our best theories in this world fall so far short, even of what we knew then, not to mention falling so completely short of what God knows, understands, and does. If theories fall short, so goes the implementation.
It doesn't matter. For the purposes of this novel, the me of this story must have been able to lead this discussion, or he could not have done what he had to do. But he has good company. There are other superhumans in this group.
*~*~*~*~*
Sheryl voiced the doubts most of the group had -- "How do we debounce a keypress we don't even know we've seen?"
"Good question." I turned it back to her. "What is that microprocessor going to see when it scans the keyboard matrix?"
Sheryl thought and then replied. "A whole bunch of zeroes and one one."
"One one? Sounds like a dog barking."
Everyone looked at me questioningly.
"Japanese joke. Woof-woof is wan-wan in Japanese. Sorry. Never mind."
Sheryl wasn't the only one shaking her head, but she replied. "Just one, I think."
I looked hopefully at Julia for support, but she just gave me a smirk and rolled her eyes.
"Does everyone agree?" I asked.
We had some nods and some blank looks.
"Okay, let's look at some possible code for this. We'll assume Mike's buffer for separation, with the keyboard matrix enabled. SHARED is the port shared for strobing the keyboard and setting the display segments, and KBDIN is the other edge of the matrix." I pointed to the buffers as I mentioned them. "Scanning will begin something like this," I erased a panel and wrote
SEC
STBLUP
ROL SHARED
LDA KBDIN
"What happens next?"
"Mike?" Winston probed.
"I know what I'm doing. We all need to think about this."
Larry said, "Well, the natural response is to wait for a one, but we have to look on seven other rows, too. And Joe keeps harping about busy-waiting, so I don't think that's what he thinks we should do."
"You can busy-wait if you choose. I'm just trying to point out how to sample instead."
"Sample?" Terry piped up. "If we're going to sample, we need to record all the samples."
I held up the chalk, and she stood and took it, then went to the chalkboard and added to what I had written:
KBDST RMB 8
*
LDX KBDST ; STATE ARRAY
CLR SHARED
SEC ; READY TO STROBE
STBLUP
ROL SHARED ; STROBE
BCS KBDDUN ; DONE YET?
LDA KBDIN ; COLUMN STATE
STA ,X ; SAVE IT
INX ; NEXT
BRA STBLUP
KBDDUN
"That records the entire keyboard state. First I point X to the keyboard state array in page zero, I mean, direct page, RAM. Then I clear the shared port so we can shift the strobe across it. Then I set the carry flag to be shifted in.
"Rotate left shifts the carry flag in the SHARED port for the strobe. First time, it shifts the carry flag in. Branch on carry set will stop us when the carry flag is rotated out of the high bit."
"Note," I pointed out, "that branch on zero, BEQ, will also work and may be more resistant to hardware failures."
Julia raised her hand. "What? Is that supposed to go in the notes?"
"In case of short circuits or other bad things that could happen to the keyboard," I explained.
Wallace was writing the notes. "Got it."
Julia gave me a perplexed look. "I guess we can go on, but explain that tonight, please."
"Well, if the strobe bit is shifted out, the carry will be set, but so will the zero flag, because there will be no ones left in the port output register. It's a different way to test for the end of the loop, and we might want to take the time to consider which will be less likely to have problems when there are hardware failures."
"Does it matter on a keyboard?" asked Javier.
"Maybe, maybe not."
Doctor Brown cleared his throat. "Leave it in the notes, and add that we really don't have the tools for the analysis yet."
I exchanged glances with him.
"Got that, too," Wallace said.
"Right," I concurred. "Something to think about later."
"I can continue?" Terry asked.
"Please."
"Then we load the column state from the KBDIN port and store it where X points into the state table, and bump X before branching back. I don't think I need to clear the carry bit after incrementing X because there's nothing in the loop that would set it besides the rotate."
"Good, --"
Wallace interrupted. "But why check them all? Why not jump out of the loop on the first scan that's not all zeroes?"
Terry pointed out, "There may be other ones, as well. You don't always release one key before pressing another."
"I guess that's true." Winston tilted his head. "But can we handle that?"
"I think we can. Terry, can you walk us through how that would work?"
"What we want to see is which bits changed." She thought for a moment. "So we need to keep a record of the previous sample, too."
"I think so. It uses a lot of the MCU's little bit of RAM, but I think we need to keep three records."
"Do we have time to copy all of it?"
"Maybe. I think we can do it without copying three times, but let's look at copying first. I think it would be easier to understand."
Terry nodded, erased her code and started over.
KBDST0 RMB 8 ; NEWEST
KBDST1 RMB 8
KBDST2 RMB 8 ; OLDEST
*
CLX ; FIRST COLUMN
LDA #1
STA SHARED ; STROBE
STBLUP
LDA KBDST1,X ; COPY 2ND
STA KBDST2,X ; TO OLDEST
LDA KBDST0,X ; COPY PREVIOUS
STA KBDST1,X ; TO 2ND
LDA KBDIN ; GET STATE
STA KBDST0,X ; SAVE CURRENT
INX ; NEXT COLUMN
ROL SHARED ; NEXT STROBE
BCC STBLUP ; UNTIL CARRY
"That's pretty tight programming."
"Thank you."
"After finishing the copying, is there anything left to do before returning from the interrupt handler routine?"
"Wait," Julia said. "Pat and Tanya are stuck."
I laughed. "Sorry. I'm getting carried away. This little routine should be called 'Copy Keyboard State' or something." I paused until they were ready.
"Terry?"
"It starts with zeroing the index and preparing the strobe for the first column. Then it enters a loop without testing first." She paused.
"Copies the previous state over the oldest state for the column.
"Then copIes the most recent state over the previous state for the column.
"Reads the new current state and saves it."
"Bumps the index and shifts the strobe for the next column.
"Finally, if the strobe bit has shifted out, it's done."
Pat's pseudo code looked like this:
Copy Keyboard State:
Zero column index;
Prepare column strobe;
Loop --
Overwrite oldest state for this column with 2nd oldest;
Overwrite 2nd oldest state with most recent;
Overwrite most recent state with current;
Bump column index;
Shift strobe bit left;
Until no columns left to strobe.
Tanya's flow chart looked like this:
"So, Terry, is there anything left to do?"
"If we've already done the display stuff when we get here, I don't think of anything else."
"Very nicely done. And that was no idle compliment. Let's count the cycles to see if that can all happen within a millisecond."
Everybody got involved in digging into the cycle counts from the dataheets and adding them up.
"CLX is four cycles."
"Three cycles for CMOS."
"These are CMOS chips aren't they?"
"Yeah."
"I'm counting HMOS cycles, just to be safe."
And so forth, some using the detailed timing charts and others using the summary in the op-code table.
"Fifty cycles through one loop."
"Roughly, worst case."
"Times eight is four hundred cycles worst case."
"That's not quite half the time between interrupts."
"Is that too much?"
"It'll only happen once every sixteen milliseconds, or so, right?"
"We'll have to test it."
"Joe said we could avoid all the copying."
"Well, we can avoid copying the previous and second previous. It's a little less straightforward, because we have to keep track of which one is the oldest and only overwrite that one. Then remember which is the new oldest. I think that should cut the time down under a hundred cycles. But I think four hundred cycles, plus the time for the interrupt counting, etc., isn't too much. Some of you might want to try both. Or you could also adjust the timer interrupt, to two or four milliseconds."
That gave everyone something to work with for a bit, each fitting the processes to their own circuits.
Then Carlos asked, "Okay, we've recorded all this state, now what? How do we check for someone hitting a key?"
"Good question." I checked the time before asking, "Any suggestions?"
Carlos frowned. "Looking for ones is not the answer, I guess."
"Almost."
"Look for changes."
"Right."
"Compare instruction, CMP?"
"That'll only tell us if there's a change. It won't tell us which changed. There's a way that can tell us which of eight bits changed with just one instruction," I prompted.
"The exclusive-or instruction?"
"Bingo."
"Does that mean we have to use eight more bytes to remember which bits went high?"
"Yes -- or to remember which changed and are no longer bouncing. We can check the most current state to figure out whether the change was a press or release."
"And this is not in the interrupt routine?"
"Right."
"How do we know when to look?"
"How about checking the interrupt count?"
Carlos shrugged. "Uhm, explain that?"
"After the interrupt routine counts sixteen interrupts or so and records the new samples, it can leave the count at sixteen, and the non-interrupt code can see that sixteen, check and record which changed, and subtract sixteen from the count to start over. Or clear the count if we are sure we don't get interrupted. But subtracting would be safer."
"Hmm. I guess I need to think about that."
I checked the clock again. "Well, I need to go deliver my newspapers. Who wants to lead the discussion of how to turn this into code, and how to work out the key codes from the bits that changed, and how to buffer key codes that the main CPU hasn't read yet? Mike?"
"I vote for letting Jennifer lead it."
"Why not? I'll let you guys work it out. I have to run."
*****
When I got back, they had worked out recording the changed bits, and were working out out to turn a changed bit into a bit number, to figure out which key was pressed. I suggested not loading the bit or count into the index or accumulator, to avoid having to save and restore them:
KBIT RMB 1 ; BIT TO COUNT
KBITCT RMB 1 ; BIT # COUNTER
*
CLR KBITCT ; START AT BIT 0
KBITLP
SHR KBIT ; SHIFT DOWN
BEQ KBITDN ; DONE IF OUT
INC KBITCT ; COUNT BIT
BRA KBITLP ; DO IT AGAIN
KBITDN
* BIT NUMBER NOW KNOWN
There were several using math to convert the keyboard matrix to ASCII codes, but some had keyboard matrices that varied enough from ASCII to make that hard. So I showed them how to put the key codes in an array to match the keyboard matrix they had, using the bit number concatenated with the column number times eight to index the array.
* COLUMN INDEX IN X
SHLX ; TIMES 8
SHLX
SHLX
TXA ; COLUMN NUMBER TO A
ORA KBIT ; KBIT <= 7
TAX ; MATRIX ELEM #
* USE THIS TO INDEX
* ASCII CONVERSION TABLE
George complained, "I've heard that global variables are bad, but we're using globals all over the place."
Jennifer complained, as well. "Doctor Brown just laughs at us when we worry about it."
"I'm only here to make sure you don't destroy the lab." If anything, his grin was even broader. "And steal ideas for my lesson plans next year."
That provoked much laughter, and a release of stress.
"Seriously, though. I'm getting a lot of good ideas from watching you guys. And I want to see what Joe has to say before I weigh in."
"I'm not sure what I have to say, but it seems to me there are several problems in organizing our variables. One is where you declare them in the source program. We've been declaring them as we invent code snippets, then moving the actual declarations into the direct page variable list when we put the snippets into our code.
Jennifer tilted her head. "What about variables on the stack? Doesn't the 6805 have a way to put variables on the stack?"
"First question, which stack?"
"Now it gets interesting," Doctor Brown intoned.
"Which stack?" Winston echoed. "Is there more than one?"
"The 6805 doesn't have a parameter stack, perhaps because Motorola
figures, if the code is complex enough for re-entrant parameters,
it's complex enough to use something more powerful."
"Then why," asked Jennifer, "the jump subroutine instruction?"
"Cheap on transistor count and allows some simple code reuse? I guess. Anyway, that appears to be the approach we should take, graduating the project to a more powerful processor when we want to put parameters on a stack."
Julia shook her head. "I don't think I'm the only one who's lost."
"Can we talk about this tomorrow? I'm kind of hoping we can get some of the keyboards working today."
Doctor Brown laughed. "Classic avoidance maneuver, but I agree. Too early for a lot of you to talk about re-entrance and stacks."
Having only one computer to program 68705s on was a bottleneck, but we were able to get Winston's, Mark's, Jeff's, and Suzanne's keyboards working, and they plugged them into their Micro Chroma 68+6803s and started playing with the TV-BUG monitor. Some of the students who were waiting watched the fun.
Julia declined to use group time to program her keyboard. "I didn't bring the Micro Chroma today, anyway."
"Oh, is that why tomorrow?" I asked, and she just gave me a kind of thoughtful look.
"Sure. That's why." And she winked at me, but wouldn't explain further.
"Okay."
We got a few more keyboards running before time to shut down.
*****
"Intel 8086?" Julia looked at the book I was borrowing from the library. "What do you need that for?"
"Ammunition."
*****
From school, Julia and I went to her house for dinner, and from there
we went to her Bible study group. Reverend Johansen was there, and while I don't remember what we discussed, I do remember we enjoyed the discussion. I carefully limited my contributions, to avoid raising issues that would lead to contention, and to focus on supporting the witnesses the members of the group held.
We studied together at her home afterwards, before taking fifteen minutes for me to practice for the recitation. Her mom and Dad joined in, singing in English.
Then we set up my Micro Chroma 68, and Julia programmed her keyboard controller and plugged the keyboard into my Micro Chroma 68 to test and play with it, while I studied the i8086/8088 manual and the TMS 9900 and 9940 manuals.
Her little brothers watched for a while, but got bored and left.
I recalled one of Julia's questions in class.
"Remember that BLWP instruction I was looking for last night?"
"Yeah."
"You can use it to allocate variables on a stack. When you leave a subroutine, you deallocate the variables."
"Allocate, I think I can understand. That's like reserving space for working on things?"
"Right. Reserving space to work on things."
"So deallocate would be giving the space up?"
"Right again."
"I guess that makes better use of RAM."
"It also means that, if you have more than one process running, the variables on the stack are local -- kind of private -- to the the process that owns the stack.
"I'll have to think about that. So what kind of ammunition are you getting from the 8086 book?"
"Registers that have limited uses. It's better than the 8080, but they are still pretty limited, compared to the even 6800's use of memory."
"Do you think they have a reason for that?"
"Simplifying their circuitry, mostly, I'm sure. And adding special purpose features in the transistors that are left available."
"Marketing?"
"Yeah."
I read in silence for a bit more. "Really weird address registers. It's like they deliberately put holes in addresses."
"Huh?"
I showed her a diagram of the 8086 segment registers and how addresses are assembled in the original 8086 segmentation.
"I can't even begin to understand what they are trying to do."
"The actual address registers are sixteen bit. So are the segment registers. But the segment registers are slid over four bits, before being added, so you can play address games and use two megabytes of RAM, if you do it right."
"So you can add more RAM. Do Motorola processors do that?"
"There is a memory management unit for the 6809, and, I think, the 6800, that allows a megabyte of memory to be addressed, and allows memory to be moved around in two kilobyte pieces to mix and match. The 8086 gives a cheaper, half-baked approach that doesn't really allow mixing and matching, except in sixty-four kilobyte sliding frames that slide with a sixteen address bump."
"Hmm."
"The address registers of the 68000 allows completely linear segmentation, if you want to use it. No shifting partial addresses around. No bumpy slide. The 6809 has a single direct page register that's similar to the segment registers, but is just appended whole to the direct page address, and doesn't extend overall space."
"I'll have to figure out what this is all about later."
"Yeah. Ah. The 8086 has instructions to support stack frames, kind of like the 9900. And it becomes clear to me why I don't like the idea of keeping return addresses in the stack frame."
"Return addresses?"
"The program counter from the routine that calls the subroutine, so you can get back to the calling code -- you save the program counter on the stack. With parameters and locals on the same stack, you're going to have return addresses and parameters and locals colliding. And bad things will happen, like returning to data instead of code, and then who knows what happens next."
"Who knows? I'm getting sleepy."
"Bad things like when my Micro Chroma's reset switch bounced and it would cause random text and flashing meaningless graphics to show on the screen."
"Oh." Her eyes closed and her head nodded, then she shook her head and blinked. "I think it's time for you to go home."
We shared a quick kiss or two as I prepared to leave, and her mother cleared her throat from the kitchen, where she was working through the monthly bills.
"Mom, not tonight. I've been studying stuff that is completely foreign to me. Joe calls it playing, but I'm tired."
Her mother smiled gently. "Some days are like that." She took us both in for a hug.
"I have to admit to being a bit tired myself," I added. "Julia's keyboard will now talk to her computer. Tomorrow's going to be another long day, I think."
"Speaking of her computer," Mr. Cisneros spoke up from the couch, "I think she needs a box to put it in."
"True."
I sat back down, and we discussed different kinds of enclosures for her computer for maybe a quarter of an hour, Julia and I holding hands in between making sketches and using our hands to talk about the shapes of things. We talked about a box like mine, and we also talked about putting her keyboard in a separate enclosure so she could move it around separately from the computer.
Mr. Cisneros asked about possible standard bus technology, and I promised to look more into Motorola's EXORbus.
Julia put the sketches with her notes, and we shared another quick kiss before I left.
[Backed up at https://joel-rees-economics.blogspot.com/2020/07/bk-33209-straits-keyboard-decoding.html.]
