Can a modchip/custom BIOS theoretically report Game ID to a Memcard Pro?

[bobrocks95]

Good luck getting it working. I was asked by some to see if I could support it in Stealth Unlocker. I'm willing to add support for it but it seemed overly complicated at the time, and not having the real hardware to test with made it pointless to even attempt. Well that and ofcourse no emulator can really test it either.

But I see the appeal in automatically selecting the game's own memory card image for you.

Hopefully I can get some decently well-written and documented assembly up when I'm done, it's certainly more complicated than I thought it would be but nothing too terrible past the learning-curve of MIPS assembly and no$psx debugging.

Final testing will be a major problem though- funny enough I'm waiting on a Memcard Pro restock that isn't coming until next month. Gameshark serial port carts are only 128kB right? Can I load a BIOS payload via CD somehow? Hardware verification might be tricky though I do have a broken SCPH-1001 I might be able to do something with or test BIOS swaps on.

My current status is that it looks like I have everything set correctly, I send the first 0x81 bit and JOY_STAT switches to 1 (TX Ready Flag 1 switched to ready/started) and then eventually it switches to 7, which is not what I'm expecting. 7 means TX Ready Flag 1 ready, RX FIFO Not Empty, and TX Ready Flag 2 Finished I think? No action on the ACK line like I was expecting, do I have to do some kind of read operation first or is my configuration incorrect? I did JOY_CTRL = 0x1003 for TX Enabled, JOY1 Select, and ACK Interrupt enabled.



Wait no because of endianness that's 207 = 1100 1111 which means the 8th ACK bit is set and my assembly logic is just wrong for reading it, well that's nice to see.

[nocash]

Uhm 11001111 binary would be 207 decimal, not 207h hex.
What you are seeing is bit9 (200h) being set, in the "terrible Nth bit notation" that would be the 9th or 10th or 7th bit (depending whether consider bit0 or bit1 or bit15 as "1st bit").

When waiting...
First, wait for JOY_STAT.bit2=finished or bit1=RX data available (ignore bit0=started, that's useless).
You can then read the RX response byte.
Second, wait for JOY_STAT.bit9=IRQ (indicating ACK was toggled) (don't try to read bit7=ACK directly, that bit may be set only for a very short moment).
Then use JOY_CTRL to reset JOY_STAT.bit9 (as you already said you did).

Remember that the last byte won't respond with an ACK/IRQ, so skip the IRQ wait after last byte.
And remember that missing memcards won't respond with any ACK/IRQs, so do some timeout in the IRQ wait loop.

Code: Select all

slti    r9,r9,0x0A

That keeps getting turned into

Code: Select all

jmp     0B4A40028h

Oops, thank you! I'll fix that in next update... and in current version... you could use .nocash to switch to the setlt syntax, and .native to switch back to the standard MIPS syntax... that workaround is a bit awkward, but I hope it will work for now.

[nocash]

PS. for the IRQ flag to trigger on ACK, enable only that IRQ source (JOY_CTRL.bit12=1, bit10-11=0).

[bobrocks95]

Finished a big refactor tonight since I was out of memory space for the code. It's pretty tight and well-documented now, and I should be able to finish up the controller handling tomorrow hopefully.

Still have no clue how I'm going to test this though. Short of outright replacing my BIOS chip with my untested, modified version, I don't know another way to load a custom BIOS on hardware, or to simulate the MemCard Pro in emulation software. Gotta wait until November for a MemCard Pro to be available anyways.

I also thought about the PS1Digital since it would be nice to support, but if it's just a "bus sniffer" that doesn't send any ACK's back, it sounds like you'd have to have a MemCard Pro to go with it or that feature wouldn't work at all because you'd never get an ACK back before sending another byte. If you're supposed to just shove every byte into the data address, how slow are you supposed to do it? Too many unknowns to explicitly try to get it working I think (you can't get a PS1Digital right now anyways).

[bobrocks95]

Pretty much done now I guess. Just curious what anyone thinks the best way to handle the lack of an ACK signal should be-



The final 4 bytes do not send an ACK signal, just changes JOY_STAT bits 1 and 2 for TX finished and RX FIFO available. Should I just hardcode a skip on the ACK check for those bytes? Or maybe always continue even if I don't receive an ACK IRQ, so long as data is available to read?



It also leaves me stuck with yet another unknown on the MemCard Pro- how many bytes will respond with an ACK?

[nocash]

That's because your timeout is too short for the 7th ACK.
See the "Timings" part in http://problemkaputt.de/psxspx-memory-c ... mmands.htm
Alltogether you should get nine ACKs (the 10th byte-pair is also transferred, but doesn't respond with an ACK).

PS. After re-reading the psxspx description, I am not sure if the slow 7th ACK should occur in Get ID command (or only in Read Data command). Anyways, no$psx does currently emulate that slow 7th ACK effect in all memory card commands.

[bobrocks95]

Dang I just needed to read one paragraph further, sorry for the trouble on that one. Wouldn't affect the Memcard Pro but good to know what a reasonable timeout is anyways (I ballparked it very generously but not enough for 31,000 cycles lol).

Well, I think that's everything I need then. Didn't hear back via twitter from Chriz so I opened an issue on the Gitlab to verify the total command length (padded to 100h bytes or 4 + bytes in Game ID string).

Unless there's a reasonable way to load a modified BIOS on hardware (doubtful beyond of course replacing the BIOS chip, which is what I'd want to do once I can actually test it) I'm not sure how to test things beyond really stepping through the assembly super carefully and hoping it works first try.

Can dev hardware of any kind load alternative BIOS files? Maybe I can contact someone who'd have the equipment to test this to see if they're willing?

[MottZilla]

Why can't your execute your code from a CD-R or serial upload? Or you could use a program to serial upload your program to a GameShark cartridge.

But it seems premature if you don't have an actual MemCardPro to test with yet.

[bobrocks95]

I've got a modchip and would love to test off of CD-R's since I have plenty, but given the crux of the code is a BIOS modification I would think I'd either have to fully load a modified BIOS (512kB, not sure there's any method to do so), or append the code at the start of a game's executable and see if the ID string is still in memory.

