Question about OneChip BIOS patch and color fix

Hi,

I couldn't find answers to these questions anywhere, so I'll try it here.

1) There are reports that the OneChip for the PSOne forces the video mode to NTSC while the console boots (and in the BIOS of course). Does the chip permanently force the NTSC videomode (i.e. even in PAL games) ?

- If so, can this be changed in the source ?
- If not, can this still be removed from the source, to not even force it during boot up? Or is it mandatroy for its function (region check bypass) ?

2) Does the color fix for the several models only affect the composite video output? Would I notice any difference in the picture if I'd do this fix + use a RGB cable ?

I hope you can help with these questions
The usual suspects like @TriMesh etc. are probably bored by such questions

Thanks !

Regards,
iCEQB

 

The NTSC video mode forced by the OneChip is only in the boot screens and the BIOS - as soon as the game loads, it will operate in whatever mode the game is written to use. Forcing the console to NTSC mode during boot is essential to the way the region patch works - basically, it makes the console think it's running the NTSC:U/C boot ROM, which doesn't have a region check because it's also used in the Asia model console, which boots NTSC:J discs.

The color fix only affects composite and Y/C (S-Video) - note that there are several different color fixes and they vary slightly in their effects.

The console will always output a correct signal in PAL mode, and the output in NTSC mode varies depending on which color fix you do.

a) No mods at all, just switching to NTSC mode
In this case, the output is NTSC 4.43 with slightly incorrect line and frame rates
b) PAL/NTSC input on the encoder wired to force PAL mode at all times
In this case, the output is PAL 60, also with slightly incorrect line and frame rates
c) 53.693MHz oscillator wired to NTSC clock input of the GPU
Output is NTSC 4.43 with correct line and frame rates
d) 53.693MHz oscillator installed and encoder subcarrier clock wired to GPU
Output is standard NTSC with correct line and frame rates

Note that even in case d the output is not quite perfect because the trap on the video encoder is still set for PAL mode.

 

Thank you for that detailed answer !

Ok, so let's say I decide to do color fix d) (which looks like best in that list?), will this affect the PAL signal output whenever I decide to play a PAL game on a PAL console?
Also, can this be done on any revision?

This is exactly what I mean when I say that all this info is scattered around the web. You (or someone else) probably wrote about this many times somewhere. But how to search for this info?
When you look for "PS1 color fix" you get the same "lift pin + 1 wire install" everytime

I knew that there is a color fix which involves an oscillator on pre SCPH-7000 models, but I never knew that you can also do that on later models, let alone that there are multiple possibilities

Do you have a guide on hand, where I can quick check the correct pins to the oscillator for method d) ?

Thank you very much!

Regards,
iCEQB

 

Sorry for the double post

I found this guide: http://studyres.com/doc/7902520/pu-18-colour-mod

But god damn, what is it with these 53.693MHz oscillators ?
Does anyone know a good source to buy these ? They seem to be hard to find in the usual places.

 

Sourcing 53.693 oscillators is hard to do these days, as no mass market electronics still need that particular frequency.
This even lead some people to create their own replacement. See here: http://nfggames.com/forum2/index.php?topic=5744.0

Still, this is a tricky mod and it's main benefit is to get proper NTSC for S-Video and Composite.
If you're looking for RGB eventually, you'll be fine with no mod at all.

 

Is that true?
The whole oscillator story is only for Composite and S-Video?

I thought this affects all outputs including RGB.

 

It affects all outputs, yes.
A PAL console will have about 1% slower update rate.
To notice that difference, you'd have to be a professional rhythm game player that's been handed a PAL console controller out of the blue

I'm just saying that crystal replacement is a tricky mod to do.

 

Running a PAL system with the slightly off output rate in NTSC is mainly a problem when not using a CRT. On LCDs it usually causes some very annoying stutter.

 

On paper, it might slightly degrade the phase noise characteristics of the subcarrier (since it's now being generated by dividing down a signal derived from a PLL rather than by directly dividing a crystal), but in practice I have never been able to see any adverse effect on the video. It's also worth pointing out that this is a mod that requires fairly steady hands and a good soldering iron - in principle, it's quite simple, but the pins are small.

Step 1: Installing the oscillator
Trace the signal from pin 1 of the clock synth chip (IC204) - it goes through a resistor and then connects to pins 192 and 196 of the GPU. You want to disconnect it from pin 192, but leave it connected to 196. Then connect the output of the 53.693MHz oscillator to pin 196 to provide the NTSC clock.

Step 2: Rerouting the FSC signal
This is currently driven from pin 6 of the clock synth via an RC filter network - you need to isolate it from pin 6 of the clock synth and wire it to pin 153 of the GPU instead. Leave the RC network in place, and feed the signal into the end of the resistor that used to be wired to IC204 pin 6.

This should work on any board that has the new GPU, although it's possible that the last PSones (PM-41 (2)) are different. I don't have one here to check.

Also note that although I mention phase noise as a potential problem, I really don't think it is in practice. Back when I was first playing with this stuff, I removed the clock synthesizer entirely from one board and replaced it with 3 separate oscillators (for NTSC video clock, PAL video clock and CPU clock - FSC was derived from the GPU) - neither I nor anyone else could see any quality difference.

 

What I don't understand, is how this now also affects the RGB output ?
Everywhere I look (also mentioned here), it says that these fixes are only for Composite and S-Video output ?

EDIT: @TriMesh did you check that DFO PCB that @rama linked here? tbh, that looks like an awesome solution and is easy to make. I need to make PCBs anyway in the coming days, so I'd also built a few of those.

 

Same result here, using a CRT and especially focusing on Composite video artefacts.
It looks the same as a stock console (of the same region) that uses the PLL.

@iCEQB
The mod slightly changes the video timings. All of them.
The digital image is later being converted into amplified RGB, S-Video and Composite.
RGB works fine with a wide range of timings but the other modes require them to be a multiple of FSC (3.597*15 = 53.69 for NTSC, 4.43 *12 = 53.20 for PAL).

 

I realy like that DFO mod you posted, did you try it yourself?
Are those frequencies correct that these output?

Or is 53.693175 MHz the same as 53.693 MHz (and 53.203 MHz the same as 53.203424 MHz) ?
That realy seems like the cleanest solution in my eyes.

 

The actual NTSC color burst frequency is (315/88) MHz (yes, it's defined as a rational number like that). The numeric value is 3.579(54)MHz where the (54) is a repeating decimal. Since the PSX GPU divides the master clock by 15 to get the subcarrier reference, the actual frequency should by 53.693(18) where the (18) again denotes a repeating decimal.

With PAL, the color burst is defined as exactly 4.43361875MHz and the reference clock is 12x that, or 53.203425MHz

I would assume that the output frequencies generated by the DFO mod are as close as you can get to those ideal frequencies as can be attained given the resolution of the synthesizer in the chip. Also note that in the real world the accuracy you get depends on the reference clock - and most low cost xtals have a tolerance of 10ppm at best, with 20ppm being more typical. So even with the better 10ppm xtal, you can be 500Hz off and still be in spec, which is why the xtals are typically only marked with 3 digits after the decimal point. Basically, the company making the xtal doesn't want to create the impression they are promising more accuracy than the part can deliver.

 

So the DFO has your blessing to be as good as your described method d) ?

 

I can't see any reason it shouldn't work - it's called out in the datasheet as being suitable for video applications, and apparently they have been used in devices like Megadrives without any visible artifacts.

 

Nice, going to built up a few in the coming weeks, if anyone is interested in such da PCB, let me know.

 

I could use one. Cant find the PM button...

 

Noticed, will take a while tho...