What's new
That's pretty cool.

If you're building that off of the research provided freely in this thread, it would be nice for you to provide a shout-out to contributors - both @MetalliC and android gave invaluable information. Based on your questions here, I'm assuming you used information provided by both of them, even if you're doing your own logging from actual hardware. If I'm mistaken, then I apologize for the assumption.

I'm curious, assuming netbooting is involved in the majority of the configurations where people are playing these games, why you want to do a dedicated device for the card reader in addition to the netboot device. If your pcb could manage netbooting, and it seems like it maybe could with additions, it might be more attractive. Otherwise, if someone is already using a Raspberry Pi for netbooting, it seems like a decent menu system could be put together on that platform for free.

@mathewbeall has put together a couple of RPi based images that integrate the card reader functionality into a web front-end that can be accessed by a phone. I personally would like to see someone build that out for all available games.
 
I passed many hours on original memory card reader with my logic analyser to retrieve the protocol logic. I found your thread when "Aspic" (Gamoover member) give me the link. But, at this moment, i've allready founded all protocol infos.

I'ved used the RFID counter address decoding informations gived by Metallic (Thanks a lot to him) but nothing else.

Soo, now, my system is for people want to have plug and play system (i sold it with wiring). I think, you can integrate the logic in raspberry with netboot, but it's not my way.
 
I passed many hours on original memory card reader with my logic analyser to retrieve the protocol logic.
lucky you, last ICRW device I was RE'ing uses data encryption, so communication logs is not much useful.
 
Aganyte,

Could your card emulator be setup to store the emulated cards directly to compact flash? This way different users wouldnt have to share emulated cards and could switch out sd cards
 
Aganyte,

Could your card emulator be setup to store the emulated cards directly to compact flash? This way different users wouldnt have to share emulated cards and could switch out sd cards
This wouldn't be a huge stretch to set up on a Raspberry Pi with the scripts provided here.
 
Aganyte,

Could your card emulator be setup to store the emulated cards directly to compact flash? This way different users wouldnt have to share emulated cards and could switch out sd cards
This an update on my todo list.
 
I don't have WMMT3 to test. I think it uses a slightly different card reader, but no clue if it can use the script for WMMT1 and 2.
 
I'm currently working on refactoring some of the scripts with the hopes that front-end support will be easier.

A stretch goal, and the ultimate evolution of this project, is to interpret and visualize print commands. There had been talk of it in this thread, as well as some discoveries made by others. I encourage any and all participation in making this happen.

I'm kind of disappointed in the lack of progress in the community advancing beyond the original scripts I posted. @mathewbeall is basically the only one I know of to take it further with front-end implementation on a couple of the scripts. That is much appreciated and is hopefully going to serve as a starting point for some of my changes.
 
Let me know how I can help @winteriscoming - I can cobble together a system in the garage where I can do some testing I believe - just need to get brake/accelerator hooked up somehow.

The biggest challenge in a "public" setting with the script as it exists is when people say "yes, I have a card" but then don't actually "load" the card in the frontend - the game errors out because it's not seeing the response it needs and timing out.... Other than that, it was working pretty flawlessly in most situations I can into.

Matt
 
I just recently got a card reader, still need to hook it up, but it should be working - assuming it is i'm happy to try to help as well.
 
The biggest challenge in a "public" setting with the script as it exists is when people say "yes, I have a card" but then don't actually "load" the card in the frontend - the game errors out because it's not seeing the response it needs and timing out.... Other than that, it was working pretty flawlessly in most situations I can into.
I don't have a great solution to this short of having a populated card file on standby and if the game sends a load card command and the current card file is blank, then it loads in the standby file instead.

The script unfortunately allows for this scenario that's not as feasible on a real card reader. The user is essentially inserting a card that has 0 bytes. I don't know if that's the same as what would be read by the reader if the card file is blank.

However, I'm not sure what happens in real life. What happens if you insert a blank card at the time you say you have a card? If that works and the game just rolls with it as if you purchased a new card, then perhaps it's a matter of making sure new blank card files are generated appropriately, rather than just starting with a 0 byte packet and sending that to the game.
 
I just recently got a card reader, still need to hook it up, but it should be working - assuming it is i'm happy to try to help as well.
There may be some benefit to tests done with a real card reader, but I'm not sure what that would be at this point.

It may actually be beneficial to send print commands to a real card reader. However, at least with ID3, this will lead to wasted cards since the printing can't be erased. With WMMT, the printing can be erased and reprinted. The printing protocol may be similar among the readers, but ultimately it's probably going to be a matter of figuring it out per game. See what a command is, see what printed. Try to figure out how the command translates to what got printed.
 
The biggest challenge in a "public" setting with the script as it exists is when people say "yes, I have a card" but then don't actually "load" the card in the frontend - the game errors out because it's not seeing the response it needs and timing out.... Other than that, it was working pretty flawlessly in most situations I can into.
I don't have a great solution to this short of having a populated card file on standby and if the game sends a load card command and the current card file is blank, then it loads in the standby file instead.
The script unfortunately allows for this scenario that's not as feasible on a real card reader. The user is essentially inserting a card that has 0 bytes. I don't know if that's the same as what would be read by the reader if the card file is blank.

However, I'm not sure what happens in real life. What happens if you insert a blank card at the time you say you have a card? If that works and the game just rolls with it as if you purchased a new card, then perhaps it's a matter of making sure new blank card files are generated appropriately, rather than just starting with a 0 byte packet and sending that to the game.
I was thinking that when it wasn't running with a card actually "inserted" that it could run a loop and basically respond to commands with "no card inserted".... I will have to get my stuff all setup again with the serial sniffer in place to be able to see what that actually looks like in real life on the card reader.

Matt
 
I think it will allow for a no card loop with nothing inserted. I would guess it times out at some point.

I'm more curious what happens if you take a blank card from the hopper and try inserting that during the time you tell the game you have a card.

However, you bring up a good point. Perhaps the script just simply shouldn't "insert" the blank card.
 
Back
Top