Keyboard replacement

Modern, Memotech inspired, hardware projects
User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Keyboard replacement

Post by Dave » 15 Feb 2018 21:51

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

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Keyboard replacement

Post by Tony Brewer » 15 Feb 2018 22:28

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:

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

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Keyboard replacement

Post by Dave » 15 Feb 2018 23:03

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

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Keyboard replacement

Post by Tony Brewer » 16 Feb 2018 00:28

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?
Last edited by Tony Brewer on 16 Feb 2018 20:00, edited 1 time in total.

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Keyboard replacement

Post by Dave » 16 Feb 2018 01:22

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

Bill B
Posts: 159
Joined: 26 Jan 2014 16:31

Re: Keyboard replacement

Post by Bill B » 16 Feb 2018 09:46

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.

User avatar
1024MAK
Posts: 555
Joined: 24 Dec 2012 03:01
Location: Looking forward to summer, in Somerset, UK

Re: Keyboard replacement

Post by 1024MAK » 16 Feb 2018 13:32

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:
  • 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.
I have never investigated this aspect of the MTX, so I don't know if games coders used the MTX ROM routine, or developed their own custom keyboard reading code. But as some programmers may have worked on projects for both the MTX and the Spectrum, they may have used similar techniques on both...

While on the subject of the ZX Spectrum and the MTX, how does Speculator handle the keyboard?

Mark

User avatar
Dave
Posts: 735
Joined: 11 Aug 2012 18:16
Contact:

Re: Keyboard replacement

Post by Dave » 16 Feb 2018 15:32

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

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Keyboard replacement

Post by Tony Brewer » 16 Feb 2018 15:44

1024MAK wrote: While on the subject of the ZX Spectrum and the MTX, how does Speculator handle the keyboard?
Mark
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.

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.

Tony Brewer
Posts: 62
Joined: 08 Jan 2014 20:50

Re: Keyboard replacement

Post by Tony Brewer » 16 Feb 2018 17:25

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.
Last edited by Tony Brewer on 16 Feb 2018 19:51, edited 1 time in total.

Post Reply