Posted By azog on September 24, 2012
The ultimate goal for this post is to have a more usable keyboard on a PET 4032, which currently has a graphics keyboard. This is a long, and hopefully not-too-rambling post, where I try to detail what I’ve explored. And also perhaps if someone stumbles on this, might help with a more reasonable solution than what I have to date.
This is how the graphics keyboard is laid out. Pay particular attention to the upper row of keys (and ignore the dirty keys, which have since been cleaned):
These keys have symbols rather than numbers. The numbers were accessed via the numeric keypad. This makes “normal” typing difficult. For the last mumblety years, I’ve been trained that the numbers are on the top row, and symbols are SHIFTed numbers. While the symbols themselves may change, that particular difference is easier to overcome than the absence of numbers.
There were a surprisingly large number of versions available, and even models with the same model number may be significantly different. For example, you could have a PET 4032 with TTL graphics or the CRTC. For this purpose, I will only focus on a specific set of parameters, which are still widely variant: a PET 4032 with CRTC and BASIC 4.0.
The one I have is equipped with the FAT-40 “universal” board. With a few changes, one could “upgrade” a PET 4032 to a PET 8032 by basically adding additional memory for the larger screen layout and glue logic and some new ROMs.
The bonus of a PET 8032 is that they were equipped with business keyboards; a more familiar layout. But the more “popular” version of the PET was the 4032, the 40 column version, for which there seems to be much more software available. What’s the trade-off? A better keyboard or higher software compatibility? Isn’t it possible to have the best of both worlds: a more natural keyboard layout on a more popular version of the PET?
Why not just plug an 8032 business style keyboard into the 4032?
For starters, the case cutouts are different. While I suspect the screw-holes would line up, the keypad on a graphics keyboard is larger than that of the business keyboard, and it would not look nice.
More significantly, the scan table between the two appears to be completely different. Looking at this document, one can see that the scan table does not match 1:1. Some do, some don’t. I’ll show my tests with substituting the 8032 scan table a little later…
What other options are there? The 80 column PET has twice as much video memory and the necessary glue logic to decode it. The dot clock is also doubled. Perhaps it is possible to take an 8032 ROM and patch its dot clock to the same speed as a 4032, but I have not explored this possibility yet, as it seems to be more complex.
Being a “universal” board, the other differences must be in ROM, in this case, what is known as the “edit ROM”, which is where keyboard decoding occurs. There are a variety of ROMs available, to fit the variety of systems, but sadly, this particular ROM does not seem to exist. Using the same naming scheme, it would probably be called edit-4-40-b-60Hz.
So let’s explore some PET ROM internals. Even if I don’t solve this problem, it’s still an interesting journey.
Using a hex editor on the edit-4-40-n-60Hz ROM I downloaded from above, and using the scan table from the same source, it was relatively quick to locate the scan table in ROM. In this case, it begins at offset 1855 for 80 characters ($73F for $50 characters). Just look for the beginning two bytes ($3D $2E) and the ending two bytes ($23 $21) and you’ll find it. It matches exactly.
Starting at the end is the codes for the symbols. If you edit these for the numeric codes instead, you’ll produce numbers on those keys. So change the last byte from $21 to $31, you will produce the number “1” rather than the symbol “!”.
I’ve edited the ROM as follows:
From: symbol / code | To: symbol / code
! 21 1 31
" 22 2 32
# 23 3 33
$ 24 4 34
% 25 5 35
/ 27 6 36
& 26 7 37
\ 5c 8 38
( 28 9 39
) 29 0 30
Here is a screenshot of a HEX editor highlighting the original scan table.
Here is the modified ROM, after editing the changes from above.
Hard to tell, with all those hex numbers floating around, but look at the last highlighted numbers to see the differences.
I use VICE to load this ROM image into the “editor” section:
Word of caution: when you edit a ROM and want to load it into VICE, make sure you close the hex editor (or close the file) before you open it in VICE. And vice versa, when you want to edit the ROM image, make sure VICE is not running. I had a session of head-desking trying to figure out why my saves were actually not saving…
And indeed, this works. The upper row of the keyboard now outputs numbers instead of symbols.
But this reveals a further issue. There are no longer any symbols. These number keys, SHIFted, still outputs the graphics characters as they did before editing.
It was at this point I took the 80 column ROM, edit-4-80-b-60Hz, and found _its_ scan table (which begins at offset $D61, for $50, or 80 characters), and copied it into this 40 column ROM. I found that many of the keys no longer mapped to where they should, so that particular avenue was a dead-end.
Looking at the two scan tables on zimmers, it appears that SHIFT is handled differently on the business keyboard than it is on the graphics keyboard, as revealed by the statement “The shift key always set the high bit, producing a graphic character”.
This is easy to verify. Just PRINT ASC(“A”) and then do for SHIFTed-A (a heart symbol). Since your dealing with bits, it’s easier to look at them in binary. “A” = 65, or binary 0100 0001, SHIFT-A = 193, or binary 1100 0001. And so on thru the whole character set. Indeed, when you press the SHIFT key, it just sets the high bit.
I guessed that the easiest way to do this is to simply ORA #$80, which is the logical “or” operation, to set individual bits, in this case $80 being the high bit. In 6502 opcodes, this would be 09 80. Indeed, there were several spots where this sequence occurs, so I tried each one until I either hit the last one, or changed the behavior in expected ways. I actually found my guess was correct at location $E578. Changing the operand of the ORA from $80 to 00 has the effect of disabling the SHIFT key (since it does not set anything). Changing the opcode to various numbers changes the shift behavior.
How to take advantage of this, so that rather than setting the high bit for graphics characters, allow SHIFT to produce the more usual characters? What is the difference between a number “1”, and its SHIFTed counterpart, “!”?
$10 is the difference. The number “1” is $31, and the SHIFTed “!” is $21. What if I change that ORA #$80 to subtract $10? SBC is opcode $E9 with the operand $10. Patch that into location $E578:
It is the last code listed on this disassembly.
This works, with yet other issues become apparent. Of minor note, it affects non-numeric SHIFT keys, like regular letters.
But the numbers, which are my focus, are not 1:1. Look at my original table above, and you see that the symbols are not in sequential order. The “/” and the “&” are in opposite order than I would expect, and the backslash, “\”, is completely out of order. So subtracting $10 does not give the desired outcome.
Since a simple subtraction does not suffice, I suspect there will need to be some comparisons to take this range into consideration, which might mean patching in additional code.
In the short snip of disassembly above, there are about 16 bytes of NOPs just before the SHIFT twiddle. I figure I can use these bytes for additional patched code, as long as the SHIFT twiddle address ($E578) is not the target of a JMP or branch, and as long as those NOPs are not timing critical delays.
But at the moment, I’m out of ideas, and staring at all these hex numbers is making me wonky.
Here is an image of the edits that I’ve made. If you load this into a HEX editor and compare this with the original, you’ll see the changes (and only those changes) that I’ve listed above. The upper row outputs numbers, and the SHIFTed keys of this row puts of some, but not all, of the correct symbols (and you’re losing the SHIFTed graphics symbols in the meanwhile).