PlayStation 2: Are There Any Hardware Mysteries Left?

This is actually really interesting, do you have a source for this by chance? I guess I have never seen an FPGA based one, since even the early NEWS based H500s or whatever were apparently already R3000 based. Was Sony's approach at the time to do an intermediate RTL design first the then go to fab?

 

I don't think that it's the same thing though. The PlayStation 3's PlayStation 2 BOOT ROM does not have the DECKARD emulator, so they would have likely written a different emulator. This PPC IOP also has most of the peripherals that the original IOP had, so DECKARD is just an emulator for the MIPS core.
It is still possible that they might have reused the code though.

Perhaps I am wrong, but I always thought that PlayStation emulation on the PlayStation 3, is done through the PlayStation 2 emulator.

Someone should really design a new device that interfaces with the PIO interface.

It's just not like PlayStation 2 mode, whereby the low-level device drivers can be replaced.
In PlayStation mode, the game runs on the IOP and the game controls the hardware directly.

If that is somehow done, I guess that it would end up being like the PSIO project.

In what way are they more detailed? Have you seen information in them, that is not available in the PDFs that come on those discs?

 

LSI didn't have an FPGA, you simulate your design on a computer and then have ASIC's baked by LSI. I don't have the sources available to hand, but it was mostly from press LSI releases circa 1994 and comparing datasheets plus some inside info.

I haven't seen an H500 motherboard unfortunately, but I doubt that it used an actual R3000 either. Sony always tried to keep the exact details secret, as they wanted you to use their libraries and their R3000 compiler as they could then change things without compatibility issues. So it makes sense to just call it an R3000.

They implemented register compatible versions of all the MIPS IOP hardware in the PPC IOP?

It is completely separate. IIRC The BIOS on the PS3 is the same as the PS1 BIOS, except they patched out the boot logo.

Searching through RAM for the SDK and then patching it would probably not be that hard. If the hardware isn't available in PS1 mode then it may be possible to run in IOP mode, with the rest of the system in PS1 mode (graphics/sound etc). Similar to how Nintendont runs gamecube games in Wii mode on the Wii/Wii U, loading off USB and using USB/Bluetooth controllers. Streaming audio would be difficult, as I don't know if you can load red book audio into ram and get SPU to play it unless it comes from CD.

 

Unfortunately, (for the PS2) on the Wii you have a isolated sub CPU (ARM core) running a program(IOS) which the game is not aware of it's existence. On the PS2 the game actually runs code on the IOP, which make things a tad more complicated. Because of that the IOP has the actual PS2 specific features hardware-disabled when put on PS1 mode... I'd bet it's a sort of a single toggle which you set on or off and you get or not PS2 features. Even the memory map changes when the IOP is put on PS1 mode...

 

Interesting, do you know what their iteration cycle was like? My limited experience with HDL and RTL has been in an era where FPGAs were plentiful and cheap so we always tested that way.

Reading the SCE developer portal BBS dumps and some various threads around the internet has lead me to believe that the H500 was heavily based on the R3000 NEWS system, which would have made sense at the time. Information is a bit scarce on those as well but it might be worth it to pick one up for a teardown at some point. Some of the mysteries of the H1000 BIOS would probably make a lot more sense in the context of that hardware.

 

As all hardware access is supposed to go through the SDK, so even if you need to patch every hardware access then it should be relatively doable. Much more so than the xbox1, where they seemingly put out monthly xbox SDK's that were randomized and obsfucated to make it difficult to do this.

The only two things that could be a problem is if switching to IOP mode disables GTE or stops the GPU emulation from working.

I don't & I don't know much about their process. Simple gate arrays just have one layer which is configurable, so you can turn that round quite quickly. The decap however doesn't look very structured at all, so the chips may be completely custom.

I would love to have an H500 to reverse engineer, but they don't appear very often. The NEWS workstations seem to come up less The case looks the same, other than that it's just speculation. If it had a GTE then it would be completely different, which is possible. I haven't seen a GPU decap and none of the information I have found so far has mentioned it. The GPU did go through a number of revisions that are incompatible with each other, one of them ended up in some arcade games.

