|
Post by tiberiyltim on May 11, 2020 14:21:53 GMT -5
Does anyone know how the multiplayer works in ZT via cable? I know the features of the cable, I guess how the controls in the game are adjusted. But how does the subroutine work, what addresses in memory are involved? Perhaps someone has already investigated this issue ...
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 12, 2020 12:01:46 GMT -5
I believe it just emulates button presses and sends that data through the controller port and is read by the other console. You'd have to design a transfer bus as if you just pass button presses back and forth, you're going to have data collisions (lost information).
|
|
|
Post by tiberiyltim on May 12, 2020 12:29:36 GMT -5
If it was only a button press, then the ZT could be played on the second joystick. And in ZT there is a program for determining whether a cable is connected or not. If you do not connect the cable, then there is no access to the character selection menu. If you disconnect the cable, then the second player dies.
If it were just control over the second port, the cable would connect from port 2 to port 1 of the second console. But in ZT from port 2 to port 2. But the game is the same.
Thus, everything is complicated.
It somehow works like a 4 Way Play adapter or something similar.
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 13, 2020 8:19:21 GMT -5
It's literally just a crossover cable (i.e., there's no hardware between the ports, just wires, and 4 of them are remapped to different pins), so it's only sending what can be read as button presses. You wouldn't be able to play as 2 player with a controller because the software is interpreting the "button presses" as data. 4 player adapters have a bus built in for handling data flow (where you poll the registers to get the controller states), the ZT cable doesn't, so you have to program your own. That means you'll need to find a way to write controller statuses to transmit (BEX only reads them), then read and process the state of each "button".
The link cable was poorly received and probably not worth the effort to implement.
|
|
|
Post by tiberiyltim on May 13, 2020 9:02:17 GMT -5
It's literally just a crossover cable (i.e., there's no hardware between the ports, just wires, and 4 of them are remapped to different pins), so it's only sending what can be read as button presses. You wouldn't be able to play as 2 player with a controller because the software is interpreting the "button presses" as data. 4 player adapters have a bus built in for handling data flow (where you poll the registers to get the controller states), the ZT cable doesn't, so you have to program your own. That means you'll need to find a way to write controller statuses to transmit (BEX only reads them), then read and process the state of each "button". The link cable was poorly received and probably not worth the effort to implement. I know the cable information. These are all clear things. I'm talking about a software SDK or documentation of methods involved in ZT. The status of the pressed buttons is not enough. I have a cable, I tested it: If you connect the cable, then all the buttons (JoyPad (0) function) have status 1, except for "A" and "B" = 0. If you press any button, then all the buttons get the status 0, except for "Start" and "C" = 1. If console 2 is turned on, then after pressing "A" or "B", all buttons have the status 0. If this were primitive, as you think, then you could simulate the presence of a cable in ZT by clicking on the corresponding buttons. But in ZT, the program understands: the command came through the cable or through the joystick. You need to use ASM to implement a program for processing the availability of cable (SDK). I can’t understand how the same game assigns the console the status of a leading player and a second player. For example, only the first player can press Pause and cancel it. This is a simple device, but you need to understand how to use tricks. romhacking.ru/_fr/5/1780257.jpg
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 13, 2020 9:24:16 GMT -5
It is as primitive as I think. You need to write to the controller port to send the data, not read it. There is no function in BEX to write to the controller ports. If you aren't writing data to the ports, how do you expect console 2 to read them? You need to use ASM to write data to controller port 1 (player 2).
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 13, 2020 9:32:56 GMT -5
Here's the registers you need to use:
$A10014 - $A10015 Controller 2 serial transmit $A10016 - $A10017 Controller 2 serial receive $A10018 - $A10019 Controller 2 serial control
Rather than be argumentative and Mr. Know-it All, you could save yourself (and others) a lot of annoyances.
|
|
|
Post by tiberiyltim on May 13, 2020 10:43:13 GMT -5
I do not show arrogance. I posed a problem. Without an example of using (SDK), new games with this feature will not appear. This is the reason. I was thinking of making a project like Counter-Strike, TDS like this: youtu.be/cP7m1qK4Ciw
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 13, 2020 14:56:55 GMT -5
You can try this and see if it works. You'll need to run Console A on one console, and Console B on another console:
Console A:
While 1 a = JoyPad(0) If a.7 Then Asm move.l #4,($A10014) End Asm Print "Data Sent!" End If Sleep 1 Wend
Console B:
While 1 c = 0 Asm move.w ($A10016), __integer_c End Asm If c > 0 Then Locate 1,1: Print "Data Received!" End If Sleep 1 Wend
Report back if this works or not.
|
|
|
Post by tiberiyltim on May 13, 2020 16:48:25 GMT -5
Console A, Console B? There should be a single ROM without differences. If different ROM: Console A code and Console B code. Console A (ROM A code) at the click of a button writes "Data Sent!". Console B (ROM B code) - nothing, black screen. If so, it does not work. romhacking.ru/_fr/5/9331960.jpg
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 14, 2020 11:04:31 GMT -5
|
|
|
Post by tiberiyltim on May 14, 2020 18:55:59 GMT -5
Thanks for the info. Initially, I went the wrong way. Now I understand something.
|
|
jovial
Moldy Popcorn
Posts: 36
|
Post by jovial on May 14, 2020 21:17:25 GMT -5
Great! Let us know if you come up with something.
|
|
|
Post by lunchbox on May 22, 2020 2:09:19 GMT -5
Thanks for the info. Initially, I went the wrong way. Now I understand something. You can use any controller port in Serial mode or parallel mode. Serial has a max speed of 4800 Baud and can only push about 4-5 bytes per game frame before slowing down your code. Additionally the receive buffer on the controller port is only 1 BYTE. You must read the byte and store it in your own larger buffer in ram as to not over run the 1 byte buffer. If you send 4 bytes to another console and you're not able to read the 1st byte received fast enough, the next bytes behind it will over-write the current 1 in your receive buffer. Sending is not a problem and you can send fairly quick. Parallel WILL be faster, but not as easy to probably get working. Ive used the serial function pretty extensively for debug purposes and other things. TXDATA EQU $A10015 ; SERIAL TRANSMIT REGISTER (CONTROLLER PORT 2) RXDATA EQU $A10017 ; SERIAL RECEIVE REGISTER (CONTROLLER PORT 2) SCTRL2 EQU $A10019 ; SERIAL CONTROL REGISTER (CONTROLLER PORT 2) ;***************************************************************** ; INITI SERIAL 4800 BAUD ** ;***************************************************************** INIT_SERIAL: MOVE.B #$30,SCTRL2 ; INIT SERIAL 4800 BAUD CONTROLLER PORT 2 RTS;***************************************************************** ; RECEIVE BYTE ** ;***************************************************************** RECEIVE_BYTE: MOVE.B SCTRL2,D0 ; SERIAL CONTROL TO D0 AND.B #$02,D0 ; IS RECEIVE BUFFER EMPTY? BEQ.S RECEIVE_BYTE ; IF EMPTY, JUST KEEP CHECKING MOVE.B RXDATA,D0 ; READ BYTE INTO D0 RTS ;***************************************************************** ; TRANSMIT BYTE ** ;***************************************************************** TRANSMIT_BYTE: BTST #0,SCTRL2 BNE.S TRANSMIT_BYTE MOVE.B D0,TXDATA RTS ;***************************************************************** ; FLUSH SERIAL RECEIVE BUFFER ** ;***************************************************************** FLUSH_SERIAL: MOVE.B SCTRL2,d0 ; LOAD SERIAL CONTROL REGISTER TO D0 AND.B #$02,d0 ; SEE IF BYTE WAITING IN RECEIVE BUFFER BEQ.S SERIAL_EMPTY ; IF NONE THEN EXIT MOVE.B RXDATA,d0 ; OTHERWISE READ IN BYTE TO D0 AND FORGET IT BRA.S FLUSH_SERIAL ; CHECK AGAIN FOR MORE BYTES... SERIAL_EMPTY: RTS Hopefully this helps you add some networking fun to your games
|
|
|
Post by tiberiyltim on May 22, 2020 13:14:36 GMT -5
This is only the second controller. Without taking into account differences ZT cable. I still did not understand how to initialize, how the program will understand that this is the second joystick or cable. Unconnected cable or cable connected at bid. It is very difficult. Now it’s clear why there are no games with this feature.
|
|