Chipless Modchips

[nocash]

Well, yes, Chipless Modchip sounds nonsense. The idea is to omit classic microprocessor based modchips, and instead output the SCEX signal on the PSX address bus, either using a custom internal BIOS ROM (which would be quite some work to install), or an external expansion ROM (eg. a cheat device cartridge).

That, yeah, with the required FLASH/ROM memory chip, it isn't truly chipless, but it might be useful if you do already have that memory chip. To some level one could also use the secret unlock commands instead of generating the SCEX signal, but that won't work for Asian and Japanese consoles, and even if it's working: secret unlock just isn't very fast (the unlocked console is still trying to read the SCEX signal until some timout occurs after several seconds).

Apart from the memory chip, one would need some minimal circuit on the mainboard, consisting of transistors/resistors, or just some wires/diodes:

Code: Select all

External Expansion ROM version, for older boards (PU-7 through PU-20):
              .--------.-.                 .--------.-.
  GATE--------|C  NPN  |  .    DATA--------|C  NPN  |  .
  A20--[10K]--|B  BC   |  |    A21--[10K]--|B  BC   |  |
  GND---------|E  547  |  '    GND---------|E  547  |  '
              '--------'-'                 '--------'-'

External Expansion ROM version, for newer boards (PU-22):
  (todo)

Internal Kernel ROM version, for older boards (PU-7 through PU-20):
  GATE---------GND
  DATA---------A20

