Project: USB connected downloader tool for PS1 development

it is selfmade board by me on my work/job.

 

oke maybe this is gonna be a stupid thing to say and my knowledge of the how, why and what isn,t that big at all!
but psxs have a serial io port and a parallel io port why not try to use the serial port to push games some how?

i have played many games like command and conquer with the link cable between the psx,s would it not be easier to create a serial to usb cable and run some kind of emulator on the pc its connected to that pushes the game to the psx?

it may sound stupid and i do not know if its even possible but i saw this tread and i would love to buy one of these devices when they come out but i thought that the serial port could be used to?

 

For running games, the biggest problem with the serial port is that even with short cables it maxes out at about 150kB/sec - and this is less than half the rate that the CD-ROM drive can handle. You can use it for program development (the original Sony Yaroze system did this), but the tools are not very developed.

The expansion port is much faster, and also allows you to provide a boot ROM that will get control when the system is turned on.

In fact, this thread is about a development tool (broadly a replacement for the old Action Replay + Caetla ROM + Comms Link card setup), rather than an optical drive emulator - that's cybdyn's PSIO project.

 

SIO is slow.

TriMesh - what .bin you used from AR (http://www.psxdev.net/forum/viewtopic.php?f=60&t=366), i can help with extacting/decompressing executeble code, if you need?

 

oke that clears up alot thanks ill just keep watching this tread and see if i can help out in any way

 

It's the 0.35 caetla ROM (I had a look at the "0.37" version, but I suspect it's a hack since I can see what look like object patches in there, and the 0.35 is clean). I've worked around the problem for the moment by swapping the flash for an SST part that's supported, so it's low currently a low-priority issue.

Thanks for the offer though - and I might well take you up on it later

 

Just to throw out the idea, network connected may not be much more difficult than USB connected, and would make implementing things like gdb remote server a bit easier.

 

Hows it going Trimesh? Did you manage to make any progress?

 

A little, but then I blew up the 5V tolerant I/O bank on the CPLD and haven't got around to getting another board yet. The basics are (or at least were) working, but the current crude protocol is very slow, since it's based on the original Datel one that worked in pseudo full-duplex mode. Basically, for every byte I send, I have to receive one, and even using the D2XX drivers the limited size of the FIFO means that I have to turn the bus around a lot, with the result that the transfer rate is only about 150kb/sec best case.

I should get back on it - I'll try to pick up another board this week.

 

can you show what scm you used - i mean do you use direct connect ps1<->ftdi or through cpld ps1 <->cpld<->ftdi ??

 

On the test board, it was all going through the CPLD - the only reason I needed the 5V tolerant I/O is that I'm using a hacked up action replay cart and in has a 5V flash on it, so when you do a ROM read the data lines go above VCC - so I stuck some 220R resistors in the lines and enabled the I/O clamps. For the real version, this won't be necessary, since I'll be using a 3V flash. I'm also going to connect the data lines of the FTDI chip directly to the bus.

I'm not sure exactly what happened, but the ground wire came off, and after that the I/O on the CPLD stopped working. Another board is pretty cheap, so I really should get one.

 

sorry , i still dont get how your scm looks like. but i think only one device is accessed at time and another in Z-state. but better see scm - at least from scratch on paper

i think - if you wanna get more speed - cpld should emulate caetla side that connected to AR db25 port, from another side cpld should store data in temp buffer from ftdi.

 

OK, there is no DB-25 port, it's been removed, along with the 'LS245 and the PAL.

Basically, the board is just the connector, flash and 5V regulator - the functions that were in the PAL are now being handled by the CPLD, and the data bus on the FT245 is connected to the PSX databus via a tristate bridge (I would have connected it directly, but didn't want to expose the pins to the voltages that the flash ROM outputs are producing on a read cycle - the PCB version with the 3V flash will just have the busses tired together).

The very first version connected to the comms link port and just imitated the protocol from the original Datel card - I suspect this is the approach you are thinking of?

The thing that's slowing it down is that the current logic will only assert the data available strobe to the PSX if there is both a received character in the RX FIFO and available space for the response byte in the TX FIFO. Hence, even if you are sending a large block of data and the code on the Caetla end is returning zeros you need to repeatedly turn the bus around to flush the FIFO on the far end.

Using the original AR hardware, there is nothing you can do about this, since it always sends bytes in both directions in lockstep and there are only two handshake lines. The action that triggers the generation of the ACK pulse is writing the response byte, and there is no way to tell at an electrical level if that response byte is useful data or just padding.

This was the reason that I decided to replace the original PAL, since it would let me define an additional response type that would send the ACK pulse, but would also carry the information that nothing should be stored in the TX FIFO.

 

as i remember, transfer controls by code it gets. so code is part of protocol. it means data is not all 8byte

 

http://www.psxdev.net/forum/viewtopic.php?f=60&t=397
http://www.psxdev.net/forum/viewtopic.php?f=60&t=398

 

Yeah, on the software level, but the original HW on the AR cart has a pretty simplistic protocol - using the original comms link card, the PC would write a byte to a holding register and that would then be driven onto the bus, and the STB signal driven high. When the AR end reads it, the code then sends a reply byte, drives it out onto the bus and pulses the ACK line high.

The basic problem is that every time you send a byte you have to receive one, and vice versa. This is not a problem on the software level because the code can just ignore the stuff it doesn't need, but it causes a problem when you are using another transport because there is no way you can tell by looking at the interface lines if this byte is a dummy or not.

 

if such algorithm hard to define/make in cpld w/ using methods like "state machine", maybe it's easy make in controller w/ usb (arm)

 

The biggest problem isn't implementing it - it's that the current protocol is basically defined by it's implementation. So, you basically have to reverse engineer it so that you can know which bytes don't count. In some cases, it's easy - the memory download protocol consists of a header (checked by the host), 4 bytes of address (echoed back), 4 bytes of length (echoed back) and then <length> bytes of actual data and a 2 byte checksum (none of which is checked) after this, the target sends back either "OK" (for a good checksum) or "BC" (for a bad checksum) - this, obviously, is checked.

So in fact there are only 5 bytes that need to be echoed (and 3 of them are constant) - but there is no way you can tell this just from looking at the interface because it just blindly transfers data. And you need to do this for each command.

 

dont get a little. maybe translation problem. cpld works fast to recognize what to do next send or read data... no problem to emulate caetla IF by cpld.
but make this idea works it takes time, that is always insufficient.

 

OK, I just got a replacement CPLD and soldered it to the board