Controllers and wrong I/O pin directions

For hardware talk only (please avoid ROM dumper stuff)
Post Reply
User avatar
Sik
Very interested
Posts: 730
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Controllers and wrong I/O pin directions

Post by Sik » Tue Nov 13, 2018 5:08 am

Continuing from these posts:
viewtopic.php?p=34165#p34163
Sik wrote:
Mon Nov 12, 2018 4:06 pm
TmEE co.(TM) wrote:
Mon Nov 12, 2018 3:24 pm
Pins on the controller port can be both inputs and outputs and some devices expect the direction to be set different from what a normal controller configuration uses. If two outputs get connected together you will have one or both sides getting damaged sooner or later.
Reminds me, apparently the 3-button controller has no protection at all there (it wires the outputs as-is without any way to account for when the pin is configured the wrong way, which is common for TR on games supporting other devices). Does the console provide anything? Because I think Jorge said it doesn't, in which case WTF Sega (・_・)

My first thought was to add some sort of escape route (sorta like a pull-down resistor but working backwards, in that it would suck in the current to GND if two outputs happened to collide), but Jorge also scoffed at the idea.
viewtopic.php?p=34165#p34165
TmEE co.(TM) wrote:
Mon Nov 12, 2018 4:26 pm
There are 330ohm series resistors on TH and TL or TR lines which will help in cases using those pins out of the normal way. 330 ohms isn't a huge load to fight.
I was also told that, but the problem is that honestly to me this smells about as bad as trying to prevent damage to 3.3V Flash memory using resistors instead of proper level shifters - eventually the damage should accumulate over time, right? Given how much we bash people over not using level shifters now, to me it seems like the same logic should apply here. I suppose I could be overestimating the issue, but I really wouldn't like the idea of telling people to do something that turns out to slowly damage the thing with just normal use.

