Project: USB connected downloader tool for PS1 development

This was something that I had been thinking of for quite a while, and from the discussions in the PSIO thread it seems that there is some interest in it - so it seemed like a good idea to create a thread to discuss this.

The $0.02 version:

Build a PS1 expansion port cart that supports USB communications with a focus on homebrew development. The idea is to provide at least the same level of functionality as the old AR/Caetla/Comms link setup - but without requiring either an ISA slot in your machine or the now very hard to obtain comms link card.

Hardware:

Some flash ROM to hold the monitor program
Glue logic (probably CPLD)
USB interface chip + support

Flash: can be tiny - 128 or 256K - MX29F002 or equivalent
CPLD: Altera or Lattice - the MAX parts have user flash memory, which might remove the need for a serial flash on the USB controller
USB: Some possiblities:
FT245 - Cheap, simple, not the best performance
FT2232 - Better performance, more expensive, typical package is QFN, which makes home assembly harder
CY7C6801x - Excellent performance, supports HS USB 2.0 - but also expensive. Has a built in MCU.
TUSB3210 - Don't know much about this part - made by TI. Apparently Cybdyn is familiar with it. Aslo has built in MCU

Not necessary, but nice ideas:

Provide some extra scratchpad RAM on the cart so that the monitor can stash values without having to worry about stepping on user code
Extra debug resources (break on access, break on write to specified ranges w/mask, etc.) - need to do some playing with a logic analyzer to see how much is visible on the expansion port.

First proposal for hardware:

2mbit flash ROM (MX29F002)
CPLD: MAX V 5M160Z (64pin EQFP) - with 5M80Z and 5M40Z as migration options depending on the size of logic required in the final unit.
USB: FT245 - cheap and slow, but the PSX only has 2M of RAM, so this isn't a huge issue...
EEPROM: 93C46 (maybe use CPLD UFM later).

Note that all of this is just a suggestion, and intended as a starting point for discussion.

 

Sounds interesting, and I'll definitely buy one (or build one myself, if schematics are made available publicly once completed).
I wish I could help, but my programming skills are still rough, and I'm just learning how to solder...

 

i remember we got a plan about such device: http://www.psxdev.net/forum/viewtopic.php?f=62&t=207 so in this case hardware is almost developed - and wait someone who wanna work under software for this

 

WOW today psxblaster become open? LOL
good luck for the project
Also i think FT245 it's enough for psx speed

 

I am interested too and will help if I can at all. I have an FT245RL module ready to go.

Would people rather interface with an existing cheat cart such as an Action Replay etc? Saves on having to rebuild a whole cart?

 

Anybody has the source code for Caetla firmware? I bet it would be possible to rewrite the code for external communication to handle the FT245 logic. You would just need to desolder the DB25 port and place a small addon PCB with FT245RL and USB connector.

Following the idea of the cheat device modification, it could also be possible to reverse the current communication protocol and create an interface board that would translate USB into whatever protocol was used witeh th PC Comm link card. Of course the PC softwares would need to be modified to support USB connectivity instead of the real PC comm link card.

 

Hmm, where would one locate the connector needed for the parallel IO port on the PSX-Blaster? I remember haunted said he found a source for them, but he wouldn't say where the source was or provide a part number O_O

 

As far as I know, the only person that ever had the Caetla source code was yums/K-Comm, and nobody has any idea where they are now...

Having said that, it's not an especially big binary, and finding the code that handles the host communications and patching it shouldn't be that difficult, especially if you are using a simple device like a USB FIFO chip.

As far as creating a hacked transport layer, I did have a look at that - the biggest problem is that the native Action Replay / Gameshark protocol is "sort of" full-duplex - each byte transferred on the interface is a 2-way exchange with one byte being sent and another being received (a bit like SPI) - and if you operate purely at the transport level there is no way of knowing if this data is actually useful or not, so the only way you can transparently proxy the protocol over USB is by sending two packets, one inbound and the other outbound each with a one byte payload for each byte transferred. Needless to say, this has a rather horrifying effect on performance. To get anything better, you need to embed some higher level protocol information into the link so it knows when it can just send dummy bytes.

Good question - I have had a quick look, and come up blank - one of the add-on units I have (a Video CD player) has a connector with "MXJ" molded into the plastic - and that normally means "Molex, Japan" - but I can't find anything that looks like it in the Molex catalog - and none of the connectors on any of the PSX main units I've looked at have any manufacturer markings at all. The only thing I've found that looks close is this Hirose part: http://www.hirose.co.jp/cataloge_hp/e57220088.pdf - look on the page marked "A97" in the PDF, and pretend that the angled ends on the connector have been filed off The only thing that bothers me is that Hirose connectors generally have "HRS" marked on them and the PSX expansion connector doesn't.

 

FT245 can handle USB2.0 and has 128byte receive buffer and 256 byte transmit buffer. Latching the data by a microcontroller or even a CPLD would allow us to control the flow of data to handle the simultaneous transfer of byte in each direction.

The only thing I was wondering was if the data transfers for either direction were on the same data line(s) or not? Is it serial or parallel transfer? If parallel, how wide? 8 or 16 bits?

Also, does the Caetla device runs on CPU clock or is it slower?

 

They are on the same data lines - basically, the protocol works like this:

