What's new
I'm not sure. There's something in the status text that says open at one point before it says success. I'm not sure what "open" status means. I don't have an actual ID3 cabinet. Is there some sensor that indicates the reader is pulled out? I've just got it sitting out with wires running to it and it works for me during game play. I've never inserted a card during any initialization, and the test for read/write uses a card from its internal card dispenser. As far as I can tell, a card is only inserted into the slot when you've already got a game card and you insert it at the start of a play session. Otherwise you're having the reader make a new card that it dispenses from inside.
 
More good news!

I've successfully communicated with the NAOMI from the USB serial adapter on my laptop!

Just sniffing one direction during the initialization sequence and then swapping pins and sniffing the other direction, I tracked down the send and receive from NAOMI and reader during initialization in the test menu.

I decided to try unplugging the reader and see if I could fake the signals back during the initialization sequence. I wired everything including RTS from the serial adapter into the NAOMI.

One important piece of information I figured out is that the NAOMI expects the reader's RTS to be on. While off, it immediately fails the test and doesn't even send any kind of request.

Using the free version of 232Analyzer, which has some annoying limitations so that you'll buy the full version, I managed to figure out the responses to the output from the NAOMI during the test menu initialization. I didn't have the ability to program any kind of macro, so I was just copy/pasting strings of numbers for the program to send back to the NAOMI. Fortunately the NAOMI sends repeated requests several times before giving up. That gave me enough time to quickly reference the next line I needed to send back.

I allowed the game to boot and got through most of the initialization that comes up there, but it sent a different string at the end than it did during the test menu manual initialization, so I wasn't able to get the game to start.

I'm pretty optimistic that reader emulation is going to be possible with just a simple $10 USB Serial adapter. I'm currently working in Windows and may proceed with figuring out the proof of concept on this platform before porting to something more permanent like the RPi.

Just for reference, if I consider the NAOMI's output as the Question and the computer's (emulated reader) output as the Answer, I used the following to get through the manual initialization in the test menu:
Q: 2,6,64,0,0,0,3,69,
A: 6,2,6,64,160,48,50,3,231,
Q: 2,6,32,0,0,0,3,37,
A: 6,2,6,32,160,48,48,3,133,
Q: 2,7,16,0,0,0,49,3,37,
A: 6,2,6,16,160,48,51,3,182,
6,2,6,32,160,48,48,3,133,
Q: 2,6,32,0,0,0,3,37,
A: 6,2,6,64,160,48,50,3,231,
Q: 2,6,32,0,0,0,3,37,
A: 6,2,6,32,160,48,48,3,133,
Q: 2,6,64,0,0,0,3,69,
A: 6,2,6,122,160,48,50,3,221,
Q: 2,79,122,0,0,0,36,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,18,
A: 6,2,6,122,160,48,50,3,221,

I'm not sure what to make of it, but that long string that the NAOMI outputs isn't the same every time. In the test menu initialization, it doesn't seem to matter. I could give the same response every time and it indicates that the test was completed without errors.

I'll have to do some more sniffing to see if I can get through the boot initialization sequence.
This is great! How did you determine if it was RS-422 or RS-232?
 
Good news!

I had my new USB serial adapter wired up to the reader/NAOMI incorrectly.

Now with it wired up so that I'm just getting input from one direction, I monitored what the reader receives from the NAOMI. Basically I think I'm seeing what the reader would see with regards to data coming on the RXT input and anything happening on CTS.

Reading the data in as decimals, I see a series of repeating strings sent to the reader during initialization, a few more smaller strings after initialization during attract mode, and then some during the command to insert a card and read it in. I only saw CTS activity very briefly, I believe after the card was read in, but I'd have to confirm that. I did not see any CTS activity during initialization.

During the request to remove the card, I see a constant repeating string sent to the reader that keeps coming until I remove the card.
What was incorrectly wired?
 
Good news!

I had my new USB serial adapter wired up to the reader/NAOMI incorrectly.

Now with it wired up so that I'm just getting input from one direction, I monitored what the reader receives from the NAOMI. Basically I think I'm seeing what the reader would see with regards to data coming on the RXT input and anything happening on CTS.

