Project: USB connected downloader tool for PS1 development

I initially planned on making a Whole new pcb with better and newer Chips that also had usb support,I didn't really plan on making existing AR hardware work. Maybe you could concentrate on making a new board and revisit adding usb support for the old AR, maybe see what other People might be interested in and concentrate on the majority of votes .

 

The advantage of using an existing cartridge is you should be able to pick up a cartridge cheaper than you can get the connector and flash chip for.
You could probably build the interface on strip board, making it the cheapest way of making it. Nobody has to do pcb runs etc (although you can).

 

True but I wanted more memory and native usb support and from the looks of it the protocol on the AR which I own seems more trouble than it's worth. I have no issue reusing the connector from my AR so it can still be cheap, in the end it's Trimesh's project and decision and I just wanted my thoughts about it to be heard.

 

Id be happy with either solution. I just want a fast way to upload code with caetla without using the parallel port.

 

so , what the main purpose of this device : to load ps-exe (executible file for ps1) ? and what else?

 

Well, I had intended from the outset to get people's ideas - that was why I started this thread, but at the time I didn't get much in the way of feedback, so I just carried on with the ideas I had in my head.

Initially, I was thinking in terms of a USB <--> PAR interface converter that would be used with an existing cart and operate using an unpatched version of Caetla. At the least, the client software should be able to upload the the PSX memory, hook the console stream and carry out basic debug functions (like breakpoints and get/set register values). Hooks for connection to a GDB stub should also be provided.

I was also initially thinking of using an MCU - but once I started to look at the details it became obvious that the PAR protocol was fundamentally unsuited to that sort of application (incidentally, I wish I had seen that FreeWing schematic before - it would have saved me quite a bit of time), and that I was going to need external logic to handle that - and at that point I started to think that if I was going to do that, I might as well build a complete replacement. The next step was thinking that maybe you could replace the MCU + CPLD with just the CPLD.

And that's how it ended up as it is now.

I'm not adverse to using an MCU - and there are certainly a lot of things that are far easier to do in C than they are in VHDL. So if you any specific use cases in mind, then by all means express them - maybe even at this point we can actually develop an objective spec :smile-new:

This is what I have got so far:

smf likes the external protocol converter approach - and specifically with support for the Xplorer/Xploder carts.

Helder likes the cart replacement with updated hardware idea.

dahans115 doesn't really care about the approach - he just wants something that works.

From my point of view, the biggest practical problem with supporting the Xplorer/Xploder is that I don't have one here, so it could be a bit hard to debug (although I managed to get the PAR protocol working despite the fact that I couldn't find my comms link board and don't have a machine with any ISA slots to plug it into anyway). And I can likely work out what the protocol is by disassembling Caetla and some of the utilities like Caeflash.

The other question is what OS are people using - I mostly write stuff that runs under Unix or Linux - but it doesn't seem a very common OS for PSX development...

 

At the moment I'm using an xplorer via parallel port and Orions modded catflap under Windows 7 x64.

I have the yaroze + psyq SDK setup in DOSbox and newer psxsdk installed. I'd just like to be able to use all the features of catflap via USB.

Just an extra thought as well, if you are using a CPLD, would it possible to add some GPIO to the cart?

 

You could certainly do it using the CPLD - but it would be a lot easier with an MCU, since they have hardware features specifically designed to implement GPIOs.

