PS2's builtin PS1 functions: documentation?

For the most part it is hardware virtualization (the original IOP was deliberately chosen to be compatible with the PS1's processor, and while still disputed, the theory that the new generation "Deckard" IOP still contains a MIPS core has been catching on; the EE and GS emulate the PS1 GPU more or less accurately depending on whether you select PS1 or PS2 style rendering in the console's settings, which by the way doesn't carry across a reset, same for unlocking full PS2 optical drive speed)

It is also believed that, like the various PS1/PS2 modes of a PS3, there some preprogrammed "config" patches, with some consoles (all 3xxxx models and more) supporting loading more from memory card (which was abused for the Independence Exploit)
 
Last edited:
Ryccardo said:
It is also believed that, like the various PS1/PS2 modes of a PS3, there some preprogrammed "config" patches, with some consoles (all 3xxxx models and more) supporting loading more from memory card (which was abused for the Independence Exploit)
Click to expand...
wait so do the patches affect the PS1 emulation IOP or something else?
 
Pre- SCPH-75000 (non-PPC-IOP) models emulate the PS1GPU interface using a dedicated the PGIF interface (PS GPU InterFace), while SCPH-75000 and later use the SIF interface a misuse some other registers to emulate the interface.
http://psx-scene.com/forums/f19/deckard-ppc-iop-discussion-157416/index2.html#post1216607 There appears to be a MIPS core APU, connected to the PPC, that gets sent (or pointed-to maybe - I didn't determine that) the instructions to execute. DECKARD also includes settings for some particular games.

http://psx-scene.com/forums/f167/speed-iop-dma-relaying-156928/index2.html#post1219636
The differences between PS2 and PS1 mode are noteworthy. Initially I assumed that most functionality of devices is the same in both modes, but tests showed that PS2 functions get disabled for most devices in PS1 mode. The switching between modes seem to can only be done in the direction PS2 -> PS1 mode and is done through a dedicated reset line, while the switch to PS2 mode again can only be done through another reset line on a full PS2 reset. One of the few exceptions is the SIO2(SIO0) interface, as it is switched using a dedicated register (AFAIR). So all-in-all, PS1 mode is not particularly useful, as most of the PS2 functions are lost, so a PS1 emulator is the way to go if PS2 specific features are needed. Although I am not sure, I think the MDEC and the IOP GTE might be available in both PS1 and PS2 modes.

The PCSX2 emulation of PS1 mode is mostly complete, but not bug-free, so it only works correctly with some PS1 games.
The EE only switches its SIF/SBUS device between PS1 (PGIF) and PS2 (SIF) mode (only on non-PPC-IOP models) and that can be controlled again with the SIF registers, without a need to reset the EE.

I have a speculation that the SBUS becomes exactly like the PS1 main bus (CPU<->GPU) when in PS1 mode, so it might even be possible to substitute the EE or IOP with a PS1 GPU or CPU, as most of the SBUS signals change altogether and seem to closely resemble the PS1 main bus signals.
The switching to PS1 mode (the dedicated reset line) is controlled through the EE SIF/SBUS registers.
 
wisi said:
Pre- SCPH-75000 (non-PPC-IOP) models emulate the PS1GPU interface using a dedicated the PGIF interface (PS GPU InterFace), while SCPH-75000 and later use the SIF interface a misuse some other registers to emulate the interface.
http://psx-scene.com/forums/f19/deckard-ppc-iop-discussion-157416/index2.html#post1216607 There appears to be a MIPS core APU, connected to the PPC, that gets sent (or pointed-to maybe - I didn't determine that) the instructions to execute. DECKARD also includes settings for some particular games.

http://psx-scene.com/forums/f167/speed-iop-dma-relaying-156928/index2.html#post1219636
The differences between PS2 and PS1 mode are noteworthy. Initially I assumed that most functionality of devices is the same in both modes, but tests showed that PS2 functions get disabled for most devices in PS1 mode. The switching between modes seem to can only be done in the direction PS2 -> PS1 mode and is done through a dedicated reset line, while the switch to PS2 mode again can only be done through another reset line on a full PS2 reset. One of the few exceptions is the SIO2(SIO0) interface, as it is switched using a dedicated register (AFAIR). So all-in-all, PS1 mode is not particularly useful, as most of the PS2 functions are lost, so a PS1 emulator is the way to go if PS2 specific features are needed. Although I am not sure, I think the MDEC and the IOP GTE might be available in both PS1 and PS2 modes.

The PCSX2 emulation of PS1 mode is mostly complete, but not bug-free, so it only works correctly with some PS1 games.
The EE only switches its SIF/SBUS device between PS1 (PGIF) and PS2 (SIF) mode (only on non-PPC-IOP models) and that can be controlled again with the SIF registers, without a need to reset the EE.

I have a speculation that the SBUS becomes exactly like the PS1 main bus (CPU<->GPU) when in PS1 mode, so it might even be possible to substitute the EE or IOP with a PS1 GPU or CPU, as most of the SBUS signals change altogether and seem to closely resemble the PS1 main bus signals.
The switching to PS1 mode (the dedicated reset line) is controlled through the EE SIF/SBUS registers.
Click to expand...
This is precisely what I needed, thank you! It looks like there are a few holes I may be able to poke at.
 
I don't understand what you are trying to do (or discover / check-for).
The PS2 (and the PS1 also AFAIK) has only a few specific types of discs it allows, and anything else is considered an invalid disc and can't be read (the data can't be accessed). The valid formats are Audio CD, VideoCD (used by POPSTarter AFAIK to load PS1 games, from what I understand) DVD - used by ESR to load games, PS1 CD, PS2 CD, PS2 DVD.
(I know very little about the CDVD stuff, so I may well be making a mistake about some of the things I write.)
There have already been programs that patch the PS1 GPU emulator running on the EE. This is not hard because the EE does not get reset. In fact, you can even load the emulator ELF yourself from a homebrew loading method and have it pre-patched, or patch it after load.

