Flashable replacement for PS1 BIOS? (IC102)

[K4DoS]

So I've seen the NO$PSX thread and the replacement ROM being a SST 29EE020 (of course it's probably possible to substitute it for the correct 512K ROM, assuming it runs on 5VDC).

Now here comes my question:

Will this method work for replacing the BOOT ROM in a PSone (or grey PS1) with a BIOS of your choice? As far as I know there are a lot of BIOS dumps here (including the rare SCPH-5903 and the 7000W Midnight Blue) and it would be interesting to try for example a NTSC boot rom (i.e NTSC BIOS from SCPH-101 ) on a PAL machine.

So, what are your thoughts on this idea? Will it work and will it require other modifications? (other than a PLCC32 socket maybe )

[K4DoS]

I just came back to thinking about this - I am still not sure - will I need to replace the mechacon and X201? (the 17MHz XTAL present on all PAL boards) I want to get a 7502 or a 9002 and flash the NTSC-U counterpart BIOS on a flash chip and solder it in just to see if it works.

[TriMesh]

I just came back to thinking about this - I am still not sure - will I need to replace the mechacon and X201? (the 17MHz XTAL present on all PAL boards) I want to get a 7502 or a 9002 and flash the NTSC-U counterpart BIOS on a flash chip and solder it in just to see if it works.