I also had a look at just implementing the minimum hardware required for the PAR interface in the PLD - it would all fit in the smallest MAX series device - which is $2.40 one off at Digikey prices. The EPM240 (smallest device in the series I'm using now) is $6. FT240X is $2.52 - so you can use a ~ $6 MCU with on-board USB and the BOM cost is a wash with the USB + CPLD approach. There are a whole bunch of chips from the like of ST and NXP that are in that price range...

 

My wish list is basically to have a modern cheat cart with larger memory and usb support with debugging features. I really don't care what rom is on it whether it be caetla or custom, I just want functionality out of it. If you could upload programs like some people want to the PSX then that's an added bonus. I mainly use Windows OS like XP and 7 both x86 and x64 so something that would work on these would be great.

 

Another thing that comes to mind is that if we are using an MCU then quite a few of those parts have ethernet on chip. Does anyone think that would be a useful feature?

 

How would using the ethernet as an interface connection work compared to usb? I don't see a use myself but not sure what other people think about it.

 

One thing is that it's a lot faster than 12Mb/sec USB (although slower than high speed USB 2.0) - it's also much easier to run multiple protocols over. It also doesn't need any specific drivers, which might be a big issue for people that are running things like the 64 bit version of Windows 7 that you can't load unsigned drivers on. This is not an issue with that FTDI chip since as long as you don't change the PID or VID then you can use the stock drivers, which are already signed, but most of the MCUs don't have any signed drivers available.

 

I would like to see ethernet over usb so long as the same tools work with it. Would be quite easy to develop tools on other platforms then too

 

I like having usb but this sounds like it would definitely be a good idea to add, maybe get some votes on it.

 

Yes, hooking it up to a router and debugging wirelessly would be awesome.

 

Well, I just did some investigation about why the transfer rates are so horrible at the moment. Obviously USB is faster for bulk transfers, but I didn't expect it to be that much faster. This was done with the state machine on the board modified so that it just read the character and immediately went to check for another one, so there is no overhead from the PSX end of things (in fact, it was turned off).

The results were quite interesting. It seems that Windows has a huge amount of overhead on each send, and you have to use block sizes that are larger than the buffer in the chip to get best performance. For some reason, the perfomance with 512 byte and 1K blocks is very similar, but as soon as you get below that the time basically becomes proportional to the number of blocks you send - using larger blocks is also faster, but not to the same extent.

PSXUSB detected!
Start: Sending 1024 kilobytes (BUFLEN = 4096, LOOPS = 256)
Stop: Took 1281 ms
Start: Sending 1024 kilobytes (BUFLEN = 2048, LOOPS = 512)
Stop: Took 1531 ms
Start: Sending 1024 kilobytes (BUFLEN = 1024, LOOPS = 1024)
Stop: Took 2063 ms
Start: Sending 1024 kilobytes (BUFLEN = 512, LOOPS = 2048)
Stop: Took 2047 ms
Start: Sending 1024 kilobytes (BUFLEN = 256, LOOPS = 4096)
Stop: Took 4109 ms
Start: Sending 1024 kilobytes (BUFLEN = 128, LOOPS = 8192)
Stop: Took 8219 ms
Start: Sending 1024 kilobytes (BUFLEN = 64, LOOPS = 16384)
Stop: Took 16391 ms
Start: Sending 1024 kilobytes (BUFLEN = 32, LOOPS = 32768)
Stop: Took 32812 ms

So this is certainly another win for the MCU based approach.

 

It's not windows, it's how USB works. You basically get an amount of time to send data, if the packet you send doesn't have much data in it then you're wasting time. Ethernet has an overhead for each packet, which also means that sending data in small packets is a lot slower than sending in large packets.

Only point to point ports without any kind of protocol, like parallel and serial ports, have no overhead on sending bytes.

Whether you create a new board or reuse an existing cheat cartridge, you're going to end up with the mcu having to know how to talk to the cartridge. If you want super fast access then you'll need your own cartridge with the mcu hooked up to dma channel 5, whether that is worth the effort is up to you to decide.

By doing an add on it restricts you, but those restrictions might actually help you finish it

 

try set "Latency Timer" to minimum =2 , because by default it's 16 (ms)

ftStatus = FT_SetLatencyTimer (ftHandle, 2);

 

I can assure you that the behavior that is being exhibited is not derived from any requirement of the USB specification.

Firstly, the fixed time slots you are talking about only apply to devices that are set up to use isochronous mode - and this FTDI chip is not one of them. It operates using bulk mode, where it will use whatever frame time is available after the higher priority transfers (isochronous, interrupt and control) have completed.

The basic issue is that either the Windows HCI driver or the D2XX driver (probably the former) seems to only want to schedule a maximum of one transfer to or from any given endpoint within each frame. This is not a requirement that derives from the USB spec - multiple transfers to the same endpoint in a frame are perfectly legal. Given the historical basis that USB was designed in part to replace serial and parallel ports, this is not surprising.

Yes, there is overhead on the bus for multiple transfers - it's 85 bit times in total, or slighly less than 11 bytes since it's a synchronous bus - this should mean that doing a pair of 256 byte transfers would take about 2% longer than doing a single 512byte transfer - in practice, given the implementation in Windows, it takes twice as long. This is making the (reasonable) assumption that both will fit into a single USB frame.

I'm certainly not trying to deny that longer transfers are generally better - but I also don't think you should be defending the rather clearly degenerate behavior of the Windows USB driver in this case.

Thanks for the suggestion - but it doesn't appear to be making any difference.

 

Any new info on the status of the project TriMesh?