USB Development Cartridge for PS1

[Orion_]

I am currently developing a cartridge for Playstation 1 which plugs into the so-called "action replay" connector. This cartridge has a USB socket and allows you to transfer data from your computer to the PS1 via a Linux/Windows compatible tool. (bi-directional)
this makes it easier to develop on PS1 than via the old parallel port which required an old PC and an Xplorer FX cartridge which is increasingly rare to find.
This cartridge will be plug and play and the tool will be available under Windows and Linux

Pre-order page:
https://www.orionsoft.games/retroshop/ps1usb.htm

Demonstration video:

[nocash]

Nice, such a thing is somehow missing for people without parallel ports.

What chipset are you using? Minimum would be a single chip that could both simulate a boot rom stub and manage the usb transfers.

Do you have a reset signal implemented for automatically rebooting the console on each upload?

838Kbyte in less than 7 seconds isn't impressive, a parallel port could do that in 1-2 seconds, and usb could probably do it in milliseconds.

Some kind of an open standard transfer protocol (or driver interface) would be nice. I have a "upload exe via parallel port" function in no$psx, and it would be neat to also have a "upload exe via psx usb interface" function. With a generic "transfer-to-psx" driver, the actual transfers could even work with anything like usb, wlan, whatever.

[Orion_]

What chipset are you using? Minimum would be a single chip that could both simulate a boot rom stub and manage the usb transfers.

I'm using an FTDI USB chip FT245, an some 74 logic chip.
I'm not skilled enough to do fpga or stuff like that, this is my first real electronic project.

Do you have a reset signal implemented for automatically rebooting the console on each upload?

No

838Kbyte in less than 7 seconds isn't impressive, a parallel port could do that in 1-2 seconds, and usb could probably do it in milliseconds.

I have an Xplorer FX cartridge and the parallel port transfer was about 100kbytes/s.
The speed limitation is more on the psx side I guess, I also use 16bits CRC check per 4kbytes block transfer to avoid transfer corruption.

Some kind of an open standard transfer protocol (or driver interface) would be nice. I have a "upload exe via parallel port" function in no$psx, and it would be neat to also have a "upload exe via psx usb interface" function. With a generic "transfer-to-psx" driver, the actual transfers could even work with anything like usb, wlan, whatever.

The tool might be open source.

[nocash]

I'm using an FTDI USB chip FT245, an some 74 logic chip.

Only an USB FIFO, and some logic, without any microprocessor? And the photo looks as if you have a huge eprom or something similar...?

I'm not skilled enough to do fpga or stuff like that, this is my first real electronic project.

Me neither, I have never used fpga, and my experience with microprocessors is mostly from 8bit era. I guess some modern microprocessors could be fast enough to inject boot code to the MIPS data bus (but it could be challenging if it has to watch the USB bus simultaneously).

Do you have a reset signal implemented for automatically rebooting the console on each upload?

No

Must-have feature. It would be a bit awkward to do something like "Your transfer will start as soon as you push the reset button on the console (and/or all pictures with traffic signs)". Dragging /RESET to LOW is by far the easiest thing... unless your circuit does really only have that USB FIFO thing, and it spits out only raw data, without any additional control bits?

I have an Xplorer FX cartridge and the parallel port transfer was about 100kbytes/s.
The speed limitation is more on the psx side I guess, I also use 16bits CRC check

I am getting about 400Kbytes/s for Xplorer upload in no$psx utility menu. The PSX is so fast that it could transfer megabyte(s) per second (by software/polling with 74xx logic), and perhaps up to 66Mbyte/s (by hardware with 16bit dma).
The bottleneck are the parallel port waitstates on the PC side (about 1.3us per I/O access in DOS, plus more overload on Windows in protected mode). And the main problem was that the makers of the original Xplorer/Datel transfer tools were all stumbling over their own feet (like making many such I/O accesses for each single byte).

The tool might be open source.

One problem with DIY projects is that there are too many of them, and they are often discontinued before anybody could use them (creator lost interest, parts no longer avaible, etc).
For hardware that is intended to be used (and kept used) by many people, I was hoping for a simple open standard with a handful of basic commands (detect hardware, reboot, upload block, execute, download block, get status).

As for how to do that under windows, you do probably know more about that than me. As far as I know microsoft is putting restrictions on low-level driver creation, so you would probably need to have everything transferred through some generic driver?
Nethertheless, you could probably make some docs that describe the commands that are getting transferred, or make some high-level plug-in driver.

[Orion_]

Only an USB FIFO, and some logic, without any microprocessor? And the photo looks as if you have a huge eprom or something similar...?

