Net Yaroze DTL-H 3000 PS1

I hope this is the right forum
I was thinking about picking one of these up listed locally, but the seller is sparse on details,
I have read that they are region free, but can they play disc backups?

thanks

 

No - they are region free and produce correct video output in both modes, but can only run original discs.

 

thanks, I assume the blue kits are the same?

 

Blue kits can run burned discs.

Only difference is whether you can burn a disc and have it work (outside of using the system as intended)

 

Both the blue and green debugs can boot games burnt on CD-R. The ability to boot discs from a different region varies depending on the model and in some cases when it was made.

For the Japanese debugs, the late DTL-H1000 and all DTL-H1100 and DTL-H1200 will only boot discs that have a Japanese boot sector on them. The early production DTL-H1000s will boot anything, but PAL games run at slightly the wrong speed and the composite doesn't work. PAL mode on the DTL-H1200 will lock up the console, even if you get past the boot sector check.

US models don't have a boot sector check, so will boot US, Japanese and PAL discs - but some of the DTL-1201s have the same problem with PAL that the DTL-H1200 does.

PAL models don't have a boot sector check, and will also boot discs from any region - but they play NTSC (both J and U/C) games at sightly the wrong speed and produce broken composite output.

 

Wow, the speed issues seems quite a letdown. I was almost tempted to buy a DebugStation as a collector item, but I guess a modded system is probably a better choice and is cheaper anyway.

 

wow have had Green debug for eons and never tried with the burnt CD-R

 

You will get exactly the same effect with a modded retail - in fact, the only consoles that Sony ever made that run both PAL and NTSC games at the right speed are the Yarozes.

There are normally 2 different clock crystals in a PlayStation (the later ones use a clock synthesizer, but the same principles apply) - the first is the clock for the CPU, which runs at twice the actual CPU clock frequency (I.E. 67.7376MHz) - this is the same in both PAL and NTSC machines.

There is also a separate clock that runs the GPU - this is 53.693MHz in a NTSC machine and 53.20MHz in a PAL machine. The GPU is designed to produce the correct video frame rates when using these clocks. The problem is that with a PAL machine set to NTSC mode the internal logic of the GPU is set up to produce correct timing with a 53.693MHz clock - but it's still being fed with a 53.20MHz clock, and as a result runs about 1% slow.

On a NTSC machine, it's the other way around - when you switch it to PAL mode, it sets up the logic expecting a 53.20MHz clock, but it's actually still getting the 53.693MHz from the NTSC clock crystal and as a result it runs about 1% fast.

This is also the reason that the composite output is broken when you put the console into the "wrong" mode on the pre PU-20 machines - the subcarrier is generated by the GPU based on these clocks (it uses /15 in NTSC mode and /12 in PAL mode) - and since the reference clock is wrong, so will the subcarrier frequency.

The practical implications of this change in the GPU clock will vary depending on the game design - if everything is locked to the video, then the only effect will be the 1% change in speed, which most people will not be able to even notice. It tends to affect rhythm games badly, since they normally synchronize the timing to the audio (which is locked to the same clock source as the CPU), and just rely on the video to stay in sync - which it normally does, but not if its running 1% off speed.

The only real fix for this is hardware - the GPU has provision for separate clocks for PAL and NTSC mode, so it's possible to fit both oscillators to them and get correct timing in both modes - this is how the Yaroze does it. There are even certain PU-8 boards that have spaces for both reference oscillators (presumably this was done that the time the Yarozes were being produced).

The reason certain NTSC PU-8 based machines lock up when you select PAL mode is also related to this - there are two jumpers on the board, one of which connects the NTSC and PAL clocks together and the second of which connects the PAL clock to ground. The PAL machines normally have the clocks commoned and the NTSC ones have the PAL clock grounded - hence when you select PAL mode there is no clock signal and hence neither any video signal nor vertical sync interrupts.

 

I thought it was much worse than just a slight speed difference (i.e. those locks you mentioned are a deal breaker to me). In this case I guess it's fine after all, never noticed any issues on my PAL modded system, which also works great for development in the end. I'm kind of tempted to get a modded NTSC system just to check the difference for myself.

 

The Yaroze purpose wasn't for playing games, it's a development console and a pretty good one at that.
At the time (1997-1999) it got bagged for it's price, cut down API and lack of 3D authoring tools (pipeline).
All of which isn't true, the price was too cheap IMO, there's away around the API and the pipeline is always difficult on any early 3D console, with most game devs making their own formats and export plugins.
A Net Yaroze dev env is still usable today, I have mine setup on modern hardware thanks to the use of serial port and emulating on No$PSX.
I think the PRO dev kits require win98 and a PC with a ISA 16 or 8bit slot?
Anyway, it's most likely sold without the manuals, software and comms cable, which is a shame.

 