Mysteries?

 

~

 

@wisi was the one who looked into DECKARD. He wrote that the peripheral registers are there.

Coincidentally, the IBM PPC 405GP seems to have the same EMAC3 as the IOP. That was where I got the documentation for controlling the SMAP's EMAC3 from.

It wouldn't work well if code self-modifies itself (i.e. in the case of packed executables) or if it boots other programs.
Given that the IOP is reset into PlayStation mode and the PlayStation ROM boots the game directly on its own, the EE (which is the only processor that can have modified code loaded from) will have no way to determine when a new program is loaded.

Something like PSIO would probably work better here, as it can intercept reads and writes to the CD-ROM registers without needing to ensure that all reads/writes to the CD-ROM registers within the game's code are identified.
Not to mention that having the extra code stored elsewhere, will prevent memory problems (i.e. lack of RAM, or RAM conflict).

 

The PlayStation kernel gets copied into RAM at startup because ROM is slow. The first consoles had a 16bit rom, so each access took 2 cycles. Later on they switched to 8 bit roms, which take 4 cycles. The later versions of the SDK patch the kernel when the game starts. So assuming the EE can access the IOP ram then it could wait for it to be copied into RAM and then patch it. I thought there was a PS1 homebrew loader for the PS2 that did something like that, but I can't find it. Alternatively you could hack the kernel and run it in IOP mode.

Fitting a USB stack into RAM at the same time however may be a problem. You may have to ditch the USB discovery code after mounting the ISO, it's not like you would support hot swapping of drives at run time.

I don't know how common self modifying code was, anything doing it safely would call the cache clear function.

I see in the shoutbox that you're doing some reverse engineering on ps1drv, that would be interesting to see. If you need any help then I have quite a bit of PS1 background.

 

The problem is that it has no idea what the IOP is doing.

Do you know what it's called? I have not heard of such a thing.
If you're referring to PSXLauncher, then that isn't a homebrew software loader.

I haven't checked if it really does this yet, but it seems like a hard reset will occur and the IOP will reboot from the reset vector (0xBFC00000). I think that it works that way because that seems to be the only way for TBIN (the PlayStation ROM monitor) to get run by the IOP, once the PRId changes.

Thanks. Right now, I haven't actually hit the GPU emulation routines yet, hence why I haven't shown anything.

 

EE can access IOP ram, so it can just poll waiting for the kernel to start copying and then overwrite it. You should have enough time to notice the beginning of it being written and then overwrite the beginning with a small synchronising stub, the IOP will keep copying the kernel into ram and then jump to it. But it will jump to your code, not the rom. You then have time to do whatever you want with IOP ram, uploading exe's or another kernel. The synchronising code should be small enough to fit in the cache, so you can even overwrite it. After EE signals to start then the IOP will need to clear the instruction cache, it might need some register manipulation to make it jump back to the kernel start but that should be relatively easy.

No I don't unfortunately and I've tried to find it, but haven't come up with anything. I might be dreaming or it might not have been publicly released.

Yeah, the simplest way would be to reset the IOP when switching to PS1 mode. How that happens (and it might be different for different hardware versions) is another matter. The simplest is an IO pin from the EE that controls the IOP reset line., but simplest isn't always the way hardware is actually implemented.

 

I think someone here mentioned that on the PS1 mode the PS2 emulates the GTE using one of the EE vector units? So the IOP has no real GTE in it...

MDEC likely is emulated in a similar way using EE IPU hardware...

 

I'd like to know more about the OSD ELF file (Which seems like it may be similar to what VSHMAIN on the PSP was?)

 

This change to pcsx2 makes me think that GTE in IOP is real, I'm not sure how well you could hook up a coprocessor interface to a CPU anyway.

https://github.com/PCSX2/pcsx2/commit/09817b24f0d5b04c83d1f44aa95f0c4cac37f2eb

MDEC certainly could be done by EE, GPU is and both of them have bidirectional dma.

 

It's possible that GTE exists. Considering that IOP on everything lower than 7500x were still being made at LSI Logic...

