SpritesMind.Net

Sik wrote: ↑

Wed Jul 17, 2019 5:15 pm

I imagine Control mode is basically "emulate a D-pad"? Especially since the Master System controller calls it Control Pad (the term Direction Pad came with the Mega Drive).

Oh, duh. Yeah. No wonder it doesn't decode like a trackball - because it's emulating the standard SMS control pad. That explains why the buttons decode but not the moving.

Stef wrote: ↑

Wed Jul 17, 2019 10:13 am

I have to admit i don't know too much about that HV latching, i though it was "temporary", just the time you read out the HV value from the Int2 callback then the latch was released (probably by writing according register to VDP). Is that the case ?

Nope. Basically, the HV counter is frozen (from the 68000's viewpoint) and it's updated whenever TH goes from high to low (i.e. whenever IRQ2 would have to fire). The whole point of this mode is to make life easier when programming lightguns.

It's a bit silly that no one thought to make the latched counters a SEPARATE SET OF REGISTERS from the normal counters, and yet I don't know of a single chipset that does: the Atari 8-bit - same registers; the Amiga - same registers; the Genesis - same registers. The SMS has no latching. You're supposed to poll the light detect line while constantly reading the counters and then average out the values you get for horz and vert start/end readings.

The NES is even worse... no registers at all. You're supposed to blank the entire screen except for the target and then check the light detect line. If it's set, you hit, otherwise you missed.

…that leaves me wondering what happens when you first set the latch register (does it halt where it was at that point, or does it expose what would have been the last "latched" value, i.e. acting as two separate registers over the same address?). Then again, it didn't occur to Sega to latch the HV counter on 68000 read when in running mode (which leads to the potential of bits changing mid-read).

There's also the question of why the Nomad doesn't take the Sports Pad… but then again, I recall hearing it doesn't like the link cable in Zero Tolerance? (ironically, since two Nomads would have been the perfect way to use it) Not sure how true is that but I wouldn't be surprised if there's something weird going on with the pin directions. Do any other devices work?

Nomad + Propad6 = ok
Nomad + 3button pad = ok
Nomad + Mega Mouse = ok
Nomad + Phaser = ok
Nomad + Justifier (both guns) = ok
Nomad + Sports Pad = fail

Doesn't work in SMS games from flash cart either, so I wonder if it's a power problem. Not enough current on the port to power the optical pickups, maybe.

Sik wrote: ↑

Wed Jul 17, 2019 6:09 pm

There's also the question of why the Nomad doesn't take the Sports Pad… but then again, I recall hearing it doesn't like the link cable in Zero Tolerance? (ironically, since two Nomads would have been the perfect way to use it) Not sure how true is that but I wouldn't be surprised if there's something weird going on with the pin directions. Do any other devices work?

Nomad works just fine with the ZT link cable, I never had any issues with it and I did run it between two Nomad for extended period of time.

No clue about Sports Pad, don't have one but I can imagine maybe it has something to do with dirty power rails of Nomad, the pins of IO ports work exactly as other MDs...

Yeah, I just tried my ZT cable today and it works fine on the Nomad. As to dirty power rails, that might be the case. The Sports Pad uses an old MB88201 MCU to handle the trackball. Maybe it was susceptible to noisy power. The only thing on the Sports Pad that works on the Nomad are the two buttons, which I'd guess either go directly to the port, or through a 74HC02 to the port.

Chilly Willy wrote: ↑

Wed Jul 17, 2019 5:02 pm

joytest.zipI couldn't tell you why it was hanging, but it was. And the new code fixes the issue. The new functions for checking and setting latched counters is a good idea in any case. Here's the joytest main.c file - I changed it a bit to make it clear that you can compile with it set to auto detect the peripherals, or force the setting of trackball or phaser. Since those are SMS controllers, they don't autodetect. The code also defaults to autodetect. I also set it to use VDP_init() and JOY_init().
...

Glad to hear that ! Thanks again
I'm not really sure why it was hanging too but it's resolved so..
Thanks for having updated the joytest exemple too, I will update SGDK sample according..

@Sik> Thanks for clarifying, honestly it would have make sense to latch HV counter until the next read (or duplicating registers, don't know which ones is easier to build)..

It's possible it's not the MCU that's too susceptible to noisy power (though that probably isn't helping it) but the optical part. If the lights fluctuate too much I could see it causing the photosensors pick up spurious motion (and hence causing the random values).

Now I also wonder if there's enough decoupling in the Sports Pad (as the job of decoupling capacitors is precisely to avoid this problem).

Sik wrote: ↑

Thu Jul 18, 2019 2:57 pm

It's possible it's not the MCU that's too susceptible to noisy power (though that probably isn't helping it) but the optical part. If the lights fluctuate too much I could see it causing the photosensors pick up spurious motion (and hence causing the random values).

