Hardware pinout/protocol questions

[Spitko]

I'm working on a USB/BT->controller/keyboard/mouse dongle. I don't actually have an x68k yet, (In the mail) so I'm hoping a few questions can be answered in advance so I can have a prototype ready to test before then.

1) Can 6 button controllers be used as 2 button ones for games that don't support it, or would I need to have a mode switch of some kind?
2) Are controller buttons dead shorts, or are there resistors inline with each button?
3) Does anyone have info on the mouse protocol? I've seen a few .asm files floating around, but please spare me the disassembly.
4) Does anyone have pinouts for the expansion header? I'm curious if I could build this as an expansion card vs a tacky external dongle that requires you plug a bunch of stuff into it.

[SuperDeadite]

The hardware only supports 2 buttons.  All games that support more buttons load their own drivers.

[Spitko]

Right, but it looks like all of the 2 button controller pins are on channel 1. So, if my understanding of the 6 button circuit is correct, you should be able to use a 6 button controller as a 2 button in games that don't support the 6 button setup (because the driver won't be flipping the CS pin).

[neko68k]

1) Yes. >2 buttons are supported by strobing the select pin for the multiplexers in the Capcom adapter. The Magical Pad should work too, but I'd have to check to be sure. The default state for the select pin is HIGH so games that only use 2 buttons will see dpad+ab but not the other buttons.
Caveat: This does not work with MegaDrive controllers, they use a goofy protocol because they have controller type ID in the DPAD bits when the select line is LOW.

2) The data pins on the controller should have pull-ups. IIRC the controller port also has pull-ups. Schematic

3) The mouse and keyboard protocols are documented in Inside X68000 somewhere around page 350. There are pinouts in Outside X68000, I don't remember where.

4) There are pinouts in Outside X68000. IIRC the entire 68000 bus and two clocks(at least) are on the IO headers. All address decoding is done on the IO slot card and not by the system itself. AFAIK you can't inject joystick, keyboard or mouse data since they're all controlled by physical, memory mapped devices. As in, the memory where the joystick is read doesn't really exist, it is pins on the joystick controller. uPDwhateveritis... I can't remember off the top of my head. Games would need to be patched to support this method.

re: SuperDeadites reply: the only games that need special external drivers are the ones that use the CyberStick in analog mode, AJOY.X. Everything else is just toggling the select pin(pin 8 on the joystick port) and reading the 6-bits of data for each HIGH and LOW. This includes: MD controllers including the CPSF stick _without_ the Capcom adapter(even though their protocol is gross it still works basically like this), Capcom adapter, Magical Pad, Crazy Climber controller, and CyberStick digital mode.

You can check the program and source here for some basics but I think you get it.

[Edit]
When the SEL pin for an MD controller is HIGH you get DPAD+A/Start. Obviously that's not ideal and games need to support the MD protocol to use these controllers correctly, even for 2 buttons mode :/

[Edit 2]
Also be aware that the SEL timing is really fast. Capcom toggles the SEL pin, IIRC, ~4us apart once per frame(~16ms) and expects data to be there instantly. For example, a 15mhz AVR isn't going to be fast enough to respond to that with interrupts or polling without dropping/ghosting button presses. I know, I tried. Now I'm redesigning with multiplexers on the output to guarantee stable output at least.

[Spitko]

Ah, this is great info.

I was building around mbed (since it has a built-in USB host controller) but I was hoping to drop to arduino for cost reasons. Looks like that's not super likely without some supporting hardware. Even with the mbed it might be tricky without multiplexers.

Is there any info on how the analog stick worked? It might not be worth worrying about for now, but I'd like to at least not design myself out of supporting it in the future.

[neko68k]

Here's the nitty gritty about AJOY.X

Link

[Spitko]

Ignoring the AJOY.X for a bit, I've got what I believe to be a working starting point for USB -> keyboard/joystick (in lieu of actual hardware).

The last remaining major component is the mouse. I can find pinouts, but no data on the protocol beyond some firmware that I'd rather not disassemble if I can avoid it.

[neko68k]

Here is the mouse protocol.

It's very nearly the same as a PS/2 mouse but just not quite there :/

[Spitko]

I've been doing some preliminary tests with my setup. Snags so far:

1) There's a weird behavior with the joystick that's hard to suss out. I think I need a debugging program of some kind. I believe you wrote one, though it's not clear how to boot directly into it. Right now it works fine in puyo puyo's menus, but once the game starts, several buttons become stuck down, and others stop working entirely.

