Backup of
https://joelrees-novels.blogspot.com/2020/07/33209-straits-keyboard-decoding.html.
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 buffers for
the displays as one of the buffers 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 of 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, but the other is going to be adding
sixteen or something, depending on the bits used, right?"
"Exactly. So we'll look at that, 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 when I'm using the displays. 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 value 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 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 functions 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 taking notes is an opportunity for work, like any other."
I
don't know if that was a very good sales line, 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,
I 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 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 in the implementation. If you've ever worked on a systems development team, you know they always do.
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.
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 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."
"Does everyone agree?"
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."
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.
"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.
"It starts with zeroing your index and prepare
the strobe for the first column. Then you enter a loop with no tests at
the entry point." Again, I paused.
"Copy the previous state over the oldest state for this column.
"Copy the most recent state over the previous state for this column.
"Read the new current state and save it."
"Bump index and shift strobe for next column.
"Finally, if the strobe bit has shifted out, we're 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 withing a millisecond."
Everybody got involved in digging into the cycle counts from the specsheets 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, 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 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 the 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 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 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."
*****
After
studying and singing, Julia programmed her keyboard, then plugged it
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.
"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 6800's use of memory."
"Do you think they have a reason for that?"
"Simplifying their circuitry, mostly, I'm sure. Add special purpose features in the transistors that become extra."
"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."
"Hmm."
"The 68000 allows completely linear segmentation, if you want to use it. No shifting things around."
"I'll have to figure out what this is all about later."
"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?"
"So
you can get back to the code that called a subroutine, 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."
"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."
"Let's get you home."
We shared a quick kiss on her doorstep, and her mother opened the door and cleared her throat.
"Mom, not tonight. I've been studying stuff that is completely foreign to me. Joe calls it playing, but I'm tired."
"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
went in and sat down, and we discussed plans for an enclosure 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.
Julia put the sketches with her notes, and we shared another kiss before I left.
Chapter 13.5: what?
[Backed up at https://joel-rees-economics.blogspot.com/2020/07/bk-33209-straits-keyboard-decoding.html.]