It depends on what you are trying to do. If you just swap the boot ROM on a 7502 or 9002 you will end up with a console that still only boots PAL discs (since that's controlled by the mechacon), but which produces 60Hz video in the boot screens and memory card / CD player menus. The video mode in games will still be determined by the disc.

Note that although the video is 60Hz, it's not really NTSC compliant - the line and frame timings will be about 1% off and the color subcarrier will still be the 4.43MHz PAL one - if you want to make it generate real NTSC then you need to change the clock chip (IC204), the xtal (X201) and the luma trap inductor (L507). You really don't need to bother with this unless you are either a perfectionist or are running some NTSC rhythm games, though.

[K4DoS]

I actually just want to do that for fun. It's going to be chipped with a classic 4 wire chip though.

So it's going to generate PAL60 on bootscreens and menus? Sounds like what the ONECHIP for the slim PSOne does.
Initially I was going to try this on a 5552 but I gave up after finding out the XTAL problem. (it will output B/W all the time if I use a NTSC boot ROM)

[TriMesh]

I actually just want to do that for fun. It's going to be chipped with a classic 4 wire chip though.

So it's going to generate PAL60 on bootscreens and menus? Sounds like what the ONECHIP for the slim PSOne does.
Initially I was going to try this on a 5552 but I gave up after finding out the XTAL problem. (it will output B/W all the time if I use a NTSC boot ROM)

If you don't do any hardware mods, it will generate NTSC4.43 (I.E. NTSC video format, but with a 4.43MHz color subcarrier) - if you cut the mode select line to the DAC/Video encoder and hardwire it to PAL mode then it will generate PAL60 in NTSC mode.

Note also that the timing is slightly wrong - in the PAL versions of PU-20, PU-22, PU-23 and PSone the clock synth chip generates a 53.20MHz GPU clock (this is mask-programmed into the chip, and can't be changed). When you switch to NTSC mode, the GPU is expecting a 53.693MHz clock, and is designed to produce correct timing with this clock. Since it's still getting the 53.20MHz that's correct for PAL mode, it outputs line and frame rates that are about 1% slow.

With a NTSC board, the situation is reversed - the clock synth outputs 53.693MHz and when you switch over to PAL mode the line and frame rates are about 1% fast. It also always generates signals with a 3.58MHz color subcarrier even in PAL mode.

Note that the GPU actually has separate clock inputs for PAL and NTSC - so on your PAL unit if you cut the trace tying them together, leave the existing clock connected to pin 196 and inject a separate 53.593MHz clock into pin 192 then the timing will be correct in both modes. After you've done this, you can also move the subcarrier input on the video encoder from pin 6 on the clock generator (IC204) to pin 153 on the GPU (IC203) - this will also give you the correct subcarrier frequency in both modes.

I've also got to say that although I would normally not like the idea of generating the color subcarrier from a digital frequency synthesizer, by the time it's divided down in the GPU, the phase noise seems to have mostly gone away. It's about 220Hz wide at -10dBc - not exactly great, but certainly good enough.

fsc.bmp

[likeabaus]

H/o, i think ur mistaken. From my expreience with overclocking the CPU on a SCPH-9001 (NTSC US) the GPU normally operates at 33mhz and the GPU is in sync with it. When doubling the CPU clock speed by bypassing the frequency divider and feeding the original 66mhz signal the GPU falls out of sync bc its capped at about 40mhz. I never got around to investigating why, but there's likely another frequency divider circuit feeding the GPU somewhere.

My point is that unless something is drastically different between the PAL boards (besides the video output and the region info, duh lol) in theory the GPU should be running at about 33mhz to be in sync with the CPU, NOT 53mhz.

Of course, i could be completely wrong as i've only ever dealt with NTSC US models...

[TriMesh]

H/o, i think ur mistaken. From my expreience with overclocking the CPU on a SCPH-9001 (NTSC US) the GPU normally operates at 33mhz and the GPU is in sync with it. When doubling the CPU clock speed by bypassing the frequency divider and feeding the original 66mhz signal the GPU falls out of sync bc its capped at about 40mhz. I never got around to investigating why, but there's likely another frequency divider circuit feeding the GPU somewhere.

My point is that unless something is drastically different between the PAL boards (besides the video output and the region info, duh lol) in theory the GPU should be running at about 33mhz to be in sync with the CPU, NOT 53mhz.

Of course, i could be completely wrong as i've only ever dealt with NTSC US models...

There are 3 clock input pins on the GPU. One is the bus clock, which is 33MHz, and presumably the one you are talking about. There are also 2 clocks used for video generation, one for NTSC and the other for PAL, although in practice they are normally tied together since retail consoles are only expected to run in one video mode. These are the 53Mhz clocks.

On a NTSC PU-23, the master clock is 14.318182MHz, which is used to drive the clock synth chip (IC204) - this generates 3 output frequences: the color subcarrier (3.58MHz - the xtal divided by 4), the master clock for the CPU (67.7376 MHz) and the NTSC reference clock for the GPU (53.693MHz) - both the latter are generated by PLLs from the reference xtal.

On the older boards (pre PU-20), these two clocks were generated by separate xtal oscillators rather than a clock synthesizer - but the main GPU clock input on an NTSC console has always been 53.693MHz.

[rama3]

likeabaus:
There are several synchronization signals between the various chips, that's correct, but ultimately the GPU is referenced / clocked to deal with television signals while the CPU is referenced / clocked to deal with the CD subsystem and audio.
These reference clocks can be independent, as it used to be in PU-18 and older mainboards.

TriMesh:
More information please! :p
Have you measured phase noise for the older design as well?
What does 220Hz at -10dBc compare to, will that cause visible problems? If not, what kind of value would be visible?
This is very interresting stuff from a scope I'll probably never have access to ;p

I've modded a PAL 7502 console to use a 53.69Mhz oscillator for the GPU clock input pins (I use it for PAL and NTSC mode for simplicity, but I only run NTSC titles).
I've completed the mod by using the GPU FSC output for the encoder, using the same passives as in a PU-18 (resistor and 5pF capacitor, I believe).
The goal was to check the Composite image quality I could get from the newer encoder.
And yea.. It is acceptable. I'd say it is about the same as a pure NTSC 750x output, but the artifact pattern is different.
It's just overall very comparable.

K4DoS:
Go check the PsNee development thread!
I just got the PSOne BIOS patch working and it will also patch your 7502 console.
You will effectively have an "NTSC" BIOS then. The PAL and NTSC BIOS only differ by a few bits, one of which the mod patches.

[TriMesh]

l
TriMesh:
More information please! :p
Have you measured phase noise for the older design as well?
What does 220Hz at -10dBc compare to, will that cause visible problems? If not, what kind of value would be visible?
This is very interresting stuff from a scope I'll probably never have access to ;p

That should be fine - it's basically the response of the analyzer. The most significant thing is that it's a nice Gaussian response without any spikes. The noisier the oscillator is, the wider the line gets when you turn the averaging up, and I couldn't see any sign of that.

I suspect the biggest limitation on the video quality on these units is the noise on the power supply. Its also not a very good square wave - the Fourier sequence of a perfect square wave will contain power only at odd harmonics - but if you look at the signal, the even harmonics are only about 40dB down. This wouldn't be an issue if you were using it with an old SD monitor, but a lot of modern TVs and video converters still have significant gain up at about 9MHz and it will manifest itself as noise.

fsc_harmonics.bmp

So yeah, I don't think deriving fsc from the GPU is going to hurt much - it might be worth putting more decoupling/filtering components on the DAC/encoder power lines and trying to clean up the subcarrier drive to reduce the harmonics, though. My take is that it's all reasonably good for a low-cost consumer product and there is nothing that makes me go "that sucks".

[rama3]

I've done most of these things but without the right measurment tools, it's hard to judge the effect.
The GPU has one corner of the IC (top right on a 7502, iirc) where the 3.5 supply gets very noisy. An SMD capacitor of some uF helps lots there. Sony must've thought the same and installed a rather big decoupling cap as well. It's just not enough by far :p

Anyway, I heard of something called software defined radio. These are cheap USB devices that I believe can be made into crude spectrum analyzers. Maybe I can build something from one of those

Edit: It's even on Hackaday! http://hackaday.com/2014/11/19/rtl-sdr- ... -analyzer/

Edit2: Would a suitable inductor improve the signal? By testing I found that the right inductor and probably a capacitor to ground shapes the square wave into a sinus. I lack the background to calculate a suitable value though ;p

[TriMesh]

Anyway, I heard of something called software defined radio. These are cheap USB devices that I believe can be made into crude spectrum analyzers. Maybe I can build something from one of those

I've had a play around with those things - the performance is pretty horrible, but they do work. I was using this one:

sdr-dongle.jpg

Well, not precisely that one, but one like it - the one I was actually using has had the input socket replaced with an SMA, various components removed, more filtering added, covered with kapton tape and finally wrapped with copper shielding tape. It helps with the noise, but it's not interesting to look at anymore

Biggest problems are the narrow span (unless you do multiple sweeps), high noise floor, very limited front end dynamic range (it punishes you with lots of intermod products if you ever forget this), multiple spurious signals and absurdly bad frequency accuracy (it's driving a GHz range frequency synthesizer with a typical low-cost MCU clock spec xtal).

So yeah, the performance is pretty bad - but it's a lot better than having nothing that will let you examine signals in the frequency domain at all.

[rama3]

Exactly. I do have the 20 bucks for it and I think I can do some power supply noise filtering. And then it'll be about 90% better than nothing xD

Update: About $4! It's going to be awesome!

[K4DoS]

K4DoS:
Go check the PsNee development thread!
I just got the PSOne BIOS patch working and it will also patch your 7502 console.
You will effectively have an "NTSC" BIOS then. The PAL and NTSC BIOS only differ by a few bits, one of which the mod patches.

Thing is, I don't have an Arduino

Unless this works with a ATTiny45 (as the original thread states on assemblergames). If it does, I might look into it.

My recently bought PSone Slim will still get a self-burnt ONECHIP though. I looked into the soldering points and while I found a trick to remove some of the noise from the CD-ROM (related to pin 6 on the chip) I still am looking into how to fix the CD signal problem (so I don't have to adjust the laser so much - BTW I replaced the KSM-440BAM with a KSM-440AEM from a 900x. Works like a charm!). Just a matter of getting some PIC12F508As. I did my own JDM programmer (using a serial port, a few resistors, a BS170 transistor, a socket and a old USB cable from a dud keyboard.). Shame it can't write 12C509A chips though. (according to assemblergames, and confirmed somewhere else because of high programming voltages.)

[rama3]

The original PsNee (v6) will patch the BIOS when using an ATtiny45. The thing is, for those you need an SPI programmer.

"Pin 6" is data probably? That isn't noise you get there, that's the tracking error signal and it should better be left alone.
It appears that the MM3 code pulls this permanently low, which isn't so great. I haven't checked if they changed that in Onechip.

[likeabaus]

Thanks for the explanation guys! I only had the main clock in mind. Didnt even think there were other clock inputs, carry on lol

[K4DoS]

Although not a whole flashable replacement, I just soldered in a SCPH-5502/5552 BIOS on my 9002.

I used a paperclip to gently push the pins out of where they were soldered, and didn't rip any pads!
Soldered the replacement SCPH-5552 BIOS on my 9002, checked that I soldered the pins right.
Fired up my TV tuner's software (I have a PCI TV capture card), and powered the PS1 on.
Success, the BIOS booted up and I got the memory card/musical notes menu, that looks similar to the slim PSone BIOS.

Anybody crazy enough to build a ONECHIP diagram for the PU-23?

[K4DoS]

Okay so I've went over an diagram of the PS1 BOOT ROM.

In theory I could use any PLCC EEPROM that's erasable - the only thing I'd need is VCC points for the EEPROM since I don't have any MB that uses a 5v EEPROM, thus the need of a 3.3v point on the PS1 board.

I'm going to buy another PS1 (I only have a fat and a slim, and since the slim will exclusively use ONECHIP I don't want to replace its bootrom at all.)

I'll look into a 7502 or another 9002. I'll have to simply remove the BIOS chip (SOIC format) and solder in my replacement EEPROM (with a NTSC BIOS, just for the sake of it, heh) and then test if the ROM runs okay.

Also, check this out. Not my work but apparently somebody had a tough time fitting a windowed EEPROM (just why windowed? I'd guess by 2000 there were already flashable non-windowed EEPROMs.) on a slim PSone.