Reading the data in as decimals, I see a series of repeating strings sent to the reader during initialization, a few more smaller strings after initialization during attract mode, and then some during the command to insert a card and read it in. I only saw CTS activity very briefly, I believe after the card was read in, but I'd have to confirm that. I did not see any CTS activity during initialization.

During the request to remove the card, I see a constant repeating string sent to the reader that keeps coming until I remove the card.
The constant string seems to be a polling command that stops upon receipt of ack for card removal.
 
This is great! How did you determine if it was RS-422 or RS-232?
As far as I can tell in the little amount of research I did, RS-422 requires twice as many pins (basically a positive and negative for every signal so TXD-, TXD+, RXD-, RXD+, etc). The pinout for the reader only listed enough pins for an RS-232 connection, so that was my guess.


What was incorrectly wired?
Since the USB serial adapter terminates in a standard 9-Pin D-sub connector, I searched on google for R-232 pinout and I think I referenced one that had the pins listed incorrectly . I had my what should have been RX wired into the TX pin, so that's what was throwing off the reader when I had it wired in. :whistling:

Here's the one I had referenced:
https://www.google.com/imgres?imgur...d=0ahUKEwikxc3Sy5DLAhWJND4KHREiCXwQMwg0KAMwAw

Here's one that I believe is correct:
https://www.google.com/imgres?imgur...d=0ahUKEwikxc3Sy5DLAhWJND4KHREiCXwQMwgxKAAwAA


The constant string seems to be a polling command that stops upon receipt of ack for card removal.
I agree. I haven't gotten to the point where I saw what the response from the reader is during that sequence.
 
Last edited:
Awesome! Thank you for that info. Were you able to compare your hardware logs with MetalliC's software data? I will update my notes as well. Both of your serial port pinouts are correct. The one you had referenced incorrectly was the Female pinout. The 'correct' one is Male. Glad you got it figured out tho. I'll try to take pics of my setup when I get a chance. For those of us that like visuals, do you have a quick and dirty image of your wired setup? NAOMI2 (CN2) <-> ID3 Card Reader (CN8).
 
The one you had referenced incorrectly was the Female pinout.
You're absolutely right. That would be a correct pinout if it was located on a RS-232 device. Though I was wiring a female header to adapt the wires to the reader, so it gets confusing. :S In my case, even though I was wiring a female, I needed it to match pin for pin to the male. Basically the way I wired the header, it's a straight-through adapter with wires coming out that I then attach at the reader for sniffing.


Were you able to compare your hardware logs with MetalliC's software data?
I haven't requested his logs yet. I'm not sure they'd be meaningful to me at this point. As far as I can tell with other serial terminals I've played around with, I'm just showing a representation of the signals as decimal characters, but most terminals aren't displaying them that way. I think they're either ASCII or HEX. When I move to Python, I'm going to have to figure out the translation for whatever that reads in and can successfully use for output, so even my current log isn't likely to be that useful without some kind of translation, at which point it would probably just be easier to sniff in the language I'm ultimately going to be using.


For those of us that like visuals, do you have a quick and dirty image of your wired setup? NAOMI2 (CN2) <-> ID3 Card Reader (CN8).
I'll see if I can get something together.
 
IMG_20160224_110739.jpg
IMG_20160224_110840.jpg
 

Attachments

  • IMG_20160224_110938.jpg
    IMG_20160224_110938.jpg
    115.2 KB · Views: 215
  • IMG_20160224_111041.jpg
    IMG_20160224_111041.jpg
    65.6 KB · Views: 211
Last edited:
Ok, I was wrong. The card reader WILL take a card in during initialization in the test menu.

With the card in, the reader keeps outputting:
6,2,6,32,161,48,48,3,132,

When the card is removed, the last output is:
6,2,6,64,160,48,50,3,231

When the card is in, the NAOMI keeps outputting:
2,6,32,0,0,0,3,37,5,

When the card is removed, it outputs 2 separate things:
2,6,64,0,0,0,3,69,5,

