I’ll add more when I find time but have moved away from using PsyQ on dosbox and am now using sicklebricks bare GPU+pad example code as a base for these experiments. So far so very bloody good. Check it out (I’ll add the link soon)
Have had to switch back to sio for code upload duty as the usb controller is in use for host duties. I’ve got data transfer to pc working reliably in both directions now.
Also, am fleshing out the code with a usb stick browser using the inbuilt support offered by the ch376.
Thanks go out to sicklebrick for the examples and help, Nicolas noble for pcsx-redux openbios stuff. Also, big mention for Team Shinra.. they are an Amstrad demo group who have used the ch376 with the CPC.. their basic examples were invaluable in early tests.. thanks – I’ll be rigging one up to my CPC464 soon 🙂
Few screenshots below.
Oh.. and I made pong from scratch using the same code stuff.. I’m in the process of tidying it up and ill stick it up on GitHub. Be a easy thing to understand for anyone new to PSX home-brewing.
Since my last update haven’t done a great deal other than adding a second CH376 to my setup.
Main reason being, I can use one for Comms as a device and use the other as a host for connecting devices to. It was getting tricky juggling things around so thought this would make life easier.
The usb controller for Comms is working pretty well, psx-pc uploads are flakey but I can sort that later when I actually draft up some sort of packet based protocol to resend stuff when usb is busy. Sure it’s something simple, but chipping away at it was boring me so I needed to change to something else.
So got back to usb mass storage. Initially I was looking at using the 375.. however the 376 supports FAT12/16/32 so meant less work psx side. However, the documentation is difficult to read which has slowed progress.
So far I’ve got it mounting the usb stick fine, reads the size of the first partition and returning its size and free space. Also getting a directory listing. Next up is to get it to open a file and load it into memory. The screenshot below shows the debug output into a serial monitor. Nothing major.. but progress nevertheless 😁
Further to my previous post on using the CH375 as a USB host to enable the use of USB Mass Storage on the Playstation – so I thought I would look at device mode for a bit and see how hard it was. Idea being that this could be a faster alternative to using something with a PC Parallel port or SIO cable etc.
Here is the work I’ve done so far. First video was the first attempt at this. The CH372 datasheet is thankfully a lot easier to read, and more accurate than the CH375. I reference the CH372 as that is essentially the command set that is used by the 375 for device mode.
Video below is first attempt. Literally safe mode timing – didnt do anything other than ‘get it working’ Not exactly breaking speed records.
Whilst improving the linux client side of things – that naturally left me looking back at improving things PSX side. After a few attempts,I got trimming some values right down when reading the buffer.
The client is written in C using libusb. Current features are data upload to address, or upload EXE.. Playstation side of things is a small program that just loads the data into memory. It is currently running from the EEPROM on the Xplorer so can be loaded instantly at boot
Started to tidy up the code a bit and add some more features and error handling, and managed to quicken it up quite a bit… see below. Waay faster than the initial experiment.
Thanks again to the people over on the psxdev discord, especially Grumpycoder who helped with libusb examples and talking through endpoints and whatnot.
My experiments with communication and using a CPLD has had me thinking, far far too much probably. But yes, I started looking at what other devices we can attach to the Playstation,
We have serial, we have sound (I did consider an OPL2 just for shits and giggles), it already has CD. Keyboard maybe? Nah.. how about USB?
I started looking at some IC’s such as the USB3300 etc, and Grumpycoder over on the discord suggested a CH375B.
The CH375B supports USB mass storage, it also works as a CH372 (peripheral), so can be used for data transfer.
Quick google and these things are cheap, the datasheets are a bit shit to say the least.. I got more information by running the source code through google translate (it actually translates back to near perfect English).
Above is the connection scheme. Unless this makes sense to you, or you want to write your own software for it – do not spend time or money building this yet!
In the above diagram, you can see we just piggyback the CH375 straight onto the back of an Xplorer cart. I would recommend a standard Xplorer/Xpldoer, as we are re-purposing the SRAM /CE to drive the CH375B’s /CE. Obviously the standard Xplorer doesnt have SRAM fitted.
You could use an SRAM equipped model of xplorer, but then you would have to lift the SRAM /CE pin. I have also connected the /INT pin from the CH375b to the SEL pin on the DB25 connector (pin 17) – although this currently isnt used.
Anyway, to test the theory I wrote a little test program that talks to the device. It does very little other than query to check that a USB stick is attached, gets its size and reads two sectors of it into memory, you can see the output below :-
The screenshot above shows the first sector of a USB stick, loaded into RAM at 0x80100000.
The code is currently horrible, just a massive static list of commands that are run in sequence but it proves the concept works.
What can we do with this? Firstly, no it wont play ISO’s or backups – this will be for loading/saving data to.. be it memory card backup, bios dumping, loading homebrew.. whatever.
Ill be putting this into a git repo as soon as there is something worthwhile using. The idea is there will be some simple code you can use in your own projects to load/save data.
If you would like to contribute jump on the PSXDEV Discord.
Credits ;- thanks to the people who listen to my daft queries in #hardware on the discord. Not in any particular order but thanks to grumpycoder, sickle and everyone else on there.
This is a tidier version without all the other stuff attached. If you removed the header on the ch375 module and just soldered the connections the profile may be low enough to replace the case, and cutout for the usb stick/cable.
Covid 19.. nasty stuff. Been a funny old few months, stuck at home and whatnot. Not all doom and gloom though. This extra time for thought and tinkering leads us to some new and interesting learning.
So to rewind a bit, I have always had a bit of a thing for wanting to get away from having to use a PC parallel port for PSX communication. It was great and all but most modern PC’s lack this hardware. Also, not everyone wants to use old tools on an older machine.
So I thought about using a Raspberry Pi with an Xplorer, that works – see my previous post.. but what if there was no Xplorer cartridge available, and you wanted to build something from scratch? This is where the EPM240 CPLD steps in.
In this respect, its a bit of a waste of a CPLD really, but it just makes life easier. You could use a simpler approach using a simpler FPGA, or even a modern equivalent of a PAL/GAL.. but that means more wiring and complexity… and why bother? Using one CPLD is cheaper – they are around £10 for the board I used. See here
I needed something that would happily coexist with a cheat cart so I had the cheat cart to upload test code, so opted to use the Expansion 2 region, which is documented in noca$h psx specifications document.
By using A22, A23 and A13 I created a chip select using the CPLD that works at 0xbf020000 and 0xbf020001. Data is transferred via the lower port, the handshaking occurs on bit 0 of the higher port.
The CPLD is handling the address decoding for 2 x 8bit inputs and 2 x 8bit outputs which then allows 8bit bidirectional communications (xplorer as standard is 8 bits PC-PSX, and 4 bits in return). We then use 1 additional input and output for handshaking.
So what to do with said ports? Thats where the Raspberry Pi ZeroW steps in. Using WiringPi, we are using 9 inputs and outputs on the Pi GPIO. A simple client/server utility handles sending code over.
Speed is fairly respectable. Can you can dump the PSX bios in around 2 seconds. Sending something like n00bdemo (~130kb) is around 0.6 seconds.
As it stands I am not sure what route to now take.. Part of me wants to start from scratch and see if I can design something that uses the expansion 1 space that can then be worked into a actual simple cheap pcb design, so may not use the CPLD after all – I may look at going backwards and using one of those SPLD type modern PAL chips and use external 373’s and 245’s.
All fun and games. I write these posts as a memory dump, so this post will probably get more detail and images added to it.
See above. Xplorer on the back of the console (it provides the EEPROM and connection points). Then you can see the EPM240 stuck on the lid, and the RPi over on the right hand side.
The two USB devices are JTAG for the CPLD and a budget FX2 Logic Analyser.
Interested? Take a trip over to psxdev.net and join the discord. Its fairly active with quite a few projects going on.
Finally got around to making a PIO version of SIOLOAD.. So here we have it PIOLOAD. Not sure if/when i would release it, as its so simple and does little. Its just some code to test stuff with and make sure what ive done so far is up to the job.
Speed seems pretty good. Need to actually measure it – ill code something into the upload tool. Currently uses WiringPi library and the sendbyte function. Need to now really work on comms the other way around, which is always a pain in the ass..
More to come, and a video below showing the upload speed of good old n00bdemo.
The Xplorer has been modified so it powers the EEPROM at 5v from the regulator, and everything else is tied to the +3.3v supply. This means I can get away without having to use level shifters, as the Xplorer/Xploder is built for 5v.
Never understood that really, given the PSX IO is 3.3v.. 5v EEPROMS must have been cheap back in 1998? but yeah – saves a few ££ and means this works with just a fist full of DuPont leads 🙂
The case is currently removed from my Xplorer as I am going to connect the PSX reset pin to a free GPIO. This will mean I can reboot the console without having to be physically near it.
IN the meantime I will be tidying up the code, adding binary file upload function and when its working well, burn it to a ROM.
So using psxbasic as my base for experiments, I have added some extra commands to it to allow experimentation with the Xplorer. One of these functions is ‘xploadexe’, which lets you upload and execute a PSX-EXE using a Raspberry Pi.
The video below shows this in action. Nothing that impressive yet. The video shows me loading PSXBASIC over SIO, then using PSXBASIC to load an EXE. As you can see, it loads Lameguy64’s n00bdemo pretty quickly. Not bad for the first attempt!
Over the next few days I will get some timing code in there so I can get some real life benchmarks.
Still plenty more to do, but not a bad start. Hopefully want to get to the point where I have a RaspberryPi+Xplorer solution that means that the SIO port is free again.
Well, after not doing much with the PSX since the summer I’ve started to tinker again.
Nxflash is fine for now, and made me realise I needed to learn more about hardware.. so I thought why not learn by trying to get parallel IO working.. so I have spent the last few weeks experimenting with Arduino Mega.. then a Due..and now have gone full circle back to Raspberry Pi.
Reason being is price.. why bother with a Due (£18), Mega (£12) when I can get a Raspberry Pi Zero W for around £7