What I remember is that the SIO2 interface can be used ot interface with microSD cards, according to
@wisi.
Correct!
However, that will make it incompatible with normal PlayStation 2 memory cards. This is configurable via software.
Hm... I wonder if it could work on a Multitap, but (sadly) I suppose it can't... It would be great to have a device, where both could still be used.
The implementation
@wisi did and @Maximus32 wrote an SD-Driver for however is a DIRECT connection without any extras! No chips, no MCU, no nothing!
Also no kinds of emulations (externally within the device instead of on/in the PS2) like for VMC, MagicGate, Multitap and etc. are possible.
These ARE indeed possible with a bit more sophisticated device! The biggest issue I faced was even predicted by
@wisi! How more sophisticated and complex the HW-structure becomes (like using a RasPi, or ESP) and without a MCU or controller-chip programmed for the task you will run into issues 'answering' fast enough BUT ONLY on power on! The devices need too much time to initially boot up, to emulate an MC (even when MG-emulation were supported) to boot FMCB.
When it already is powered on (external power-supply or even when connected to the PS2's USB), it can work with a RasPi (GPIO) as well! So on a reset, FMCB actually could be loaded from it, like
@Anonamous also had in mind.
We can read the size of the NAND installed. It's how we can support cards larger than 8MB.
I ought to remember that the usefulness and size of those cards is still limited. Well, you probably know that. I am just mentioning it for those who might not know it.
Here some limits which come to mind.
- Filesystem... Was it a (proprietory) variation of 'FAT12' or 'FAT16'?
- Some games just don't work with bigger cards (i.e. because of a too small value used for addressing the sectors, much like the 2TB-issue where it used 31Bit instead of 32Bit for addressing sectors. So... Possibly 16Bit sometimes signed sometimes unsigned to work with cards up to 16MB (15Bit) or 32MB (16Bit)?) or...
- some games work with certain cards up to the point where they are filled or 'behind'/after the normally addressable sectors!
- ...and possibly more...
But today, if we have a choice, we can use USB devices instead.
True, but here are some reasons why I agree that VMC-Emulation (but NOT limited to it, or it would be quite costly 'for the fun') via an external device is indeed an interesting and useful idea:
- No need to care about it being fragmented or not!
- The VMC's could be compressed (well maybe not so much of use nowadays given the amount of space available nowadays, but I thought I'd mention it anyway).
- No extra-code would run!
- The compatibility could be next to or even PERFECT as long as the emulation is done well!
- VMCs can then be used everywhere as they would seem to be normal (P)MCs to any program.
Along these things, it is possible to use the same device to do what @pelvicthrustman created with his custom BT-Dongle for controllers (works for USB and BT as long as the device has such a connection or a connection where it can communicate following that standard).
If you're in favour of a software approach, nobody has taken a look at OPL's VMC functionality since 2010 or something lol
For soooo long?
Well... I think there is still a bit 'room for improvement', but the approach I (and probably
@uyjulian and
@Anonamous as well) meant is rather an external device which has the capability to emulate VMCs which are present as files on a storage-device/medium (SD-Card, USB-Stick, whatever) connected to that 'emulation-device'.
This requires the instructions to be rewritten on-the-fly.
That's only true for those which are not natively supported!
@ffgriever made a 'write-up' (well... The info is rather scattered around in the PS2PSXe-Thread) about it a while ago!
Apparently, you can execute atleast quite some of these without a recompilation/translation (to the target)!
Some of these also need to be 'reworked', but not in the total sense of a recompilation, which are those which have an equivalent call (essentially doing the same work), but which uses another name!
So you will use a binary translator/dynamic recompiler.
That's one way, but you also can strip down the recompiler to only recompile those where it is needed and 'pass' the others.
The 'passing' for supported calls is not just limited to the CPU, but partially others HW-Parts as well thus not only limited to the recompiler... AAAAAND it even yields an interesting effect(!). It sometimes looks better on the emulator in certain games, even without additional filters(!) enabled!
One great example is a kind of hardware-antialiasing-effect on some 3D-Meshes ('bodies') and on T&L (especially light-effects have less jagging, IMO), even tho' there is no code for Anti-aliasing running.
@ffgriever would be a great resource to explain this!
This method (recompiler) is thread-safe (as long as the recompiler itself isn't multi-threaded), but introduces quite some latencies, even on those which could be executed natively.
...and every interrupt causes the rest of the emulation to 'wait', if it were meant to be synced (quite often this is important for emulators and a reason, why they need sooo much processing-power, how more accurate they should emulate a platform)!
An alternative to that is a thing I mentioned regarding N64-Emulation, because I came to the conclusion that only HLE (high level emulation) would be efficiently possible on a PS2 using that approach, while 'killing unnecessary structures' which cause latencies and interrupts, MIGHT make LLE of an N64 possible on a PS2.
I had various ideas regarding this.
One which is a rather easy implementation is, to split the recompiler into an input-layer which tries to natively execute some stuff directly and the other things are sent to a recompiler...
The biggest problem here... You still need to catch (which means they are technically buffered on the RAM, checked by the 'mask' and then either send via a task to the instruction-cache (Warning: There you also have to make sure that cache-coherence isn't affected, or the entire console crashes.) or if it is not natively supported through the Recompiler!
I thought of another approach as well, but I am not sure if the PS2 supports something like 'sigill'! If it does, it is even possible to just send all commands 'blindly' to the CPU (but AFAIK only cached and via a thread/task and not via directly moving it to the instruction-cache) and if an unsupported instruction is detected, this causes the 'mask' to send it through the Recompiler...
Both methods have their advantages and disadvantages... and I have no clue, how it is possible to combine the best of both...
The sigill-method would require it to be at least single- or even double-cached. It is killing some latencies and interrupts as well, essentially making it faster (but...)
The other method could be done via one less caching, thus it has a bit less interrupts there...
Well... That all might be a bit off topic...
Either
@wisi or @Maximus32 (or did someone else tested the 'SD-Gecko'?) mentioned that in either the SD-SIO2-Thread or in the speed-testing-thread or somewhere else!
I am quite sure it was on psx-scene.com ~ beginning of 2018 (or so?!).
Let's hope one of them chimes in and can confirm the speed!
I was thinking to have a microcontroller provide an interface that would present itself as a normal 8Mb
Yes, that IS possible! However, it either needs a specially/specifically programmed MCU or you would need to start the device somehow before the PS2 starts, because every device (even an ESP32 or so) needs a few seconds to boot up (thus they only work properly on rebooting the PS2 or booting the device beforehand).
memory card for storing FreeMCBoot and the like
Yes, that's also possible but needs additional support for MC-Auth and so on...
However... There is yet another issue, which I don't know how to get along with, because the Hardware-ID of the MC is not the same like the MCID/MC-KELF- Signing-ID and we can't read the true HW-ID... Thus, the emulation is currently bound to fail, except if we can re-calculate the Hardware-ID from multiple MC-KELFs bound to the same MC... Btw.: IMO that's also possible, maybe in a similar way how Doormate does it... However...
@krHACKen knows why there is this 20MB-file and essentially this would need another one of these and would need a cross-verification-algo which means for every single key checked, the time to calculate it would grow in square (again PER KEY), essentially leading to quite some time to calculate it...
VMC-Emulation itself? VERY possible!
MG-Emulation (including decryption and possibly encryption)? Hard!
Fortunately, it would be possible to change the Hardware-ID of the emulation-device, thus this would be a great tool to decrypt some stuff like MC-KELFs bound to a specific MemoryCard. We could emulate i.e. a Memor32 with it (and Memento's 'protection' wouldn't notice the difference), lol...
and then having the rest of the space available by specific command issued by OPL, ule, freemcFree, etc.
That's a possibility but would require specific software-support for it...
This is also possible, if you have some kind of 'interaction' available on the device itself (Buttons, or whatever)!
Having both would be neat (and possible), tho'!
Would likely use an avr as they are cheap and easy to use.
Yes, that could possibly be used.
I am using these for my tests:
- RasPi
- SHA 2017+ (ESP32-Badge with a small ink-display)
- An 'El-Cheapo' (not its actual name. . Just a cheap adapter) USB-TT(Y)L/UART-Serial-adapter
The main issue I see at the moment is clock speed and instruction time.
Exactly! + the initial bootup-time of the device!
It would come down to hold long of a delay the PS2 will accept before receiving a response.
Yerp... More info on that on the SD-SIO2-Thread and on the BT-Adapter-Thread!
http://psx-scene.com/forums/f19/sd-card-sio2-driver-157485/
http://psx-scene.com/forums/f19/how...3-ps4-controllers-wirelessly-your-ps2-127728/
The other problem, or at least uncertainty is as follows. [User]@uyjulian [/user] did you mean an SD card or an actual emmc chip? The emmc chips I found are mostly bga and have a capacity of 4Gb or larger. The main issue with this is it makes it difficult for prototyping and may make it more difficult to manufacture.
To be honest, that's one of the main-reasons why my idea doesn't use a big internal memory, but only a small MCU (to circumventtthe need for pre-booting the device or rebooting the PS2) and a bit memory (for a 'firmware') and the rest is provided via external means, being it an SD-Card or a USB-(Storage)Device!
In a nutshell it would be a device with two partitions.
I ought to say that IMO it would be cheaper and better to split it into 2 physical storage-devices... One small internal Memory and one for the files which are meant to be stored and/or accessed (i.e. VMC)!
The smaller memory could also hold the KELF for a fast delivery, once MG-Emulation would work!
One of the standard mc format with 8Mb and than another with the rest if the space that can be utilized via the ps2sdk.
The overall ideas are good IMO, but I have to point out that pretty much everything of this could also be done with external storage-device ls which could possibly be plugged into the device, thus neither limiting the size of the storage, nor would it cost so much in production (it even gets down to the point, where some people could build their own) AND if the adapter supports a kind of pass-through-mode, it could access the SD-Card via wisi's method still, making it perfect to play from it (via OPL)!
Edit: After doing a bit more research, it may be more logical to use a nand flash chip instead and have a USB interface in the back to make it easier to put files on via computer.
I would rather make the storage removable from the device!!!
either SD card or eMMC works fine.
The more components you put, the more the cost increases.
Correct!
Last but not least: I certainly wrote about this idea on psx-scene.com or so (~3/4 or 1 year ago)! I think it was in the SD SIO2-Thread and maybe even a seperate thread as well and yes I am still working on it once in a while but am just too busy (sadly).
Where is the living search-engine when you need them?
@jolek (who curiously finds almost all/everything, lol)
Edit: Ahaaaaa! Found it!
http://psx-scene.com/forums/f19/sd-card-ps2-memorycard-adapter-implementation-157491/
Please read it! It's only 1 page and holds some valuable information, like the following link!
http://psx-scene.com/forums/f19/ps2-memory-card-infos-spi-bus-commands-format-120052/