no microprocessor, there is an eeprom of course for the software that handle the data reception and executing.
the pcb is a prototype with a bunch of debug stuff, the final cart will use TSOP/CMS so it will be much smaller.

Me neither, I have never used fpga, and my experience with microprocessors is mostly from 8bit era. I guess some modern microprocessors could be fast enough to inject boot code to the MIPS data bus (but it could be challenging if it has to watch the USB bus simultaneously).

I thought about it because I saw some projects doing this for 8bits computers, but we are talking of a 33mhz RISC cpu here so I guess this would require a pretty fast microcontroller to stuff data into the bus in realtime.

Must-have feature. It would be a bit awkward to do something like "Your transfer will start as soon as you push the reset button on the console (and/or all pictures with traffic signs)". Dragging /RESET to LOW is by far the easiest thing... unless your circuit does really only have that USB FIFO thing, and it spits out only raw data, without any additional control bits?

that would require a microcontroller

As this is my first electronic project, the idea was to have something working, not something with high end tech.

As for how to do that under windows, you do probably know more about that than me. As far as I know microsoft is putting restrictions on low-level driver creation, so you would probably need to have everything transferred through some generic driver?
Nethertheless, you could probably make some docs that describe the commands that are getting transferred, or make some high-level plug-in driver.

I'm using linux myself but it will be windows compatible, as I use FTDI chip, the drivers are available for Windows and linux.

[nocash]

I thought about it because I saw some projects doing this for 8bits computers, but we are talking of a 33mhz RISC cpu here

The 33MHz is for the cache, the external bus for the ROM is less than 2MHz. About same as many 8bit computers.

[nocash]

The FTDI specs say that the chip could support 1Mbyte/s, so it looks as if you are doing something wrong.
Are you executing your program code directly from ROM, in an uncached memory area? That would drop the CPU speed from 33Mhz to somewhere below 500kHz.
Or are you reading/writing lots of USB control/status registers for each single byte-transfer? That could be also slow, if you forgot to change the playstation's Memory Control waitstate settings.

But overall, the FTDI chip looks a bit too expensive. A microcontroller with USB support like STM32F070F6P6 would be much cheaper, it could do the same thing, and it could probably additionally replace the eprom and logic chips.

[Orion_]

The FTDI specs say that the chip could support 1Mbyte/s, so it looks as if you are doing something wrong.
Are you executing your program code directly from ROM, in an uncached memory area? That would drop the CPU speed from 33Mhz to somewhere below 500kHz.
Or are you reading/writing lots of USB control/status registers for each single byte-transfer? That could be also slow, if you forgot to change the playstation's Memory Control waitstate settings.

But overall, the FTDI chip looks a bit too expensive. A microcontroller with USB support like STM32F070F6P6 would be much cheaper, it could do the same thing, and it could probably additionally replace the eprom and logic chips.

Usain bolt can run 100 meters in just 9.58 seconds, can you ?
I'm not a programming or electronic guru trying to make the cheapest and fastest cartridge ever, I have not infinite time and money to make dozen of prototypes, I'm just trying to make something usable and available easily to the end user.
There are already open source cartridges with newer and faster FTDI chip available on the PCSX github since 2 or 3 years and yet no one released a final usable product, that's why I'm making my own, and making it available to people interested.
As you sure are a way better programmer and with lot more knowledge of the inner ps1 hardware than me, If you want to make a faster code, the specs will be available and you can reflash the cartridge chip easily.
As I said I'm reading the USB status register to check if a data is available + using CRC each 4kbytes to avoid corrupt transfer, so that is sure slowing down the process.

[nocash]

Hmm, I just tried to send some constructive or motivating feedback, as far as possible without seeing your unreleased open source code. But if you want to make it faster, you'll have to do that yourself, I could only tell you how.

Usain bolt can run 100 meters in just 9.58 seconds, can you ?

Yes, probably, I guess so. And I certainly wouldn't claim that I couldn't run faster because I had to do bloody crc calculations.

[Orion_]

Hmm, I just tried to send some constructive or motivating feedback

yeah like, "you could redo the whole thing using STM32" .... not very motivating on my side.

But if you want to make it faster

I never asked for that, you told me it could be faster, I don't care, I just want to get something working.

[szalay_1]

Hi! @orion
What about in future ?
Possible using modified e.g: Caetla or PAR.rom to using cheat codes and could manage them with savegames etc ?

[Orion_]

Hi! @orion
What about in future ?
Possible using modified e.g: Caetla or PAR.rom to using cheat codes and could manage them with savegames etc ?

this is a dev cartridge, not a game cheat cartridge.

[Orion_]

downloading VRAM from USB

[Orion_]

I updated the first post with a pre-order page and a demonstration video (english subtitles available)

[Orion_]

I made a short english video: