I thought about posting this in the Conservation forum, but then realized the right people may not visit it, so I'm posting it here. If mods / admins feel this should be moved, feel free to do so. The device is the InterAct V-Mem (Virtual Memory Card System), by the creators of the Gameshark. It connects to the fat PS1 parallel / expansion port and basically allows saving to its internal memory that is split in 60 virtual memory cards (you can only have 2 "active" VMCs). -Does anyone here own this device and is willing to (try to) dump its ROM / Firmware? -Also, anyone that owns one of this, can you provide the ROM / Firmware version? Not sure where it would be listed, but it should be somewhere (hopefully). I was always curious to know if more than one version was released. "Fun" fact: As far as I know (ie. by searching around the net), this device was never released outside the US, which is kinda weird, as Interact (US) was just a reseller of Datel (UK) products. But I couldn't find an equivalent product with Datel brand. PS: I'm NOT talking about the V-Mem feature of the GameShark and similar cartridges; this is a separate device that was exclusively a huge storage with multiple virtual memory cards. Google "interact v-mem" (no quotes) and you'll find pictures of it.
I wasn't aware of this hardware, seems like a nice solution for a quick memory card replacement. I'm guessing it actually patches memory card calls before it launches the game? Since you can't really intercept memory card stuff from the PIO.
I ordered one, has arrived today, gentleman. ROM dump posted here. Same PCB ref and parts as this one btw...
Many thanks for the ROM. Looking into it, trying to dig memory card interception code; this could come in handy at some point.
Oh, I forgot to mention that the rom was dumped from a brand new (not inited) device. So V-Mem owners, be aware that flashing my rom image may wipe your VMCs, if the config field is in the SST chip... EDIT : Nope. I've dumped the rom again, after the "1st time use" memory wipe. The dump is identical to the one I've posted yesterday.
From what I could see, it has a function that does exactly that first time use thing you mentioned (it's located right at the top of the secondary ROM with a RAM base address), but it doesn't seem to alter the cartridge in any way. It's probably writing stuff back into some other onboard flash, got to get to that point yet as its possibly nested deep further into the code. Still, very interesting piece of hardware. ------------------------------------------ UPDATE 1: I've started digging a bit more into the rom itself and found more or less how it works. As expected, it seems to replace parts of the RAM BIOS with injected procedures that override memory card behavior. From what I could see, it uses some basic pattern finding to locate where to hook events, returns their positions, and installs custom events. It even comes with a custom exception handler installed at 0x80000000, which executes rom code at first and then resets itself to no execution. Most of the communication with the memory card flashes seems to be mapped onto 0x1F060010 (write), 0x1F060030 (read), and 0x1F060038 (read), more or less like the Caetla protocol to receive and send packets. I would guess 0x1F060010 is used to dispatch commands to flashes in order to grab memory card contents, while the other two seem to be used to checking some status. Needs more investigation and disassembling. With these finds tho I have a few questions, since I can't test exactly how the cartridge software works in details. So, does it emulate just one memory card port or can it do both at the same time? Also, when you start its internal card manager for transfers, does it allow both mc slots to interact just fine (i.e. by not overriding them completely) or it only lets you use one of them? I'm asking this because initializers in the rom seem to take a branch at some point, triggering different event installers which look more or less the same, but possibly related to forwarding different mc slots. ------------------------------------------ UPDATE 2: Uploaded what I got reversed from the card so far here. If you look carefully at some of the main code, you can see how it's pulling patch addresses in the initaliazer code, which pretty much sends a bunch of bytes through receiver ports and reconstructs both the addresses and some patched up code. Unfortunately there's no way to know exactly what it's pulling without some first-person debugging, but I'm assuming it's getting all the data from one of the other roms, which haven't been dumped. If only those could be extracted as well we'd have the whole thing, plus all the missing data for patching. ------------------------------------------ UPDATE 3: Figured out what BIOS RAM functions are touched up by the VMem. It completely kills nextfile() off. Adds hooks to functions usually called internally in the MC dispatched when you invoke _card_info(), _card_write(), and _card_read(). Rerouted event handlers usually all have a special case where they load from 0x3DB4 into T9, add 0x18 to SP, and jump to T9 (i.e. when reading from VMem, otherwise it's regular memory card handling). This is an elaborate trick to skip the current event altogether and return directly to the memory card dispatcher. They could have simply reread RA value from SP, but I guess they wanted to make it cryptic to avoid exploitation of their "super duper secret system". Besides these hooks, the rest is unknown and probably not even necessary to write a replacement with an FPGA or whatever. Still, nice trick.
