[Question][1.0-1.5] How to you force switchover from ISA to LPC for firmware load?

[bennydiamond]

Hi,

Congrats on your Modxo project. It's super interesting.

I'm trying to figure out how you can get the console to load its firmware from LPC rather than TSOP on ISA bus without forcing d0 to 0 on first read from MCPX.

From my experimentation, if d0 is at 1 on the very first read from MCPX, Xbox will try to get its firmware from ISA and won't go to LPC; hence the need for a d0 line from the modchip.

Thanks

BTW, I'm the original author of XBlast.

[shalxmva]

Hi, nice work with XBlast!

Currently the modchip is keeping grounded D0 using a GPIO, But i dont know if there is a way to manipulate OE or CE on the TSOP to disable it. But maybe you are looking for a better way than forcing pins.

Thanks!!

[bennydiamond]

Somehow I missed the d0 indication on your install instructions... I was brought here by a console modding news outlet and it stated no wires were necessary outside of interfacing the LPC port. So my curiosity got the best of me!

AFAIK, MCPX is looking for a value of 1 on bit0 on its very first read of the TSOP (start of flash array). If it doesn't get it, it failsover to querying the LPC. Disabling the TSOP via OE/CE would likely result in an unstable setup as then the data lines between TSOP and MCPX become High-Z on both ends. I agree forcing/overiding pin values via d0 isn't ideal but tbh I would assume the ISA bus has some sort of overcurrent protection in the event of 2 devices wanting to emit at the same time on the bus.

[shalxmva]

Ok i got it.

What i had in mind was to disable the outputs from TSOP, then just enable a weak pull down on a gpio pin, so there when the MCPX is trying to read, the weakpull down will drive the pin.

But yes, we are driving the LFrame and D0 pins from the pico in the new version.

[MrKittenK]

If the timing is right, couldn't the D0 be pulled to gnd by the gpio for the needed time for the mcpx to know to load from lpc, then be released once done? That way the interference on D0 is short?

[bennydiamond]

If the timing is right, couldn't the D0 be pulled to gnd by the gpio for the needed time for the mcpx to know to load from lpc, then be released once done? That way the interference on D0 is short?

Yes it is possible and what was implemented in XBlast CPLD code. Keep in mind you will need to force back d0 to '0' after every reset event. This includes soft resets like through IGR.

The way I did it was to force d0 to '0' upon detecting /RST signal being toggled to '0'. Then release d0 tamper upon receiving CYC nibble. I don't remember why I chose to wait until receiving a valid CYC op rather than LPC START, it could very well be on LPC START nibble as well. You'll have to experiment to see if it's stable. But quite frankly, holding d0 a few nanoseconds more than it needs to be isn't the end of the world.

From experience, once MCPX switched to reading from LPC for its firmware, it will not go back to ISA until a /RST event; unless you're in that weird state being used to do TSOP recovery (by forcing a15 to '0').

[bennydiamond]

For LFRAME tampering on 1.6(b) consoles. It's a tad more tricky and requires GPIO of the MCU/CPLD to switch quite fast. The rationale is to prevent Xyclops from ever seeing a LFRAME signal that signals a LPC START event by forcing it to a '1' state (idle) on every LPC transaction. So the Xyclops would never see a LFRAME at '0' and thus would never handle the command.

XBlast CPLD code keep track of LPC transaction through its FSM and when it knows it's waiting for a LPC START event and sees LPC DAT to all zeroes, it will force Xbox's LFRAME signal to '1' for that single LCLK cycle. CPLD's reaction time on this was in the order of single digit nanoseconds. Effectively, when the Xyclops IC was sampling the LFRAME signal on LCLK rising edge, the LFRAME signal was already at a steady '1'.

From an electrical point of view, usually, IO drivers (we're talking about the MCPX here) are much more tolerant on sinking high currents to GND than supplying it. Hence why I prefer my LFRAME tamper solution over simply strapping it to GND all the time. The goal is to prevent IO driver burn-out in MCPX even though there is very little reason to keep the ability to boot to stock firmware from Xyclops. Burning out the LFRAME's IO driver in MCPX isn't a big loss in 2024!

[shalxmva]

Raspberry pi pico can't handle too much current. In order to effectively make D0 = 0, the GPIO drive strength has to be increased to 20mA, which is not letal. There are a lot of people which tie directly D0 to GND, but i don't how much current it will draw from the tsop flash or the MCPX when driving the bus. It can be interesting to know if 20mA is too much for either IC.

[bennydiamond]

In comparison, LC4032V CPLD can supply 8mA and sink 4mA per IO, in ideal conditions, hence why Aladdin modchips original design had 2 IO pins jointed to handle d0 sink to GND. It's not a clean solution but it works and is cheap.

So while having a good FET to handle d0 would be ideal, I would expect the Pico's GPIO to handle pulling d0 to GND (or close enough to it). Unless max sink current on the Pico is way lower than 20mA.

What is too much current and what isn't all depends on how all the parts in play here handle working at their limit or exceeding them. Some devices will burn out their IO driver flat-out. Others might tolerate these working conditions for a while and finally give in or have their performance reduced permanently. Others, like MCPX and TSOP in Xbox seem to handle it very well and protect themselves from overcurrent.

MCPX and TSOP are not power delivery devices, their IO drivers are designed to work in very High-Z environments. But since they operate on a shared bus, they must be able to handle unexpected bus collisions. They are not able to supply a ton of current but they will protect themselves against reasonable current surges.

[shalxmva]

Sorry, 12mA is the maximum programmable drive strength