ZX Spectrum Recreated Would Work as Bluetooth Keyboard With MiSTer?

[pgimeno]

I've now read Sorg's other reply. I keep both a PC keyboard and a Recreated keyboard connected through USB; the hub has room for both and it's not a problem, I keep the Recreated behind the normal one while not in use (there's room between the PC keyboard and the monitor) and I switch them depending on the core. Similarly I have three controllers connected, and I choose one depending on the core I'm playing. So I can't follow his reasoning.

The ZX81 and Jupiter Ace cores could take advantage of this keyboard as well. In fact the ZX81 patch is already written.

A normal PC keyboard is not too suitable for the Spectrum core; the Symbol Shift key in particular (and the space bar at times) is in an inconvenient position.

[LamerDeluxe]

I've copied the responses here to a comment in the pull request, in case Sorgelig is not following the thread here. I hope we will be able to get to a compromise.

I don't even have one of these keyboards myself (yet?), but we used ZX Spectrums in middle school. I remember their unique system of entering code, which is impossible to do with a regular keyboard.

I do have a messenger bag with an image of the Spectrum keyboard on it, because it looks so cool and iconic.

[LamerDeluxe]

Good-News-Everyone.gif (59.71 KiB) Viewed 19628 times

The Spectrum Recreated support has been merged into the main core!

Sorgelig did mention that ZX80 mode has a completely different layout to the ZX81, if that core also gets official support. I have no idea how popular the ZX80 is, I don't think anyone familiar with it would expect it to work with the Spectrum keyboard.

[AmintaMister]

The Spectrum Recreated support has been merged into the main core!

Sorgelig did mention that ZX80 mode has a completely different layout to the ZX81, if that core also gets official support. I have no idea how popular the ZX80 is, I don't think anyone familiar with it would expect it to work with the Spectrum keyboard.

GREAT NEWS, thanks for your efforts and thanks to Sorgelig!

[rhester72]

Fantastic!!! Thank you for your efforts! (And thank you, Sorgelig, for the consideration!)

[Hetzen]

That's great news! It's not the real thing but it helps get near the feels of the system.

[pgimeno]

Thanks a lot LamerDeluxe! It's a relief that this was merged.

And again I have a hard time understanding Sorgelig's position. He seemed very adamant to insist that people with a non-US keyboard should use the US layout despite the keys not matching how they are labelled - why then should it be a problem for him to understand that people can use a keyboard that doesn't produce the same outputs as the labels in it?

Oh well.

[LamerDeluxe]

Thanks a lot LamerDeluxe! It's a relief that this was merged.

Glad to help. I was happily surprised that it did end up getting merged. Makes me want to source one of these keyboards.

And again I have a hard time understanding Sorgelig's position. He seemed very adamant to insist that people with a non-US keyboard should use the US layout despite the keys not matching how they are labelled - why then should it be a problem for him to understand that people can use a keyboard that doesn't produce the same outputs as the labels in it?

Oh well.

I think what usually is the thing with these old computers, is that games use different keyboard input layouts. There was often no standard for it. International keyboards often have characters in different positions. This might mess with the positions of keys that are use to control certain games. For instance, the key positions of Commodore keyboard symbols don't match those of an actual Commodore keyboard.

I've been thinking about what kind of solution I'd like for Commodore keyboard input. Someone recently told me he had been planning to have custom key caps printed for a mechanical keyboard, with up to four different characters per key, for use with multiple cores.

[LamerDeluxe]

I'm not sure how it works with getting the official release rbf updated.

Maybe people in this thread can test the unstable nightly version to see if it has any problems at all:
https://github.com/MiSTer-unstable-nigh ... 20fb16.rbf

[Hetzen]

I'm not sure how it works with getting the official release rbf updated.

Maybe people in this thread can test the unstable nightly version to see if it has any problems at all:
https://github.com/MiSTer-unstable-nigh ... 20fb16.rbf

All seems to work for me. Giving Dizzy a go.

[LamerDeluxe]

I'm not sure how it works with getting the official release rbf updated.

Maybe people in this thread can test the unstable nightly version to see if it has any problems at all:
https://github.com/MiSTer-unstable-nigh ... 20fb16.rbf