Since it's hinged on "load this game normally, just send some extra data to the memory card before the game starts", I can't just throw the code as an executable on a disc, right? Maybe I'm misunderstanding your suggestion though.

My other thought was socketed EEPROM so I can reflash the BIOS chip on the board, but I don't actually know if you can get sockets for SMD parts?

EDIT: Looking around I see that no$psx has an option to create a BIOS ROM installer (PSX-XBOO.EXE) that is separate from the expansion ROM installer for Gameshark devices. I also found a "BIOS Flasher" CD image from megavolt85 (who I happen to recognize as the creator of the Dreamcast Atomiswave ports a couple years ago) that has a list of supported flash memory chips from AMD, ATMEL, SST, and WINBOND.

Maybe that means if I install a replacement chip, which I was expecting to have to do anyways, I can reflash it from a burned CD? Presumably with a wire or two added, maybe just a write enable line connected up? I don't really see instructions for these from googling...

EDIT 2: A PS1 BIOS replacement PCB is on its way from Will's Console Mods in the UK! He told me he uses SST 39VF040 flash chips on his board, and I've confirmed with megavolt85 that any flash chips with a byte-by-byte writing mode can theoretically be supported with his flashing program- commands are actually identical between this chip and the SST 39SF040 megavolt85's program already supports, so it will be as simple as updating an array to allow the software to recognize the newer chip, and placing my patched BIOS file on the disc.

From there, all that is needed is 1 wire from /WE on the new chip (disconnect it from VCC first) to CPU SWR0 (should be pin 100), and the BIOS can be reflashed via CD.

I'll be testing as many firmware variations as I can, and will hopefully be posting a release thread by December then! Unfortunately I will be waiting quite a while before a MemCard Pro is available lol.

[bobrocks95]

I finally got this board in today from Will's Console Mods in the UK- https://www.willsconsolemodifications.c ... duct_id=55

Unfortunately it's going to be difficult to work with and I don't think I'll be able to broadly recommend it. On the replacement TSOP flash chip, pins 7 (/WE) and 8 (VCC) are directly connected to each other and I believe it's through a trace + via that's underneath the chip on the surface PCB layer. So the only reasonable way to isolate /WE for reflashing the BIOS is to lift pin 7 on the TSOP package and solder a wire directly to it (I was hoping I could cut a trace and expose some copper from it instead).

I'd rather have a direct SOP replacement chip to work with where I can just lift the /WE pin to begin with and bridge it to VCC when I'm done. Or if nothing's available that matches the required pinout, having an adapter board for a TSOP package with a nice solder pad breakout for pin 7 that you bridge with a VCC pad next to it when you're done.

Still waiting on Memcard Pro stock so I looked around Mouser/Digikey and didn't see any replacement 32-pin EEPROMs. They wouldn't be flashable anyways since the original BIOS are needed to launch the flashing program to begin with...

EDIT: I broke pin 7 so there's some money down the drain... I'd classify lifting a pin on an already-soldered TSOP package as extremely difficult so I need to find an alternative anyways. Very frustrating since I thought getting a replacement EEPROM in would be simple!

EDIT2: This PCB will be perfect actually, I just need a pre-flashed SST39VF040 chip to go on it which I've put out some feelers for. The solder pads are for bridging /WE to VCC or putting a large resistor in to hold it at ground, but work out perfectly for attaching a wire temporarily, then bridging it when you're done. Open-source and cheap on OSHPark too.

EDIT3 11/16: Flashing hardware is here, chips are here, PCBs from OSHPark are here... Just waiting on the Memcard Pro!

EDIT4 1/30/23: Still waiting on a Memcard Pro in case anyone checks this thread on occasion lol.

[bobrocks95]

I've released my patches and instructions on my github: https://github.com/jdfr228/PS1-Disc-Based-Game-ID

Any feedback or testing is welcome, I don't have a lot of hardware to try it out with.

So far limited testing has been working! Funny enough I'm still waiting on my memcard pro, but mi213, whose flash adapter PCB I recommend for the installation, has shown it working on video for disc and even PSIO loading.

[bobrocks95]

Project update (please don't be mad at the quadruple post):

Hardware issues with SD2PSX and newer MemCard Pros have been resolved, and so have most edge cases for weirdly formatted SYSTEM.CNF files! The Github isn't updated yet so stay tuned if you're a lurker actually looking for the patches.

All that remains to fix are some stability issues- I may make another thread if I need to, but do any kind developers know if I'm using the syscall functions correctly like this?

Code: Select all

; enterCriticalSection()
        li      r4,0x01
        syscall
        
; exitCriticalSection()
        li      r4,0x02
        syscall

I got StopPad working (wasn't checking destroyed registers before) and call it at the start of my payload, but I still seem to be getting a capital B (ascii 0x42) in the middle of the string I'm sending on certain boots, which seems to be from a 01 42 00 00 00 command (controller read?) that pops up during the kernel booting sequence (maybe from initCard or startCard?).

I thought I'd add enterCriticalSection() and exitCriticalSection() in to see if that did anything, but they don't seem to have an effect so I'm not sure if I'm calling them correctly...

EDIT: Issues resolved by throwing another stopPad() in there! I think the important part was putting it after initCard() and startCard(). Github will updated shortly...