But I wonder, is it accessible while on PS2 mode?

 

I don't see why they would go to the hassle of locking it out. It might need to be enabled in cop0 though.

 

The test runs in PS2 mode so yes, it is available there.

More information here:
https://github.com/unknownbrackets/ps2autotests/issues/30

 

@rama
Was the PS1 GTE test done on a pre- SCHP-75000 or on a later model?

@all
Regarding the IOP emulator and the IOP's PS1 mode:

The first task was to prove that the DECKARD file is at all used (read from the BOOT ROM). Initially, I too looked for DECKARD in the PS3's PS2 and PS1 emulators, but didn't found anything to suggest a connection. On the PS3, the PS2 emulator uses a TOOL's PS2 BOOT ROM image, while the PS1 emulator uses image from a US CEX PS2 (if I remember correctly). Both successfully load games in pcsx2.
Because at that time I had just finished my HDpro clone (http://psx-scene.com/forums/f98/hdpro-clone-132869/), I could use the CPLD connected to my PSTwo to detect reads from the area of memory in the BOOT ROM, where DECKARD is stored. This, however, didn't show any accesses to the DECKARD file. So while I was trying to think of another way to determine whether the file is read, I started measuring some unknown pads of either a missing IC or a connector on the PCB (at that time I thought that it was meant to be an IC, but later it turned-out to be for a connector). It was then, that I noticed (on the oscilloscope) that something was being output on one of its lines, fairly slowly, and only on boot-up. It turned-out that it was s serial port, and by the logic levels (3.6V) it seemed to come from the IOP. After connecting it to a PC, I saw a single line of text printed in the terminal program ... involving the string "D E C K A R D"! So it did run on the PSTwo after all.
So, why then a read of the file from the BOOT ROM was never detected? It turns-out that the ROM of the later versions has not one, not two, but three chip select signals! The third one, being exclusively for booting DECKARD. It is possible that both this and the /CS of the BOOT ROM access the same memory, although it is also possible that they access separate memory areas of the BOOT ROM, both of which contain the same data (tested).
Later I found-out, that the new SSBUSC device, through which DECKARD is loaded from the ROM, is configured exactly the same way, as the other (old) SSBUSC devices (its SSBUSC registers are the same). I named this line /CSunk13, because while exploring the test points, this was the 13-th unknown line to number, and it looked like a /CS line. Coincidentally, later it turned-out that this is actually the 13-th device (configured through the SSBUSC registers) Dev#13 with /CS13!
In fact most of the PPC IOP peripheral hardware is (as far as I checked), the same as the one of the original IOP. There are some minor changes. The SSBUSC and some other devices are exactly the same. Even the SMAP/SPEED has the same registers - only a few are either missing or were changed (and are emulated). The reason the SPEED is not accessible at its old location, from EE side, is that it is shifted higher in memory. It should be accessible at its new location from EE side (if the missing registers are handled properly).
I fact the peripherals are so much alike, that even the SIF/SBUS works the same way, and can access all IOP memory: "all" meaning - the whole emulated IOP and PPC IOP RAM, and all its devices. The PPC IOP is (should be) stopped (much like the original IOP), while EE is accessing its memory. This enables patching DECKARD while it is running (tested). EE access to IOP memory, basically grants full control to EE over the system bus of the IOP (basically the EE "goes in the place" of the IOP).
There are some new peripherals - like the PPC IOP serial port, which is from a PPC.
Not many of the peripheral hardware registers are emulated, even though there is a huge (a whole 512kB of the 2MB RAM for DECKARD) look-up table of routines in RAM for the device memory range. These tables don't do much and it might be possible to be optimized to branch instructions, freeing almost 512Kb of RAM to the IOP! It is a very useful area for test code because, as long as the test code is in an unused address range in the LUT, nothing will crash, and to jump to the code, all that is necessary is to write its start address to some location in the LUT and then access the address mapped to that location from the emulated IOP.
The PPC IOP is most similar to the PPC440. I couldn't find any PPC, the version number of which to resemble that of the PPC IOP.
The PPC has big-endian byte ordering.

One of the faults of the emulator, is that it actually doesn't emulate all IOP registers - accessing the register for configuring IOP RAM, for example, causes DECKARD to crash, as this memory area is not mapped through the TLB. This register should be functional on all original IOP (and PS1 CPU) models.

Some registers are 'partially' emulated - for example the SSBUSC registers. Only some of their bit-fields can be modified from the emulated IOP, while the rest are kept at a hard-coded state by the emulator.

Many IOP (peripherals') registers are derived from the PS1 CPU and have mostly the same functions. See http://problemkaputt.de/psx-spx.htm for more info.

One of the possible reasons for DECKARD's existence is the great amount of logic circuitry that may have been necessary to make the IOP both PS2 and PS1 compatible.


When talking about the EE<->IOP connection, one must always consider the SIF/SBUS. It is a combination of several interfaces:
- EE access to (any - including PPC) IOP's entire memory. (as if the EE is in the place of the IOP) At that time IOP is stopped. The complete bus cycle takes longer than doing the same access from the IOP (it also 'slows down' the EE because it needs to wait for the access to end, before it can execute more instructions). It is unknown (yet) if this works in PS1 mode or not.
- The DMA channels of the SIF (PS2-mode-only).
- Control interface (PS2-mode-only) - several registers that control the SIF/SBUS. Most of them can be accessed from both EE and IOP (with some limitations). There are bit-fields for resetting IOP (on EE side) here and bits for checking the mode of the IOP (IOP/PS1) (on IOP side). The bit controls the IOP reset line directly.
- Interface for emulating the PS1 GPU. It is separate from the SIF DMA channels (on both EE and IOP side), though it might use the same hardware and buffers. It it unknown if it works in PS2 mode, but most likely it does not.
- Interrupts between the EE and the IOP.
Some IOP modules check if the IOP mode is PS1 and refuse to load if it is (SIFMAN).
Switching the IOP to PS1 mode is done through a register from EE side. A bit is set, which directly drives a line which has the purpose of resetting the IOP into PS1 mode.
Then the IOP boots RESET from the BOOT ROM and depending on the bit, which gets set by resetting it into PS1 mode (bit 3 on 0x1F801450) boots either IOPBOOT for PS2 mode or TBIN for PS1 mode. If a DIP switch, bit 6 (at 0x1F803100) is low, IOPBOOT is loaded even in PS1 too.

As far as I know, there is no way to reset the IOP back into PS2 mode, after once it is in PS1 mode, other than with warm/cold hardware reset.

 

I don't know. I didn't do the testing. If you need to know this, I can do this next weekend. I've got a couple different PS2 revisions.

This was long ago but I believe in PCSX2 we call this SIF2 and (here my memory goes fuzzy) one game uses this channel to stream audio to the EE for signal analysis. It does a visual equalizer display with the data.

Maybe I remember it wrong but this game/scene is definitely tricky for emulators.

Also the homebrew "SMS" (simple media station) uses SIF2 to stream data.
If you need me to verify this, I'll add it to the list to do on the weekend

 

From what I uncovered, from measuring on the actual hardware (GH-006), the SBUS (the bus between the EE and the IOP) is (very) different between PS1 and PS2 mode. In PS2 mode the SIF0 & SIF1 DMA channels are used for "normal" communication, while SIF2 is for debugging (AFAIK). In PS2 mode, for EE access to IOP memory, the SBUS is mastered by the IOP, until the EE takes control. A dedicated clock line (EE->IOP) is used.
On the other hand, in PS1 mode, the SBUS is much like the System bus in the PS1 (between the CPU and the GPU). A different clock line is used (IOP->EE) and it is always mastered by the IOP (EE access to IOP RAM may even not be possible - untested). The signal lines' functions are different, the IOP SIF DMA channels (and their EE counterparts) are nonfunctional, and only(?) access to the PS1 GPU registers from IOP side results in SBUS activity.
So the SIF2 (DMA) registers are almost certainly not used from neither IOP nor EE side for PS1 GPU emulation, even if some part of the actual hardware processing the transfers might be shared.