The Sinclair QL Forum

Thanks for all the replays, let me give you some answers to your questions:

- Development environment is standard Arduino IDE which can be easily found here https://www.arduino.cc/en/software. First version was build on a breadboard using an Arduino Nano but then changed to the Atmega 328P (basically the same as on the Arduino Nano board) for this 1st PCB version.

- Capslock LED is PB5 like the Arduino Nano. So same as in your QLbase setup

- For a single pin 16 to 18 mA is no issue. Norman already gave some details about the limitations of the Atmega 328p. Currently I have no idea how much current flows trough the other Pins in case of a key press. I doubt this is a problem but I am going to measure this within this evening and will let you know the answer.

- The QL Power LED draws quite a lot of current. The one on my board, see picture above, is just using 2mA and bright enough.

- tofro wrote: "...(2 "normal" keys combined with the modifier keys)..." Is this really the case? This means I can not move my sprite in a game diagonal and shoot using space in the same time? Only go straight up down left right and shoot? A PS/2 Keyboard connected to QZero can do this (go diagonal and shoot). I never tried this using a QL keyboard on a standard QL. Probably some gamer can give clarification if this feature is needed? I guess a Joystick is probably an even better choice?

- "...<Shift><CursorUp>, some <Alt><CursorUp>..." So this is interesting. <Arrow up> creates the PS/2 scan codes 224, 117, 224, 240, 117 which seems to be correct. <Shift> + <Arrow up> creates the scan codes 18, 224, 117, 240, 18, 224, 240, 117. I see no scan code for page up. BUT the cursor movement in SMSQ/E is clearly page up, page down and word left, word right respectively. Is SMSQ/E translating this? I do not see any problem here but could be interesting to fully understand.

- "...16 MHz? If you could run it at 8 MHz..." I have no idea if it could run at 8Mhz w/o external X-tal and one could use the 2 gained pins for an other use case. I am most likely not going to try this but I am happy to see the results of someone else experiments.

Remarks: Thanks for all your inputs, really appreciate it. The project is still in an early stage where as I am already very satisfied with the result. Of course there will be some modifications in the software. I will release it in one or the other way to the community, I know some community members plan to build a Q68 into a QL housing. I am just doing this for fun, I personally have no use case for such an IF.

Stephan

Maskenlos wrote: "...(2 "normal" keys combined with the modifier keys)..." Is this really the case? This means I can not move my sprite in a game diagonal and shoot using space in the same time? Only go straight up down left right and shoot? A PS/2 Keyboard connected to QZero can do this (go diagonal and shoot). I never tried this using a QL keyboard on a standard QL. Probably some gamer can give clarification if this feature is needed? I guess a Joystick is probably an even better choice?

Indeed you can't (at least not without a quirk): If you have a look at the keboard matrix in the QL service manual, you'll see that once you press a third key (of the "normal" ones, which includes the cursor keys), the matrix "sees" an additional fourth key being pressed (the one that completes a rectangle over the key matrix). Keys within one keyrow can always be distinguished (that's why the cursor keys and space are located in the same row, presumably), but if you for example press <Left>, <Down> and "J", it looks to the QL as if "1" would have been pressed as well.
For games that wouldn't normally matter (because they concentrate on single keyrows), for character input it probably would.

The User manual even spends a complete paragraph on this:

Note that multiple key depressions can cause surprising results. In particular, if three keys at the corner of a rectangle in the matrix are depressed simultaneously, it will appear as if the key at the fourth corner has also been depressed. The three special keys CTRL, SHIFT and ALT are an exception to this rule, and do not interact with other keys in this way.

Maskenlos wrote: - "...<Shift><CursorUp>, some <Alt><CursorUp>..." So this is interesting. <Arrow up> creates the PS/2 scan codes 224, 117, 224, 240, 117 which seems to be correct. <Shift> + <Arrow up> creates the scan codes 18, 224, 117, 240, 18, 224, 240, 117. I see no scan code for page up. BUT the cursor movement in SMSQ/E is clearly page up, page down and word left, word right respectively. Is SMSQ/E translating this? I do not see any problem here but could be interesting to fully understand.

Then, apparently, you don't do the translation in the Arduino. PgUp should be the same scancode as "NumPad 9" (because it's the same key on the XT), or, "Gray PgUp" (the dedicated one) has e0 49 on some keyboards.

I think SMSQ/E translates these to <Shift>+Cursor Up/Down

NormanDunbar wrote:* Per pin, 40 mA maximum, 20 mA typical and advised, but note port and board limits.

Thank you.

NormanDunbar wrote:If you could run it at 8 MHz, then you can do away with the external oscillator thingy (or a crystal and 2 capacitors) and gain two extra GPIO pins

That sounds interesting. It would even be useful without PCB redesign, since I used a 3 pin 2.54 mm spaced footprint for the resonator. A 3 pin header could sit there instead.

