Project: USB connected downloader tool for PS1 development

USB is a poor replacement for a serial or bidirectional parallel port as one end is in control. If you don't ask the other end for data then it can't send it, which means you end up sending poll packets constantly. This is why it's not a good idea to use it for bitbanging where you need to read a value and respond quickly. The latency for sending data and getting it back even in ideal conditions is 100's of time slower than bitbanging a parallel port.

I don't believe an FTDI chip is going to be good enough on it's own, whether the problem is FTDI/Windows/USB is irrelevant. Loads of people have latency issues with it. I'd be interested if you had the same problem trying it under Linux (not that it would help as any solution needs to work on both). The way that FTDI seem to work round various issues leaves a lot to be desired http://blog.ilektronx.com/2010/02/xbee-and-ftdi-latency-and-dropped.html

The latency timer is like the nagle timer in tcp/ip, it's basically a timeout & doesn't really control latency http://www.ftdichip.com/Support/Knowledgebase/index.html?an232beffectbuffsizeandlatency.htm

 

What do you think the interrupt endpoint type in the USB spec is for? It's provided specifically so that you DON'T need to send poll packets, since the device gets a fixed slot in each frame where it notify the host controller that data is available.

Accepted - which was why I was trying to minimize the number of times I turned the bus around, since I was expecting that to be slow - what I wasn't expecting was even on a sequence of pure writes without any intervening reads that the throughput would degrade so badly with smaller write sizes.

I agree with you that it's not likely to give adequate performance - but I emphatically disagree with the idea that it's not important to understand why - the very first step to resolving a problem (or deciding that it can't be resolved) is to accurately identify what the source of it is. As it happens, I already knew enough about the USB protocol to know that the behavior I was seeing was not caused by protocol limitations - it had to be either the USB stack in Windows, the FTDI chip or both.

The actual answer is "both, but mostly Windows". The biggest limitation with the FTDI chips is that they do *everything* with bulk transfers - they don't support interrupt mode (which is strange, since USB<->Serial converters were one of the specific use cases that interrupt mode was designed for!) and they don't support isochronous mode (which is what you would normally use for bitbanging) and instead implement their own rather strange mode where they receive the data using bulk transfers and clock it out to the ports using one of the baud rate generators.

I also took that board into work and hooked it up to a USB protocol analyzer - and what was coming down the wire each frame was

<SOF><OUT Token><DATA><ACK Token> ... wait until end of frame ....

There were no NAKs (which might have caused the HCI stack to stall), and nothing else in the rest of the frame time. Interestingly, even if you used a very large block size part of the frame was still dead time, which suggests that the HCI stack in Windows is reserving time for interrupt and iso transfers even if nothing on that port is actually using them.

Interesting, but sort of irrelevant in this case - my testing was done with the chip acting as a bit bucket - as soon as the flag went high, the FPGA read the character and discarded it, so the only constraint was how fast the host could send data to it - and that appeared to be critically dependent on the block size in use.

I also repeated the experiment using one of the SiLabs USB chips, and got very much the same result - which tends to rule out both the D2XX drivers and the FTDI silicon and leave only the Windows USB stack as a common factor.

I didn't try it on Linux, but it works the way I would expect on FreeBSD and VxWorks - if you send multiple small packets with nothing between them they get merged, if you send alternating out and in packets then they are interleaved in the same frame.

Yeah, and it only seems to work on receive, too - so it would clearly have no effect at all on that output-only test.

In any event, getting decent performance on windows looks like it's going to require moving too much stuff into the converter - and a lot of it is the sort of thing that's going to be very painful to do in VHDL or verilog. So it looks like it's going to turn into an MCU based project.

I've also been giving some thought to making it as homebrew friendly as possible - the basic aim is that you can just solder unprogrammed devices to the board and then bring it up without using any device specific programming tools.

This is the current thought:

CPU - STM32F107VC

This device has USB and Ethernet on chip, but requires an external PHY for the Ethernet. It also has the ability to boot from USB using the internal ROM so all you need is the ST DFU software and you can load code into a blank chip just using a USB port.

Glue logic - XC9572XL

This is a small Xilinx CPLD holding the glue logic - the JTAG lines will be connected to GPIOs on the MCU so that people without a platform cable can download the CPLD config as a .xsvf file to the MCU and configure it that way without external hardware

Flash - AM29F020

Probably most easily programmed from the PSX side once the CPLD has been loaded, since it will just appear as a flash ROM at 0x1F000000

Again, all suggestions are welcome

 

Interrupts are polled for as well, they are just a high level concept that is implemented in the spec.

 

But to the user this is completely irrelevant, since it's all handled automagically by the HCI driver - you set up an interrupt endpoint and get data when it's available without any further actions being required. This is why the fact that those FTDI chips don't support it is so strange, since that basically forces you to poll the device in your own user code. Add this to the "only one transaction per endpoint per frame" restriction and you get a fine recipe for shitty performance.

 

All components besides the AM29F020 are easily found and cheap here in the states, do you have a good source for the AM29F020 flash? or perhaps another alternative that is widely available?

 

You could basically use any 8-bit wide flash in that position - the reason I chose that EOL Atmel part was that all the code in the existing cheat cartridge images seems to have support for it. There are some other parts that were used in various carts (the Xplorer / Xploder carts used SST chips, for example), but almost anything seems to work with AM29F010 / AM29F020.

So this is basically another of those backwards compatibility traps

 

AM29F020 is a AMD (now Spansion) part.

 

You are quite right - it was supposed to be AT29F010 - that AMD chip is one of the devices that's not supported by the firmware...

 

Have you made any progress at all Trimesh or did you get bored of the project?

 

I have got sidetracked, but it's not dead - I have a hand drawn schematic, I just need to get it into CAD and lay out the board.

 

I can help you if you send me the schematic trimesh.

 

It's been a long time since I made any updates to this thread, so it would be reasonable to assume that this project is dead - but it actually isn't. It's just ... resting. Like the parrot in that Monty Python sketch.

Having said that, I have managed to get some stuff done on it - once I decided to go with a CPU, I was doing my tests using two development boards - one was that EPM 1270 CPLD board that was in use before, and the other was a STM32 board.

The problem was that (probably as a result of the long wires carrying bus-speed signals) it was all rather unstable - which made working on it a frustrating experience, and eventually made me basically ignore the project. Over Christmas, I managed to get some work done on it - most significantly, I got rid of the EPM1270 board and made a much smaller and simpler CPLD board using a EPM3064A and shorter wires (this was part of the circuitry I was going to put onto the PCB, but I wanted to verify the software first).

And it's a lot better - I can run block transfers between the STM32 and the PSX for several hours without dropping any characters or corruption - now all I need to to do is get the software finished.

The new CPLD board:

http://bayimg.com/jaFBGAafJ

Development setup:

http://bayimg.com/jAfBKAAFj

 

Brilliant

 

It was nice to get working on it again, to be honest. There has been a bit more progress since the last post:

1) The new CPLD seems to be 100% working and you can read and write the registers in it from the PSX with 100% reliability.
2) The physical layout has been cleaned up, and the flying leads removed - this was to try and fix the some noise problems
3) The actual cause of the noise problems was bad grounding on the MCU board - so I'm using a different one.