Getting your code to the IOP (PS1 CPU) side in PSMode is much harder. The EE has a method of accessing IOP memory (basically almost all of it, except IOP Core registers), however that gets disabled when the IOP is reset in PS1 mode or the SIF is switched to PS1 mode. The SIF DMA channels also stop working, as the whole SBUS changes its signals to a different configuration. (I have checked this).
So to load test-code, the only way seems to be to run a PS1 CD that loads code from a location you would like. I did this once, but that required a modchip. (My program on the CD would load the code from the SIO0 (controller ports connected over serial to PC).)
I don't know of any other way. You can check the PS1 BIOS (TBIN, SBIN) in the BOOT ROM still, but it is relatively short and does not load from anything but CD (if I remember correctly).
There are two communication registers in the EE PGIF range, that are connected to another two on IOP side in the PS1 GPU range, but nothing uses them, so they can only be of some use if you already have your code running on the IOP in PS1 mode. I don't remember if IOP RAM gets wiped while loading the PS1 BIOS, but I don't think it would help even if it isn't.

On PPC-IOP models, things are quite different, as the IOP is never actually 'reset' into PS1 mode. So on them it should be possible to patch the IOP RAM from the EE or even patch DECKARD in advance. I did this once - made it print all MIPS IOP emulation registers when I activate the controller port interrupt and that worked fine.

From what I remember, OSDSYS checks the disc type in PS2 mode, and if a PS1 disc is found, sets some of the PS1 mode configuration, then loads PS1DRV, which sets the remaining configuration, does pre-configuration of the IOP peripherals, resets the IOP and peripherals to PS1 mode. When the IOP is reset to PS1 mode, a certain bit 33 of IOP reg 0x1F801450 gets set (read-only) and the IOP RESET code (booted from the reset vector) checks it and if set boots TBIN (the PS1 kernel) and it initializes the environment and loads CD data from the now switched to PS1 mode CDVD DSP and MechaCon (which act just like those of a PS1 would act).
 
Last edited:
wisi said:
I don't understand what you are trying to do (or discover / check-for).
The PS2 (and the PS1 also AFAIK) has only a few specific types of discs it allows, and anything else is considered an invalid disc and can't be read (the data can't be accessed). The valid formats are Audio CD, VideoCD (used by POPSTarter AFAIK to load PS1 games, from what I understand) DVD - used by ESR to load games, PS1 CD, PS2 CD, PS2 DVD.
(I know very little about the CDVD stuff, so I may well be making a mistake about some of the things I write.)
There have already been programs that patch the PS1 GPU emulator running on the EE. This is not hard because the EE does not get reset. In fact, you can even load the emulator ELF yourself from a homebrew loading method and have it pre-patched, or patch it after load.

Getting your code to the IOP (PS1 CPU) side in PSMode is much harder. The EE has a method of accessing IOP memory (basically almost all of it, except IOP Core registers), however that gets disabled when the IOP is reset in PS1 mode or the SIF is switched to PS1 mode. The SIF DMA channels also stop working, as the whole SBUS changes its signals to a different configuration. (I have checked this).
So to load test-code, the only way seems to be to run a PS1 CD that loads code from a location you would like. I did this once, but that required a modchip. (My program on the CD would load the code from the SIO0 (controller ports connected over serial to PC).)
I don't know of any other way. You can check the PS1 BIOS (TBIN, SBIN) in the BOOT ROM still, but it is relatively short and does not load from anything but CD (if I remember correctly).
There are two communication registers in the EE PGIF range, that are connected to another two on IOP side in the PS1 GPU range, but nothing uses them, so they can only be of some use if you already have your code running on the IOP in PS1 mode. I don't remember if IOP RAM gets wiped while loading the PS1 BIOS, but I don't think it would help even if it isn't.