Host (PC) puts transmit byte on data bus
Host asserts strobe line
PSX reads incoming data
PSX sends response byte
PSX asserts ACK line
Host detects ACK
Host reads response byte
Host releases STB
PSX detects STB release
PSX releases ACK

The basic problem is that sometimes the response byte is valid data, and sometimes it's noise - but unless you decode the protocol you don't know which is which - in the same way, if you are transferring a block from the PSX to the host, then the data sent from the host does not contain any useful information - but you have to send it anyway.

The bus interface between the cart and the PSX is asynchronous - it's also only 8 bits wide and seems to have multiple wait states, so running code from extension bus ROM (especially if it's uncached) is far slower than running things from internal RAM. I haven't put a number on it, but I think it could easily be 10 times slower in real terms - obviously you can fix this by relocating the code to RAM, but then you have to worry about stepping on things.

That was one on the reasons I was thinking of putting some RAM on the cart - it's too slow to be especially useful, but could be used to save and restore the main RAM context when you hit a breakpoint or a trap.

This was the setup I was using for my initial POC testing - it did sort of work, but the transfer rate seemed pretty slow...

 

i think - if you wanna use FT for replacing LPT - you will lose speed - cause max speed you can get only on continuously reading data from buffer. when you polling RXF flag and read 8byte from buffer.
chk scm for our blaster. i made flag/status register.

caetla or how it calls for AR/Explorer use 7 or 6 bit protocol at all, and additional operations to set dir/ack data. so FT usb will work slowly by changing packets every time or doesnt fill it with data only couple bytes.

so if you wanna get max speed - you need make your own protocols for pc and ps1 sides.

actually it's not too complex. but from what points of view)))

 

Yeah, the main reason I wanted to retain the existing protocol as much as possible was to allow the reuse of existing code - just use a shim that traps access to the comms link registers and then reflects them out over the USB port. Possibly I'm just making work for myself, but it seems like an interesting problem.

Sure, there is some PC side client software like PIOCONS and catflap that have available sources, and they can be hacked, but its nice to enable legacy support?

Did you just put that archive up on the PSXDEV site? I'm pretty sure it wasn't there the last time I looked? Thanks, I will have a look at it once I get Eagle installed.

 

we decide make it "open" for someone who wanna continue work w/ FT , maybe it can be useful to someone...

also i got idea , if you really wanna use AR/Explorer as is , i think if you use good speedy chip for example on ARM or like you used Cypress, your task is fill buffers of mcu by usb on high speed, and using same protocol/algorithm that was used on pc side use it in mcu. dont remember but it was written on ASM for PC and it used access to LPT port through direct address like 0x378 or similar. so mcu can replace lpt by mcu.


maybe i'll try this idea in real with any mcu, but it's interesting to see if anybody else try it.

also you can use what you show cpld+ft, like i advice about ARM. cpld can emulate what LPT does for AR. but you need app for win-32.

i also got almost same hw max2 + ft245,



so i can try make connection, and share results w/ you if you want. or if you make success early. do you good at FPGA/CPLD programming? or programming for win32?

 

about speed from expansion port y're right - from ram it's faster. but no problem copy code to ram and perform it)) also if you use cpld/fpga you can use address line to separate flags , flash code, outpup from buffer - something like PAL/GAL does in AR.

 

Well, I do a bit of Win32 programming, but mostly end up getting shouted at by the software guys at work

My day job is probably 90% VHDL and about 10% low level Asm/C (mostly ARM) - for personal projects, I use verilog, since writing stuff in VHDL feels too much like work...

 

sounds good. so what is your plan: make direct connection of cpld+ft to ps1 or emulate "LPT" or device that attached to 25pin conn of AR ?

btw: with what ARM did Y work , i just only start work with it.

 

My feeling is that there is so little hardware in the AR that it makes more sense to build the whole thing from scratch. For testing, probably the easiest approach is to take an action replay, remove the PAL and wire the signals directly to the CPLD board (basically, just use the AR as a connector + flash combo).

At work, we are mostly using ARM9s, for for personal projects I like the Cortex-M3 devices. Right now, my favorite series seems to be the NXP LPC parts - although there are also some very nice STM32s (especially the very low end ones in tiny packages). Mostly, it's just a case of working out what on-board resources I need and selecting the chip based on that. For example, if you want an ethernet interface in a very small space, the Luminary/TI chips are very nice because of the on-board PHY.

 

so y wanna use AR's code on ps1 side?

dont know maybe Y're right in this way, but to reduce work better make adaptor between AR and PC. so no need cut/remove))) but still question about package/ plastic case. so to keep AR case beeter remake pcb at all - but it need more parts : flash, cpld, mcu....

so all depends of how it popular can be.

 

Just a mini status update:

1) The basic USB<-->Comms Link converter is working - currently only with a hacked version of PIOCONS (which presumably should be renamed to something more USB ish)
2) Right now, the AR cart clone bit is partitally working - only the lower 128KB of flash seems to work
3) The AR ROM images only appear to have support for a rather narrow range of flashes, and all of them are quite old. The SST 29EE010 looks like the baseline part that everything supports.
4) The part of Caetla that writes the flash is (obviously) copied to RAM before it does any writing - it's also compressed, and I haven't figured out how the compressor works yet. I have managed to locate the code that communicates with the comms link (at least the bit in the uncompressed area).

My aim right now is to get it working enough that I can get some PCBs made with reasonable confidence that they will be usable.

 

do you have a link to that board you have?