Trying to make a Home Made SS 6P Multitap

[SaturnAR]

Hello forum, im working trying to make a SS 6P multitap.

I'm using a Microchip PIC microcontroller model: 16F873A to simulate the MT & process info that'll be sended to SS.

The comunication between SS and my PIC(MT simulator) seems to be working fine. Aprox. 40 refresh per second(this speed really surprise me, because its really to slow for the PIC, but...40 is a respectable number)

Im simulating as if the PIC is the MT and haves a Digital SS pad connected on channel 1 ,all other 5 channels i'm sending them as UNNCONECTED TAP.

When i plug my electronic circuit on the SS, games recognize the simulation and shows one digital pad connected on game screen(the one i say is connected to channel 1) but when i press a button in the pad, the SS console doesn't do it. So...it all works fine, but...SS isn't detecting the buttons im pressing on the pad.

The protocol and the data im sending:

Multitap Protocol

Of course, i've connected a trigger on PORTA,0 of the microchip PIC microcontroller, so that if i press the button, it sends the Right arrow of the pad as pressed.This isn't shown in the tables.

Tech Definitions & structure im using:

*I'm comunicating with SS in SH-2 direct mode.

*Method of comunication: 3 line hand-shake method (between TH,TR & TL pins)

Each connected peripheric on each channel of the MT haves their own Saturn ID and must be sended one by one.

Info:

The Saturn ID(the size is 1 byte) have this struture:

High nibble(four bits) indicate the "Saturn peripheric Standard Format"(there are 4 avaiable):

Digital device(0 hex);

Analog device(1 hex);

Pointing device(2 hex);

and keyboard device(3 hex).

Low nibble(the other 4 bits) of Saturn ID indicates data size of connected peripheric:

for digital device, data size is 2 bytes;

for analog device, data size is 5 bytes;

for pointing device,data size is 3 bytes;

for keyboard device,data size is 4 bytes.

*So, Im sending 0 Hexadecimal to indicate Digital Device connected on channel 1.

* DATASIZE im sending for pad connected is 2 hexadecimal, this also taken of : "SATURN Digital Device Standard Format"

*For the channels im sending as unconnected tap: i use F hexadecimal as ID and F hexadecimal as data size. Why? The document(PDF file) says that when a channel of the Multitap have no peripheric connected to it, FF hexadecimal must be sended as Saturn ID.

Any help or sugestion will be really usefull.

Regards.

 

[ExCyber]

The basic protocol looks correct as far as I can tell. Are you sure that you're supposed to send a Saturn ID and not a Megadrive ID when sending the ID code of each attached device?

 

[SaturnAR]

Hi ExCyber, thanks for the response.

Nice question...

Well as you would all be able to see on the protocol in the link i've posted, the oficial document refeers as M6ID3,M6ID2,M6ID1,M6ID0.

Last number seems to be(must be) the bit hierarchy in the high nibble of the ID byte.

"M6ID" part is the problem! is the only part in the entire documents in witch this word appears

So..i've readed & readed over & over again, and seems like M6ID+DataSize is in fact, Saturn ID byte.

All the info i have to make this you can see it here:

SMPC Document

On page 86(Acrobat counter) you can see the section specifiying the 4 types of "Sega Peripheral Standard Formats". So i think this is the ID i should respect & send.

I'll try sending the Mega Drive ID(B Hex) and not Saturn ID, I've already done this, but i forgotten what happened( obviously nothing great!).

But...Perhaps something is wrong, some byte i'm not sending..don't know! im getting crazy...

I really need some help, as soon as i'm able to make the Multitap Works,i will post all the info and files.

For those who know asm lenguage, Microchip PIC Microcontroller use a "similar" asm, but with a smaller instruction set & sometimes pretty different instructions.

Here's the file i've made and that i'm actually trying(my original program was larger(complex), but im now trying to make work this basic thing... )

I've attached the asm file so all of you could see it and, why no?, analize & critic it.