2) Keyboard input is ignored. I think. I tried launching the cho ren sha image, but it boots to a command line prompt. However, while I've verified the data going to the serial port is sane, and the computer seems to be doing SOMETHING (PSU has very loud coil whine right now and reacts to even minor load/state changes), no keys actually show up. I'm using pretty standard 8N1 at 2400 baud, which seems to be correct (I certainly have no trouble reading the data coming from the 68k), and the protocol itself is very simple (7 bits for the key + 1 for make/break), so it's not clear what's going wrong here. KBD_READY pin is high.

What would be helpful:
1) Bootable images for controller, keyboard, and/or mouse debug programs if they exist.
2) Bootable human68k image that's known/good.
3) Moral support

[neko68k]

Huh... I'll throw together some bootable disks for you later. I don't think I have anything good for KB or Mouse testing but of course the command line will test the KB and you can right click on the mouse get the software mouse cursor to display at the command line (keep going and you'll get a soft keyboard, then a calculator, then disabled).

I have been distracted with other projects lately. I'll get back to mine later...

[Spitko]

Controller works. I thought buttons were wired to short to 5v, but it's the reverse; they're 5v pullups and the button shorts to ground.

Easily fixed, and now puyo puyo works as expected. The reason it worked in the menu is simply down to how it was coded; menu state doesn't have button repeat, so it was triggering on button release (which was re-press in this case). I've not yet checked extended button perf; I'll probably need your tool for that.

Keyboard is next to debug. I'm starting to think maybe there's some kind of handshake in the serial protocol, so I'll have to start digging deeper into the docs.

[Spitko]

Dug through the source code of a ps/2 adapter, and I don't see any kind of handshake. It also looks like bog standard 8N1 per the docs, so I've got no idea why nothing's working. I've checked the output with a scope and the signal is clean. The data the 68k sends to the KB on boot looks correct and matches the hardware docs, it just completely ignores bits I send it.

I'm starting to think my test case is just broken. Right now I'm using a cho ren sha image which fails to launch, then kicks me back to dos. The cursor blinks, but it's possible the system is wedged and not accepting input. Is there a better test for this?

I also tried booting into human68k but noticed the clock doesn't tick and it doesn't seem to do anything, so that's not a useful test either.

[Spitko]

Ok I'm know I'm being trolled by this damn thing.

With little progress being made I went ahead and hooked up the TX line so the x68k can control keyboard leds. There was a moment of silence followed by loud cursing when I realized it works. This means the 68k is absolutely getting my keypresses, and responding to them accordingly.

But I'm still having no luck at all translating that into actual input in things that need it. My new test case is Abunai Tengoku Densetsu, which boots to a "hit key" prompt; but no keys seem to advance it. So either the keyboard is in some kind of software state in which it doesn't forward input to the game, or it's just cursed.

EDIT: Ok turns out that test case was just bad. I went back to the broken chorensha image and I have functioning keys in DOS now. I have no idea what I did that fixed it, but at some point in time it was fixed and I just never knew because the new test case was bad.

WELP.

Mouse next.

Edit 2: Aaaaand something just let go in the 68k. Lost video, no longer boots, and you can hear the PSU fan slowing WAY down when the boot process tries to read the floppy drive. Guess the adapter's on hold for a bit. 

[Spitko]

Aaaand mouse works. It's a bit twitchy, but it gets the job done.

This all generally works as a proof of concept, and I'm getting tired of dealing with all these loose jumpers, so I just need to verify my joystick hack works, then I'll probably just make a PCB for it so I don't have to keep worrying about something coming loose and sending 5v up a 3v3 only pin

Should I make a new thread for this thing?

Edit: I could also really use a disk image with the joystick test on it. Capcom games don't seem to want to load on this thing as-is (Final fight gives a memory error, I guess it needs more than 2mb?)

[LowDefAl]

Final fight requires 2mb. Mine stopped booting and the error let me determine my ram setting has been lost (or perhaps worse, I have other issues with my system atm). I confirmed this with strider which also requires 2mb ram and now gives an error too. Both games previously worked on my Expert.

[neko68k]

Sorry, slipped my mind

Link

[EDIT: Hi, this is Kendrick. neko68k obviously meant to indicate that this link leads to a Zip archive that contains a disk image with input testing software. As a reminder everybody, please make sure you describe both embedded links and URLs that you spell out, so that everybody has a proper expectation of what they're clicking on]

[Spitko]

Works! No signs of ghosting. Going to call that a winner and spin up a new thread for the device itself.

As it turns out, the solution to "a 15mhz arduino isn't fast enough" is to use a 180mhz Cortex M4 instead