How a PS2 Modchip works electronically

[howiiieee]

Hi folks:
I am studying electronics and I am very curious about how a PS2 modchip works. Is there any article, posting, or forum that kind of explain how a PS2 modchip works electronically inside a PS2? Any help will be appreciated.

[pico996969]

electronically the ps2 modchip(by pico)

1. the ps2 turns on and you select the mode by pushing a button that is tested whether or not signal is going thru during certain time periods to select mode

2.the R wire waits for the bios to tell it that it is done writing it's info and the chip kicks in writing over some of the bios's writing
using q,t,u,v,m,n,o,p

3. the a wire tells when the dvd bus is buzy or not(correct if i'm wrong), then the B-I wires are sending the signal that a ps2 normally receives from an original disk, to fake the authentication of a disk
.....sorry, also B-I reads certain data off the bus to determine cd or dvd

4. the game should run, and certain patching goes on with the bios some more, and most chips patch again if needed..

anyone can add or correct me.

[LostAtC]

As a long time EE, my concern with this approach has always been that there are two busses tied together both trying to output at the same time. As an example when the BIOS chip is outputting the Magic chip is also trying to output and override the BIOS data, on the same bus.

I realize that this is a "hack" and that it seems to work well for most people, but it is a situation that would never be allowed in a new design. Not only does it generate excess electrical noise and heat, but it has the potential of physically damaging the chips.

Has anyone ever experienced intermittent operation or a damaged system? Opinions? Comments?

[Emanuel]

What heat? The chips patch only a few bytes and for very short periods of time (about 200ns per byte, correct me if I'm wrong). So no heat is produced in this case.

[ingsebastian]

Originally posted by Emanuel
What heat? The chips patch only a few bytes and for very short periods of time (about 200ns per byte, correct me if I'm wrong). So no heat is produced in this case.

With a uC running at 50 - 54 Mhz, there is always heat. Besides, when you path the bios, there is always short-circuits in the data bus.

Bye

[pico996969]

i thought the R wire tells when the bios goes low, when it's not writing, then it patches when the bios is not sending a signal?...
if the bios and say a magic 3.1 are sending signal at the same time wouldn't that mean, that 8.3 volts were being sent over the bus?....

i made my little help info, but actually imagining certain things is beyond me, my EE classes haven't brought me that far yet, or else i should not skip so many and maybe i would learn

[Ex-Cyber]

I'm not an EE myself, but I have played around a bit, so hopefully I can explain it...

i thought the R wire tells when the bios goes low, when it's not writing, then it patches when the bios is not sending a signal?...

Whenever the CPU is trying to read the BIOS, the BIOS is enabed. When it is not reading, the BIOS is disabled. So if the chip were to wait until the BIOS was disabled before sending a signal, it would be patching nothing.

if the bios and say a magic 3.1 are sending signal at the same time wouldn't that mean, that 8.3 volts were being sent over the bus?....

No, what happens when there's a conflict is that one output is providing a path to Vcc and the other is providing a path to ground, effectively creating a short circuit. However since this state does not occur often (only a few times during boot and disc changes) and doesn't last very long (probably around 100-200ns) there isn't a chance for the heat to build up much. In principle this type of design is risky if something goes wrong, but in most cases any problem that would cause the chips to overheat should (hopefully) also crash the system before the heat has a chance to build up...