Thanks for reading me.(yes, my english sucks, i know...sorry..im trying my best)

Good luck!

 

[ExCyber]

Yeah, I noticed that "M6ID" wasn't used anywhere else, but it is somewhat similar to "MDID", so I thought maybe the translator misread it or it was an error in the original docvument...

edit: I see on Table 3.38 there is a "DS9ZE" rather than "DSIZE" in one cell, so this seems even more likely now...

 

[SaturnAR]

Hello Again ExCyber, and thanks.

Well, i tought that too, first i tought it was an error, and thar M6ID should be MDID as you've said. But then i saw that the "D" letter is pretty far away from the keyboard numer "6"(suponsing that who write the document used an english Keyboard).

So, analizing a little what you have said:

DS9ZE is DSIZE. See the proximity between the "I" key and the "9" key.

Now analizing M6ID, i supose then that the author of the datasheet was trying to type: MTID(MultiTap ID?).Look the proximity between the "T" key and the "6" key.

I've tryed with what you said. I Replaced the 0H by BH(witch is the MDID for Digital Pad).The result has been that SS do not recognize any pad(but still recognizes the MT).

With 0h, the games recognize exactly what i want: one digital pad connected,but no there is no response when i push buttons.

I've tryed too with 1H,2H,3H, all with the same result. Unrecognized.

Im trying it in the SS Cd player screen, and in FIFA SOCCER 96 in the Select Team Screen.

Now, in Night Into Dreams Demo CD, when i plug the PIC(Multitap); it automaticaly goes to CD Player screen(exits game). Is this normal?

Another thing:

Im 99% sure that anyone who have made a SS Home Made game that support Multitap peripheric, knows the ID of the Digital Pad in Multipad mode.

Its a constant value, and its under the label of: PER_ID_DGT (i found it in the page 30 of the ST-162-R1-092994.pdf doc file)

So...please,if you've used it, tell me value of this Constant! <_<

Now i'll try with others ID and see what happens(there're only 16 posibilities of ID).

Thanks.

 

[ExCyber]

Yes, that makes sense... I originally suspected problems with TH/TR getting mixed up or wrong polarity, but I think the ID sequence wouldn't work if that was the case. I'm not sure what else to suggest.

 

[vbt]

#define PER_ID_NCON_UNKNOWN 0xf0 /* –¢Ú‘± or SMPC UNKNOWN */

#define PER_ID_DGT 0x00 /* ƒfƒWƒ^ƒ‹ƒfƒoƒCƒX */

#define PER_ID_ANL 0x10 /* ƒAƒiƒƒOƒfƒoƒCƒX */

#define PER_ID_PNT 0x20 /* ƒ|ƒCƒ“ƒeƒBƒ“ƒOƒfƒoƒCƒX */

#define PER_ID_KBD 0x30 /* ƒL[ƒ{[ƒh@@@ */

#define PER_ID_MD 0xe0 /* ƒƒKƒhƒ‰ƒCƒu */

 

[SaturnAR]

Thanks! Now i'm sure that Digital Pad ID is 0H.

Well, i've tryed now simulating 2 Digital Pads connected to the MT on Channels 1 & 2,sending all their buttons as unpressed.

The result: Complete crazy behavior, all kind of triggers pressed/unpressed (but still shows only 1 digital pad connected). So, something in the official document is wrong, something is missing. Seems that the Data Body of each channel haves more than just what document shows.

I've tryed sending a zero nibble (binary 0000) after each channel Data, (0000 seems to be "Confirming Data" instruction) but the result was that communication between microcontroller and SS crashes in the third lap.

I'll post some screenshots & videos next week, but sending as if 2 Digital Pads where connected to Channel 1 & 2 of the MT, makes START,A,C,B to be considered as pressed(in SS CD player screen, the Track info changes showing Date & time) making me believe that these 4 buttons are sended as pressed. Also, Z seems to be sended as pressed/unpressed, because it continously Plays/Stops Audio tracks. The same with L or R trigger, it just goes from one screen to other, like if i pressed/unpressed several buttons at the same time.

