Hi Bill,
Then, there will never be a problem with games that use the Right Hand joystick keys ("B", "M", "Z", "C", <space>) as they are on 1 drive line.
A maximum of 5 drive lines are used for the Left Hand (keypad) joystick. In practice, think that the worst case would be 3 drive lines being driven at one time, two direction (for diagonal movement) and fire.
Detecting all 8 is probably overkill?
regards
Dave
Keyboard replacement
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Keyboard replacement
Dave, I think it would take 1.5 us max to handle all eight drive lines. There is more than 2 us to play with on the MTX. Wait states would be required for most of the faster clocks on the MTXPlus+. In fact, the Prop could output /WAIT and there is a spare open-collector buffer available.
Without data packing, five more hub reads are needed but five fewer rotates/shifts, with a net increase of 20 cycles, making the worst-case 1.7 us, which is still doable at 4 MHz assuming the cog has nothing else to do. Modified code:
All hub reads after the first would be in sync, wasting no time.
If eight drives lines can be dealt with in time, there is no real reason not to do that on the MTX. The point of taking all drive lines low is to test for any key pressed. If a key or keys (as yet unknown) are pressed, then test each row individually to find out which one(s). This was done a lot on the Spectrum, but I don't know about the MTX. Perhaps a request on Facebook would help? Andy would know what he did if nobody else.
Without data packing, five more hub reads are needed but five fewer rotates/shifts, with a net increase of 20 cycles, making the worst-case 1.7 us, which is still doable at 4 MHz assuming the cog has nothing else to do. Modified code:
Code: Select all
' add0-add7 are eight registers that hold
' hub addresses which have key bit data as follows:
'
' (add0) bits 0-9 = KB0-9 drive 0
' (add1) bits 0-9 = KB0-9 drive 1
' (add2) bits 0-9 = KB0-9 drive 2
' (add3) bits 0-9 = KB0-9 drive 3
' (add4) bits 0-9 = KB0-9 drive 4
' (add5) bits 0-9 = KB0-9 drive 5
' (add6) bits 0-9 = KB0-9 drive 6
' (add7) bits 0-9 = KB0-9 drive 7
'
' Rotate all bits left by two bits if USB on P00 and P01
'
sensepins long %1111111111 ' sense pins are 0-9 (for prototype)
drivepins long %11111111 << 10 ' drive pins are 10-17 (for prototype)
sensehigh long %1111111111 ' bits 0-9 all high (too large for immediate)
sense long 0 ' holds sense output value
drive long 0 ' holds drive input value
add0 long ? ' holds hub address x
add1 long ? ' holds hub address x + 1
add2 long ? ' holds hub address x + 2
add3 long ? ' holds hub address x + 3
add4 long ? ' holds hub address x + 4
add5 long ? ' holds hub address x + 5
add6 long ? ' holds hub address x + 6
add7 long ? ' holds hub address x + 7
key long 0 ' holds key bits from (add0)-(add7)
'
start mov dira,sensepins
loop mov sense,sensehigh
and drive,drivepins
waitpne drive,drivepins ' wait for new DR0-7 after OUT 5
mov drive,ina
ror drive,#10 ' needed as ror a,b wc writes only a[0] to c
rdlong key,add0
ror drive,#1 wc
if_nc and sense,key ' drive 0
rdlong key,add1
ror drive,#1 wc
if_nc and sense,key ' drive 1
rdlong key,add2
ror drive,#1 wc
if_nc and sense,key ' drive 2
rdlong key,add3
ror drive,#1 wc
if_nc and sense,key ' drive 3
rdlong key,add4
ror drive,#1 wc
if_nc and sense,key ' drive 4
rdlong key,add5
ror drive,#1 wc
if_nc and sense,key ' drive 5
rdlong key,add6
ror drive,#1 wc
if_nc and sense,key ' drive 6
rdlong key,add7
ror drive,#1 wc
if_nc and sense,key ' drive 7
mov outa,sense
ror drive,#32-8-10 ' drive rotated 32 bits, back to original value
jmp #loop
If eight drives lines can be dealt with in time, there is no real reason not to do that on the MTX. The point of taking all drive lines low is to test for any key pressed. If a key or keys (as yet unknown) are pressed, then test each row individually to find out which one(s). This was done a lot on the Spectrum, but I don't know about the MTX. Perhaps a request on Facebook would help? Andy would know what he did if nobody else.
Re: Keyboard replacement
Hi Tony,
OK, I am happy reading the 8 drive lines if that's what's best.
I am less keen on having the Propeller drive /WAIT though, that will make connecting to the MTX a little more difficult - its stops the board being "plug & play". I think that people would be OK with plugging a DIP header into the User Port for access to power (and anything else if needed), but I am not keen on hanging other stuff of other chips if we can avoid it.
For MTXPlus+ we had been thinking about adding Port 5 to the existing GAL logic to generate the wait states.
I hate Facebook for Technical discussions, it is almost impossible to find anything later, after a couple of posts on a thread, they get lost. I will drop Andy an email and ask if he can catch up on this thread here
regards
Dave
OK, I am happy reading the 8 drive lines if that's what's best.
I am less keen on having the Propeller drive /WAIT though, that will make connecting to the MTX a little more difficult - its stops the board being "plug & play". I think that people would be OK with plugging a DIP header into the User Port for access to power (and anything else if needed), but I am not keen on hanging other stuff of other chips if we can avoid it.
For MTXPlus+ we had been thinking about adding Port 5 to the existing GAL logic to generate the wait states.
I hate Facebook for Technical discussions, it is almost impossible to find anything later, after a couple of posts on a thread, they get lost. I will drop Andy an email and ask if he can catch up on this thread here
regards
Dave
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Keyboard replacement
Hello Dave,
There would be wait states only on the MTXPlus+, not the MTX. The number of drive lines supported is a Propeller software issue.
This project is a welcome short-term diversion for me. Further thoughts:
1. Add a 4-pin right-angle header to the back of the new PCB pointing backwards and connect a motherboard-to-USB cable, so that the keyboard connection would be external to the MTX. The part to go for is a StarTech USBMBADAPT (sorry, I can't attach photos on this forum or any other files), cost ~£2. It's a question of whether the flat part of the cable is long enough to fit in the slot above the joysticks or maybe the fatter part of the cable can be squashed.
2. Connect a PS/2 keyboard by attaching a USB-to-PS/2 passive adapter to the StarTech USBMBADAPT, e.g. StarTech GC46MF or similar, cost ~£1.
3. Keep on eye on the current consumption. Use of old keyboards might be best discouraged.
4. On second thoughts best to forget about more than one USB device, as Bill says. It strikes me, though, that the Propeller could do something extra, maybe a SPI interface. Would a MicroSD card fit in the gap above the joysticks?
There would be wait states only on the MTXPlus+, not the MTX. The number of drive lines supported is a Propeller software issue.
This project is a welcome short-term diversion for me. Further thoughts:
1. Add a 4-pin right-angle header to the back of the new PCB pointing backwards and connect a motherboard-to-USB cable, so that the keyboard connection would be external to the MTX. The part to go for is a StarTech USBMBADAPT (sorry, I can't attach photos on this forum or any other files), cost ~£2. It's a question of whether the flat part of the cable is long enough to fit in the slot above the joysticks or maybe the fatter part of the cable can be squashed.
2. Connect a PS/2 keyboard by attaching a USB-to-PS/2 passive adapter to the StarTech USBMBADAPT, e.g. StarTech GC46MF or similar, cost ~£1.
3. Keep on eye on the current consumption. Use of old keyboards might be best discouraged.
4. On second thoughts best to forget about more than one USB device, as Bill says. It strikes me, though, that the Propeller could do something extra, maybe a SPI interface. Would a MicroSD card fit in the gap above the joysticks?
Last edited by Tony Brewer on 16 Feb 2018 20:00, edited 1 time in total.
Re: Keyboard replacement
Hi Tony,
I'm not keen on piggy-backing off the '273. This would be different to your past Spectrum interface as there would be a chip connection AND the fixed connection to the MTX keyboard header. Getting the two spot on might take a few iterations of the PCB. For MTX, I'd like to see if we can get it working reliably without the OUT5 connection on the prototypes. If that doesn't work, then a clip on connection is always possible - messy, but possible.
I'm not sure if a microSD card would fit, but there would need to be some software written to use it. There likely isn't enough space in the ROM to fit any SD code, so I'm not sure how an SD card would be used unless a "disk" ROM was also put on the keyboard interface?
regards
Dave
I'm not keen on piggy-backing off the '273. This would be different to your past Spectrum interface as there would be a chip connection AND the fixed connection to the MTX keyboard header. Getting the two spot on might take a few iterations of the PCB. For MTX, I'd like to see if we can get it working reliably without the OUT5 connection on the prototypes. If that doesn't work, then a clip on connection is always possible - messy, but possible.
I'm not sure if a microSD card would fit, but there would need to be some software written to use it. There likely isn't enough space in the ROM to fit any SD code, so I'm not sure how an SD card would be used unless a "disk" ROM was also put on the keyboard interface?
regards
Dave
Re: Keyboard replacement
Tony,
The Propeller output cog does a "waitpne" on nine pins, not eight. The ninth pin is toggled by the keyboard decode cog whenever the state of the keyboard matrix changes. This causes the output cog to update the sense lines, even if the drive lines don't change.
Bill.
The Propeller output cog does a "waitpne" on nine pins, not eight. The ninth pin is toggled by the keyboard decode cog whenever the state of the keyboard matrix changes. This causes the output cog to update the sense lines, even if the drive lines don't change.
Bill.
Re: Keyboard replacement
It's also worthwhile pointing out that like mice, some USB keyboards will fall back to PS/2 mode if USB communication fails. Some keyboards were even sold with passive USB->PS/2 adapters. The difficulty is that nowadays very few (if any) manufacturers and suppliers include this information. So you have to buy and try...
It has to be said, I prefer PS/2 connections for keyboards
On the subject of keyboard sense lines, various "tricks" were used on the ZX Spectrum. In the Spectrum, Sinclair used address lines A8 to A15 to drive the keyboard "scan" lines. So the CPU could activate one or more, including all the keyboard "scan" lines.
Some of the techniques used are:
While on the subject of the ZX Spectrum and the MTX, how does Speculator handle the keyboard?
Mark
It has to be said, I prefer PS/2 connections for keyboards
![Wink ;)](./images/smilies/icon_e_wink.gif)
On the subject of keyboard sense lines, various "tricks" were used on the ZX Spectrum. In the Spectrum, Sinclair used address lines A8 to A15 to drive the keyboard "scan" lines. So the CPU could activate one or more, including all the keyboard "scan" lines.
Some of the techniques used are:
- As already mentioned, activating all of the "scan" lines simultaneously so that the CPU can detect if any key is pressed.
- Only activating the "scan" lines required for the game's keys, hence totally ignoring many of the unused keys, hence less work for the software to do.
- Using an address that activated multiple "scan" lines. So for example, the user had a choice of which keys to use, e.g. Left being "Q" or "A" or "Z" (all being on the same column) without having a special define/select keys routine.
- Scaning the keyboard (whole or parts of it), but in a different order to the ROM routine.
- Using one (or more) of the above to support joysticks mapped to the keyboard ("cursor", Sinclair) only, or as well as keyboard control keys.
While on the subject of the ZX Spectrum and the MTX, how does Speculator handle the keyboard?
Mark
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
Looking forward to summer in Somerset later in the year
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Not as many MTXs as Dave!
![Laughing :lol:](./images/smilies/icon_lol.gif)
Re: Keyboard replacement
Hi Guys,
I'd like to try and "finalise" the design that we're going for here and think that it's worth restating the, or at least, "my", design goals . . . . .
1 A PC keyboard interface for the MTX
a) as a stand-alone add-on board for the MTX
b) integrating the stand-alone design into the I/O board of MTXPlus+
2 PS/2 and USB keyboard compatibility
3 "Plug & Play", i.e., minimal (NO !) modification to the MTX
a) MTX keyboard interface connecting to existing MTX keyboard interface pin header
b) incorporating a pass-through connector to allow the MTX keyboard to be connected in parallel with the PC keyboard interface
c) minimal external signals, preferably NONE, other than power (and possibly additional ground)
4 Unless a compelling reason can be found, NO additional functionality to exploit any spare Propeller capacity
(Thought the I/O lines of Port 7 are available and conveniently placed should a use be found for them in this project)
Based on Bill's work so far, I believe that connection to the MTX OUT5 signal is NOT required (see 3c)
(Justification for this is described in Bill's earlier messages)
Ideally, a single pair of pins would be connected to the PS/2 or USB interface
To be connected to Propeller pins 1 & 2
One Additional Propeller I/O required for internal use for each keyboard type (i.e., 2 additional pins used)
(As a byproduct, also provides the interface for the activity LED)
(The second I/O could drive another LED if there was any point in it?)
(Need to "reserve" one of the currently unused pins on the Propeller - which?)
The feasibility of this depend son whether the pull-ups/downs and series resistors for both interfaces can be the same (requires testing)
Assuming that this can be done, a single jumper to select keyboard type (see Version 2.01 schematic)
If it can't additional jumpers will be required to select the keyboard type as per the Version 2.0 schematic)
Assuming that we can agree on this, the next step would be to test the USB code on the prototype boards - this would require swapping the current PS/2 keyboard interface pins with the low order sense bits
Any comments ?
regards
Dave
I'd like to try and "finalise" the design that we're going for here and think that it's worth restating the, or at least, "my", design goals . . . . .
1 A PC keyboard interface for the MTX
a) as a stand-alone add-on board for the MTX
b) integrating the stand-alone design into the I/O board of MTXPlus+
2 PS/2 and USB keyboard compatibility
3 "Plug & Play", i.e., minimal (NO !) modification to the MTX
a) MTX keyboard interface connecting to existing MTX keyboard interface pin header
b) incorporating a pass-through connector to allow the MTX keyboard to be connected in parallel with the PC keyboard interface
c) minimal external signals, preferably NONE, other than power (and possibly additional ground)
4 Unless a compelling reason can be found, NO additional functionality to exploit any spare Propeller capacity
(Thought the I/O lines of Port 7 are available and conveniently placed should a use be found for them in this project)
Based on Bill's work so far, I believe that connection to the MTX OUT5 signal is NOT required (see 3c)
(Justification for this is described in Bill's earlier messages)
Ideally, a single pair of pins would be connected to the PS/2 or USB interface
To be connected to Propeller pins 1 & 2
One Additional Propeller I/O required for internal use for each keyboard type (i.e., 2 additional pins used)
(As a byproduct, also provides the interface for the activity LED)
(The second I/O could drive another LED if there was any point in it?)
(Need to "reserve" one of the currently unused pins on the Propeller - which?)
The feasibility of this depend son whether the pull-ups/downs and series resistors for both interfaces can be the same (requires testing)
Assuming that this can be done, a single jumper to select keyboard type (see Version 2.01 schematic)
If it can't additional jumpers will be required to select the keyboard type as per the Version 2.0 schematic)
Assuming that we can agree on this, the next step would be to test the USB code on the prototype boards - this would require swapping the current PS/2 keyboard interface pins with the low order sense bits
Any comments ?
regards
Dave
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Keyboard replacement
Mark, the Speculator uses the NMI to update part of the screen, read the border colour and write the Spectrum key values. /NMI goes low when /INT goes low, if enabled with an OUT FF bit. There is a 2K SRAM (6116) that stores Spectrum key and Kempston joystick values. The Spectrum border written by OUT FE is read by IN 7E, while Spectrum key bits read by IN FE are written by OUT 7E. The Kempston joystick read by IN 1F is written by OUT 1F.1024MAK wrote: While on the subject of the ZX Spectrum and the MTX, how does Speculator handle the keyboard?
Mark
One of the two PALs on the Speculator board acts as a 8-to-3 line priority encoder and could have been replaced by a 74LS148. A8-A15 are converted into a three address lines that go to the SRAM. If A15 is low they are are 000, if A15 high and A14 low they are 001, etc. This gives priority to the half row with the Space/Break key.
Looking at the code again, it seems I didn't use a ninth SRAM byte for A8-A15 all low after all, which means the Speculator and the current version of the new MTX keyboard interface act in a similar way, but the latter could be improved.
Last edited by Tony Brewer on 17 Feb 2018 00:30, edited 1 time in total.
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Keyboard replacement
Dave,
How about adding the physical connection to your list of design goals? No need for any butchering of the MTX case in my opinion. Could you please post the photo of the StarTech USBMBADAPT cable here so others could see it? If the cable would be compressed when the lid is closed, then that would be an effective and free form of strain relief.
Here is a simple change I think you should make, requiring no modification to the circuit board. The Propeller output pins are logically OR-ed so that any cog can take an output high, whereas the keyboard matrix is logically AND-ed. Change the 74LS17 open-collector buffers to 74LS16 or 74LS06 open-collector inverters (or CMOS versions if you can get them in DIPs). The Propeller key logic could then become positive and two cogs could output to the sense lines, one for DR0-3 and the other for DR4-7, or perhaps even three cogs. The worst-case delays after OUT 5 would be reduced to 1 us or under and any lingering timing worries would disappear.
How about adding the physical connection to your list of design goals? No need for any butchering of the MTX case in my opinion. Could you please post the photo of the StarTech USBMBADAPT cable here so others could see it? If the cable would be compressed when the lid is closed, then that would be an effective and free form of strain relief.
Here is a simple change I think you should make, requiring no modification to the circuit board. The Propeller output pins are logically OR-ed so that any cog can take an output high, whereas the keyboard matrix is logically AND-ed. Change the 74LS17 open-collector buffers to 74LS16 or 74LS06 open-collector inverters (or CMOS versions if you can get them in DIPs). The Propeller key logic could then become positive and two cogs could output to the sense lines, one for DR0-3 and the other for DR4-7, or perhaps even three cogs. The worst-case delays after OUT 5 would be reduced to 1 us or under and any lingering timing worries would disappear.
Last edited by Tony Brewer on 16 Feb 2018 19:51, edited 1 time in total.