Now I also wonder if there's enough decoupling in the Sports Pad (as the job of decoupling capacitors is precisely to avoid this problem).

That would make more sense, and be an easier fix. Open the Sports Pad up and solder in a few caps.

Looking at this pic: http://www.smspower.org/forums/files/8_702.jpg
Seems there's no caps on the optical boards at all.

And if you look at this one: http://www.smspower.org/forums/files/5_781.jpg
There's no caps on the main board near the connectors for the optics.

Some more research related to mouse packets: Body Count is unable to detect the mouse in Fusion and I noticed that the mouse broke in Arkagis Revolution recently too, and the latter definitely doesn't care if the mouse is instantaneous or not. The only big change I did recently was changing the input code to rely on the peripheral ID so I suspected it may be related…

…and, um, yeah. Wrote some quick diagnostics screen and Fusion returns %1111 as the ID (occasionally blinking to %0000), when the mouse is expected to return %0011. So it's likely that Body Count is trying to detect the mouse through the ID as well. How the heck this didn't break more games is beyond me (I guess most games just try to read a mouse packet directly and see if it works?).

I guess that's one reason why games with hacked in mouse code don't use Fusion as their emulator of choice in playing the game. I can't say I remember ever trying the mouse support in Fusion.

For the sake of keeping track of this: when retrieving the peripheral ID you must absolutely make sure to read the TH=1 bits first and the TH=0 bits later.

I still want to see Body Count's code though, it's possible it's indeed doing it backwards and it somehow works with an actual mouse (but could still break other peripherals?).

I think the order isn't the main thing here, but rather the amount of time you wait after setting TH=1. When you reset the ports (generally to 0x40/0x40), you are supposed to wait two vblanks before reading the port to get the TH=1 ID bits. I imagine that if you read TH=0 bits first, but waited two vblanks after setting TH=1 before getting the bits, it would be okay. The wait period is almost certainly to give devices a chance to stabilize in their "off" state.

Except my init code actually sets it to 0x40 then goes to initialize the video hardware (which does take several frames) before it ever gets to even attempt to go into the detection routine and it still fails to see the correct ID (and the code doesn't bother retrieving a peripheral ID again if it decided it knows what device it is).

In any case I'm probably going to go even more extreme and add not just several frames (at the very least 0.1 seconds and I'm still not confident, just about anything MCU based will need a while to initialize after receiving power) but also force all three-line devices to do the reset sequence just in case. And that still probably wouldn't explain Fusion. And that still doesn't solve the Body Count mystery (which we really need to look into or we'll be left with an emulation unknown).

Didn't you send me your asm for that? I remember it setting the port to 00, reading for ID bits, then setting to 40 and reading for the other ID bits... basically a few usecs between setting 40 and reading the port. Now if you had done it the other way around, read the port, set to 00, read the port, set to 40, you'd probably have been fine.

You missed the initial write in InitInput.

Either way, I rewrote the whole thing as a state machine that changes what to do every frame and includes the reset sequence for both mouse and keyboard (・＿・) (especially since the latter may actually need it if you press Reset in the middle of reading it, as it seems to lose sync of what it's supposed to return if you read the wrong amount of bytes)