Thanks for your time, i'll continue investigating.At least i now know that SS is responding in some way to my circuit, its now time to figure it out whats wrong with the official document protocol.

Regards.

 

[ExCyber]

I finally got a chance to read your code, and it seems that TH is not really respected. You wait for the rising edge at the end, but I don't see any loop at the beginning waiting for the falling edge, and no checks in the data send routine to see if it has been pulled high (to terminate the read process early). I'm not sure that this is the cause of the problems you see, but I'm pretty sure it's not really correct behavior.

This is more of a matter of taste/style than correctness, but I think it might be better (especially for debugging and changing the code) to write some sort of "3WIRE_SEND" routine that handles the handshaking details rather than repeating that code in your main loop. Right now your program looks almost like a direct translation of Table 3.39 rather than an implementation of the 3-wire protocol. I think if you did a proper 3-wire protocol routine you would also be more likely to have "real" behavior rather than "documented" behavior (i.e. from side effects of the 3-wire standard).

I hope this makes sense. Feel free to ask questions if I haven't explained it well...

 

[SaturnAR]

Hello again, and thanks for reading.

Well, yes. The idea was to exactly imitate the table in the

algorithm.As i've said before, i wrote other program with the 3 line hand shake protocol "optimized"(lets say it that way), but i wrote this one to simplify all and filter any kind of errors that the other code could have(for being complex).

I put a loop to wait TR & TH = 0 before start the sequence:

movlw b'01100000' ;move literal to W(Work=W)

andwf PORTB,W ;Filter other bits, keep only with TR & TH values

btfss STATUS,Z ;The "AND" result is zero?

goto Wait00 ;No, so wait...

That part waits until TH & TL are down, before starting the 3-line hand shake.

The other correction you made...Yes, its true, the algorithm i attached doesn't detect if SS abort asking for data(TH goes high). But i did it in other activating the Watch Dog Timer that Microcontroller haves, that Reset the program if it stays stucked for more than 72ms.

Of course, this isn't the same that checking TH bit inside the algorithm, i should try doing that..

Thanks & let's see what happens.

 

[ExCyber]

Realistically I think a timeout should work for most games (this is the approach used by the 6-button Megadrive pad), but I think 72ms is a bit long... after all one video field only lasts 16.7ms or so (unless I messed up my math)...

Of course this approach won't work for games with a debouncing algorithm, same as the 6-button pad (I think some early Sega-Capcom ports for MD in particular had this kind of algorithm). However I think most games don't bother with debouncing (maybe because the usual console controller designs don't suffer from it much? I think it's normally a problem with traditional pushbuttons and microswitches which aren't normally used for consoles...)

 

[SaturnAR]

Well, i must say that, 72ms was wrong. 72ms was when using a 4mhz crystal with the PIC, but i'm using a 20Mhz crystal, so...Time-out ocurrs after 14.4ms if the algorithm get stucked.

Now... i've made the analog Pad using a PIC microcontroller, based on the protocol that the .pdf describes without time-out algorithm.

The pad works excellent, and ,as i supossed,when i debug the circuit,i saw that the console freezes the peripheral adquisition sequence in certain moments, like when SEGA logo appears, when a game loads,etc...

So,implementing a time-out algorithm could really complicate things.

Now, i would like to know, because i dont have an original multitap to test it, if multipad peripheric is recognized in Cd audio screen for example(im trying it there, so i should confirm this).

I'm beginning to think that the easier way to understand this protocol, its having an official multitap, and use a microcontroller( or just a PC) to act as the SS console, and read what Multitap Sends. That would work.

But i dont have and cant buy( they're not popular here) a Multitap to reverse engineering it.

I will attemp to ask someone who owns one, and make a program for a PIC or just a PC,and send it to that person that would try it, to discover whats wrong, and finally be able to make my own one and publish the project.

Regards.