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

TnA said:
Well, that's not so far...

Give it a few days and we have the first people which can provide some tests HOPEFULLY!

I assume most get it next week.

Beside @Takeshi, 1 who connected him to the project (he saw it on psxtools.de and shared it on trisaster.de) already got his Adapter (or PCB?).

Some more adapters and BLANK PCBs are already on their way to various people (in Europe)!
Let's hope they work as intended and that this first test-batch will help to push the project.

Let's hope it doesn't take too long!
Click to expand...

All good.
@Takeshi hit me up, got a PCB on the way :chewie:
 
Maximus32 said:
But I think it should go back into SIO2MAN if we want it to play nice with other SIO2 transfers.
Click to expand...
Yes and no. If, in theory we could go in SIO2MAN, that would make things a lot simpler. But for programs like OPL, where the SIO2MAN IRX comes from the game, this is not possible without patching.
I still haven't tested the code I proposed for more compatible interrupting of ongoing transfers of other SIO2 devices. If that works, then we won't have to worry about this. If that doesn't work, then the only way to make things not interfere with each-other will be SIO2MAN integration / patching, and I really hope we don't have to resort to that.

Maximus32 said:
SIO2D is a sony driver that is supposed to detect insertion/removal of devices, but we don't have an open-source ps2sdk version of it. Perhaps we'll need this in the future.
Click to expand...
I have done many tests on the SIO2 interface and I don't think there is an feature to detect insertion/removal, other than simply transferring data, etc. (There is also the ACK line that has to be driven active at the end of each transferred byte AFAIR, else the transfer will fail, which is why we have it constantly connected in that state.)

Maximus32 said:
One thing slowing the transfer down seems to be bit-inversion for all transmissions. @wisi do you know why this is needed?
Click to expand...
This cannot be avoided. The bits in each byte are in reverse order, so they need to be reversed, or it won't work on a PC (or anything else) then.
Maximus32 said:
Perhaps we can double-buffer the transfers, and invert 1 block while the other is being transferred.
Click to expand...
This is mostly what the driver is currently doing. This is why it is using PIO and not DMA. DMA requires having all bytes with bits order already reversed, so it actually makes the transfers really slow.

The current driver reverses the bits order of the bytes in one word, then sends it, and while it is being sent, it reverses the next word. Also the fact that it is done in word pieces, makes it faster per-byte.
And even if this is done, the SIO2 is *still* too slow! So there is time left, which is why I added the fast asm CRC code, which only slows-down things a little bit.
In fact I am so certain that this is the maximum possible speed of this interface that I am very keen on seeing anybody achieving a higher speed, if possible.

I don't know what we will see on a PPC-IOP. I really hope it is not lower speeds.

Are the above tests with CRC enabled or disabled?


Maximus32 said:
@wisi did you make this yourself or is it a copy from somewhere?
Click to expand...
I copied it from that same website you found, back in our first discussion about this on psx-scene.com. But I don't remember the website.
I am quite certain that the code doing the transfers is mostly OK.
The part I am having doubts about is the initialization. There may be more steps needed there and some changes as well. This may improve compatibility with some cards.
The problem is that we have no way of giving the card clocks without having the /CS line active low. An MCU can help with this. I think this may be one of the reasons for the incompatibility.

But yes, maybe we can use that new code, as long as it doesn't makes the driver too big, as in the case of OPL, this is a requirement too.

There are some workarounds I had to do, to make SIO2 compatible with the SD SPI interface transfer specs - mainly related to the inability to easily transfer single bytes.
 
wisi said:
I have done many tests on the SIO2 interface and I don't think there is an feature to detect insertion/removal, other than simply transferring data, etc. (There is also the ACK line that has to be driven active at the end of each transferred byte AFAIR, else the transfer will fail, which is why we have it constantly connected in that state.)
Click to expand...
How about connecting the reistor to ground onl if a SD card is inserted? You still have to send data to get the state, but you don't need to read the data.

wisi said:
This cannot be avoided. The bits in each byte are in reverse order, so they need to be reversed, or it won't work on a PC (or anything else) then.
Click to expand...
The read speed on the PS2 is the most important thing. Either a special PC software is used for copying process or a PS2 software swaps the bytes after the transfer. This will take time, but after that the speed is increased.
 
  • Like
Reactions: TnA
More of a suggestion than a request.
But what are the possibilities of running FMCB from this card? Would be an amazing solution for exploiting and also would be an all in one solution for ps2, a plug and play memory card that also contains content.
Pretty cool "library in you top pocket" allowing for instant gaming on any ps2, wherever you might be that day lol
 
  • Like
Reactions: TnA
Takeshi said:
None. The SD card can only be adressen through homebrew so you need FMCB before. If it's possible, then with other hardware.
Click to expand...

If an original ps2 memory card was retrofited with an SD card slot and a switch to to change between the 2, FMCB could be used before switching to SD?
Or some kind of IC that contains the FMCB payload to start before it switches to SD?

This maybe too much work for the return of only using one memory card though
 
  • Like
Reactions: TnA
Yes, both "modification of an MC" and an "extended version" with MCU and Debug-Capabilities has been talked about and might be the 3rd board-revision.

However! For the second PCB, some other things are planned which do not include the hardware, to pull that off!
However, it has long been a dream for multiple people, hence it might come true once upon in time!
 
