Keyboard emulation, how close is it to the original?

[Optimus]

I was just curious, if there is any emulator emulating properly this bug of the keyboard matrix, where if you press 3 keys, you get a 4th one. Also, why is this happening on real CPC?


Another reason for that is Batman the Movie, where I do remember you had to press all keys together E,D,2,0 and 9 to skip level. It just doesn't work on Winape32. Maybe because if I press it on real CPC, I also get the letter 1 typed, so the game algorithm also tries to detect this? And I always wondered why the emulator doesn't detect this cheat code on the game, what's special, but I remember this keyboard bug on the real CPC. I would actually try to also press 1 with ED209 on the emulator and see if it now works.


But just wondering, what is the mechanism behind this bug on the real thing, and if there is an emulator emulating it (and how easy it is to emulate?)


p.s. Heh, I just tried ED2091 in Batman the Movie and it works, yey!!!

[Bryce]

The bug on real hardware is due to the way the keyboard matrix is done and the fact that Alan decided to skimp on diodes

Bryce.

[arnoldemu]

My work in progress version of arnold emulates keyboard clash and also the lack of clash between plus joysticks.

[TFM]

The multiple keys bug if emulated well. But there's another bug, and no one does really emulate it well at all. Caprice does too less, WinCPC too much. 

[ralferoo]

But there's another bug, and no one does really emulate it well at all. Caprice does too less, WinCPC too much. 

What is this other bug?

[arnoldemu]

What is this other bug?

TFM described it a little to me, and this what I think it is:

Some emulators do a whole frame, then update keyboard and joystick inputs, then do another frame etc.

This means that keys are either pressed or released for an entire frame and that inputs are effectively synchronised to the specific frame unit the emulator uses.

This is not accurate, it means that keys appear to be pressed longer or shorter than they should. I had a bug relating directly to this in Blue Angel where it worked on one emulator but not on a real machine.

Of course the real keyboard inputs on a cpc are "parallel" in a sense that they come at any time during a frame and last for any duration. So in this case emulators don't capture it.

JavaCPC does a better job I believe because the emulation thread runs on a seperate thread to the "GUI" thread which captures and passes through the input.

I believe this is what he was describing to me.

[Executioner]

This is not accurate, it means that keys appear to be pressed longer or shorter than they should. I had a bug relating directly to this in Blue Angel where it worked on one emulator but not on a real machine.

I wouldn't think it would actually make a great deal of difference unless you actually were capable of pressing and releasing keys quicker than 1/50th of a second.

JavaCPC does a better job I believe because the emulation thread runs on a seperate thread to the "GUI" thread which captures and passes through the input.

The problem with this method is it would actually make it impossible to create a recording using the current SNP or SNR formats since they rely on the keyboard only changing at the start of the frame. We could create another format, but I've never seen software which was adversely affected (except maybe your problem in Blue Angel)

[ralferoo]

I had a bug relating directly to this in Blue Angel where it worked on one emulator but not on a real machine.

This shows the danger of writing to work on an emulator, rather than the other way round.

The problem on the real machine, almost certainly isn't the fact that the key is pressed longer or shorter, but in the period between not pressed and pressed, the input from the key will essentially be random. The typical approach for debouncing a signal is to read a number of times and then apply some operation to the result. So, for instance, you might read over 2 frames and AND or OR the bits together. Or you could time the on pulse and only report it after n reads (actually, on the CPC this is functionally equivalent to the OR of n reads).

If this was being done correctly to work with real hardware, it'd work on all emulators too. And as Executioner said, there's almost no way you could operate the keyboard at less than 1/50th of a second anyway - more typically you'd expect about 1/10th second accuracy.

It's pretty much the same deal with tape input too - on real hardware, you have different voltages, analogue circuits and voltage thresholds to worry about. On an emulator, you get a perfect signal every time. It's not to say the emulator is wrong, it reflects one possible scenario out of the many that could occur on real hardware, but the fact that it's so repeatable can cause you to overlook the real behaviour of a machine.