Discussion in 'Arcade and Supergun' started by ASSEMbler, Mar 3, 2016.
Does anyone have pictures of it assembled.
didn't know there was devkits for it..
There is no such thing as a triforce devkit it's a regular triforce, the mediaboard's netfirm has a hidden debugging feature, it's been documented by tmbinc.
"The Netfirm has a nice “debug-mode”/”development”/”backdoor” on tcp port 10703, which allows you to read/write gamcube memory (isn’t that nice?) as well as DIMM memory as well as the DES key for the uploaded content (as decryption happens on the fly)"
This is how they developed triforce games, no rocket science here.
Not sure about the Triforce but I remember people on here saying that Naomi dev kits never existed and a few months back a guy showed me a picture of his Naomi dev kit board. Which to that point even I my self thought they didn't exist. It was pretty awesome!
very interesting. is there any chances to see this picture ?
I'm personally do not doubt there was dev.kits. every NAOMI BIOS at it's very start in bootstrap (NAOMIHAT), have code which detects some hardware components. this components is not present on regular main board, and its not something DIMM-board related. in the case of successful check in internal structure will be put system name 'NAOMI&YUKA' or 'SEGA-AM NAOMI&YUKA', otherwise will be used regular 'NAOMI' name.
so that YUKA thing is probably some development addon, similar to Katana Set5 DA (debug adapter) I think.
The picture was courtesy of a guy in arcade otaku (I have said picture) we were just talking and he brought up he had a friend that had one. His friend didn't want the info about who and what it looked like to surface entirely so I'll have to ask. Other than that I just wanted to clear up the myth that one didn't exist as it clearly does.
Sega Yuka is literally the Naomi Development kit. It's a "special" Naomi Dimm board with debugging features.
are you sure ? I'm highly doubt "Yuka" is special DIMM, mainly because "NAOMI&YUKA" texts is present in all NAOMI BIOS ROMs, including earliest revisions from 1998 and 1999, while DIMM board support appeared only from "Rev. E" BIOS in mid 2000.
I'd bet "Yuka" is code name of this board https://assemblergames.com/threads/sega-naomi-rom-development-board.60027/
which is basically SCSI controller chip + UART chip + BOOT ROM + sockets for (optional) game ROMs. where mentioned "NAOMI&YUKA" texts was used by BIOS code as SCSI IDs.
based on information I have (can't disclosure sources, sorry), original NAOMI Development box looked like "metal box NAOMI", and contained inside:
- NAOMI motherboard, almost the same as regular mobos, but there was few minor differences.
- Development board mentioned above, used as SCSI interface to host PC.
- Flash ROM board, 171-7885A type, like this one for example
so, not that cool and fancy like was Katana Dev. boxes
later boxes may use (instead of Flash ROM board) original DIMMs with "Ether board". where "Ether board" is PCB like https://www.ebay.com/itm/Sega-Network-adapter-837-13988-/153255224368
more later boxes uses Net-DIMMs with special security chip, which enables debugging features, now known as "Net Zero-key" and widely used by people.
there also was very special NAOMI development kit based on Katana Set5 called "Kunoichi", but sadly I have no detailed information about it.
That's because there is more than one Yuka revision. The first iterations did use SCSI. (as far as I know of)
Are you sure Kunoichi isn't just the first party Katana development kit with flash area populated and LAN/Broadband Adapter support?
as far as I know, there was two kinds of Development boards: 1st - mentioned above older type, and 2nd - such PCB http://www.citylan.it/wiki/index.php/Puyo_Puyo_Fever_(prototype_ver_0.01) which is basically 2in1 NRS Flash ROM board and SCSI.
based on information I have, all of NAOMI dev.kits uses one of these boards with SCSI as debugger interface, even if DIMM board is present.
why there should be LAN/BBA as you think ? I do not understand.
as was said, I have no exact information about Kunochi, but if making suggestions it should be like
Katana Set5 where:
- to Maple port A connected special PCB with JVS Host MCU, same as integrated in NAOMI mobo. and then JVS IO board(s) should be connected to it.
- flash ROM should be replaced with SRAM
- GD-M firmware should be replaced or modified, so it will emulate NAOMI ROM board instead of GD-drive. or/and there should be added connectors for regular NAOMI dev. flash ROM boards (similar to Atomiswave dev.box).
however, such setup will not give possibility to use NAOMI-specific additional hardware, like optical communication board for example.
About LAN/BBA, I know there is an internal version of the Katana that has LAN/BBA support (for first party to test/debug network capabilities) as well as having region info in flash data (this is how first party titles such as Shenmue or Sonic Adventure detect what video output modes they should allow, and why they crash on regular Katana units)
I don't know the name of the internal Katana devkit, if there is any special one however.
I would like to take the opportunity this topic about Chihiro devkit. Like Triforce is a console based, also XBOX. I succes to kernel debugging Chihiro game with debug kit, but I dont know how sega coded the JVS input...it's seemsJVS input is translate to USB XBOX input? is it true? all info about is welcome.
@nonosto all the JVS inputs magic is on Sega-made Base Boards.
in Chihiro it is handled by Cypress AN2131QC MCU, in Triforce by Hitachi H8S/2676 MCU. afaik, in both cases there used custom comm protocols, not "translate to XBOX" or whatever controller input.
THX. Do you know why when chihiro game can boot on xbox we can use xbox controller (USB 1.1). For example virtua cop 3 we can use the light gun (with LED sensor model only).
I'd guess it is nice dev/debug leftovers
It's probably easier to understand how it works if you have ever seen how it goes together - the xbox board inside the Chihiro is pretty standard except for the expanded memory and a different boot ROM.
However, the cabinet wiring doesn't go to Xbox board - it all wires to a special SEGA interface board.
This board is wired to several different places on the main Xbox board - the IDE port, the LPC port, the connectors for the front USB and the control panel and finally the Xbox video output via a little jumper cable. Note that although the USB is run to the interface board and it has a socket on the side that looks like a USB port, it isn't - it's a JVS RS-485 port. The translation is handled by a Cypress MCU on the interface board. This is a soft device - it doesn't have any internal ROM, and downloads it's operating program from the Chihiro - this means that potentially the I/O board can be reconfigured for each game.
The other bit of the system is the DIMM - this sits on top of the other two boards, and is a pretty typical SEGA DIMM unit - the GD-ROM drive plugs into this, and the board on top in the network interface.
Basically, any USB support that remains in the games has to be a leftover from the development process, since there is physically no method you can connect a USB controller when it's being used in the arcade machine.
THX when I said USB port I talked about xbox controller, it's a standard USB but with a specific plug for xbox and driver/protocol. On XBOX with ghost squad, virtua cop 3 & outrun 2 beta test run perfectly witout JVS unit and I dont understand why?
Another question: when the MENU button is pressed, a small executable vc_t.xbe is called. Do you know where the stored info is stored (level of difficulty, language, calibration of the gun ....)? What is the file type? is there a dump of this file? And finally the address in the memory please?
Presumably because they have code in them to run using standard Xbox peripherals rather than just using the arcade I/O. My point was simply that this has to be left over from development or testing, since when it's it's running on the final hardware there is no way to connect an Xbox controller or any other sort of USB device to it. On the Chihiro, the sockets that the controller ports normally plug into are wired to the interface board - where two of them don't do anything at all (they wire to unoccupied PCB footprints) and the other two are wired to a pair of those Cypress EZ-USB chips.
I honestly don't know how the setup and bookkeeping information is stored - but my guess is that it's held in battery-backed RAM on the interface board accessed over the LPC bus. That would certainly explain the system crashing when the code attempts to access it. It can't be stored on the main Xbox board, because in the Chihiro configuration that doesn't have any persistent storage - and the IDE port is connected to the DIMM, which read-only in normal operation.
From your description it sounds like the JVS inputs get converted to xbox USB controllers. So it would make sense if the game would work with an xbox USB controller.
in short: why not look into MAME's chihiro driver source code ? there is answers on all your questions.
settings stored in 128byte I2C eeprom, connected to same Cypress AN2131QC MCU, which in its turn connected to Xbox mobo USB.
Separate names with a comma.