If the MCU is used (on a future revision of the board), it is possible to program the MCU to change the communication protocol.
If MagicGate is to be used on the MCU (example: for usage of FMCB or DVD player), it would require side loading of the MagicGate keys due to them being copyrighted.
 
Technically we only need to emulate certain stuff like ack/response, MG-Auth and MCID!

The MC itself doesn't include the MagicGate Keys to my knowledge!
 
TnA said:
Yes, both "modification of an MC" and an "extended version" with MCU and Debug-Capabilities has been talked about and might be the 3rd board-revision.

However! For the second PCB, some other things are planned which do not include the hardware, to pull that off!
However, it has long been a dream for multiple people, hence it might come true once upon in time!
Click to expand...

I'm not sure which revision I'll be receiving....
 
The first Prototype-PCB, because no others have been produced yet.
There are only 20 of these, so you got one of the first 20, out of the very first prototype-batch!
Keep it honored and remember it, when the Chinese sell millions of a copy of it! :P
 
Another use case of MCU would be a filesystem layer.
It would be possible to allow the PS2 side to communicate to the MCU on the device in a contingent fashion instead of calculating offsets based on fragmented blocks, so no defragmentation for Open PS2 Loader would be necessary.
 
  • Like
Reactions: TnA
Takeshi said:
How about connecting the reistor to ground onl if a SD card is inserted? You still have to send data to get the state, but you don't need to read the data.
Click to expand...
I have some vague recollection of trying that, but it didn't work for some reason - made transfers fail or something, (but in an undetectable way, or maybe it was making them hang and not complete) so it wasn't a good way of detecting insertion. Or maybe it will work... I am not sure - if anyone can test that - do so.

Takeshi said:
Either a special PC software is used for copying process or a PS2 software swaps the bytes after the transfer. This will take time, but after that the speed is increased.
Click to expand...
Because the bits in the byte are reversed while waiting for the next SIO2 word to be received, this shouldn't be making the transfer any slower.

Fin9ersMcGee said:
But what are the possibilities of running FMCB from this card? Would be an amazing solution for exploiting and also would be an all in one solution for ps2, a plug and play memory card that also contains content.
Click to expand...
'This card' is at all not a Memory Card - in fact, it could even connect through the controller ports, but we are limited by the transfer speed there. So it is not at all like a PS2 MC.
To support FMCB, it would have to support MagicGate, which is difficult for more reasons than one. I considered this (earlier in the thread) and TnA suggested it long ago, but in the end, it is a very demanding feature.
For the time being, it is important to make the base structure - make it stable and fast, and if later, it turns out that MG on an MCU is feasible/possible at all, that could be considered too.
See uyjulian's post:
uyjulian said:
If MagicGate is to be used on the MCU (example: for usage of FMCB or DVD player), it would require side loading of the MagicGate keys due to them being copyrighted.
Click to expand...

uyjulian said:
Another use case of MCU would be a filesystem layer.
It would be possible to allow the PS2 side to communicate to the MCU on the device in a contingent fashion instead of calculating offsets based on fragmented blocks, so no defragmentation for Open PS2 Loader would be necessary.
Click to expand...
Interesting idea. The trick here is that the MCU will be between two SIO interfaces, with the PS2 being the master, so I think this might reduce the maximum speed, but who knows...
For now, the idea with a simple MCU is that it won't actually be able to change the data at all, and it will only switch the card's /CS, depending on whether the packets coming from SIO2 are for this device or a normal PS2 MC.
But yes, with this simple MCU, it will be possible to have a PS2 MC connected in parallel and use the same slot for both (the MCU will have to switch the PS2 MC's /CS too.

TnA said:
If it is fast enough, it could even do the Byte-switching for us and hence increase performance/bandwidth even more!!!
Click to expand...
Again this is for the case of a bigger MCU, which has the data passing through it. While the case with a small MCU assumes that although it can communicate with the PS2 when the SD card is disabled, it cannot change what the SD card is sending or receiving.
 
wisi said:
I have some vague recollection of trying that, but it didn't work for some reason - made transfers fail or something, (but in an undetectable way, or maybe it was making them hang and not complete) so it wasn't a good way of detecting insertion. Or maybe it will work... I am not sure - if anyone can test that - do so.
Click to expand...
Then I will test it for my own, too. If the test programm works, I see no reason to not inlude it into the hardware. That doesn't force the software to use it, if it creates problems.

wisi said:
Because the bits in the byte are reversed while waiting for the next SIO2 word to be received, this shouldn't be making the transfer any slower.
Click to expand...
Of course, I see ... and between to packages there is enough time for reading the data from SD and manipulate it.
 
  • Like
Reactions: TnA
@wisi @Maximus32
Regarding to the MCU: For privat projects I want to try ST µCs for quite long time. Their design is more modern then most other µC like PIC, they are powerfull and the design is supposed to be the same for every "class", in contrast to PIC for example. Through a research I found out that they are also cheaper. What du you think about the STM32G070CB?
CPU: 64 MHz, 32 Bit
Flash Memory: 128 kB
RAM: 36 kB
Serial connections: 2x SPI (up to 32 MHz), UART
CRC calculation unit
43 GPIOs
Price: ~1,40 €
 
  • Like
Reactions: TnA
You must log in or register to reply here.

Similar threads

Back
Top