You are very welcome Peter.

Cheers,
Norm.

Maskenlos wrote:- Capslock LED is PB5 like the Arduino Nano. So same as in your QLbase setup

Okay, thanks.

Maskenlos wrote:- The QL Power LED draws quite a lot of current. The one on my board, see picture above, is just using 2mA and bright enough.

Yes, the QL LEDs are very old and inefficient.

Maskenlos wrote:-I have no idea if it could run at 8Mhz w/o external X-tal and one could use the 2 gained pins for an other use case. I am most likely not going to try this but I am happy to see the results of someone else experiments.

Do you expect a speed issue if run at 8 MHz?

This looks really interesting.

I've recently got my QL USB keyboard adapter working after sitting on the shelf for a couple of years.

I have my name on the waiting list for a Q68 in the (hopefully not too distant) future, so I'm investing how I could modify it to work as a PS/2 adapter (though I'd like to keep it able to be used with USB as well). Mine is built on a Teensy board rather than an Arduino.

There are active USB to PS/2 converters. But converting from QL maxtrix to USB and then from USB to PS/2 is quite expensive and clumsy. Stephan's solution is so much more elegant.

By the way, my new QL baseboard can be used without Qzero, and support a Q68 inside a QL case. It was designed for that purpose also. Providing QL maxtrix to PS/2 conversion, QL network, power switch and audio ampilfier for the loudspeaker. This could be helpful as long as the Qzero is not in production due to chip shortage.

Peter wrote:There are active USB to PS/2 converters. But converting from QL maxtrix to USB and then from USB to PS/2 is quite expensive and clumsy. Stephan's solution is so much more elegant.

I agree that would be quite a clumsy approach to take. Sorry if I didn't explain very well, but that's not my intent.

I'm aiming to use a couple of spare IO pins on the Teensy board for the clock and data signals of the PS/2 interface. I should be able to insert PS2 character transmits into my current keyboard scanning routine.

I currently have a 200µs pause between each key row scan. I think that should be enough time to transmit 1 character scan code.

It should be possible to add this without affecting the current USB interface, so it could be connected to either PS/2 or USB (or potentially both if you were so inclined).

By the way, my new QL baseboard can be used without Qzero, and support a Q68 inside a QL case. It was designed for that purpose also. Providing QL maxtrix to PS/2 conversion, QL network, power switch and audio ampilfier for the loudspeaker. This could be helpful as long as the Qzero is not in production due to chip shortage.

That sounds really interesting, and I would definitely be interested. I'm building my own version as a learning project.

lostcarpark wrote:I'm aiming to use a couple of spare IO pins on the Teensy board for the clock and data signals of the PS/2 interface. I should be able to insert PS2 character transmits into my current keyboard scanning routine.

Probably you have considered that already, but PS/2 sends make codes and break codes. So it is not just other keycodes but a different mechanism compared to USB.

lostcarpark wrote:I currently have a 200µs pause between each key row scan. I think that should be enough time to transmit 1 character scan code.

Yes, but keep in mind that a PS/2 host can block the device for a while. One can not always immediatly send, but has to buffer until the host is ready.

That sounds really interesting, and I would definitely be interested. I'm building my own version as a learning project.

That is nice, but a real pity Stephan and you are not on the same microcontroller hardware. I understand the Teensy is technically superior, but it is too late now for my baseboard project to move away from the Arduino. If there is any chance to still get you involved with the Arduino: I have designed a simple PCB just for the converter. Tested and working. Which you could get for free either physically or as Gerber / Schematics. Some SMD soldering but nothing difficult. Please send me a PM if interested.

Peter wrote:Probably you have considered that already, but PS/2 sends make codes and break codes. So it is not just other keycodes but a different mechanism compared to USB.

Yes, I'm aware of that much.

Peter wrote:Yes, but keep in mind that a PS/2 host can block the device for a while. One can not always immediatly send, but has to buffer until the host is ready.

That's an issue I'll have to deal with if it arises. As many codes are multiple bytes, I'm planning to buffer them and send a byte at a time between scanning rows, so hopefully adding a check that the host is ready won't be an issue. Unfortunately most documentation seems to be written from the perspective of implementing the host side rather than the keyboard side.

Peter wrote:That is nice, but a real pity Stephan and you are not on the same microcontroller hardware. I understand the Teensy is technically superior, but it is too late now for my baseboard project to move away from the Arduino. If there is any chance to still get you involved with the Arduino: I have designed a simple PCB just for the converter. Tested and working. Which you could get for free either physically or as Gerber / Schematics. Some SMD soldering but nothing difficult. Please send me a PM if interested.

If I was starting over, I'd be inclined to use the Pi Pico, simply because they are incredibly cheap. There are ways that source code can be common across multiple microcontrollers, so perhaps code could be shared even if boards can't be.