On PPC-IOP models, things are quite different, as the IOP is never actually 'reset' into PS1 mode. So on them it should be possible to patch the IOP RAM from the EE or even patch DECKARD in advance. I did this once - made it print all MIPS IOP emulation registers when I activate the controller port interrupt and that worked fine.

From what I remember, OSDSYS checks the disc type in PS2 mode, and if a PS1 disc is found, sets some of the PS1 mode configuration, then loads PS1DRV, which sets the remaining configuration, does pre-configuration of the IOP peripherals, resets the IOP and peripherals to PS1 mode. When the IOP is reset to PS1 mode, a certain bit 33 of IOP reg 0x1F801450 gets set (read-only) and the IOP RESET code (booted from the reset vector) checks it and if set boots TBIN (the PS1 kernel) and it initializes the environment and loads CD data from the now switched to PS1 mode CDVD DSP and MechaCon (which act just like those of a PS1 would act).
Click to expand...
I was mainly just thinking of ways to slip code in or bypass the disc checks. Since we could theoretically bootstrap PS1 mode ourselves, if the trimmed PS1 BOOTROM doesn't do any disc checks, we could bypass the check entirely and possibly get burned PS1 games working on the PS2, which would be a step up from POPStarter, considering all its issues. Since I can't sit and read from/write to busses on the PS2 over DEV9 (that I can figure out), I was planning on seeing if I could replace something somewhere to try and break out of PS1 mode and do something useful, or merely get some bus pointed somewhere useful. Since almost everything is disabled, I guess i'd either have to rely on unimplemented behavior ("what happens if we try and access the serial bus on the emulated PS1?") or breaking in from PS2 mode.
 
I don't know much about this, but the checks for valid PS1 CD, PS2 CD, PS2 DVD are done internally by the MechaCon when it detects a CD that is not Audio CD or VCD or a DVD that is not a DVD-Video. So I haven't heard of anybody managing to actually make the CDVD DSP read from a burned (backup) CD / DVD without it being of the above types considered valid by the MechaCon.
The only way that has been done has been through using a modchip to modify the MechaCon <->CDVD DSP bus signals.

The PS2 TOOL and TEST can read master discs, but they have a different MechaCon firmware AFAIK. Although nobody has actually been able to actually see the MechaCon firmware either, as it the most heavily protected part of the whole PS2 perhaps. Unlike on the PS1 MechaCon - http://www.psxdev.net/forum/viewtopic.php?f=70&t=557&sid=65e6348a955a6a9de8504893b16afdac but this one is much simpler one and less protected than the PS2's in many regards (and also includes emulation for it).
And if you are thinking you could use the same method used on the PS1 - that won't work, as the MCU is totally different and a custom modification AFAIK. And even some software commands in PS1 mode that work on a PS1 don't work on it (the unlock command).

The PS1 has two serial interfaces - SIO0 - Controllers and MemoryCards (SIO2 on PS2 can be switched to SIO0 mode) and SIO1 - the serial port on the back of old PS1 models, which only has dummy hardware in a PS2 IOP AFAIK (and nothing uses it).

BTW, you can't access the SSBUS from the Dev9 bus, unless the transfer is targeted to/from the Dev9.

I am not sure, but doesn't POPStarter have other improvements over the bare PS1 mode, like more configuration, per-game patches/fixes, peripherals emulation, etc.? If so, then such an emulator is the way to go (given the bare PS1 mode limitations), though I would like it better if a homebrew one got better than it, like PS2PSXe, but that has not been developed for a long time sadly http://psx-scene.com/forums/f292/ps2psxe-downloads-updates-105355/
 
wisi said:
I don't know much about this, but the checks for valid PS1 CD, PS2 CD, PS2 DVD are done internally by the MechaCon when it detects a CD that is not Audio CD or VCD or a DVD that is not a DVD-Video. So I haven't heard of anybody managing to actually make the CDVD DSP read from a burned (backup) CD / DVD without it being of the above types considered valid by the MechaCon.
The only way that has been done has been through using a modchip to modify the MechaCon <->CDVD DSP bus signals.

The PS2 TOOL and TEST can read master discs, but they have a different MechaCon firmware AFAIK. Although nobody has actually been able to actually see the MechaCon firmware either, as it the most heavily protected part of the whole PS2 perhaps. Unlike on the PS1 MechaCon - http://www.psxdev.net/forum/viewtopic.php?f=70&t=557&sid=65e6348a955a6a9de8504893b16afdac but this one is much simpler one and less protected than the PS2's in many regards (and also includes emulation for it).
And if you are thinking you could use the same method used on the PS1 - that won't work, as the MCU is totally different and a custom modification AFAIK. And even some software commands in PS1 mode that work on a PS1 don't work on it (the unlock command).