All seems to work for me. Giving Dizzy a go.

Thanks for testing!

What I heard is that, as it is one of Sorgelig's cores, the official update will probably happen the next time the core gets a framework update.

[Hetzen]

Thanks for testing!

What I heard is that, as it is one of Sorgelig's cores, the official update will probably happen the next time the core gets a framework update.

That's good to hear. Still makes me grin using this keyboard on this core. Certainly helps with the shortcut gymnastics.

[LamerDeluxe]

Thanks for testing!

What I heard is that, as it is one of Sorgelig's cores, the official update will probably happen the next time the core gets a framework update.

That's good to hear. Still makes me grin using this keyboard on this core. Certainly helps with the shortcut gymnastics.

Really cool that it is now possible to experience the Spectrum more like it actually was at the time, on the MiSTer.

[JaseDaMase]

I was about to post about this as I noticed there had been some kind of integration. I'm about to buy one. Most are quite expensive but I'll be selling a couple of real spectrums to fund it. Wish I'd bought one when they were being sold off for about £20

[_paul_]

The good news is that support for the recreated keyboard now appears to be integrated as part of the main ZX Spectrum core.

viewtopic.php?p=69424#p69424

[LamerDeluxe]

The good news is that support for the recreated keyboard now appears to be integrated as part of the main ZX Spectrum core.

viewtopic.php?p=69424#p69424

Yes, it took a while until the framework got updated for the Spectrum core, but nice that the keyboard support made it.

These keyboards are indeed pretty expensive and seem to be only available from the UK, which would add extra VAT on top of it for me.

[Higgy]

Another option is to use a real Spectrum and convert it to USB:

https://hackaday.io/project/2076/instructions

I did this years ago when I was given a broken Spectrum. I used it with a Raspberry Pi and Spectrum emulator.
There is also a switch to toggle Keymaps.
After some time I decided to relook at the Spectrum and managed it fix it (ram chip failure).

[Newsdee]

Another option is to use a real Spectrum and convert it to USB:

https://hackaday.io/project/2076/instructions

I did this years ago when I was given a broken Spectrum. I used it with a Raspberry Pi and Spectrum emulator.
There is also a switch to toggle Keymaps.
After some time I decided to relook at the Spectrum and managed it fix it (ram chip failure).

I really want to do this but still looking for an easy solution without soldering. I saw a PCB version but I don't think it's being sold...

[MikkyTee]

https://www.hermitretro.com/zxzero.html

[pgimeno]

Why have a MiSTer, if you can emulate a Spectrum on a Raspberry Pi Zero

As for using a real Speccy case with a microcontroller for USB interfacing, well, I've got some news. I tried to do my own Speccy keyboard to USB interface, using a Speccy case that is currently unused because I have a dK'tronics keyboard.

And while working on it, I realized that things are not so easy.

The USB specification is hard to understand and quite large and dense. The keyboard protocol, by default, only supports up to 6 non-shifting keys pressed at the same time. It's possible to overcome this limitation by making a keyboard work as if it was multiple devices, i.e. as if you had several keyboards connected at the same time, each able to send its own set of 6 keys. It's a bit as if the keyboard was functioning as a USB hub with multiple keyboards attached. In one place I saw a mention that alternatively, it's possible to "negotiate" a larger "descriptor" (that's a USB protocol term) that would allow for more than 6 keys, but I'm not sure how that is done or whether it's doomed to failure or whether it would be supported by the MiSTer's Linux keyboard driver.

Given the above, you need a library that can support either behaving as multiple devices, or sending a longer descriptor, or know how to modify one or use one in a way that lets you do that, for which you need a bunch of knowledge on the USB protocol. Guess how many of these projects use a microcontroller software which supports NKRO in the USB driver. If you guessed one or more, guess again.

