- --
Viewing Issue Advanced Details
| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 09538 | DIP/Input | Minor | Random | 7 hours ago | 1 hour ago |
| Tester | Marcher | View Status | Public | Platform | MAME (Official Binary) |
| Assigned To | Resolution | Open | OS | Windows (x64) | |
| Status [?] | New | Driver | |||
| Version | 0.288 | Fixed in Version | Build | x64 | |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary | 09538: mac128k, mac512k: keyboard occasionally auto-repeats phantom character(s) with no key held | ||||
| Description |
On mac128k and mac512k, at an unpredictable moment with no key held down by the user, the emulated keyboard spontaneously begins auto-repeating a character (or a short, fixed cycle of several characters) as if a key were stuck down. This is not triggered by any user input - it has been observed to start while the machine is sitting idle (e.g. with the Key Caps desk accessory open, or a terminal window in the foreground, no typing in progress). The glitch stops as soon as any other key is pressed, but can recur later at another random interval (observed gaps between occurrences range from under a minute to many minutes; it does not reproduce on every session, and can fail to reproduce for many minutes of idle waiting even on an affected machine/software combination). macplus was tested under the same conditions and did not reproduce the issue. This is very likely explained by the fact that macplus uses an entirely separate keyboard-emulation source file with no equivalent of the watchdog-reset mechanism implemented (details below) - not necessarily because the underlying trigger condition can't occur on macplus. |
||||
| Steps To Reproduce |
1. Start mac128k or mac512k with any bootable System floppy. 2. Bring up a state where the keyboard is idle and no typing is in progress - e.g. open the Key Caps desk accessory, or simply leave a terminal application (MacTerminal 1.1 in my testing) in the foreground. 3. Do not touch the keyboard. Wait - anywhere from under a minute to several minutes. 4. Observe: a character (or short fixed sequence of characters) may begin appearing/repeating on its own, at the machine's configured key-repeat rate, with no key held. 5. Press any other key to stop the repeat. The glitch may recur later at another random interval. This is intermittent; multiple attempts and idle-wait periods may be needed to reproduce, and it will not reproduce every time even on an affected configuration. |
||||
| Additional Information |
Captured via a custom bitbanger listener attached to -bitb, so the character values below are what actually left the machine's serial port (RS-232 modem port, transmit direction) during two separate occurrences of the glitch — included here mainly to show the *pattern* (single character vs. fixed multi-character cycle), not as a serial-port bug in itself. Occurrence 1 (mac128k, MacTerminal 1.1, repeat rate set to a fast setting): the character ']' repeated continuously for roughly 9 minutes before stopping (a different key was pressed to stop it). Occurrence 2 (mac512k, MacTerminal 1.1, default/fastest repeat settings): a fixed 4-character cycle repeated continuously for several minutes: ']', 'W', 'U', '5', in that order, each cycle taking approximately 300ms end to end. In a separate, non-serial-port test (Key Caps desk accessory open, no terminal software involved), the Key Caps "key currently down" indicator lit up for '[' at the same time the terminal was receiving repeated ']' - i.e. the visibly "stuck" key indicator and the actually transmitted character did not match. This may simply be an imprecise observation, or may itself be a useful clue. The keyboard is a real, physically separate microcontroller (an Intel 8021, part of the MCS-48 family) communicating with the main 68000 over a clock/data serial link through the VIA (CB1/CB2). mac128k and mac512k use src/devices/bus/mackbd/keyboard.cpp for this; macplus uses a completely different file, src/devices/bus/mackbd/pluskbd.cpp, selected via set_default_option("usp") in the macplus() machine_config (compare with the base config's default of "pad" -> "us", i.e. the ordinary M0110/M0120 pairing used by mac128k/mac512k). keyboard.cpp models a real watchdog circuit built from a 74LS123 monostable multivibrator, with comments giving the real-world resistor/capacitor values used to derive the ~56ms timeout and ~5.6ms reset-pulse length: peripheral_base::watchdog_w() -- kicked by the keyboard MCU's own firmware toggling one of its own output pins (P2 bit 1, see keyboard_base's m_mpu->p2_out_cb() hookup) peripheral_base::watchdog_timeout() -- fires ~56ms after the last kick; asserts INPUT_LINE_RESET on the keyboard's own MCU peripheral_base::watchdog_output() -- ~5.6ms later, clears INPUT_LINE_RESET, allowing the MCU to resume/reboot In other words: if the keyboard MCU's firmware ever goes more than ~56ms of emulated time without executing the instruction that toggles this pin, the emulation faithfully resets the keyboard's own processor, exactly as the real hardware would. pluskbd.cpp (macplus) has no equivalent mechanism at all. Its header comment states the emulation is "based entirely on examining the MPU program and observing behaviour" and explicitly notes "There may be additional hardware in the keyboard that is not emulated (e.g. a watchdog timer)" - i.e. the developers are aware real M0110A hardware may have similar circuitry, but it is not modeled in MAME regardless. This is a clean, direct explanation for why macplus does not reproduce this issue in emulation, independent of whether real M0110A hardware could exhibit an analogous fault. I looked into whether this reset could be caused by a MAME scheduling shortcut (e.g. skipping emulation of an idle-spinning CPU) rather than anything protocol-accurate, but this does not appear to be the case: src/devices/cpu/mcs48/mcs48.cpp contains no spin/suspend/idle-skip logic at all, so the keyboard MCU is being executed cycle-accurately at all times; it is not being "frozen" by a scheduler optimization. Instead, the protocol documentation at the top of mackbd.cpp is suggestive: although the keyboard is the clock source for the link ("clock source in the keyboard... This is not a multi-drop bus"), the host is documented as holding the data line low until it is ready to receive a response, i.e. the keyboard's firmware is expected to legitimately wait on the host at certain points in the handshake. My working hypothesis is that if the host (i.e. the emulated Mac OS/68000) is ever slow enough servicing the keyboard's interrupt/handshake - for whatever reason, disk I/O being the most obvious candidate given the machine's other activity, though this is not confirmed - the keyboard MCU's firmware can end up legitimately spending real emulated cycles sitting in its own wait-for-host loop rather than reaching the instruction that kicks the watchdog, and the ~56ms watchdog fires as a faithful (if perhaps rarely-triggered-on-real-hardware) consequence. The header comment in keyboard.cpp also explicitly documents that neither the M0110 keyboard matrix nor the M0120 keypad matrix has diodes to prevent ghosting. This is consistent with what a reset-and-rescan event might produce: in my occurrence 2 data, three of the four observed phantom characters (']', '[', 'U') sit in the same matrix column (P14, using the labeling given in keyboard.cpp's own matrix table), which is the kind of correlation expected from a ghosting artifact rather than random noise. I have not traced the exact post-reset matrix-scan code path far enough to turn this into a fully mechanical proof, and the Key Caps "[" vs. transmitted "]" discrepancy noted under Test Data may or may not be related. What remains unconfirmed: exactly what causes the emulated 68000/Mac OS to occasionally delay servicing the keyboard handshake long enough to trip the ~56ms watchdog. I was not able to correlate this with any single specific activity from external observation alone (it has been observed both shortly after floppy-disk-heavy activity and, in other occurrences, after some minutes of the machine sitting apparently idle following boot). Confirming this last link would most likely require live tracing/debugging of a MAME session at the moment the glitch occurs, rather than further static source reading. |
||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | mac128k, mac512k | ||||
|
Attached Files
|
|||||
Relationships
| There are no relationship linked to this issue. |
Notes
2
 No.24629
Robbbert Moderator
6 hours ago
|
Unfortunately it appears that the only bootable system disk is "sys11", and it doesn't contain notepad or any kind of application for typing. There's other system disks, but they are rejected as unknown format by MAME's internals. So I'm not able to confirm your issue. |
|---|---|
 No.24633
Marcher Tester
1 hour ago
|
I booted from sys11, and it does contain all the desk accessories, including Note Pad and Key Caps. Furthermore, these programs aren't required; just click on the file/disk name within the system, and you can change them (I was able to reproduce the bug even in this filename change field). I'm currently testing the reproducibility of the bug on this (sys11) system and will edit this report as soon as any updates are available. |