2,79,122,0,0,0,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,32,

I'm working on wiring up 2 adapters to get simultaneous readings and hopefully easier sequencing.
 
NAOMI2 (CN2) <-> ID3 Card Reader (CN8).
It's NAOMI2 (CN8 - Labeled as RS422) to ID3 Card Reader (CN2 - Not sure if labeled, but it's the 8-pin connector with 5 wires in it)
thanks for the correction. Yes, I was typing this on my way out of the house. My card reader doesn't have 'CN2' on it but it was easy to figure out which pins to tap based on the Twin ID3 diagram.
 
Ok, I was wrong. The card reader WILL take a card in during initialization in the test menu.

With the card in, the reader keeps outputting:
6,2,6,32,161,48,48,3,132,

When the card is removed, the last output is:
6,2,6,64,160,48,50,3,231

When the card is in, the NAOMI keeps outputting:
2,6,32,0,0,0,3,37,5,

When the card is removed, it outputs 2 separate things:
2,6,64,0,0,0,3,69,5,

2,79,122,0,0,0,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,32,

I'm working on wiring up 2 adapters to get simultaneous readings and hopefully easier sequencing.
Forgive my poor combination of replies, still getting used to this message board. I was going to clarify this for you in an earlier post but yes, initialization should be able to take a card during load. Since you are outputting decimal, it might be a little difficult to see which are proper segments as opposed to RAW data in ASCII or Hex format. Either way, in the test menu, try to run the option that says "Test Card R/W". I have to figure out how to save the data I am getting on mine. Unfortunately I am using a logic analyzer but I can only save to a Floppy, yes Floppy drive. I to am going to purchase the dual serial as well as wiring up the an RS-232 as you have demonstrated. Hopefully I can give you some additional information on my end.
 
I received my 2nd adapter and have both ports wired up to sniff each side of the communication.

So far my biggest impediment to progress seems to be getting some software set up that will allow reading in from 2 ports simultaneously. I don't want to put any money into purchasing the full version of 232Analyzer (or pirate it), so I'm looking into alternatives.