The PS1 has two serial interfaces - SIO0 - Controllers and MemoryCards (SIO2 on PS2 can be switched to SIO0 mode) and SIO1 - the serial port on the back of old PS1 models, which only has dummy hardware in a PS2 IOP AFAIK (and nothing uses it).

BTW, you can't access the SSBUS from the Dev9 bus, unless the transfer is targeted to/from the Dev9.

I am not sure, but doesn't POPStarter have other improvements over the bare PS1 mode, like more configuration, per-game patches/fixes, peripherals emulation, etc.? If so, then such an emulator is the way to go (given the bare PS1 mode limitations), though I would like it better if a homebrew one got better than it, like PS2PSXe, but that has not been developed for a long time sadly http://psx-scene.com/forums/f292/ps2psxe-downloads-updates-105355/
Click to expand...
Alright, these are all really good points. However, in the case of POPStarter, it's not great. At all. Lots of games just don't work and some have super-crippling issues that make playing either nigh impossible or make the game completely unenjoyable (FF7 IS a popular game, and if it barely runs without patches that disable most of the battle graphics...)
 
wisi said:
doesn't POPStarter have other improvements over the bare PS1 mode, like more configuration, per-game patches/fixes, peripherals emulation, etc.?
Click to expand...
It has virtual memory cards (better than PSP's POPS or ps2_netemu's since they're optional), a few AAP patches, etc - but physical disc support is more of a novelty gimmick than something usable (and a decent PS1 memory card isn't hard to find)

I'm mostly satisfied by Popstarter over USB/HDD (worst game: Hot Wheels Turbo Racing where you must press the button combo to quit then cancel after basically every menu screen) but for those that don't, the actually-not-that-common advice is to install a non-stealth PS1 chip (4 wires, +1 for the power switch to make it manually stealth) - no BIOS/OSD hacks involved that depending on chip may conflict with other mods (none support PSBB, for example)

There is a swap-facilitating homebrew too, iirc

wisi said:
(I know very little about the CDVD stuff, so I may well be making a mistake about some of the things I write.)
Click to expand...
No VCD support, apparently (https://github.com/AKuHAK/uLaunchELF/blob/8b4d00e47279a9eecb8d66888ba3bc247b41c6f0/main.c#L172) but otherwise exactly as I remember it :)
 
@wisi an excellent account of PS1 mode - it seems the PS1 mode is last bit of the PS2 that remains locked away.
Do you have any of the code examples you used to dig around the ps1 mode posted anywhere?

Side note, given retroarch has been ported over to PS2, how difficult do you think it would be in porting one of the better psx cores over?
 
@dekkit I don't have much code examples. Most of the time I did only low-level checks, like writing to some register, the reading all registers and observing what changed. I did write a simple command user interface to read and write registers (IOP in PS1 mode) (the one I routed through the SIO0 port) (something like "wBF801450 01234567" to write a reg and "rBF801450" to read).
But all the code I have written is very messy and I don't want to spend time organizing it.
Same is the case with the registers descriptions I've written - I have such for the PGIF and the SIF/SBUS.
All-in-all my conclusion was that there is no other way to get your code running on the IOP in PS1 mode, besides booting it from CDROM or patching it to the PS1 BIOS in the BOOT ROM. So if somebody finds an easier way to do this, this might make PS1 mode tests easier, though still given that the PS2 features are unavailable, I doubt there is much use from digging into the PS1 mode.

I don't have enough knowledge to comment on the second question.
 
ParzivalWolfram said:
wait so do the patches affect the PS1 emulation IOP or something else?
Click to expand...
I don't know anything about them except for the independence exploit (which doesn't "exploit" the patching system per se like FMCB and other custom signed updates, it's just a buffer overflow), sorry :)

I don't even remember any hard proof of the kind of patches, it's just the way title.db was described...
 
The PS1DRV ELF contains some compatibility settings for the emulator. Before PS1DRV 1.3.0 which came with the SCPH-75000, it used to be region-specific; the PS1DRV module would have a compatibility list for the region's games and also be coded to use the region's video mode. With v1.3.0, PS1DRV became universal, and so the compatibility list and video mode were selected based on the ROMVER region letter.

The title.db file may extend on this internal compatibility list.

This input is different from the disc speed and the texture option. That is saved into the EE kernel and NVRAM, like with other options. But the EECONF module always erases the block containing those settings, from the NVRAM. EECONF is run with every IOP boot in IOP mode. This is why the setting does not get carried over between resets.
 
You must log in or register to reply here.

Similar threads

Back
Top