What's new
I'd say its very similar if not exact same setup as Derby Owners Club series.
i.e. it is same reader (601-11082 CRP-1231BR) also used in Initial D or F-Zero AX, but connected through 838-13661 RS422-RS232 converter board.

PS: to make it more clear - Naomi 1 and 2 have very different CN8.
N1 have there RS422 (comes from 315-6146 'MIE' MCU), and because of this it needs converter PCB
N2 have there RS232 (from main SH4 CPU SCIF serial port), so no converter required.
Hikaru mobo probably have serial IO like Naomi1.

490aa891f91adf33301755300e5ff51a.jpg
 
Last edited:
Interesting. Is that board needed because the newer systems don't have onboard rs232 ports? Would a hardware emulator be able to replace the reader and this board?
 
vice versa, older systems like NAOMI 1, and seems Hikaru as well, doesn't have RS232, so this board is required. it is no more than "transparent" converter.
well, if emulator will be able directly communicate via RS422 - this board will be not needed.
 
vice versa, older systems like NAOMI 1, and seems Hikaru as well, doesn't have RS232, so this board is required. it is no more than "transparent" converter.
well, if emulator will be able directly communicate via RS422 - this board will be not needed.
Oops, I was assuming the Virtual On: Force game was on newer hardware. I'm not that familiar with the hardware series prior to NAOMI. :P

I'm only currently running in NAOMI 2 and Chihiro in my cabinet, so don't have much exposure to the others.

So Hikaru was prior to NAOMI, and even NAOMI 1 lacks the ability to communicate natively over RS232.
 
well, it's not that easy question who was first, both was developed in parallel, Hikaru as (spiritual) successor of Model3, NAOMI as new gen system, I'm tend to think Hikaru was released first (but its possible I'm wrong).

back in the topic - it seems Japanese DOC games uses slightly different reader protocol. games expect "RESULT1" as ASCII coded number, not binary value with sensors bits like ID.
not sure if JAP DOC uses different reader (or at least different firmware), or this can be configured via reader DIP switches.
so, its possible VO4 uses same protocol as well.
 
Hikaru came out after Naomi 1. It is based on the Naomi hardware but is more powerful in the GFX department. It was specifically designed to address a graphical effects issue. They wanted the water in Brave Firefighters to behave a specific way and the N1 was not powerful enough. The Hikaru has a custom GFX chip that was state of the art at the time. This made the hardware VERY expensive to produce and only 6 games were developed for it. All DX cabs.. So instead the Naomi 2 was developed as a more powerful, less expensive, more easily mass-producible alternative.

Npw before anyone goes and says "Nice! Since it is so similar to the Naomi hardware lets try to convert the Hikaru games to Naomi 2." It really can't be done. The custom GFX chipset on the Hikaru is still WAY more powerful than the one they used for the Naomi 2.
 
Mitsurugi-w
and the source of yours information is ...? I guess some internet posts or Wikipedia. mostly consists of rumors.

I was/is involved in reverse engineering and emulation of Hikaru hardware (as well as many others). and I can say for sure - Hikaru is *NOT* based on NAOMI in any way. yes, it uses same CPU and AICA SPU, but they ware totally different systems, not related in way. and as was said - developed in parallel, NAOMI/Dreamcast architecture was mostly 3rd-party made by Videlogic/NEC, Hikaru most likely was Sega in-house creation.
 
...I was/is involved in reverse engineering and emulation of Hikaru hardware (as well as many others). and I can say for sure - Hikaru is *NOT* based on NAOMI in any way. yes, it uses same CPU and AICA SPU, but they ware totally different systems, not related in way. and as was said - developed in parallel, NAOMI/Dreamcast architecture was mostly 3rd-party made by Videlogic/NEC, Hikaru most likely was Sega in-house creation.
This makes a lot of sense, looking at the boards I always felt that Hikaru had more in common with Model 3 than with NAOMI.

I'd love to see Hikaru fully emulated some day those boards are hard to find and most of the games aren't available elsewhere.
 
By the way I just looked up the wiring diagram for WMMT on Chihiro.
http://brentelectronic.com/PDF-manuals/namco-manuals/Maximum_Tune_Manual.pdf

It looks to use similar signal pins (RXD and TXD), but does not utilize CTS/RTS.

It's a similar card r/w unit to ID3, but not sure it would be directly compatible.

It likely uses a different protocol, but may be RS232.

It looks like it communicates with its steering board using RXD/TXD on other pins in the same connector. I think the Sega one uses MIDI?

It would be so awesome to translate those signals for steering into something the Sega force feedback could use. :)

Anyway, those are other projects. Gotta get this ID3 reader emulator figured out first. I'm just now playing around in Python and plan to fake through the initialization with it before proceeding.
 
I always felt that Hikaru had more in common with Model 3 than with NAOMI.
indeed.
but note - key word was *spiritual* successor. so there no direct hardware grows, its all different, except maybe sound system. but the way this thing was developed/build really felt like well made old-school arcade hardware, like Model 1-2-3 series.

about Wangan - hard to say, needed to know CRW unit part number to be sure. also its Namco, they love to customize I/O and other PCBs, so they are becomes incompatible with anything except one game.

more about Derby Owners - it appeared Japan and English game versions uses slightly different protocols, and likely different readers as well.
so, its hard to say for sure what exactly reader uses Hikaru's VO4.
 
I believe I've heard of people being able to use Derby Owner Cards in VOF readers... but there is very little information for VOF online. The cards seem very similar, if not the same.

amixgame-img450x600-1457019724b5x7xs26630.jpg
 