I found a Python script that claims to be able to do it, but I had to comment out a lot of stuff that didn't seem to be compatible on Windows and while it is reading from both ports, it's not currently presenting the data in any meaningful way for me. Everything ends up getting printed out in one long continuous string with no indication of which port was read... :(

http://hackaday.com/2012/11/16/python-script-lets-you-monitor-multiple-serial-devices-at-once/

I'm going to try to come up with my own script. I'm still learning how to use the pyserial module.
 
I received my 2nd adapter and have both ports wired up to sniff each side of the communication.

So far my biggest impediment to progress seems to be getting some software set up that will allow reading in from 2 ports simultaneously. I don't want to put any money into purchasing the full version of 232Analyzer (or pirate it), so I'm looking into alternatives.

I found a Python script that claims to be able to do it, but I had to comment out a lot of stuff that didn't seem to be compatible on Windows and while it is reading from both ports, it's not currently presenting the data in any meaningful way for me. Everything ends up getting printed out in one long continuous string with no indication of which port was read... :(

http://hackaday.com/2012/11/16/python-script-lets-you-monitor-multiple-serial-devices-at-once/

I'm going to try to come up with my own script. I'm still learning how to use the pyserial module.
I have not used 232Analyzer before but does it not allow you to read COM2 and COM3 at the same time? This might be a stupid question but what if you hooked up one serial to one PCs COM2 and another serial to a different PCs COM2 and read 232Analyzer separately? (2 instances of 232Analyzer).
 
I have not used 232Analyzer before but does it not allow you to read COM2 and COM3 at the same time? This might be a stupid question but what if you hooked up one serial to one PCs COM2 and another serial to a different PCs COM2 and read 232Analyzer separately? (2 instances of 232Analyzer).
I think it's a limitation of the free version. There's a full duplex monitoring function that is not available in the free version that I suspect would work.

I didn't try, but it may be possible to have 2 instances of 232Analyzer open on 1 computer. Certainly 2 computers could work, but either way, deciphering the sequence wouldn't be that easy. It's not putting a timestamp on what it reads in.
 
OK, here is some info about this reader protocol

Code:
>>>	SEND PKT: [START 02][LEN][CMD][0][0][0]{optional data}[STOP 03][CRC]
<<<	RECV ACK: [OK 06]
>>>	SEND REQ: [RQ 05]
<<<	RECV PKT: [START 02][LEN][CMD][RESULT1][RESULT2][RESULT3]{optional data}[STOP 03][CRC]
<<< RECV ERR: [15]
	RESULT1 (SENSORS): binary value SSTCCCCC
		S - Shutter state:
			0 - "ERROR"
			1 - "CLOSED"
			2 - "OPEN"
			3 - "NOW" (both open and close sensors)
		T - Stocker (card dispenser) state:
			0 - "NO" (empty)
			1 - "OK" (full)
		C - Card sensors:
			0     - "NO CARD"
			1     - "CARD EXIST (ENTER)" (card inserted in front of shutter)
			18    - "CARD EXIST" (card loaded inside of reader)
			other - "CARD EXIST (OTHER)"
	RESULT2: char 01235QRSTUV`
		Error ENUM "OK", "READ ERR", "WRITE ERR", "STOP ERR", "PRINT ERR", "READERR T1", "READERR T2", "READERR T3",
		 "READERR T12", "READERR T13", "READERR T23", "SHUT ERR"
	RESULT3 (CMD_STATE): char 02345
		State ENUM "OK", "DISABLE", "BUSY", "CARD WAIT", "NO CARD IN BOX"
so on top level it works like - NAOMI send command packet (02 xxxxx), if packet was received OK - CRW send OK acknowledge (06), NAOMI requests reply for this command (05), CRW send reply packet (02 xxxxxx), and so on.

RESULT1 is bitmap of sensor bits.
RESULT2 looks like critical error code, normally always '0'
RESULT3 seems command state, can be > '0' during command execution, and '0' then done
but might be more complex, as I see 0x40 command have it always '2'
 
I found a Python Script to read in 2 ports on my Windows PC!

MetalliC, how does this line up with your findings?

Test menu initialization, no card:
2016-02-26 09:16:14.840625: NAOMI2
02 06 40 00 00 00 03 45 05
2016-02-26 09:16:14.856269: READER
06 02 06 40 A0 30 32 03 E7
2016-02-26 09:16:17.200024: NAOMI2
02 06 20 00 00 00 03 25 05 02 07 10 00 00 00 31
03 25 05
2016-02-26 09:16:17.215630: READER
06 02 06 20 A0 30 30 03 85 06 02 06 10 A0 30 33
03 B6
2016-02-26 09:16:17.496898: NAOMI2
05
2016-02-26 09:16:17.512506: READER
02 06 10 A0 30 33 03 B6
2016-02-26 09:16:17.809381: READER
02 06 10 A0 30 30 03 B5
2016-02-26 09:16:17.918756: NAOMI2
05 02 06 20 00 00 00 03 25 05
2016-02-26 09:16:17.918756: READER
06 02 06 20 A0 30 30 03 85
2016-02-26 09:16:18.059382: READER
06 02 06 40 A0 30 32 03 E7
2016-02-26 09:16:18.262525: NAOMI2
02 06 40 00 00 00 03 45 05 02 4F 7A 00 00 00 15
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 23 05
2016-02-26 09:16:18.278133: READER
06 02 06 7A A0 30 32 03 DD

Test menu initialization with card in:
2016-02-26 09:20:08.679379: NAOMI2
02 06 40 00 00 00 03 45 05
2016-02-26 09:20:08.695004: READER
06 02 06 40 A1 30 32 03 E6
2016-02-26 09:20:11.038777: NAOMI2
02 06 20 00 00 00 03 25 05 02 07 10 00 00 00 31
03 25 05
2016-02-26 09:20:11.054385: READER
06 02 06 20 A1 30 30 03 84 06 02 06 10 A1 30 33
03 B7
2016-02-26 09:20:11.335657: NAOMI2
05
2016-02-26 09:20:11.351260: READER
02 06 10 A1 30 33 03 B7
2016-02-26 09:20:11.726260: NAOMI2
05
2016-02-26 09:20:11.741904: READER
02 06 10 A1 30 33 03 B7
2016-02-26 09:20:12.038779: NAOMI2
05
2016-02-26 09:20:12.054400: READER
02 06 10 A1 30 30 03 B4
2016-02-26 09:20:13.663764: NAOMI2
02 06 20 00 00 00 03 25 05 02 06 20 00 00 00 03
25 05 02 06 20 00 00 00 03 25 05 02 06 20 00 00
00 03 25 05 02 06 20 00 00 00 03 25 05 02 06 20
00 00 00 03 25 05 02 06 20 00 00 00 03 25 05 02
06 20 00 00 00 03 25 05 02 06 20 00 00 00 03 25
05 02 06 20 00 00 00 03 25 05 02 06 20 00 00 00
03 25 05 02 06 20 00 00 00 03 25 05 02 06 20 00
00 00 03 25 05 02 06 20 00 00 00 03 25 05 02 06
20 00 00 00 03 25 05 02 06 20 00 00 00 03 25 05
2016-02-26 09:20:13.679390: READER
06 02 06 20 A1 30 30 03 84 06 02 06 20 A1 30 30
03 84 06 02 06 20 A1 30 30 03 84 06 02 06 20 A1
30 30 03 84 06 02 06 20 A1 30 30 03 84 06 02 06
20 A1 30 30 03 84 06 02 06 20 A1 30 30 03 84 06
02 06 20 A1 30 30 03 84 06 02 06 20 A1 30 30 03
84 06 02 06 20 A1 30 30 03 84 06 02 06 20 A1 30
30 03 84 06 02 06 20 A1 30 30 03 84 06 02 06 20
A1 30 30 03 84 06 02 06 20 A1 30 30 03 84 06 02
06 20 A1 30 30 03 84 06 02 06 20 A0 30 30 03 85
2016-02-26 09:20:13.820034: READER
06 02 06 40 A0 30 32 03 E7
2016-02-26 09:20:14.023140: NAOMI2
02 06 40 00 00 00 03 45 05 02 4F 7A 00 00 00 17
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 21 05
2016-02-26 09:20:14.023140: READER
06 02 06 7A A0 30 32 03 DD
 
looks nice :)

log is quite expectable,
it does 0x20 and 0x40 commands, which I suppose sort of status polling, but have no idea what is difference in them and what result3 means in both of them.
then 0x10 - probably INIT, which is return result3 '3' several times in process, and '0' then done
and at very end 0x7A command (there must be more of them later), which looks like printer initialization
so this part quite clear, as well as whole tests in game testmode.

but really not clear things happens during real game run.
I'd like to see logs starting from a bit later after "KICKBACK INIT" (no need to log from start, there is same as testmode INIT), and after coin in then game asks for a card.
2x logs like you did above, with no card and with card inserted.
 
I found a Python Script to read in 2 ports on my Windows PC!

MetalliC, how does this line up with your findings?

Test menu initialization, no card:
2016-02-26 09:16:14.840625: NAOMI2
....
If I were to tackle this I'd start translating it like this...

For instance MetalliC posted this:
SEND PKT: [START 02][LEN][CMD][0][0][0]{optional data}[STOP 03][CRC]

Which relates to this
2016-02-26 09:16:14.840625: NAOMI2
02 06 40 00 00 00 03 45 05

02 - START
06 - LENGTH of 6 bytes
40 - COMMAND 40 (what does this command mean?)
00 - (byte 1-2) data
00 - (byte 3-4) data
00 - (byte 5-6) data
03 - END DATA
45 - CRC

05 - SEND REQ


First thing would be to identify all of the different starting and end codes, then identify all the different commands and what they represent, then figure out what the data represents.
then finaly determine how the CRC is being calculated so that when you send your custom data it check out (maybe this is a standard serial thing? I don't know).
 
Back
Top