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

Sunday, July 12, 2020

Backup: 33209: Straits -- Keyboard Decoding

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


No comments:

Post a Comment

Keep it on topic, and be patient with the moderator. I have other things to do, too, you know.