m24_kbd.cpp: Add support for proprietary mouse

[donohoe00]

• Add support for the proprietary mouse which plugs into the M24 / 6300 keyboard. The Logich Serial mouse, which is populated in serport1 by default, need to be removed for this to work (based this on what the Amstrad PC1512 does).
• Make 'hdc' the default device in the first ISA slot (as per drivers for other IBM and clone machines).
• Mark 6300 Plus as Working

[angelosa]

Isn't this just: ((mx & 3) ^ 1) | ((my & 3) ^ 1) << 2), roughly?

[donohoe00]

I think there have to be additions. This version works and is probably less confusing:

  BIT(mx+1, 1) | BIT(mx, 1) << 1 | BIT(my, 1) << 2 | BIT(my+1, 1) << 3;

[donohoe00]

To explain what's going on: each signal comes from an optical sensor, which is triggered by a rotating wheel for a given axis. If the mouse is moved at a constant speed along one axis, a square wave with a 50% duty cycle will be generated by the optical sensor. However, there are two optical sensors for each axis (hence 2 signals per axis) and the second sensor is offset slightly from the first, such that the phase of the second signal is offset by 90 degrees with respect to the first. I'm using bit 1 of the mouse coordinate that comes from the input system to generate one the square waves, and and bit 1 of [the coordinate plus one] to generate the square wave that's offset.

[rb6502]

That's standard quadrature signalling, and most mice work that way internally. Data-entry knobs are often a single-axis instance, such as

mame/src/mame/akai/mpc3000.cpp

Lines 298 to 335 in ccdef41

	// MPC2000 schematics have a diagram that indicates that a single positive click of the data entry dial
	// will cause a rising edge on PC4, then a rising edge on PC5, then a falling edge on PC4, and then a falling
	// edge on PC5. We assume the negative direction swaps which bit rises first as per traditional quadrature.
	// Experimentation shows that the uPD7810 wants the pulse trains to change at most every second read of this
	// port, hence the doubling up of the phases.
	switch (m_quadrature_phase >> 1)
	{
	case 0:
	rv = negative ? BIT5 : BIT4;
	break;
	case 1:
	rv = BIT4 | BIT5;
	break;
	case 2:
	rv = negative ? BIT4 : BIT5;
	break;
	case 3:
	rv = 0;
	break;
	}
	m_quadrature_phase++;
	m_quadrature_phase &= 7;
	// generate a complete 4-part pulse train for each single change in the position
	if (m_quadrature_phase == 0)
	{
	if (m_count_dial < 0)
	{
	m_count_dial++;
	}
	else
	{
	m_count_dial--;
	}
	}

[donohoe00]

Is there any action needed here? The mouse support seems to work quite well (I successfully used it to lose a game of Reversi under Windows 1.03). To my mind the theory is sound and the implementation is correct. The keyboard MCU firmware is interpreting the signals correctly and generating the right pseudo scan codes and sending them to the motherboard MCU. I could perhaps make the code more readable, or add a more explanatory comment...

[rb6502]

The "less confusing version" with BIT() that you referenced earlier would be good to include here, because it really is a lot more readable.

[donohoe00]

OK, Done!