Electronics > Projects, Designs, and Technical Stuff
Cloning a Tandy TRS-80 Model 1
PA0PBZ:
--- Quote from: GK on January 15, 2019, 08:14:16 am ---Would NEWDOS/80 be unduly crippled without the ability to simultaneously assert keys?
--- End quote ---
There are (from memory) 3 3-key commands:
123 - debugger
DFG - mini-dos
JKL - screen print
biff:
--- Quote from: GK on January 15, 2019, 08:14:16 am ---
Correct. As currently breadboarded, aside from the shift key which is handled separately, two or more keys cannot be applied simultaneously. It didn't occur to me that this might be a desired or necessary feature; thanks for raising it. Minus the shift keys there are only 51 keys to encode, hence the six (1-of-64) key character-select lines to the LUT ROM only. One additional location needs to be reserved for an unasserted keyboard, but that leaves me 12 remaining addressable locations any/each of which can be programmed to assert any single key again or any possible combination of multiple keys. However the multiple-key combinations would have to be specifically recognized by the PIC. If there is, for example, some odd-ball program which requires you to press A and L together, such, with the current implementation, could be accommodated this way.
--- End quote ---
While NewDOS80 is the most obvious consumer of multiple simultaneous keypresses, it isn't the only one by far.
I dimly recall Big 5 games allowing the game to be aborted by pressing "Break"+"Clear" - but it might have been "Shift"+"Clear" - which you probably handle.
I do know that one of my all time favorite games "Armor Patrol" AKA "Tankzone 2000" a battlezone clone, requires pressing multiple keys together for movement.
For example, "A"+";" to move forward, "Z" + "." to move backward and combinations of those to turn. (I may be misremembering the exact keys - but you get the idea). And of course, while doing those keyboard gyrations, you're also hitting SPACE to fire.
And then in BASIC, there is the ability to press and hold the "Down Arrow" key and press another key such as "C" to generate a Ctrl-C and other control codes.
And some terminal programs would use "@" as a command key - expecting you to press that along with another key for a function.
kizmit99:
--- Quote from: GK on January 15, 2019, 08:14:16 am ---Yes, I just tried and my clone does respond this way. To be honest, this isn't something which would bother me personally...
--- End quote ---
I would have thought the same thing, but I've discovered in the (what seems like) many thousands of times trying to boot LDOS |O that when I type "1:00:00" to enter the time, I instead manage to get "1:;00:;"... Which, of course, isn't liked by LDOS and I get to try again at a slower, more precise pace... Hence my even being aware of the issue, and why I went ahead and dealt with it.
Just another point about the ROM approach to the keyboard scan-array - I suspect you've got this covered already, but in case not... While the "normal" case was to assert only one of the address lines at a time when trying to determine "which" key was pressed, a lot of code would assert multiple (possibly all) address lines at the same time in order to determine whether "any" key was pressed in a single read-cycle. Your ROM approach should easily deal with that/those cases, but of course it depends on the ROM being programmed appropriately.
GK:
--- Quote from: kizmit99 on January 15, 2019, 11:30:02 pm ---Just another point about the ROM approach to the keyboard scan-array - I suspect you've got this covered already, but in case not... While the "normal" case was to assert only one of the address lines at a time when trying to determine "which" key was pressed, a lot of code would assert multiple (possibly all) address lines at the same time in order to determine whether "any" key was pressed in a single read-cycle. Your ROM approach should easily deal with that/those cases, but of course it depends on the ROM being programmed appropriately.
--- End quote ---
Yep, my EPROM is programmed to handle this. In fact the keyboard interface wouldn't work at all if it wasn't. The TRS-80 doesn't periodically scan the entire keyboard. What it does initially is assert all of the address lines high and then checks the data bus for anything other than 0x00. If there is activity on the data bus (indicating a pressed key or keys) it then scans the full keyboard by sequentially asserting the address lines; otherwise it goes onto other things.
My EPROM LUT hack could be expanded to handle simultaneous keys - for each additional key just add an another identically programmed EPROM in parallel. The data output lines of course would need to be paralleled by ORing and the six LS (key/character select) address lines independently controlled by the PIC.
However a basic AND/OR matrix array (for the full 2^51 combinations :P ) in a CPDL is my preference now. To simply the microcontroller interface I'll add a serial-in shift register for handling the single-bit status of all 51 keys.
I cut my teeth on Altera (now Intel) MAX 7000 devices and they are still my default resort for 5V-tollerant glue logic. These parts are still going strong with a decent selection still in active production, but Microchip offers a family of device-compatible parts with claimed benefits : https://www.microchip.com/design-centers/programmable-logic/spld-cpld
Has anyone here used these? Worth switching sides?
nick_d:
I use the Atmel ATF1500 series CPLDs for retro projects because they are a 5V family that's still available, at least they were available on Digikey a year ago when I last bought them.
On the other hand, this is for a Z180 processor that has ordinary CMOS inputs with 2.5V threshold, whereas I think the TRS-80 would be mostly using the TTL compatible parts such as the Z84C00 that has the 1.2V threshold, hence the 3.3V CPLD with 5V tolerant inputs would be fine. The only thing that's a bit of a pain about this is having to provide an extra 3.3V supply, another reason I prefer the ATF1500s.
Nick
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version