3DO player bus protocol & lightgun information

[trapexit]

I recently took over maintenance of the 4DO project via libretro and have been working to cleanup and enhance the emulator. After tracking down the BIOS of Shootout At Old Tucson I decided to spend some time looking at emulating the necessary control devices to play the few 3DO arcade games (as well as retail devices yet emulated). Unfortunately there's not a whole lot publicly known about the player bus outside a patent which doesn't appear to represent the final implementation and some minor details scraped from the SDK.

 

I've mostly figured out SAOT's device but perhaps the most critical part: the translation of a X,Y coordinate to the lightgun data format.

 

Anyone happen to have any information on the 3DO player bus protocol or familiar with how these kinds of lightguns function at the data level? It appears to use a 17bit unsigned integer which is used to indicate screen position relative to a calibrated start point.

[Taijigamer]

Panasonic_FZ-1(Service_Manual).pdf

 

That's cool that you have taken on the task of improving 4DO. I can't help with the bus protocol but here is the FZ-1 service manual (PAL) which may help with the hardware side. I've also got a few retail bios if that's useful (FZ1, FZ10, ANVIL, Kanji, GDO, Sanyo).

[trapexit]

Thanks, but I do have that and the FZ-10 service manual. As part of my adventures I'm also trying to put together a mega collection of 3DO content so I've tracked down a lot of misc manuals and such. I need to categorize and publish it all to archive.org or the like sooner or later. I have all the BIOSs found defined in 4DO (I added this part). If you have anything not listed there I'd love to get that off you so I could add explicit support.

[Taijigamer]

Cool, looks like you already have all the Bios that I have. If I come across any more, I'll send them your way.

[+Stephen Moss]

I do not know about the 3DO but I would think the start point of the display would be the top right corner of the screen as that is usually where the start of each video frame is drawn from on a display. With the controller port having a CLK, In and Out data lines communication is probably operating as an SPI bus or something very similar. You may not be able to find any publicly available information on it as I am sure that is protected IP but the most likely options are outlined below.

 

Let us assume that a read of the controller is performed once per frame and the read also resets the light gun timer.

When the trigger is pressed on the screen designed for it and a hit is registered the timer is stopped, and its value is outputted to the console. A 17 bit value seems like an odd one but I guess it may depend on the screen resolution, I suspect your value relates to the XY position in one of two ways...

 

1)

The XY coordinates are calculated within the light gun and combined to create the returned value. You just have figure out the order and where the split is, as the X coordinates can greater than the Y if it is 17 bits it would make sense for Y to be the least significant byte and X to be the remainder as it may require two bytes to store it with it being a greater value.

It is quicker than method two as you can simple mask off the unwanted bits to obtain either value.

 

2)

Lets say your screen is 320 x 200 pixels, maximum value (assuming one count per pixel) = 64000

You then enter a loop then that subtracts 320 from the count while it is greater than 319 (first x coordinate = 0) while recording the number of times that it has done so, that gives the Y coordinate in Lines.

The remining value then gives you the X coordinate along the line from the Left of the screen, a bit like this...

'Loop to get Y Coordinate in lines from top of screen
While Count > 319 then
Y = Y + 1               'Increment line count
Count = Count - 320     'Decrement line value from count
Wend

'Get X coordinate along the line from the remaining value
X = Count

[trapexit]

Thanks. I actually figured out the algo with help of some code not included in FreeDO originally but was part of their last release of the closed source version. Unfortunately I don't yet understand how it was derived. As for the wire protocol... there is a patent but its clearly a bit different from the final product. Also there is some code around to convert to 3DO from other devices. There is an additional complexity in that the 3DO has an OS which seems to be "smart" about the data it gets before delivering to the app. Either that or the protocol is oddly flexible. For instance: the original freedo code had a stream of data (16bits) for the N joypads connected. However, it works in other formats. Or the mouse... it seems laid out in a different style to the joypad. And the lightgun appears to mimic the mouse but when using 1 device the mouse is player 1 and it seems a single lightgun is player 2. The patent indicates it's a stream of data with typed packets of known length based on the type and order implies position on the daisy chain but my experience with fuzzing the buffer doesn't match that.

Edited June 22, 2018 by trapexit

[trapexit]

For those interested I've documented (though not in the most structured way) what I've found: https://github.com/libretro/4do-libretro/blob/master/libfreedo/pbus.txt

 

The only thing left to figure out is the 3DO flightstick. The identifier has been elusive so far.

[trapexit]

Picked myself up a logic analyzer and a flight stick. Got all the raw data to emulate the flight stick and should have it and the docs updated shortly.