[+SC3000] Keyboard debounce and polling issues in MAME

[barbeque]

I've extended my problematic Hello World program with a call to scanf and ran into trouble almost immediately. I think I've boiled the problem down to the call to in_GetKey, which seems to return the wrong keys. Here's my test program:

Code: Select all

#include <stdio.h>
#include <conio.h>
#include <sys/ioctl.h>
#include <input.h>

#define ZX_LINE_FEED 10

void main() {
	// Setup
	textcolor(BLACK);
	textbackground(LIGHTGREEN);
	int mode = 1;
	console_ioctl(IOCTL_GENCON_SET_MODE, &mode);
	in_KeyDebounce = 120; // fixes reading "imaginary" ghost keys when pressing and releasing rapidly
	in_GetKeyReset();

	// Program continues from here
	printf("%cHello World\n", ZX_LINE_FEED);
	while(1) {
		char result = in_GetKey();
		if(result != 0) {
			printf("got %d (%c)\n", result, result);
		}
	}
}

I'm experiencing two problems:

1. Unless I set in_KeyDebounce, the key feedback is super rapid and also involves "ghost" keys (for instance, pressing F rapidly will produce the ascii characters 105, 91, and 73. This isn't such a big deal, since I need debounce also on the eSC-3000 emulator otherwise it ttttyypppeesss llllikkkeeee ttthhhhhiiissss, but it's a bit worrying that it's not reporting the correct characters.
2. The bigger problem is that only a few of the keys respond, and they return the wrong characters, all from the first "row" of the keyboard matrix (as per Enri.)

Here's a quick table of which keys produce which results.

• Pressing D (100) produces ASCII 56 (8)
• Pressing F (102) produces ASCII 105 (i)
• Pressing R (114) produces ASCII 107 (k)
• Pressing L. Alt/GRAPH produces ASCII 44 (,)
• Pressing left arrow produces ASCII 97 (a)
• Pressing up arrow produces ASCII 49 (1)
• Pressing right arrow produces ASCII 122 (z)
• Pressing down arrow produces ASCII 113 (q)

If this pattern holds, some key should also produce the kana key in PA4, but I haven't found it yet. One particularly weird thing is that the key which is produced is not even the same column of Enri's table: for instance, R is PA1 and K is PA6.

Basic Sanity Checks
Level III BASIC works fine on MAME 0227, so I'm assuming their keyboard handling is working.

As far as I can tell, the code in libsrc/target/sc3000/input/in_Inkey.asm is correct; I set breakpoints at the gotkey and gotkey_port_dd symbols, and they got hit as I would expect when hitting the keys that "respond." It also iterates the c register properly to step through the "rows" of the keyboard, and that value makes it into the I/O port write to the keyboard-select register at $0de.

I thought it might be a timing issue (somehow? MAME is obviously a software emulator, too, and just sets a member variable; if anything it would respond too quickly and mask problems that the real hardware would have) so I stuck in a pair of NOPs after the OUTs to the keyboard select register, like Level III BASIC appeared to when I looked at it in the debugger. That didn't make any difference to either problems 1 or 2.

As an aside, "sh build.sh -p sc3000" didn't seem to rebuild the target after my changes; if there's a better way to focus on quickly building one target at a time, I can update the wiki with it

Disclaimer
I know that this target is usually tested against the Common Source Code Project's eSC-3000 emulator, and this behaviour seems to work as expected there in my testing.

I haven't had a chance to test on real hardware yet, but I can dig out my SC-3000 and try to load from "tape" – almost all of the keys work.

Thanks for reading through all of this.

[barbeque]

No major update, but for the sake of completeness, I've done a small debug test here, by setting MAME to hit a breakpoint whenever ioport $DC (KEY PA7..PA0) is being read and the value is not the default FF (i.e. some keys are pressed:)

Code: Select all

wpiset $dc,1,r,{(ib@dc) != $ff}

This breakpoint only seems to get hit when I'm striking one of the above-mentioned keys (i.e. R, F, etc.) So I decided to set a breakpoint to watch for all writes to the key control register, $DE, so I can watch the key-select row strobing:

Code: Select all

wpiset $de,1,w,{(ib@de) != $ff && (ib@de) >= $f8}

This breakpoint is hit all the time in strobe order as you would expect - F8, F9, ... FF, which I already knew from disassembling my assembled rom, searching for AND $F8, and setting a breakpoint at that location yesterday.

Going for broke, I decided to see if $DD (KEY PB3..PB0) is changing:

Code: Select all

wpiset $dd,1,r,{(ib@dd) >= $f0 && (ib@dd) != $ff}

Now when I press A, I get back $FB (0b111110111). G produces $FD. These are the only keys that trip; if they're also tripping for the first row, there is no key associated with those columns in the matrix, so nothing happens.

However, the MAME debugger always says KEYSEL is set to 0b111. If I set that watchpoint for "wrote to DE," trigger it, and then do this once the emulator is paused:

Code: Select all

print (ib@de)

I get $FF back, no matter what we just set the $DE I/O port to. Which seems to be consistent with what we're seeing in the keyboard reading routine:

Code: Select all

in a, ($DE)

always ends in the A register being set to $FF. This is also what Sega BASIC seems to do, though, so it's probably the correct thing to do.

No smoking gun, but I will update the thread if I find any more keys that map weirdly, or miraculously figure out what MAME is doing differently eSC-3000 has some sort of binding system that's a little confusing for me to follow, but its actual keyboard-buffering code seems sane.

[dom]

I’m away at the moment so can’t take a look hopefully I’ll get some time after the weekend.

This does sound like a masking problem or mishandling of the modifier keys. Given that it works in takeda the key table is probably correct.

Very strange that it works perfectly in one emulator but not in another. We have run into random mame bugs on the past so maybe try a different version.

[barbeque]

No rush whatsoever, I'm just playing with stuff right now – I haven't even designed the hardware yet so it will be a long time until I'll actually need this program.

The SMSPower "MEKA" emulator has the same problem as MAME, so I think Takeda may be the odd man out here.

[dom]

I think the missing bit of code is setting up the input/output directions of 8255 - I’ve just got to remember/find the config values.

Well, this is a jolly mess all round. I tend to use either mame 0194 or 0229. Keyboard reading 0229 seems to be broken (for BASIC as well), but I've managed to get something working in 0194 (though I've had to disable reading the dd port since I'm getting rogue inputs).

The magic bit of code to kick things off is:

Code: Select all

ld a,$92
out ($df),a

[stefano]

BlueMSX includes the emulation of the sc3000. Could it be an alternative to mame?

[barbeque]

I do most of my development on a Mac, and I’ve gotten kind of used to the MAME debugger, so it would be nice to keep using MAME - everything else is Windows-only except for Meka whose Mac port is fragile. I’ve also just sent away to JLCPCB for a ROM cart PCB so I can try it on real hardware.

[dom]

I was bashing my head against a wall with this so I took a bit of a pause.

I ran into an additional problem where you can't read the port twice so as a result you couldn't have an upper case for the characters in the same row as the shift key.

So... the scanning code needs to be rewritten slightly so that all ports are read into a memory buffer and we test memory rather than ports directly.

[barbeque]

Thank you for all the attention and hard work you've given to this one so far. It seems like a confluence of annoying factors at a pretty low level.