PlayStation Development Network

Hello,

Myself and a friend are testing out Gold CDR disks of games from developers and some are NTSC and I am wondering if it's possible to switch my Blue kit to NTSC to play them in colour? Also if anyone has any more info on the type of kit I have.

The kit is:
DTL-H1102
Blue
Pal

Hi. Yes you can, but it requires a small modification to make them run at PAL60. This isn't true NTSC at all, so the PS1 will not be good for testing. In order to test them at the correct NTSC frequency, it will require a more severe modification which involves adding a second crystal oscillator. You can 'steal' this oscillator from an NTSC PS1 (IE: SCPH-9001) and solder it in, but the modification isn't for the faint at heart. You need to have a steady hand and good solderability.

I highly recommend that you leave the DTL-H1102 as it is, and you buy a SCPH-1001 since it has VRAM and a SCPH-9001 since it has SGRAM (that's why Sony released the blue and jade 'green' debuggers. There are two blue versions of the debuggers (you having the last revision) because apparently there was a printf bug in the earlier blue debugger). All you then need to do is modchip both and you have yourself some standard PS1's converted to "development kits" (debuggers).

If you don't actually care about testing the games how Sony would have (VRAM/SGRAM comparison), then just buy an NTSC PS1 (SCPH-1001, 5501, 7501 9001, etc). Do not modify the development kit (debugger) because they are not as common as the standard/stock PS1's.

Shadow wrote:There are two blue versions of the debuggers (you having the last revision) because apparently there was a printf bug in the earlier blue debugger).

Do you have more info on that bug?

No. I read it on Wikipedia so I'm not certain whether it's true or not. Knowing Wikipedia, it's probably not true, taking also into fact that I haven't read nor seen any Sony documents about it. I don't own any debuggers, so there is no way I can test the printf functions on both consoles, but taking into fact it's just the printf function, in theory one could just replace the BIOS and test it that way.

Okay, a certain someone (can't say who) stated this.

This isn't really a bug.
The original boot ROM had code that drove a UART chip located in the expansion 2 space.
Presumably there was some hardware somewhere once that actually implemented it.
The expansion 2 space is better known as the upper block of the expansion port address space.
The result was that if you had printf() in your code (and you didn't specially redirect it) it would just hang.
The later versions just threw the data away.
A printf redirect is better known in the Psy-Q library to hook the printf routine.
EG: This allows you to send stuff out of the serial port instead of the default parallel port, or, over the debugger comms channel on the DTL-H2000.
This isn't an issue on retail consoles since all those calls should have been removed, but it meant that code that ran fine on the DTL-H2000 would hard lock up on the debugger.
The later consoles still have the driver for the DUART in them, but it's not used by default.
I guess in theory you could made a board that plugged into the expansion port that provided those serial ports, but I don't think there was ever product that did that.
I've been told it was the dual serial port on the NEWS workstation, but I don't have any way of verifying this.