Triforce dev kit?

Discussion in 'Arcade and Supergun' started by ASSEMbler, Mar 3, 2016.

  1. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    It's possible - I was going to do some tests to see how it works, but I seem to have mislaid the other bits I need to make it work (like the AV jumper cable and the JVS I/O board).
     
  2. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    I guess it's possible, but as far as I can see it doesn't do that - it just sends the JVS packets it gets to one of the USB endpoints without translation. I have also found that I was wrong about the USB - the "spare" ports are wired to empty footprints on the interface board - but they are also wired to the DIN connector and ultimately to an 11-pin connector on the filter board. Hence, despite my earlier assertion, it IS possible to plug USB devices into the Chihiro without opening it.
     
  3. smf

    smf mamedev

    Joined:
    Apr 14, 2005
    Messages:
    1,259
    Likes Received:
    92
    What do you see? It just seems kinda weird to have an interface board to send JVS packets raw over USB, then on the xbox have a driver that decode the JVS packets and turns them into game inputs when the I/O board is programmable & is touching all the data anyway.
     
  4. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    It was a while ago, but I just connected a logic analyzer that had USB decode capability to the USB pins going to the XBOX board - you could see the JVS packets in the data stream - it was especially obvious since one of the reports had "NAMCO I/O" in it - which logically could only have come over the JVS interface from my (Namco) I/O board.
     
  5. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I just tested on my baseboard / filter board and couldn't find any continuity between the usb gameport 1 / 2 connection and that connector on the filter board. The only thing connected to it besides the unpopulated usb plugs is an EMI suppresion chip. It's also kind of strange that the pin layout of the non populated connectors are type B layout while you would expect a type A connector.
     
  6. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I have to correct myself. CN4 on the filterboard (11 pin connector) goes indeed to the gameport 1 and 2 usb connections of the main board.
    The 2 unpopulated usb type B connectors are connected to gameport 3 and 4 They likely where used during firmware development of the base board QC and SC microcontrollers. So they might have disconnected the gameport 3 and 4 plug and connected the microcontroller usb ports to a pc using a normal usb A - B cable.

    I measured between CN4 and those unpopulated usb connectors and obviously didn't got any continuity as CN4 is gameport 1-2 and the unpopulated usb connectors are gameport 3-4

    There also is an unpopulated DB9 serial connector, but the jumpers are missing to connect that to the QC uart 0 (JP 9 + 10 position 2 - 3)
    There also are a couple of resistors missing and the emi suppresion diodes are missing as well.
     
  7. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    Yeah, sorry about that - I was just poking around with a meter and obviously got confused between the joypad connectors.

    I suspect you are right, and those unpopulated USB-B footprints are left over from the development process - it would certainly be quicker to develop the firmware for the EZ-USB chips that way (especially if you removed the serial EPROMs and had them fall back into the internal boot ROM).
     
  8. MetalliC

    MetalliC Spirited Member

    Joined:
    Apr 23, 2014
    Messages:
    180
    Likes Received:
    133
    welp, all mentioned here 3 systems (Triforce, Chihiro, NAOMI) shares same basic design idea:
    - take console motherboard
    - remove original disk drive and connect there Sega DIMM or cartridge through special converter.
    - connect to gamepad connector(s) special MCU(s), which will handle JVS I/O interface, system/game settings EEPROM, and other I/O interfaces like RS232, RS422 etc.

    details may vary, like - in Chihiro and Triforce "game media converter" is separate "Media Board" PCB, but in NAOMI it is Altera FPGA on main board; or in NAOMI and Chihiro I/O MCU is RAM-based and it's firmware uploaded by mobo BIOS code, while Triforce's H8 MCU have all the code in internal ROM, but design quite similar in general.
     
  9. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    The chihiro I/O MCU's don't have their firmware in ram.
    They load it from an 8KB eeprom that is connected to the microcontrollers. It's possible to upgrade the firmware in those eeprom trough the usb connection.
    The I/O MCU's are dowloading the firmware from the eeprom into internal ram before they run it. so strictly, you could say they have it in ram.
    They have another operating mode that loads it over the usb connection, but it's not what sega is using on the chihiro base board.
     
  10. accel99

    accel99 Spirited Member

    Joined:
    May 27, 2008
    Messages:
    193
    Likes Received:
    19
    So is the naomi2 the same way? Naomi2 arcade board plus a debugging board connected to a PC?
     
  11. MetalliC

    MetalliC Spirited Member

    Joined:
    Apr 23, 2014
    Messages:
    180
    Likes Received:
    133
    @obcd my bad, you are right, firmware loaded from I2C eeprom into internal MCU RAM and run there.

    @accel99 high probable yes. but there is bare chances might exists Kunoichi-like N2 dev.kit kind.
     
  12. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I am confused.
    In mame, they have the QC microcontroller (the one doing the JVS) connected to gameport 3 and the SC microcontroller (the one doing serial and midi communication to the ffb boards and cardreader) to gameport 4.
    On real hardware, it's the other way around if I measure correctly.
    In mame, they fill the control buffer with (0x50 xor index).
    Real hardware doesn't seem to fill the control buffer like that. This could be due to the fact that the microcontrollers have a different firmware and they used an older one in mame for reverse engineering.
     
  13. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    This is a guess, but since they presumably have different VID and/or PID codes it shouldn't matter which physical ports they are attached to since they will have the correct driver associated with them when they enumerate.
     
  14. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    The xbox driver just checks the class, subclass and protocol of the usb devices. Class is 0x60 and subclasses are 0x01 and 0x00. So there is indeed a difference between the 2.
    The vid is 0x0ca3 = sega and the pid is 0003 and 0002. So VID PID could be used to locate the correct chip.
    Nevertheless, a bulk transfer attempt to the real thing keeps failing :-(
     
  15. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    How does the Chihiro talk to it? Given the application, it's entirely plausible that it's using an interrupt or isochronous endpoint for the control transfers.

    Edit: sorry, by "control" I mean the stuff connected via the JVS, not the USB control endpoint.
     
    Last edited: Mar 8, 2019
  16. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    It's basically using control endpoint 0 with a command followed by a bulk endpoint transfer using a bulk endpoint. At least, that's how it's implemented in mame. So for instance, the command can be "send_jvs_string" The microcontroller will wait for the bulk data and send it serial over the jvs bus. Next, they will issue a "receive_jvs_string" followed by a bulk in to read the data. For some reason, I can't get it working on real hardware. I programmed an arduino with a bulk endpoint and connected that. It works fine to send some date over that bulok endpoint to that arduino. Next step is testing own firmware on the baseboard controllers. I guess I will install some of the missing components on it to ease debugging.
     
  17. TriMesh

    TriMesh Site Supporter 2013-2017

    Joined:
    Jul 3, 2008
    Messages:
    2,365
    Likes Received:
    783
    Can you run the Chihiro test mode in the emulator? One of the options in that (I think it's under "system information") shows the firmware versions on the USB MCUs - it would be interesting to compare the numbers with the real hardware. I guess it's also possible that something else on the board needs to be set up before the USB will work.
     
  18. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I think I managed to get it running with some really dirty hack. The QC and SC chips give their class number as a device. The arduino gave it as function. When it's a function, during enumeration it receives a set_configuration which is likely what it needs before it starts working. I will try to add those functions in the adddevice function of my driver. I read some of the eeprom bytes and they seem to match those of the mame files.
     
  19. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I figured it out (took me 2 weeks).
    On real hardware, you have to send a "set configuration 1" to the control endpoint before the bulk endpoints start to work.
    The driver isn't doing it 4 you when you have a "device class" instead of a "function class"
    The arduino leonardo I used for testing didn't have a device class. so the driver send the "set configuration" control command.
    Chihiro homebrew, almost there....
     

Share This Page