I still kept my old Win98 PC with ISA slots. what kind of comms cable it comes with and is there easily available substitude?

 

To be clear, I was referring to the Pro dev kits requiring the ISA slot and not the Yaroze.
The Net Yaroze uses a PC serial to PSX serial cable.
But you can use the PSX parallel port with a Action Replay with a printer cable (null modem cable).
I think they also work via the PC printer ports, but if not then a comms card (ISA) is needed.
I have this also, but I don't even have a PC with a printer port.
And USB printer/serial doesn't work because they don't recreate the IRQ's required by the software.
Emulation via No$PSX is the better way to PSX dev these days anyway.

 

There were also PCI versions.

 

The supplied comms cable for the Yaroze is simply a RS-232 to 3.3V translator - the only oddity is that the handshake lines (but not the data lines) are inverted from the normal convention. Using a USB<->Serial chip will work, too - the FTDI FT232 is a good choice, since it has programmable polarity on the signals and you won't need an external inverter chip. Si Labs CP2102 works well, too - but you need to invert the handshake lines in hardware.

The original Yaroze kit also had a boot CD and an access card - the boot CD will only boot on Yarozes, debugs or modded systems (it has a different territory code), and checks for the presence of the access card, refusing to run if it can't be found. There are patched versions of the boot CD ISO floating around that have this check removed, but they aren't usable on a real Yaroze (since it won't boot CD-Rs).

So if you just want the cheapest way of running the Yaroze toolchain, you can just use a modchipped retail console, the patched boot CD burnt to a CD-R and a home-made USB<->Serial translator.

 

I don't think it's that easy, unfortunately.
The Yaroze comms software uses IRQ's (as does the action replay stuff).
Which the USB doesn't replicate, or at least I don't know how it can?

 

All I can say is that it works for me:



This is using a FT232R based USB to serial adapter plugged into a regular grey playstation and the modified Yaroze boot disc.

I'm having to run it under DOSbox, because I'm running 64 bit windows, and these old 16 bit EXEs don't work natively. The only change I made to the DOSbox config was replacing the "serial1=dummy" line with "serial1=directserial realport:COM15" (where, obviously, COM15 is the port my serial adapter is connected to).

 

Wow, nice!
I do have a USB serial adptor

Code:

[  921.259875] usb 2-1.7: new full-speed USB device number 8 using ehci-pci
[  921.352992] usb 2-1.7: New USB device found, idVendor=1a86, idProduct=7523
[  921.352998] usb 2-1.7: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  921.353001] usb 2-1.7: Product: USB2.0-Ser!
[  921.395115] usbcore: registered new interface driver usbserial
[  921.395124] usbcore: registered new interface driver usbserial_generic
[  921.395131] usbserial: USB Serial support registered for generic
[  921.412431] usbcore: registered new interface driver ch341
[  921.412446] usbserial: USB Serial support registered for ch341-uart
[  921.412462] ch341 2-1.7:1.0: ch341-uart converter detected
[  921.414628] usb 2-1.7: ch341-uart converter now attached to ttyUSB0

Tryied it with the NY Comms cable, couldn't get it to work tho

Hey, do you know how to send native PSX exe's (not requiring the net yaroze boot cdrom) via serial?

 

Probably the easiest way is using the Hitmen serial tool:

http://hitmen.c02.at/files/releases/psx/hit-serial.zip

If you have a chipped console, there is a boot disc ISO - if you have a standard Yaroze, then there is an EXE you can upload using the Yaroze tools.

Have you tried talking to the Yaroze over the USB serial using something like putty or minicom? It should work with no problems. If you can't make it work, it's possible that your serial converter is missing one of the control lines.

Edit: and make sure you are asserting the RTS line - if it's low then the Yaroze won't accept any commands.

 

Hi TriMesh,
Thanks for the info, I have both the Yaroze and a chipped PSX.
I use linux , Virtual Box doesn't like serial ports,
I got my desktop serial port working with DOSBOX (linux) and gave up on the USB adapter.
I packed iup again my NY, I got a good workflow just using no$PSX.
I'll get it out again one of these days and I'll try out.

That's very interesting.
Have you gotten any action reply comms working via USB?
I also have a printer port USB adaptor, again never got it working lol
ie: http://www.psxdev.net/forum/viewtopic.php?f=48&t=873&p=8289&hilit=printer#p8289

The Yaroze comms was the only thing I got working

 

I don't think you will ever get those USB printer port adapters working on an Xplorer or a late model AR/Gameshark. The basic problem is that the USB printer device class is written to very closely match the capabilities defined in IEEE 1284. 4 - and although that has support for the legacy printer port mode, it doesn't support the method used to read data back (which basically requires multiple status transfers per character).

I was working on a little project to handle this a while ago, but it sort of stalled...