Internal Kernel ROM version, for newer boards (PU-22 through PM-41(2):
  SYNC--------WFCK
  DATA---|>|---A20

The Internal mods are already supported in nocash-kernel-clone (since no$psx v1.0). They are very simple, but not suitable for use with expansion roms (the console would be "bricked" when disconnecting the expansion rom).

The external mods will be supported in next kernel update (alongsides with next no$psx release), without expansion rom the console can still boot normal licensed discs. One could use any cheap NPN transistors, like BC547 for example. The 10K resistors prevent the transistors to pulldown the A20/A21 signals (just in case somebody should ever use very large expansion roms)

And, here is the world's first attempt (?) on describing modchip wiring without using "photos with arrows".

Code: Select all

What pin is where...
  GATE is IC703.Pin2  (8pin chip with marking "082B")   ;PU-7 .. PU-16
  GATE is ??                                            ;PU-18
  GATE is ??                                            ;PU-20
  SYNC is IC723.Pin17 (20pin "SONY CXA2575N")           ;? .. PM-41 .. ?
  DATA is IC???.Pin7  (8pin chip with marking "2903")   ;PU-7 .. PU-16
  DATA is HC05.Pin17  (52pin "SONY SC4309xxPB")         ;PU-7 .. EARLY-PU-8
  DATA is HC05.Pin32  (80pin "SONY E35D, 4246xx 185")   ;LATE-PU-8 .. PU-20
  DATA is SPU.Pin42   (208pin "SONY CXD2938Q")          ;PU-22 .. PM-41
  DATA is SPU.Pin36 ? (176pin "SONY CXD2941R")          ;PM-41(2)
  WFCK is SPU.Pin5    (208pin "SONY CXD2938Q")          ;xxx .. PM-41
  WFCK is SPU.Pin84   (176pin "SONY CXD2941R")          ;PM-41(2)
  A20  is CPU.Pin149  (208-pin CPU CXD8530 or CXD8530)  ;PU-7 .. PM-41(2)
  A20  is ExpansionPortPin28                            ;PU-7 .. PU-22
  A21  is CPU.Pin150                                    ;PU-7 .. PM-41(2)
  A21  is ExpansionPortPin62                            ;PU-7 .. PU-22

Still needed are pin/chip numbers for all mainboard versions (somebody could help out there?). And, some circuit for external roms on newer boards (ie. either generating a WFCK-style signal by software, or using some hardware logic for merging the actual WFCK signal with the software generated SCEX signal (any suggestions?).

[rama3]

I've got to try this out

[nocash]

I am still trying to figure out the best way for the "External Expansion ROM version, for newer boards (PU-22)". It would need the DATA signal and a WFCK signal, and of course the circuit should be inactive when disconnecing the expansion ROM.

I have tried to output a merged "DATA+WFCK" signal to the DATA pin, but that didn't work out, probably for one (or both) of these reasons: I've used an open collector output (floating when "high"). And, I've used a software-generated WFCK-style signal instead of the real WFCK one, I have tried dozens of different frequencies, but didn't try using the exact same frequency as WFCK.
TriMesh suggested that one could use some random frequency instead of WFCK, on the other hand, rama mentioned that the frequency needs to be rather fine-tuned for different hardware setups, and doesn't work too reliable even when doing so, which sounds as if the hardware might fetch the scex signal when WFCK=high, if so, then it would be absolutely required to use the original WFCK signal instead of a software-generated frequency.

So well, the best solution I could think of would be using a 74HC126 chip as so:

Code: Select all

         .-------------------.
  A21----|OE1,OE2            |
  A20----|IN1   74HC126  OUT1|--- DATA
  WFCK---|IN2            OUT2|--- SYNC
         '-------------------'

the chip is about 33 cents, and doing the same with transistor logic would be probably a good bit more complicated. Unless somebody has a better/cheaper/easier low-end idea?

PS. the A20 and A21 would be as so:
A20 = the "normal" SCEX signal (with inverted bits, eg. ASCII "A" = BEh)
A21 = uninverted SCEC signal (with uninverted bits, eg. ASCII "A" = 41h) on PU-7...PU-20
A21 = always high during SCEX output (when detecting firmware version = C3h) on PU-22 and up
Note: current kernel clone version outputs A20 only, the A21 signal(s) would be output as shown above in next version.

[rama3]

I wouldn't put too much time into this, as the next thing you'll encounter is anti-mod games that require even more logic in your modchip. Well, unless you manage to patch in that "anti anti-mod" routine that's floating around. Aparently it's a software way to patch (all?, most?, some?) games so they don't do the check. You can find this routine in Import Player Light, for example.

But without this, it's probably better to install a regular modchip.

In case you want to continue with the PU-22 method anyway, try this method and timing:

Code: Select all

for (byte bit_counter = 0; bit_counter < 44; bit_counter++)
  {
    if (readBit(bit_counter, SCEEData) == 0)
    {
      pinMode(data, OUTPUT);
      bitClear(GATEWFCKPORT,DATABIT); // pulls data low
      delayMicroseconds(4000);
    }
    else
    {
      // for a logic 1 in the ASCII, use synthesized WFCK method
      unsigned long now = micros();
      do {
        bitWrite(PORTB,0,1); // data = 1
        delayMicroseconds(21);
        bitWrite(PORTB,0,0); // data = 0
        delayMicroseconds(23);
      }
      while ((micros() - now) < 4000);
    }
  }

The important bit is to just pull the line low for a 0 in the ASCII, and do WFCK style high/low for a 1.
For the WFCK delays, if 21 / 23 doesn't work, try 20 / 20.
(Despite what I said earlier, those magic values are very reliable. If they work once, they'll work all the time and on all PU-22+ boards.)

Good luck!

[nocash]

Okay, if that's reliable then I could do that, too. But I still need a tri-state output instead of open-collector, so the 74HC126 chip should be still easiest. At best, I could omit the two wires for the SYNC and WFCK pins, I don't have a PU-22 board for testing the software-generated clock though... so I'll better stick with the SYNC and WFCK signals for now : /

I am trying not to spend too much on it. It's mostly a for-fun project to prove that nobody never ever needed modchips - at least not for homebrew. But then, I wouldn't use cdroms for homebrew either, so it's really a ridiculous project.

That Import Player Light patch sounds a bit interesting, makes me wonder if it's using a single patch that works with all games, or if it's more complicated. And, it seems to have hotkeys for adjusting the screen centering, that idea is even more interesting! Theoretically one wouldn't even need hotkeys for that, and the kernel could simply force correct centering, either by patching the game code, or by rewriting the gpu registers in each vblank.. don't know how well that would work with different games, but if it's working then it would be really nice for all those miscentered PAL titles.

[rama3]

Yeah, it'd be nice to have the option for that.
I recently did a run of FF8 / PAL and used a force NTSC video mode patch + recentering.
It patched about 5 locations and worked fine

[rama3]

Code: Select all

GATE is 16pin IC "118".Pin7                 ;PU-18

This is a Japanese console. I didn't care about it not being able to boot Japanese originals or not, so I could just ground the gate and connect A20 to data.
With the replacement Kernel installed on an expansion module and that module plugged in, the console instantly boots backups and originals.
If you want to use this picture for your installs, please check against a clean example for the data and gate points.
My board is kind of wasted


nocash:
- I tried to do without gate grounded, by turning the RV703 potentiometer all the way down. It didn't work at any position, unfortunately. If it worked, we would have one wire less to solder.
- Currently, your ASCII diagram shows the data signal being output from A21 for expansion ROM installs. The signal is on A20 however (unless the new Kernel somehow thinks it's an internal version?).
- Antimod games fail the check, as expected. I think the best workaround would be that software patch that disables the known antimod routines.
- Great work man!