Also I recall that part of the conversation was that you should immediately switch back the pins to a "safe" configuration (read: only TH as output) if you don't immediately detect a non-controller peripheral in a port. Something that isn't ever mentioned anywhere (neither official docs nor unofficial ones that I've seen). Anybody know what's up with that, how much of a big deal is it? Because I've been trying to make sure to set up the I/O control ports a frame before actually using the peripheral, because some peripherals may misbehave if you tried to access them the wrong way the first time and don't give them time to return back to an idle state (and nobody will notice if it takes a few frames to detect a new peripheral).
Sik is pronounced as "seek", not as "sick".

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

Re: Controllers and wrong I/O pin directions

Post by Miquel » Wed Nov 14, 2018 6:59 pm

Sik wrote:
Tue Nov 13, 2018 5:08 am
I was also told that, but the problem is that honestly to me this smells about as bad as trying to prevent damage to 3.3V Flash memory using resistors instead of proper level shifters - eventually the damage should accumulate over time, right? Given how much we bash people over not using level shifters now, to me it seems like the same logic should apply here. I suppose I could be overestimating the issue, but I really wouldn't like the idea of telling people to do something that turns out to slowly damage the thing with just normal use.
Usually this kind of design is voltage tolerant, meaning a high voltage is a range of values, the chip detects a pretty big scope. Give the chip/design SEGA used to read, and we will search how tolerant is.
Sik wrote:
Tue Nov 13, 2018 5:08 am
Also I recall that part of the conversation was that you should immediately switch back the pins to a "safe" configuration (read: only TH as output) if you don't immediately detect a non-controller peripheral in a port. Something that isn't ever mentioned anywhere (neither official docs nor unofficial ones that I've seen). Anybody know what's up with that, how much of a big deal is it? Because I've been trying to make sure to set up the I/O control ports a frame before actually using the peripheral, because some peripherals may misbehave if you tried to access them the wrong way the first time and don't give them time to return back to an idle state (and nobody will notice if it takes a few frames to detect a new peripheral).
Assuming TH means high:
High voltage is never "safe mode", ground is. Why they used high as default is perhaps because it means 0, or button non-preset, when reading a button, but that's just a guess.
I think you are going too far with your considerations, a lot of hardware is resistor + grounded, for example buttons.

User avatar
flamewing
Very interested
Posts: 52
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Controllers and wrong I/O pin directions

Post by flamewing » Wed Nov 14, 2018 8:36 pm

Miquel wrote:
Wed Nov 14, 2018 6:59 pm
Assuming TH means high:
It doesn't: TH, TL, and TR are the names of pins used for I/O in the Mega Drive which can be configured for either input or output.

Chilly Willy
Very interested
Posts: 2614
Joined: Fri Aug 17, 2007 9:33 pm

Re: Controllers and wrong I/O pin directions

Post by Chilly Willy » Thu Nov 15, 2018 1:03 am

You should always try to ID the peripherals before changing lines. The controllers that need TR reversed: the mouse, the keyboard (rare), and the multitap. All can be IDed before changing the direction of TR. SGDK does so. You can force support for controllers, but that's all on the programmer at that point.

User avatar
Sik
Very interested
Posts: 730
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Controllers and wrong I/O pin directions

Post by Sik » Thu Nov 15, 2018 8:12 pm

Except that only works for Sega's own peripherals and not any of the third party ones. EA multitap is detected by meddling with port 2 and seeing what shows up in port 1, Miracle Piano keyboard is detected by configuring the I/O pins for the piano, sending a MIDI command and wait to see if it sends back a particular response in time. Those are the first two that come to my mind but I wouldn't be surprised if there are more (forgot what you did to detect XE-1AF, you just tried it and if it didn't work you assumed it wasn't there, I guess?).

The problem with "use peripheral ID first" is that it doesn't always work :​/ We need a better approach here (especially with multitaps, since you likely want to support both Sega and EA multitaps… though at least the latter reacts quickly enough that you could try bailing out quickly)

More importantly:
  • There's absolutely zero documentation on what's safe and isn't safe to do. This is dangerous.
  • Is there a list of every peripheral ID? It seems to be spread all around (and in some cases outright not documented, like with the printer - that one is %1010 if you wonder).
  • More importantly, none of that is a good excuse to not try to make a peripheral safe against misuse if it's feasible.
Also now that I'm thinking on it… what happens if you try to get the peripheral ID on an EA multitap? (given how it wants all pins in output mode for the second port, I wouldn't be surprised if it returns %1111, i.e. no detected peripheral)
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2614
Joined: Fri Aug 17, 2007 9:33 pm

Re: Controllers and wrong I/O pin directions

Post by Chilly Willy » Fri Nov 16, 2018 2:42 pm

They only unique IDs I've found are

Code: Select all

#define PORT_TYPE_MENACER       0x00
#define PORT_TYPE_JUSTIFIER     0x01
#define PORT_TYPE_MOUSE         0x03
#define PORT_TYPE_TEAMPLAYER    0x07
#define PORT_TYPE_PAD           0x0D
#define PORT_TYPE_UNKNOWN       0x0F
The keyboard is missing from that since there's no keyboard support in SGDK as I've never seen one for the Genesis. I know there is one, but it's so rare, I doubt anyone actually has one.

SGDK does the EA4Way check first, and assuming you aren't pushing the directionals on a 3 button pad, I don't see how it could cause any kind of trouble, and if you WERE, it's so brief that any currents will be transient to such a degree that I'd call it safe.

Other peripherals show up as unknown, or rarely as one of the other peripherals (IIRC, the trackball IDs as a menacer as long as you aren't moving it when the ID occurs). That's why SGDK only inits known peripherals, and requires the programmer to specifically enable the support for others. It's up to the programmer to warn the user before doing so, either in the game or the readme for the game that it WILL be using a particular peripheral.

User avatar
Sik
Very interested
Posts: 730
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Controllers and wrong I/O pin directions

Post by Sik » Fri Nov 16, 2018 8:17 pm

I mean, most games only support controllers and misbehave the moment you connect anything else, so not checking for anything not explicitly supported isn't unusual.

Some more for that list:
  • Printer returns 0x0A
  • Saturn controller returns 0x0B
  • Other Saturn peripherals return 0x05 (keyboard, multitap, analog joystick)
ID 0x00 seems to be shared by the Mega Modem (according to the docs), the Ten Key Pad, and from what I'm seeing there the Menacer too? Jeez, that ID is crowded huh? At least the modem has a physically different plug so that one is easy to rule out (and so far it seems it's "detected" by just trying to communicate with it, though I need to check again what Game Toshokan does, that one may be looking at the peripheral ID indeed). I suppose if somebody wants to support the Ten Key Pad one could check that unused bits are indeed 0 (as I imagine the Menacer will trip one of them at least, making it easy to discard).

None of the Master System peripherals can't be detected through the ID, but all of them seem to want TH as output and the rest as input (like controllers), so maybe it's easiest (and probably safest) to try to detect them first. Master System controller isn't interesting, but the trackball and the paddle may be, hence why I bring this up.

Which leaves these that I could remember:
  • XE-1AF
  • EA multitap (detected by writing %1111100 to port 2 and getting %xxxxx00 from port 1)
  • Miracle Piano keyboard (detected by sending a specific MIDI command and getting a response)
  • XBAND keyboard
Though EA multitap has no state and reacts quickly (it's a glorified multiplexer), so detecting it isn't that big a deal.

Also: note that some peripherals have a microcontroller (pretty much all the peripherals that are more than just a bunch of logic gates), and checking the peripheral ID toggles TH, which may cause them to try initiating a packet transfer. It's likely that the microcontroller will be busy after TH is brought back high again, so in those cases you probably shouldn't try reading the peripheral immediately. This means one has to keep track of what peripheral is in each port and only resort back to detection when communication failed.


EDIT: also the Saturn docs say that the 6-button controller may return ID 0x0C as well. I guess this happens if you try to retrieve the ID and it thinks it's time to return the extra buttons (in which case there will be more zeroes than usual).
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2614
Joined: Fri Aug 17, 2007 9:33 pm

Re: Controllers and wrong I/O pin directions

Post by Chilly Willy » Sat Nov 17, 2018 5:01 pm

Sik wrote:
Fri Nov 16, 2018 8:17 pm
I mean, most games only support controllers and misbehave the moment you connect anything else, so not checking for anything not explicitly supported isn't unusual.
Yeah, loads of games that hang if you have a mouse plugged in, for example. I tend to leave my mouse unplugged unless I plan to use it.
Some more for that list:
  • Printer returns 0x0A
  • Saturn controller returns 0x0B
  • Other Saturn peripherals return 0x05 (keyboard, multitap, analog joystick)
Handy... thanks.
ID 0x00 seems to be shared by the Mega Modem (according to the docs), the Ten Key Pad, and from what I'm seeing there the Menacer too? Jeez, that ID is crowded huh? At least the modem has a physically different plug so that one is easy to rule out (and so far it seems it's "detected" by just trying to communicate with it, though I need to check again what Game Toshokan does, that one may be looking at the peripheral ID indeed). I suppose if somebody wants to support the Ten Key Pad one could check that unused bits are indeed 0 (as I imagine the Menacer will trip one of them at least, making it easy to discard).
I'm not sure you CAN identify everything. For example, the SMS pad will return unknown/nothing, but it's always just readable without messing with TH. You just read the port and that's all the signals.
None of the Master System peripherals can't be detected through the ID, but all of them seem to want TH as output and the rest as input (like controllers), so maybe it's easiest (and probably safest) to try to detect them first. Master System controller isn't interesting, but the trackball and the paddle may be, hence why I bring this up.
As I said before, I think the trackball IDs to 0. Unless you move the trackball around, it's impossible to detect on it's own. You just always get 0s. Ditto for the pad, but reversed - you just always get 1s.
Which leaves these that I could remember:
  • XE-1AF
  • EA multitap (detected by writing %1111100 to port 2 and getting %xxxxx00 from port 1)
  • Miracle Piano keyboard (detected by sending a specific MIDI command and getting a response)
  • XBAND keyboard
Though EA multitap has no state and reacts quickly (it's a glorified multiplexer), so detecting it isn't that big a deal.

Also: note that some peripherals have a microcontroller (pretty much all the peripherals that are more than just a bunch of logic gates), and checking the peripheral ID toggles TH, which may cause them to try initiating a packet transfer. It's likely that the microcontroller will be busy after TH is brought back high again, so in those cases you probably shouldn't try reading the peripheral immediately. This means one has to keep track of what peripheral is in each port and only resort back to detection when communication failed.
That's pretty much why SGDK currently just IDs common controllers, and leaves the rest for the programmer to set specifically. If your game requires the trackball, there's no way to detect it, so the game just informs the player of the need and just turns on trackball reading.
EDIT: also the Saturn docs say that the 6-button controller may return ID 0x0C as well. I guess this happens if you try to retrieve the ID and it thinks it's time to return the extra buttons (in which case there will be more zeroes than usual).
I got some Sega MD and Saturn extension cables last year that I planned to hack together to make Saturn to MD cables, but wound up moving before I could do so. When I find them, I'll make a couple and work on support for the Saturn controllers I have (various pads, a 3D controller, a mouse (should be the same as MegaMouse), and a keyboard. The Saturn keyboard I have is a black PS/2 keyboard with a sega logo and a PS/2 to Saturn adapter.

User avatar
Sik
Very interested
Posts: 730
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Controllers and wrong I/O pin directions

Post by Sik » Sat Nov 17, 2018 9:25 pm

Chilly Willy wrote:
Sat Nov 17, 2018 5:01 pm
As I said before, I think the trackball IDs to 0. Unless you move the trackball around, it's impossible to detect on it's own. You just always get 0s. Ditto for the pad, but reversed - you just always get 1s.
Ugh, good call, it claims no motion. OK, just tell people to press A or B in the title screen to switch mode :v

That said, it's unlikely you'll support the trackball and something that has ID 0x00 at the same time, and telling people to keep the trackball idle when rebooting makes sense (analog joysticks already need this for autocalibration), so I guess that in practice you could just assume that ID 0x00 on boot is actually a trackball (and stays that way until next reboot, if you assume no hotplugging).
Chilly Willy wrote:
Sat Nov 17, 2018 5:01 pm
The Saturn keyboard I have is a black PS/2 keyboard with a sega logo and a PS/2 to Saturn adapter.
Sounds like you got the whole pack (the keyboard is rare, the adapter itself is rather common tho)


Anyway, the real reason for putting this thread in Hardware (and not Control) is because I wanted to know more about the hardware side of things:
  • How much protection does the console provide when pin direction is wrong… and in hindsight, many clones probably provide nothing, so it's about as good as nothing in practice I imagine.
  • The best way to provide protection on the controller side. I know about 330Ω resistors but that feels fishy, that's why I wondered if it was possible to create some sort of escape route e.g. to ground if it ends up on an output vs output situation (input vs input is easy because you can just slap a pull-up resistor there).
Sik is pronounced as "seek", not as "sick".

User avatar
TmEE co.(TM)
Very interested
Posts: 2321
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Controllers and wrong I/O pin directions

Post by TmEE co.(TM) » Sat Nov 17, 2018 9:59 pm

That resistor is the same as 330ohm to ground if it connects to another output, kind of like both outputs driving to a 330ohm load if their states differ (one side high, other low and vice versa). It is a current limit and roughly like lighting up a LED via an IO pin. I'm sure the IO port output drivers are designed for full 24mA drive capability for these long cables.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest