SpritesMind.Net

An issue came up in the Plutiedev discord with the mouse. He took out the mouse support, but accidentally left the mouse support activated. When you activate the mouse or the tap and there isn't one plugged in, the current code has to timeout before it returns, which wastes a LOT of time. The very first nibble of the header is made while the device is deactivated, so a quick check should be made for the first value of the mouse and tap as an early out to get around the timeout. Something like this
That should return almost instantly if the mouse or tap isn't plugged in. If keyboard support is ever added, it should also check for 1, the first nibble of the keyboard header.

Is it possible to just add that part of the code directly in the SGDK mouse support ?

Hmm - I guess probably the best way to handle it would be in the code where you set the support flags. If you set the support flag for the mouse, check if there's a mouse. If so, allow the flag to be set. If not, don't set the flag. That routine really should check where it's possible, like with regular or 6-button pads, mice, etc. If you CAN verify a device associated with the support, do so. That really only works for things the SEGA ID routine can actually ID uniquely.

That was the problem in his code: setting the mouse flag when no mouse was there.

Doing the check only when you set the support flags means it won't work with hotplugging (I know, it's a bad idea to hotplug in the first place, but it's doable and people will keep doing it…). You really want to do the check every time it goes look at the peripheral (or at least, whenever SGDK believes there's going to be a mouse there).

But yeah, checking the initial nibble (the one that shows while TH is still set) before starting the packet proper is a very fast way to bail out. And yes, it really should be in the SGDK code itself, since it's SGDK the one that's doing the reads.

Yeah, didn't think about hot plugging... they'd have to try to set the support any time they looked for hot plugged controllers.

So, early out it is! Well, unless you make an official interface for handling hot plugging. Maybe a callback the user registers for when controllers change.

Sik wrote: ↑

Thu Nov 08, 2018 3:46 am

(I know, it's a bad idea to hotplug in the first place, but it's doable and people will keep doing it…). You really want to do the check every time it goes look at the peripheral (or at least, whenever SGDK believes there's going to be a mouse there).

Why is a bad idea to hotplug? You can hurt the hardware or something?

You can employ a counter and check the available devices once every second or so to not harm cpu speed.

Awaiting answer, this site is like music on Mars: never stops surprising you for good!

Yes, the risk of harming the hardware is the issue. Some plugs are made so that GND gets connected first but the Mega Drive's plug is not one of those. Worse yet, the shape of the plug makes the pins wear out easily if you're constantly plugging and unplugging (probably a bigger problem, even!).

Mind you, in practice I never had an issue so you probably shouldn't worry about it if you ever need to do it (and there's probably some sort of protection going on because it's perfectly possible for a pin to be set to the wrong direction), but it's definitely something you don't want to encourage. That said, supporting it when somebody does it anyway is still a nice thing to have if you can afford it (maybe the controller unplugged by accident, maybe they forgot to swap peripherals before turning it on, etc.).

I’m not an expert on electronics but:
A circuit doesn’t work until there is a circle between ground and current/positive, that’s why is called a circuit. If one of them isn’t connected electrons don’t race in the circuit and there is no power. Only possible failure is elements that make ground with air, but that’s not the case.

I don’t fully understand this: “pin to be set to the wrong direction”, do you remember that the connector is shaped to enforce only one way to plug it?

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.

Sik, check the jar experiment its basically how electricity began to be understood.

TmEE, you will get undesired results, sure; but damaged, why? probably that's implemented as a tristate.
- If both ends get the same value, no problem.
- If one is high impedance, no problem.
- If one is ground and the other is high you have a short circuit with very low amperage, probably nothing happens

Lots of electronics are designed to tolerant in such situations, check buses and ISA, PCI and similar things.

As I said I'm no expert, so happy to be wrong and learn things.

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.

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.

Gonna continue that discussion here to avoid more derailing:
viewtopic.php?f=13&t=2936