That also explains why the Recreated ZX Spectrum creators made such a weird protocol. What they do is send a real keyboard key press as a certain USB keyboard key press + release, and a real keyboard key release as a different USB keyboard key press + release. That way, they no longer care about the limit of 6 keys in the USB protocol: they can perfectly do with even one key at a time, and that way they can detect the press and the release of every key on the emulator side without limits. At first I thought it was their way of making it proprietary and closed, but later I realized that (at least the primary reason) was for supporting more than six simultaneous key presses without going into the gory details of how USB works and possibly breaking compatibility with some keyboard drivers.

And, well, that gives us hope. Now that we have Recreated support in the Spectrum core, I can work on microcontroller code for supporting the Recreated protocol, instead of smashing my head on the wall while trying to decipher the USB specification.

[rhester72]

Asking ENTIRELY out of ignorance...are there really any (many) cases where more than six simultaneous keypresses are required on the Spectrum to achieve, well, anything at all?

[pgimeno]

I think certain cheats require that. I'd have to look up which ones.

And, well, if it can't pass a keyboard test, it feels less like the original machine. The creators of the Recreated ZX Keyboard considered it important enough as to drive the design of their protocol.

[pgimeno]

Well, the software is ready, I just have to add a README and a license (probably Expat, like the USB library it's based on) and push it to a repository. I'll try to find some time in the next few days.

This began when Chris23235 posted this link in this same thread: https://www.instructables.com/ZX-Spectr ... rd-Part-1/ - the idea was attractive, but there were some problems with it. Most importantly, that the source code was not available, and the keyboard software had some quirks that I wanted to remove: pressing BREAK would send an escape key and change the keyboard mode.

Then I noticed that the Minimus, the microcontroller board which was used in the above tutorial, was no longer for sale; the company that made it appears to have folded, because the original web is no longer online. Still, I was able to buy a few via eBay. But it's not suitable for a free open source public project, because we'd be in the same situation as with the Recreated ZX Spectrum keyboard itself: there would be fewer and fewer available units at prices higher and higher.

But the Minimus is a great platform for development and testing, so I wrote the software for it, keeping in mind the idea of porting it later to other boards. So I wrote a keyboard handler, and that's how I discovered the limitations of the USB keyboard protocol regarding 6KRO, which made me freeze the project for a while.

And then I had the idea of changing the protocol to Recreated to work around that limitation, and made the previous post. And I got it working, with some caveats. It's not too easy to explain the problem, but the short version is that it works fine with the core, but not so fine with the FUSE emulator.

Long version: The Recreated protocol requires some keys to be pressed while holding Shift, and that changes their meaning with respect to the unshifted versions. When pressing a key that requires Shift, the real Recreated always sends a sequence of press Shift / press the key / release the key / release Shift. That's at least three or four transmissions per key press or release, haven't checked which (pressing Shift and pressing a key can be sent in the same packet, and I don't know if it takes advantage of that; but releasing Shift must be sent separately after releasing the key, otherwise the Shift release comes before the key release, and order matters in this case). However, in my software, to minimize the amount of packets sent in order to reduce latency as much as possible, the Shift key is not always released and pressed again in the case of the shifted keys; instead it is held active in cases where it's not necessary to release it. This is fine in the core, because it tracks the state of the Shift key and uses that to determine the exact meaning of a given key. But FUSE seems to require receiving a Shift and the key code, every time a shifted key is expected, so for some key combinations it will read the wrong key.

Well, last weekend I was able to port it to a Pro Micro, which is still for sale (17.90€ on digikey.es, and there are cheaper ones on eBay). Whoever designed the Pro Micro made a very weird choice of pins (the letters followed by numbers, which are the port ID followed by the bit number), which has caused me a bit of headache with the porting, but I'm confident that my workaround for that mess won't add significant latency. Shame the Minimus is no longer produced - it's quite nice in comparison, and it has a more logical order.

[JaseDaMase]

I can confirm that this now works perfectly as if it was a zx spectrum. Been using it for the last month or so and it's a joy to use now it has the proper functionality.

[pgimeno]

There's been a change of plans. Rather than post immediately what I have so far, I'm going to design a PCB with an idea not too different from this:

https://hackster.imgix.net/uploads/atta ... 55&fit=max

(idea taken from here: https://www.hackster.io/news/a-zx-spect ... 5b0ceb6339 )

With the Pro Micro, obviously, instead of a Teensy. One for ZX Spectrum and one for ZX81. The problem is that these are not compatible - the data lines (the 5-pin cable/connector) are reversed, and there are two address lines (two lines in the 8-pin cable/connector) that are flipped, in the ZX81 vs the rubber-keyboard Spectrum; dunno about the Spectrum+. Also, neither of those corresponds to the layout that I used, because I mistakenly assumed that they would be in sequential address order and compatible.

Since I couldn't find it online (except for an indirect version in the Spectrum service manual), here's the pinout of the ZX81 and ZX Spectrum keyboard connectors:

Code: Select all

ZX81

  connections                  isolation
D4 D3 D2 D1 D0     A11 A10 A12 A09 A13 A08 A14 A15
   isolation                  connections

approx. 18.5 mm from D4 to A11


Spectrum Rubber keyboard

  connections                 isolation
D0 D1 D2 D3 D4     A11 A10 A09 A12 A13 A08 A14 A15
1  isolation       1         connections

approx. 145.1 mm from D0 to A11

Edit: The A and D numbers are the address and data lines they are connected to, i.e. how they are read from the machine. For example, in a Spectrum, IN 65278 would send a 0 through A08, which is the third from the right, thus reading the row CAPS SHIFT to V, and bit 0 of the response would come through D0, which is the first from the left. However, in a ZX81, the SHIFT key would come from the first from the right in the 5-pin connector, and the rows ASDFG and 67890 would be swapped with respect to the Spectrum.

I haven't confirmed it, but a friend has told me that a Spectrum+ keyboard and a rubber Spectrum keyboard are pin-compatible.

Edit: and a close look at this clear picture of a Spectrum+ membrane reveals that to be the case: http://web.archive.org/web/202305110504 ... mbrane.jpg

[pgimeno]

Progress report:

The software is finished and it appears to be working; I've added a 6KRO standard mode together with my version of the NKRO Recreated mode (see previous post for the differences with the actual Recreated keyboard and the associated issues - but it should work fine with MiSTer). Of course there's the natural ghosting that the matrix membrane unavoidably produces, so it's not actual NKRO but you get the idea... hopefully.

The hardware design is also finished and I've ordered the PCBs. I'm waiting for them to arrive, which will be a while because I selected the slowest shipment method. I have to check that the drill positions match the screws and the connectors match the original positions in the board closely enough - we want those fragile membrane ribbons to be as relaxed as possible, don't we?

I also want to test the software with the real keyboard, to verify that I didn't screw up the order of any of the connectors and to make sure that it works fine in a "field test" as opposed to a "laboratory test" (so far my testing has consisted of using a jumper wire to connect a row to a column, so I didn't even test two keys at a time).

Once the PCBs are checked and the software field-tested, I'll make the repository public. The license is already decided: Expat, like the PJRC library it's based on, as anticipated.

I've made a blunder with the ZX81 PCB. It's supposed to route a pin to zero, to automatically differentiate it from the ZX Spectrum, but I forgot to add that before ordering the PCBs. So in this first version I will use a wire to work around the mistake. The only difference is how Symbol Shift is handled in Standard mode, i.e. as Ctrl in the Spectrum and as a period in the ZX81. There's no difference in Recreated mode.

The Standard/Recreated mode selection will be done with a jumper, but I guess you can replace it with an external switch. There's a provision for an extra mode selection jumper, in case other modes are deemed necessary in future, like full Recreated protocol compatibility or other assignments for Caps and Symbol shift in standard mode.

[AmintaMister]

Progress report:

The software is finished and it appears to be working; I've added a 6KRO standard mode together with my version of the NKRO Recreated mode (see previous post for the differences with the actual Recreated keyboard and the associated issues - but it should work fine with MiSTer). Of course there's the natural ghosting that the matrix membrane unavoidably produces, so it's not actual NKRO but you get the idea... hopefully.

The hardware design is also finished and I've ordered the PCBs. I'm waiting for them to arrive, which will be a while because I selected the slowest shipment method. I have to check that the drill positions match the screws and the connectors match the original positions in the board closely enough - we want those fragile membrane ribbons to be as relaxed as possible, don't we?

I also want to test the software with the real keyboard, to verify that I didn't screw up the order of any of the connectors and to make sure that it works fine in a "field test" as opposed to a "laboratory test" (so far my testing has consisted of using a jumper wire to connect a row to a column, so I didn't even test two keys at a time).

Once the PCBs are checked and the software field-tested, I'll make the repository public. The license is already decided: Expat, like the PJRC library it's based on, as anticipated.

I've made a blunder with the ZX81 PCB. It's supposed to route a pin to zero, to automatically differentiate it from the ZX Spectrum, but I forgot to add that before ordering the PCBs. So in this first version I will use a wire to work around the mistake. The only difference is how Symbol Shift is handled in Standard mode, i.e. as Ctrl in the Spectrum and as a period in the ZX81. There's no difference in Recreated mode.

The Standard/Recreated mode selection will be done with a jumper, but I guess you can replace it with an external switch. There's a provision for an extra mode selection jumper, in case other modes are deemed necessary in future, like full Recreated protocol compatibility or other assignments for Caps and Symbol shift in standard mode.

THANKS for your great work!

[pgimeno]

I guess it's time for an update.

First, I don't have my two ZX81s because I sent them to a friend for some upgrades. There were screw position and size problems with the ZX Spectrum boards, so I was waiting until I test the ZX81 boards before ordering new ones. The Spectrum ones are supposedly fixed, but the screw positions might still be a bit off so was holding the posting of news until I had them, but it's been a while so I wanted to post something to let you know that things are still ongoing. The good news is that the Spectrum PCB works well with both a rubber keyboard and a Spectrum+ box, except for the aforementioned screw holes.

On the other hand, I've found that the ARM-based STM32F103 boards are cheaper than the AVR-based Pro Micros. The problem is that the software of the ATmega32U4 is already finished and working, and it might be a while before I get the STM-based one to work. It might take a while to get an STM based board working as a USB device, so for now I'm sticking with the Pro Micro; the price difference is not too big anyway for small-scale production.

If there's enough interest I can post the WIP software and PCBs so far, but take into account that the Spectrum PCB screw positions are off and the corrected positions are untested, and the ZX81 PCB screw positions are untested and the board still unfixed. Also, I decided to add a new feature (using the reset button in the Spectrum+ keyboard for either resetting the MCU or switching modes) but the mode switching is not yet programmed.

[AmintaMister]

I guess it's time for an update.

First, I don't have my two ZX81s because I sent them to a friend for some upgrades. There were screw position and size problems with the ZX Spectrum boards, so I was waiting until I test the ZX81 boards before ordering new ones. The Spectrum ones are supposedly fixed, but the screw positions might still be a bit off so was holding the posting of news until I had them, but it's been a while so I wanted to post something to let you know that things are still ongoing. The good news is that the Spectrum PCB works well with both a rubber keyboard and a Spectrum+ box, except for the aforementioned screw holes.

On the other hand, I've found that the ARM-based STM32F103 boards are cheaper than the AVR-based Pro Micros. The problem is that the software of the ATmega32U4 is already finished and working, and it might be a while before I get the STM-based one to work. It might take a while to get an STM based board working as a USB device, so for now I'm sticking with the Pro Micro; the price difference is not too big anyway for small-scale production.

If there's enough interest I can post the WIP software and PCBs so far, but take into account that the Spectrum PCB screw positions are off and the corrected positions are untested, and the ZX81 PCB screw positions are untested and the board still unfixed. Also, I decided to add a new feature (using the reset button in the Spectrum+ keyboard for either resetting the MCU or switching modes) but the mode switching is not yet programmed.

Thanks for your precious efforts! Lot of interest here!

[pgimeno]

Well, the code is up but remember the repo contains the BAD PCBs: https://codeberg.org/pgimeno/ZXUSBKB (edit: more specifically, the bad PCB for Spectrum and the untested PCB for ZX81).

The code is working; anyone who doesn't mind to bend the membranes a bit and who prefers to make their own way to fix the board to the case, can use it. It's not field-tested though, just lab-tested.