PS2 [MX4SIO/SIO2SD] SD Card Adapter and SD-driver for the PS2 SIO2 interface

I wonder, is it possible to "power cycle" the devices connected to the SIO2 bus without doing a full system reset (from MECHACON)?
 
  • Like
Reactions: TnA
AFAIK it is not possible. The power for the Controllers and MC SPI ports is the same one that powers most core stuff running on 3.5V - IOP, BOOT ROM, etc. The SIO2 SPI interface only controls the data lines.

BTW, this reminds me of a discover I made, when I explored SIO2 - it has a differential mode! Which is never used. It is kind of like USB, in its signals - D+, D-. I didn't explore that much. This is one of the mysteries of the PS2. I don't know if all PS2 models support this - I tested only on SCPH-30003.
 
Thanks for the input.
- I measured the MC signals. The period duration of the clock line is 42 ns -> the frequency is 24 MHz, that matches your requirement.
- For passing through the CS signal i would use a switching IC but you are right, the µC can do this. Most µCs have an external interrupt pin and a µC that can handle the SPI signal should be able to handle the CS line. And this sollution is cheaper and needs less space.
- My impression is "the scene" is familar with PICs.

I don't know if it's possible to support two pinouts but I will try to implement this. LEDs are a must have for debugging.

Du you think a debugging PCB should fit into a MC case? (I don't think, only the final sollution must fit into it)

As for the SD Card slot - I think that maybe having the PCB support both a micro SD Card slot and a normal one would be good.
Of course ... I never thought about it, but this is an easy solution. As there is no big difference between the pinout of SD and microSD this will be implemented in the next PCB.

But I think those SD Card slots (push-push) are too big and expensive.
The selected slot is a push-pull slot, but if the PCB is designed like you explained it isn't possible to replace the SD card through a hole in the case.
 
Most µCs have an external interrupt pin and a µC that can handle the SPI signal should be able to handle the CS line.
If you are implying that the gating/pass-through be done by the MCU activating/deactivating its /CS to the SDCard when it receives an interrupt from the /CS from the PS2 - I don't think that would be fast enough - the delay introduced will be too great I think, based on previous experience with MCUs. Although my measurements show, that even though the clock is 24MHz (the max possible) there are quite long pauses between bytes and the effective clock is ~16MHz - 2MHz per byte(/CS). Still I think some external gating may be better, unless the MCU has dedicated internal circuitry for that.

When I said to support multiple MCU types, I meant it like - have pinouts for both, on the same PCB area, one slightly offset from the other, still attempting to save as much space as necessary.

Du you think a debugging PCB should fit into a MC case? (I don't think, only the final sollution must fit into it)

Yes, this should be fairly simple, so the debugging should fit the MC case. A multi-color LED can be used or multiple LEDs.

Also that reminds me - the MCU should read the SD Card's Write-Protect switch and send info about that on card-replacement to the PS2. The PS2 driver should save this locally and not send write commands in case it is write-protected.

It would be good if the command that start SD Card communication also has the effect of checking if the MCU has any state info for the PS2 side (like card-replaced or write-switch, or some other fault detected).
Basically it should be decided on some command, that does no harm to normal MC cards or controllers (though controllers never connect to the MC ports so maybe this is not an issue. Initially the MCU should not respond anything and it should only start driving the bus when it detects the particular command data for SD Card I/O start. This is in the case we assume that the same bus can be used for an MC too. But as this is not the case (each port is separate) maybe the MCU could start replying from the start. And only once the driver sees the decided-upon MCU reply should it start I/O. Of course that should be made short too, so that it doesn't waste time.

The selected slot is a push-pull slot, but if the PCB is designed like you explained it isn't possible to replace the SD card through a hole in the case.
Yeah, that won't work for a push-pull slot, but then the card would have to stick-out from the MC and that is all the better for having more space for the MCU inside the MC case. :)

BTW, I really like how you solved the problem with the LEDs being on the underside of the PCB by having holes above them. I don't think I have seen this exact thing before.

And I don't know if the "scene" is familiar with PICs - indeed they were used for PS1 modchips and later there were the SX28-modchip which is a fast PIC instruction set MCU, but I see more people being familiar with Arduino nowadays.

And although it probably isn't necessary, there could be a capability to update the MCU's program (through the SIO2 SPI again), as some MCUs support a bootloader.
 
Last edited:
Thanks for the Linux version of ps2client. On this github accounts I only found the source code, don't know why.

@Maximus32 I want to send out the prototypes tomorrow, I still nead your adress. Did you receive my email?
(got it, thanks)

Edit: Requested pictures of the prototypes:


 
Last edited:
THX! I attached them to the first post as well! It's quite a little "gallery" now, haha! :D

It's definitely a step forward!

I wonder were this project might be in a few years!
If it sky-rockets like FMCB or OPL, that's going to be amazing!


One reminder: These are the 1st-batch of Prototype-PCBs regarding this project! Historical for the PS2-Scene (especially if it becomes a more known project)!


So @MrMario2011 keep watching and I think I point your attention here as well @Versatile!
 
Last edited:
most of the designs here is using a microSD card. it might be better just to use a full size SD card instead (and just use adapters for the microSD card if you want to use one) since those are much cheaper to buy in larger capacity. its not like were space restraint anyway like on PSP and Vita SD card adapters.
 
This was discussed a few days (and weeks) ago. The reason for microSD was the hight of the port. It is possible that it down't fit into the original case, so it was much more secure to choose the micro SD fot the first release, as only developer can use this board until now.
The next version of the board can handle both, SD and microSD cards.
 
@remlei Yes, that is actually the plan!

The next PCB will be "multi-compatible", which means either a Micro-SD-Slot or an SD-slot can be added!

One reason for this is, that we can technically sell a batch of PCBs (like SD2SP2) and those who get it, can decide what kind of slot they want to use!
 
oh nice, ill just wait for the full size SD card version instead, im afraid that there a highly likely that a mircosd card slot broke prematurely. given from experience with card readers.
 
oh nice, ill just wait for the full size SD card version instead, im afraid that there a highly likely that a mircosd card slot broke prematurely. given from experience with card readers.
Most card readers use cheap slots I think. I would say this one is made of higher quality and it feels like.

Btw, one microSD slot costs 2 €, the SD slot 3 €. In my experience microSD cards are a little bit cheaper than SD cards, easier to get and for microSD cards you need an additional adapter, so it is more expensive.
 
He is right, if you take the €/$/etc. per GB into consideration! ;)

When someone buys a new SD-Card (instead of Micro-SD), you get more GB per €/$/etc.!
 
So, I think the Roadmap currently looks as following!:

2nd-batch Prototype-PCB will have these changes for now:
  • It's possible to add either an SD-slot or a Micro-SD-Slot to the next PCB-Layout!
  • It's compatible with the old and the newer SONY-MC-Cases!
  • The writing for "INSERTED" and "TRANSMISSION" is being switched (because it is currently inversed on accident, lol)
  • Any more ideas?
This will probably be the "final" PCB-Layout of the "easy version"!


The 3rd layout will probably feature these additions and is basically the "end-product" featur-wise regarding the hardware itself (especially for developers), even though there might be updates to the PCB-Layout!:
  • a programmable (probably PIC-based) MCU
  • an additional Debug-LED or "Mode" (using the 2 available LEDs)
  • an interface to connect to the MCU via a PC
  • MAYBE being able to flash the MCU from the PS2 itself as well, but that needs software-side support!

Is that "Roadmap" alright @wisi, @Maximus32, @Takeshi, etc.?
If it is, I would like to add it to the first post, if you don't mind!
 
I was taking a look at the thread, did read about the logo, i had an idea for it and i could not resist the temptation to do it and show it to you :D
So here is a logo proposal, is a dirty sketchup
iwgmp3O.png
WBQoTtL.png
MTpTjU3.png

The idea is to "print" it at this position/size... well aligned with the "rectangle" engraved in the plastic
dRZIg3j.jpg
 
Last edited:
Btw, one microSD slot costs 2 €, the SD slot 3 €. In my experience microSD cards are a little bit cheaper than SD cards, easier to get and for microSD cards you need an additional adapter, so it is more expensive.
yeah sure, but ill take that expense just to buy a lets say a 512GB SD card for like 100 dollars cheaper compared to a microsd card version of it. Not to mention that SD card is usually a UHS-II and also a low latency SD card, I dont know if this matters but that's what I usually have most used on my DSLR.
 

Similar threads

Back
Top