sega/segapico.cpp: Add support for PS/2 peripherals

[qufb]

Adds 2 new devices for PS/2 peripherals, along with some common state that can be reused for future peripheral additions. Games that depended on these previously hanged waiting for communication, but are now playable.

Some small changes were done to the base state:

• Buttons for page changes were not being applied in a discrete manner, causing pages to advance multiple times on key press. Now they only advance a single time per key press;
• There was no way to map pen presses to the Storyware, so an additional input port was added to allow switching between tablet and Storyware, this is a workaround until proper layout support is landed, but at least allows more thorough testing of games;
• Memory mappings always assumed a max rom size of 0x7fffff, but PS/2 peripherals are mapped at 0x200000, therefore mappings have to be adjusted depending on which driver is loaded;

[ajrhacker]

These peripheral emulations should really be done through slot device interfaces instead of creating new clone systems, even if it's the case that they can't use the existing pc_kbd bus for technical reasons.

[qufb]

Can you point me at a reference example?

In that case, peripheral addresses would have to be mapped on the devices, and there's potential for conflicts. While we can just look at the ROM size to figure out in drivers which max size to map, it isn't clear which games use SRAM (if any at all), which would require larger mappings. Not mapping SRAM introduces unknown regressions. Any workaround here?

[qufb]

I guess something like this would be fine: https://github.com/mamedev/mame/blob/2afe6115b713867c217813970f3d5c31d676a923/src/devices/bus/sg1000_exp/sg1000exp.cpp#L126

Have 2 options, one for each device, then depending on which one was passed on the cmdline, use that device for peripheral read/write.

If this slot is already populated by the time the driver needs to configure memory maps, then we can just check if present and avoid those mapping conflicts. If not, at worst, we can just make some byte signatures of these ROMs to decide mappings, but I'd rather have a cleaner solution.

[qufb]

@ajrhacker Updated, should address your comment. Realized I could just install handlers like base_md_cart_slot_device, and these would take precedence over previous memory mappings, which ended up simplifying this logic.

[qufb]

Applied some cleanup based on suggestions I got on my other PR. Not planning on adding more to this at the moment, so feel free to review.

[cuavas]

Do these peripherals actually use the PC keyboard protocol to communicate with the system? If they do, they should really go in the pc_kbdc bus and emulate the wire protocol, even as a high-level state machine. Same for the host side – if it’s PC keyboard protocol, it should simulate the wire protocol.

[qufb]

I don't own these peripherals, but it seems like they use that protocol. Apparently you can use the keyboard with a regular PC: http://www.komotch2.com/junk/kj/skpico.htm

I'll adapt these to use pc_kbdc methods instead of ps2_r/ps2_w.