I can confirm DOC cards work in ID3. That's what most of the cards I purchased and loaded into my reader for use in ID3 are.
 
I have a little bit of progress to report. I now have my Python script successfully getting through Game Test Mode initialization with automatic replies.


Opened: NAOMI2
2016-03-04 14:47:17.941711: NAOMI2
02 06 40 00 00 00 03 45
Reader Emulator: Sending: 06 02 06 40 A0 30 32 03 E7
2016-03-04 14:47:18.129213: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:18.254213: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:20.488592: NAOMI2
02 06 20 00 00 00 03 25
Reader Emulator: Sending: 06 02 06 20 A0 30 30 03 85
2016-03-04 14:47:20.722985: NAOMI2
05 02 07 10 00 00 00 31 03 25
Reader Emulator: Sending: 06 02 06 10 A0 30 33 03 B6
Reader Emulator: Sending: 06 02 06 10 A0 30 30 03 B5
2016-03-04 14:47:20.832344: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:21.144843: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:21.269843: NAOMI2
02 06 20 00 00 00 03 25 05
Reader Emulator: Sending: 06 02 06 20 A0 30 30 03 85
2016-03-04 14:47:21.394844: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:21.535469: NAOMI2
02 06 40 00 00 00 03 45
Reader Emulator: Sending: 06 02 06 40 A0 30 32 03 E7
2016-03-04 14:47:21.722988: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:21.847988: NAOMI2
05
Reader Emulator: Sending: 06
2016-03-04 14:47:22.066721: NAOMI2
02 4F 7A 00 00 00 26 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
10 05
Reader Emulator: Sending: 06 02 06 7A A0 30 32 03 DD
2016-03-04 14:47:22.207345: NAOMI2
05
Reader Emulator: Sending: 06

That long string sent by the NAOMI seems to change each time at the the spot where it currently shows 26 above and at the CRC. Maybe it's a timestamp? I check for that command based on the it consistently having 02 4F 7A at the beginning.
 
I'm also able to get through boot initialization since it sends the same long commands that all start the same way and accept the same response.

I'm currently able to get all the way to the point where it asks to enter a card or press start. I think I'm not sending the expected command because it eventually gives a card r/w error before allowing the game to continue.
 
Mitsurugi-w
and the source of yours information is ...? I guess some internet posts or Wikipedia. mostly consists of rumors.
I read this like 6 months ago:

http://segaretro.org/Sega_Hikaru

I guess my mind made up the based on Naomi part. Eh, details escape me sometimes. I blame the stress at the restaurants. ;)
 
Ok, more progress. I can get all the way to where it lets me hit start to skip entering a card. This is where I get stuck.

I can't figure out the correct reply to:
02 07 D0 00 00 00 30 03 E4 05

I see it shows up twice in my logs with two separate groups of replies from the reader. I tried both and the game immediately gives a card r/w error.

I verified there is no CTS/RTS activity during this part, so not sure how I need to reply.
 
looked at log and it looks a bit strange. workflow must be like
NAOMI2 02 xx xx xx xx 03 crc
Reader Emulator: Sending: 06 (command received OK acknowledge)
NAOMI2 05 (request reply)
Reader Emulator: Sending: 02 xx xx xx xx 03 crc

two last steps can be repeated several times if RESULT3 is not 0x30 "OK".

for example full flow of front door closing:
N2: 02 07 D0 00 00 00 30 03 E4 --- command - front door control, parameter '0' = close it
Emulator: 06

N2: 05 - request reply
Emulator: 02 06 D0 A0 30 33 03 crc - sensors bits: 2msb bits = 10 -> door opened, bit5 = 1 -> stocker(hopper) have cards, 5 LSB = 00000 -> no card inside reader,
Result 2 = '0' -> OK, No Error
Result 3 = '3' -> BUSY - reader is in process of command execution.
so, after Naomi sees reader is "BUSY" - it poll its status again

N2: 05
Emulator: 02 06 D0 E0 30 33 03 crc - same thing but sensors 2msb bits = 11 -> both opened and closed sensors active - door in transition

and again
N2: 05
Emulator: 02 06 D0 60 30 30 03 crc - sensors becomes 01 - door closed, and result 3 finally becomes '0' - OK, command completed

other commands have similar workflow, i.e. reply request 05 will be repeated until full command completion.
ps: simplified simulation possible, game code not that strict, at least in D0 command, so its possible to set correct target sensors status and result='0' immediately.
 
The game is accepting the replies with 06 put at the front and just replying 06 when there's an 05. Maybe it loads the input into a buffer and interprets it correctly if it gets a reply back that makes sense? At the moment, it's easier to put 06 at the front than having to remember the previous command. So far I don't think that has caused any issues.

I started doing it that way since it looks like the 05 and 06 are getting appended onto the various lines from the logs. NAOMI commands were showing to end in 05 and reader replies were often beginning with 06.

I'll give your suggested reply a try.

Thanks for the help!
 
I can't figure out the correct reply to:
02 07 D0 00 00 00 30 03 E4 05
This lets me get past it. I can now successfully start a game with no card entered and no card purchased!

2016-03-04 22:24:32.208966: NAOMI2
02 07 D0 00 00 00 30 03 E4 05
Reader Emulator: Sending: 06 02 06 D0 60 30 30 03 B5
 
More progress!

Using the same code from the logs for the card that was read in, I was able to send that data to the game and it loaded up just fine for me!

Now I just have to figure out what it saves out compared to what it reads back in.

I should also be able to play around with editing the data I send back in.
 
Back
Top