Project: USB connected downloader tool for PS1 development

wait so how does this work? do you need an old playstation with a paralell port and is it for copying files from pc to ps1 to develop or what?

 

as i can get : idea is load code/exe files to ps1 like it did Explorer/AR with PC , but use USB for transfer. as we use AR - we need ps1 w/ parallel port.

 

Yeah, it's a development tool - basically a replacement for the old Action Replay + Comms Link + Caetla setup, but one that doesn't require a PC with ISA slots and just connects via USB. The two basic functions are the ability to download code and remote debugging.

The biggest problem I'm having is effectively self-imposed; I want it to be able to work with unpatched AR ROM images, and this means that it has to precisely emulate the original AR hardware, which had a pseudo full-duplex communications protocol. Since a single USB transaction can either send data or receive data, but not both this means that any transfer were the response bytes are being checked ends up needing two USB transfers per byte, which is very slow. To add to the annoyance, a lot of the time the data being transferred in one of the directions is not being used for anything and could just be ignored - but there is nothing in the electrical protocol that lets you know which bytes are actually important, and even if you could embed protocol level information into the hardware it would only be valid for a specific ROM, which would defeat the whole purpose of making it hardware compatible in the first place.

 

Cant you have two usb ports both writing and receiving into the same board?

 

I would just rewrite the whole Action Replay/Xploder ROM and give it all the necessary features, the most important probably being patching the BIOS section in RAM to perform every required task, which IIRC is what an AR PRG does anyway. Given how this hardware isn't exactly a whole lot different among revisions, it might turn out that you'd only need to use features supported by all chipsets, with a few API branches where required.

 

Couldn't you use USB 3.0 (or 3.1 when it comes out) to do full duplex data transmission?

 

the idea was leave almost all things same, only replace old ISA interface by USB. but as we see it cant be done with good speed. maybe by using USB3.0, but it makes hardware quite complex (in my opinion)

would like to see if Gemini made what he said. hope it wont be another "waste of time" w/ long story on his blog)))

 

http://oi50.tinypic.com/16jn0o.jpg Hardware w/ USB3.0 almost ready?

 

USB 3.0 supports full duplex communication, which appears to be the limiting factor.

 

i doubt if it really helps even with such feature. best way is remake all things soft and hardware. but this is another story.

ISA can be replaced by PCI, but not USB.

BUT, it's just a theory. better see how it'll be in practice. like to see when talented persons work on their ideas, not only talk

 

TriMesh has already stated that it was the full duplex function of the AR that was limited by USB's non full duplex nature. USB 3.0 fixes that. USB 3.0 could easily replace ISA in an emulated form. 5Gbps leaves a lot of room to play around with. USB 3.1 can rival a PCIe 2.0 1x connection

Yes it's all theory, but I think it would be the most logical starting point.

 

USB 3.0 sounds like overkill to me.

 

all speedy IF (like USB 2.0 and 3.0) works fast only in bulk mode, and hw should read data very fast. so it's same problem it can be fast if used for one byte read and then another write.

 

Just a quick status update to say I haven't forgotten about this project - although I've been a bit distracted by Real Work (tm).

Got it all hooked up again, and cleaning up the state machine that controls the transfer to the PSX - it's basically working, but not quite at the point where I want to start ordering PCBs, since sometimes it just hangs up and you have to power cycle to fix it:


Here is an almost completely stripped action replay (just has the connector, flash and regulator left...)


Hopefully I will get some time to fix the bugs on the weekend.

 

Really looking forward to this. I assume it will work with caetla given your compatibility plans?

 

Yeah, that's the idea - and I'm using Caetla for testing, since it seems to be the most fully featured ROM replacement.

I've also figured out why it was hanging, although I haven't worked out the best way to fix it yet - the basic problem is that when you send a command to the cart, you prefix it with the sequence "CL" - and if the first character isn't "C" then it just waits until it is but it doesn't generate an ack pulse - since I was using a state machine to transfer data from the USB FIFO to the PSX, it ended up getting locked up in the "wait for ack" state. You couldn't send the converter another character, because it doesn't read it until the previous one has been acknowledged. Add to this the fact that my long wires were causing occasional transfer errors (I knew this, but thought that this was not a bad thing when you were testing) and you could get the situation where the PSX rejected the command because of bad data and then went back to command state - at which point the next character sent (probably a parameter byte) never gets an ack pulse and the whole thing deadlocks.

Normally, the PC would just detect a timeout and reset - but in this case there is no out of band channel to send the reset to the USB adapter.

 

i remember there's a way to reset FT245 and use signal from it as "reset". i used PWREN# pin. if you call ResetPort or Recycleport (or something like this) it shakes this pwren pin.

 

The only real way to get this working fast and reliable is to bake the caetla protocol into an embedded processor with usb and enough I/o pins to do the parallel port access itself.If you're trying to create a usb to parallel converter and have the protocol controlled on the pc side then the latency is going to kill you. Any protocol errors, like a timout due to a missing ack would then just get reported back to the host as an error.

I've been planning on doing this for a while, but life happens. I know someone who uses caetla using gdb for single stepping and would love to combine usb with his work (unfortunately he has a parallel port so hasn't had the need to do it himself yet).

 

The thing is that I was trying to make this as close to transparent as possible - and implementing the protocol in the converter would mean that it was only suitable for use with that ROM and nothing else, which would kind of defeat the purpose. It would probably end up being less frustrating, though

Even as it is, it works pretty well with a GDB stub - because the stub code knows that if the STB bit is set then you need to generate an ACK for it, even if the value you are currently reading makes no sense, and this means that the state machine will never deadlock. I could patch Caetla to do the same thing very easily, but that would also defeat the purpose...

That's worth looking into, although I have a nasty feeling that that will force a USB disconnect. I guess the other option is to use a different chip that has some OOB data channels (like the FT2232 GPIO pins).

Edit:

Just got some interesting numbers - using the original protocol which sent a single byte at a time, it was (as expected) horribly slow. My reference was to download the (128KB) ROM and time it. After 10 minutes, I got bored and stopped it, and then did the test on just 4KB - which took 68s, so presumably the whole ROM would have taken about 36 minutes.

I then put a very simple and dirty hack into the program that in the special case of uploading and downloading blocks of data would send {x} bytes then receive {x} bytes, so these would fill up the FIFO in FT245.

As you would expect, increasing the block size also increased the transfer rate:

32 byte block size - took 66s for 128KB
64 byte block size - took 34s for 128KB
128 byte block size - took 18s for 128KB
256 byte block size - didn't work, resulted in a communications timeout (probably because one of the FIFOs is only 128 bytes on the chip).

But even at the fastest, it wasn't much better than you could get out of a serial port...

 

I recently started to take apart my GS/AR which I asked for some help in finding the connector as well as the caps on the board to basically do what you are trying to do. I was planning on updating the on board memory with newer and larger flash chips and replacing the PAL with some other chip but I had no idea what was programmed on it. I was looking to take the data lines and using an FT USB chip namely the FT240XS-R and tie them into the datalines on the chip and spitting it out to a USB port and hoping that would work, but after reading from your findings and testings that isn't so simple. I would love to have one of these boards or build one myself once you have worked out the bugs. I'm part of a game hacking site where we deal with the RETRO systems and having an updated cheat device like what your trying to build would be great to have and I'm sure would sell well to the RETRO players/hackers since most people would prefer USB as the interface of choice.