PS2 HDD for PS2 SCPH75000x & later models

[Vanja_Mileshovskyj]

@iCEQB


I see you have saved some attachments from that branch on psx-scene, I read it in the archive, but did you have a diagram of this device, I downloaded the archive you attached, but there is only the software part, I download the entire archive with attachments from psx-scene, but the download speed is too slow and I don't know if I'll download it today

 

[iCEQB]

If I remember correctly, there was no diagram...

 

[Vanja_Mileshovskyj]

@iCEQB
@wisi said that it was, I'll look in the archive when I download and unpack it, it will be sad if it is not there

 

[wisi]

Do you have any plans to pick this up again? Maybe after MX4SIO
I realy love this project and I still put a lot of hope into it.

Not really. I think I did most I could. Maybe I could consider it, if somebody else could manufacture the hardware. But still I don't think there is much for me to do. I really don't like 'completing' projects, as that takes a lot of effort (a lot more than I have put in so far, which wasn't little already).

For dev8 mode, I did not find the CSEX signal, which I wanted to use instead of CS9, but in general what is this signal for?

The EXTR /CS signal is called /EXTR. The device is named "EXTRA". It is for connecting the PIF/MRP on the PS2 TOOL, while on CEX PS2 it is unused.

To use a different SSBUSC channel for a device, you have to:
- make sure the device that is already using it, won't use it - for Dev5 this can be done through the line that disables it.
- make sure that no code from PS2 (IOP and EE) side does not access it - this requires knowing what is running on the PS2 and what programs usually do (usually only IOP drivers access IOP devices, but there are exceptions). Also this can be solved by making your device not respond or respond correctly to such accesses that are not targeted to it.
- set the desired SSBUSC channel configuration for your new device through the corresponding registers. Also redirect the accesses there and/or set the desired mapping (if possible - some channels don't support some address ranges).

Attached is a document on the SSBUSC and its regs. As well as the docs from this thread: https://ia802907.us.archive.org/11/items/psx-scene-processed-archive/part0292.html#T156928P1


The HDpro (PS2MADD) internal schematic is attached. I thought of later rewriting it in Verilog, but never got to doing so I think.

 

[Vanja_Mileshovskyj]

@wisi thanks for the photos and the diagram, but your version does not suit me, I don't understand just your diagram, I'm used to a slightly different display (such as in the service manual) but for the description of dev9 and ssbus I am very grateful and grateful to you, I will try follow the address reassignment method.

Maybe I could consider it, if somebody else could manufacture the hardware

what do you mean by manufacturing equipment? making hardware or software, or both?

 

[wisi]

@wisi thanks for the photos and the diagram, but your version does not suit me, I don't understand just your diagram, I'm used to a slightly different display (such as in the service manual) but for the description of dev9 and ssbus I am very grateful and grateful to you, I will try follow the address reassignment method.

It is not really applicable in your case, unless you are making an HDpro clone. It is of the internal CPLD logic and not of the actual connections.

what do you mean by manufacturing equipment? making hardware or software, or both?

Making the hardware.

 

[Vanja_Mileshovskyj]

Making the hardware.

In my opinion, making the hardware is much easier than writing software code. When there is a code and firmware for a controller (or PLD), it is already easy to develop a board for it, and even though you can make it yourself manually using varnish, textolite and ferric chloride, and now there is a DIY printer that will draw all the tracks themselves (though you have to draw the board in AutoCad),
flash the controller (or PLD) using the programmer or using the ISP directly on the board, unsolder all the components, check everything, configure (if necessary, correct mistakes), turn on and get good pleasure from the fact that something you did with your own hands works, it brings good pleasure, and also makes you move forward and try something else. It is very cool

 

[wisi]

Not everybody can make their own PCB or order one. So the solution would be for somebody to make(assemble) and sell them, which is something I can't do. This is what I meant.

Also when trying to make a, more or less, finished device, there are many small bugs and incompatibilities which have to be fixed, also support has to be offered to the users, which again is something I can't really do. Even though the hardware and software was working, it was sometimes crashing and there were some things about it that were unnatural and the causes for them had to be determined and fixed if necessary - like the longer delays needed on initialization.

@sp193 Is there any way (email/PM) I can contact you by?

 

[Vanja_Mileshovskyj]

@wisi, now I understand you.
[email protected] here is the mail @sp193

 

[sp193]

Since the SSBUS can be configured via the SSBUSC service (ssbusc.h), the SSBUS itself seems to be quite flexible. For example, you can configure the access mode, strobe signals, memory window size and so on.
On various non-standard PS2s like arcade boards, the DEV9 device is occasionally replaced with something else.

@sp193 Is there any way (email/PM) I can contact you by?

It's embarrassing to say, but you already know how to contact me. The channels do work, but the problem is that I became a full-time developer for a company since 2019. Although it might seem difficult to believe in some parts of the globe, I tend to have very heavy overtime. So it's just difficult to find it within me to spend another hour writing e-mails.

I wanted to disappear from PS2 development.
Of course, it's always a part of me and I understand what it's like to struggle with this primitive console alone - so I do occasionally pop by to help, but my replies tend to be slow and spaced out.

But thanks for sharing the things you have discovered.

 

[Vanja_Mileshovskyj]

@ sp193 I apologize for giving your email without your knowledge, although your email is easy to find on your website, I found you pretty quickly. By the way, engineers almost everywhere in factories work overtime, sometimes they even come home for them. I did not find any non-standard PS2 consoles, but I had another thought, perhaps there is a ready-made controller for Ide, and if you use the via6421 controller (or another), this is a pc controller, a pci-pata & sata converter, but it will have to be connected directly to the processor, so as an input he has AD, not SA or SD. But I'm not sure that this will work, and I don't know if it will be possible to control it, but a ROM is connected to the controller, which configures the controller's operation
what is DECKARD and can you provide me with information on it?
@wisi https://ru.scribd.com/document/374688144/PS2-EE-SIO-Info
what is the documentation?

 

[wisi]

The IOP SSBUS is a bit like ISA bus. But actually it is a mostly a standard (if there is any standard about those things ) microprocessor peripheral bus. So you can connect different devices to it, as long as they meet the timing and signal levels requirements. Of course it may need to be buffered if more than one additional device is connected. So yes, you can connect a compatible PATA/SATA controller, but you would also have to write a driver for it. The HDD registers access is usually the same on all controllers, but the DMA and other configuration stuff are different. Which is why using a CPLD with minimal logic also works. Of course maximum DMA speeds can't be reached with a small CPLD, due to the lack of an internal FIFO. To solve this a bigger CPLD/FPGA has to be used or a dedicated ATA controller. But there is a chance that you might not find a controller that would work with the SSBUS directly, so you may need a CPLD to interface them anyway, which is why using an ATA controller only makes sense, if you can find a suitable one.

what is DECKARD and can you provide me with information on it?

This is the old thread on DECKARD: https://ia802907.us.archive.org/11/items/psx-scene-processed-archive/part0293.html#T157416P1
It is a partial emulator of the MIPS-IOP on SCPH-75000 and later models.
It emulates the loads and stores by code, while the actual MIPS core instructions are emulated by a MIPS APU to the PPC-core CPU, which replaced the original IOP MIPS core.
It's code can be easily patched from the EE, so it can be used to add virtual IOP devices, without mostly any effect on the IOP operation.

@wisi https://ru.scribd.com/document/374688144/PS2-EE-SIO-Info
what is the documentation?

This is some old info I wrote about the EE SIO (UART) port. It is commonly used for debugging the EE.
(I attached the file, because I, like many others, who don't have registration there, can't view scribd.com documents.)

 

[Vanja_Mileshovskyj]

@wisi
adding virtual devices to the IOP sounds pretty interesting. I read a little from that thread that you threw, you created experimental code for loading IRX modules (actually PRX PPC Relocatable eXecutable) on PPC along with DECKARD, I hope this code is not lost and research on DECKARD is still ongoing. I know that I am too intrusive and ask a lot, I ask you to forgive me for my curiosity, but I am not yet sure of the connection method - hardwired using a network adapter and reassigning strobe signals, or the second - software using DECKARD and CPLD (most likely not he namely, but some kind of controller with a driver embedded in it).
I want to collect as much information as possible, translate it and then do something. In general, initially when I was not familiar with this console (in the fall of 2011), I had a desire to install Windows on it (use it as a normal PC), then I found out in the VK group that this is impossible, but I found out about sms, file browser, FMCBOOT and other programs, then I was also a green noob, as now here. but after a short period of time I made a detailed instruction for those who do not understand beginners at all how to install a file browser on a memory card, I also made a description of how to set up Free mc Boot Configurator.
It was just that adequate instructions did not come across to me in Russian, from that moment people wrote to me with letters to help me install a file browser or Free mc Boot on a memory card, well, as an example, I gave them a link to the instructions I wrote earlier, since the console I did not turn it on from 20015 to 2019, both slims I had were lying around in the attic.

 

[wisi]

I hope this code is not lost and research on DECKARD is still ongoing.

The code was attached to the thread ... I see the attachment got lost... I haven't worked on it since then.
It is now attached to this post.
dpLibMod/ppc-iop_patch/src/dp_drv.c still contains the ATA 'emulation' code for making the CPLD look like the SPEED ATA Controller (same code is in the attachment from the HDpro clone thread).

Original release text:

Attached is an experimental code for loading IRX (actually PRX PPC Relocatable eXecutable) modules on the PPC alongside with DECKARD.

For the PPC-side modified versions of SYSMEM and LOADCORE from pcsx2 Fps2Bios are used. They handle loading PRX modules and linking imports to exports.

The code also includes a very small "library" of functions and hooks to DECKARD functions to make coding easier.

A MIPS-IOP <-> PPC-IOP communication virtual interface is included. It runs over a pair of unused registers and enables each side calling functions on the other, along with passing arguments and returning a result (or a structure of data). Because (MIPS-)IOP RAM is accessible from the PPC-IOP at the same offset (0x000000) "both" can access structures in it and pass data this way (the code on the PPC-IOP has to make sure to mask the segment).

Code on the PPC can access peripheral devices registers the same way code on the virtual IOP would (with the emulation provided by DECKARD) through the use of provided load/store functions.

Makefiles and linker scripts are included, which can build ELF PSX (static - at fixed address, but with imports and exports) and PRX binaries for the PPC.

Example modules are included - the most complete of which is a modified version of the (old now) USBD module, that has several of its functions ported to PPC-side. This however led to no change in transfer speed as the chosen functions are neither called that often, nor so processing-intense to make a difference.

It is structured, so that its PPC-counterpart PRX is loaded as data in the IRX. From there, it is loaded to PPC-RAM. There is a bug that prevents modules with symbols stripped from being loaded correctly, so they currently consume a lot of RAM.

The code is neither complete nor bug-free.

Although I am doubting more and more whether this would actually be of much use for making IOP modules run faster, if not that, then at least the property of this code to load multiple modules on the PPC may be useful.

I know that I am too intrusive and ask a lot, I ask you to forgive me for my curiosity, but I am not yet sure of the connection method - hardwired using a network adapter and reassigning strobe signals, or the second - software using DECKARD and CPLD (most likely not he namely, but some kind of controller with a driver embedded in it).

You will still need some software emulation in DECKARD for remapping of memory ranges, interrupts and DMA, even if you use an original NetworkAdapter connected directly (without Dev9C) to the SSBUS. Of course that can also be done in a normal IOP IRX driver or even on EE side, but the emulation can make it appear to other PS2 software as a native HDD on a fat PS2 model.

And don't worry about it. I am happy when people ask about those things.

I started back in 2008, knowing next to nothing too. And being interested in PS2Linux, after 'installing' most of the available homebrew software. But more significant things I made, did not come until 2014.

 

[Vanja_Mileshovskyj]

@wisi
when your hard drive was connected via CPLD, then in CPLD you changed the firmware (did you erase hdpro's firmware and flash your own?) and did the modchip also have an upgraded firmware? After all, hdpro uses a modified firmware as far as I know (from information on the Internet)

 

[wisi]

No I use my own CPLD with my own "firmware" = logic configuration. The logic config is this schematic I uploaded above: https://www.psx-place.com/attachments/main_circuit-jpg.27304/
If you program the same CPLD with the same logic and connect it the same way and use the same software it should work. (Just saying this as an explanation.)
I never had HDpro, which is why I started making a clone in the first place. If I had it, I would never have made this.


EDIT:
I now noticed that the above is the old PIO-only schematic. Attached is the DMA one and with some more messy ATAD code.

 

[Vanja_Mileshovskyj]

@wisi how can I open a ready-made elf file to view its contents (in the Windows operating system), for example, I want to open uLaunch.elf. I want to try to edit it, I think this is the simplest and most suitable program for experiments

 

[wisi]

Hmm... this is an odd question.
ELF is similar to a Windows EXE, so you can't just open and edit it - for the PS2, it is MIPS code + data.
You can open it with a disassembler such as IDA Pro or Ghidra, but that is usually only done to know what and where is inside, while modification in such cases is done by patching it and 'injecting' (loading side-by-side usually and linking to it) your own code.
But you don't need to do this for programs like uLE, the source code is available of. You just get the source code and install the PS2 homebrew toolchain and compile it and test it. Then edit anything and compile again and so on, until you get what you want.

Usually when dealing with IOP drivers, you can only compile the driver and test it separately. The loading can be done using ps2link (and ps2client or Xlink on PC) over network. Most of the debugging is usually done with printf() (there are the RDB Startup Card and Kermit, but usually ps2link + printf() is enough in many cases).

I don't know if I can help you though if you don't have experience with coding in C...

 

[Vanja_Mileshovskyj]

@wisi
And where can I find the uLE source code? Yes, you can hardly help me with programming, I have to figure it out myself.

 

[krHACKen]

https://github.com/ps2homebrew/wLaunchELF