While I was doing this, I shortened all the wires - it turns out it's not actually necessary, since the problem was with the STM32 devboard,
but I figure having shorter leads can't do any harm anyway.

Current status:

CPLD is working, comms between STM32 and PSX are working, and you can send Caetla commands from the firmware running on the STM32 board. Current step is getting the USB port working (right now, it's not even enumerating - but I suspect this is simply something I don't understand about the STM32 USB controller).

Latest pics - not much difference, but cleaner looking

http://bayimg.com/OaFhpAAfn

http://bayimg.com/pAfHbAafn

 

Awesome! Hopefully you get that USB thing straightened out and then we will be in business!

 

Is an Arduino capable of this? I saw that it has 13 digital I/O pins and a USB connector. I don't know whether the Arduino is capable of using the USB port from the microcontroller as opposed to USB being solely for programming the microcontroller or similar.

Is the Çaetla/GameShark 2/AR comm link port TTL? I guess the Arduino would need a level converter on the I/O pins if so, but I don't know whether the Arduino can do TTL natively. Also, I have no idea what kind of current is required for the Comm Link cable, which may be something else that the Arduino can't handle.

 

I'm not much of an Arduino expert - but the ones I've seen that support USB do it using a USB-serial converter (either an FTDI chip or a pre-programmed Atmel MCU), so you should be able to use the serial port for communications after you have finished programming the board.

If you are hooking up to the external connectors on the cheat carts, then all the signals are TTL - the Xplorer (as you said) has 13 signals, and the original PAR/GS "Comms Link" interface has 10. You should be able to hook it up to an Arduino - they are still using old-school 5V MCUs.

If you want to do this, I would strongly recommend you use the Xplorer type cart, since the ACK line on the PAR/GS is only about 200ns long, and has negative setup time and very short hold time (~ 15ns) - so basically the only way you can reliably capture it with a latch. You also need to handle the interlock between STB and ACK in hardware, since some of the internal Caetla routines are in very tight loops and if you take too long clearing it you will get the same character repeated twice. Basically, the problem isn't electrical - it's timing.

This reminds me I should do another status update

The code has been moved over to a little (Teensy sized) STM32 board from that larger devboard, and the whole thing is now basically self contained - this has also involved some changes to the USB code, since although both of the boards have USB support the original one was using a "communications line" STM32 and they have a significantly more powerful USB controller than the STM32F103 that's on the little board.

The software is still being developed - the first plan was get the board to identify as a custom HID device, since that way you wouldn't require any special drivers - this ran into exactly the same performance issues I was getting with the FTDI chip in version 1 of the hardware. Right now, I'm in the process of changing the code so that it identifies as CDC device (like a USB serial cable) - since that operating more doesn't seem to have any bottlenecks. Right now, it's running the ST demo code in serial emulation mode, but I haven't ported over the PSX specific stuff.

 

Any new news on this project?

 

Any news on this project trimesh?

 

Bump, any work on the software end yet Trimesh? that's all that's holding this back right?