A week ago I received my first even PlayStation 1 with a couple of games. I already talked about it a little in the comments of my previous blog post. The main goal of my homebrew project has been learning about new consoles and how to write homebrew for them. And the PlayStation 1 will require some interesting challenges to overcome to make it interesting. Given that it's an old console also makes the hardware design a little easier to understand. I am not saying it's simple or anything...just that it's "easy enough" to learn in a relatively short time.
The PS1's GPU had a few quirks that make the 3D it generates a little...unique I guess. But my homebrew game is a 2D platformer so I will not be having that problem. I think. The low amount of memory, vram and loading from CD-ROM (or other storage) will all be separate milestone's or challanges. On thing that will be impossible is my current method of unpacking the gamefiles from the original installer and storing them on some form of local storage medium. Usually on most of the consoles that is an SD card...or memorystick on the PSP. But the "challange" on the PlayStation 1 is that there is no writable storage that is fast enough for this purpose. Or big enough even!!! I need about 8MB of installed space for the original files and a memorycard is only 128KB!
But before any of that becomes and issue I need a PSX development kit that works on my (kinda) modern Linux Desktop PC. And that is currently where I am running into a few hickups! I have been running Xubuntu 18.04 for a long time...and recently updated to 20.04. But the SDKI really wanted to try (PSnoobSDK) even though it's not really finished I believe requires VERY updated recent versions of various system components! I am not blaming the SDk's creator(s) but it is really sad that I can't easily use it now!
I really tried hard with compiling from the git repository, needing a higher CMake that I installed trhough a Snap package ...eventually it workedm but now the mips GCC compiler binaries that I had to download require a higher version of GLIBC!!!!! Why they are not compiles a statically linked versions is beyond me....and for now I gave up for a few days. The main reason for wanting this SDK is that it promises to have "limited C++" support ...and my current code is all C++ using classes and stuff. But beyond that I don't really use much C++ specific stuff so far as I know. I never had to think about it as every platform so far...except GameBoy Color...had a C++ compiler available for it! I'll figure something out with either docker or a VM later.
I have also been learning more about the PlayStation 1 architecture and history. I already knew about how it came from a failed joined operation with Nintendo for a SNES add on. And I had watched other video's about original PlayStation 1 developers from back in the day. Most notably how Crash bandicoot worked around the Sony SDK libraries to get more speed...and clever tricks to load/stream level data from the CD-ROM allowing for a much bigger and more interesting looking level. (going to borrow that idea
)
I also got most..if not all...components needed for testing homebrew on real hardware!
- I have a PlayStation 1 console...kinda obvious!
- And that PS1 is a model including the parallel I/O port
- In that parallel I/O port I have a "cheat cartridge" and flashed that with Unirom
- Just for completeness I also flashed unirom...or FreePSXBoot..to a memory card.
- And I got a Serial I/O cable (third party) that I cut in half and tested with an FTDI serial 2 USB board to my PC.
- Also to my suprise the system I received from a used retro console webshop was already fitted with a mod chip. So it can read CD-R's directly.
This whole contraption allows me to do the following:
- Boot into unirom in 1-2 seconds
- Select the serial interface....or maybe it's always listening, not sure yet.
- Download a memory card image from a card in the slot of the console to my PC.
- Dump the entire RAM
- And after I get the SDK issues resolved...upload a PlayStation EXE of my homebrew to execute on the hardware!
So I am not there yet to actually test anything on the real hardware related to my own homebrew yet. But as said I have the minimum required parts to make it happen. With the research I did I have a fairly good idea of how the PS1 hardware is working and what would be required to get something to show on screen. My plan is to convert the tracker music files into WAV and then burn them to CD-ROM as audio tracks. This will give me the music in good quality and there will be almost no overhead in the playback as the hardware will take care of it. This is how most of the official PS1 games do their music actually. It's just CD Audio tracks that are played back and send straight into the audio chip without the CPU having to do anything to move the data.
When I was still prototyping my homebrew game on the PC in Python I had it unpack ALL of the original game files once. Every bit of ZLIB compressed stream was unpacked and the raw bytes were dumped into files. I am planing to burn these onto a CD-ROM and as said also make the music playable as CD audio tracks. This will take a bit of research on how to actually convert the .XM files into .WAV and then the WAV into .BIN to include in a .CUE that can then be burned.
If this PlayStation 1 version of BatteryCheck get's far enough it will be one of the first versions of my hombrew that will not require the download of the original installer. And also because of this I have the possibility to convert the graphics and level files into formats that are easier to use on the PS1 hardware loaded from CD-ROM.
I am still hoping to find out that the memorycard slot is actually fast enough to allow an alternative storage device like an SD card to be used! I am aware that "memorycard access" is really slow, but most of that is because it's the flash memory itself that is too slow to do it faster! And with my idea I won't be writing to a MemoryCard but to an SD card...or most likely to a RaspberryPi Pico that is wired to the memory slot and has an SD card too. If the Pico can "talk fast enough" I think the thoughput could be really high. But I so far have not been able to figure out the actual hardware limitations. and the "Baud calculation" examples are a bit above my math skills. or I am too lazy to really calculate. Or both!
There are enough projects already that use a Pico as a memorycard "emulator/simulator" that as far as I know do not do out of the box what I am talking about here. But that does not mean it won't be possible! Also the commercial MemCard Pro does not provide file level access to the SD card. So I hope I can modify the "Pico MemoryCard" code and add in some extra commands in the protocol...or another way...that will give PS1 homebrew access to a "mass storage" device like an SD card!
Besides writing/porting my homebrew game to the PlayStation 1 I also want to look into what cool games are available on it that I never played before. Crash Bandicoot is one of them! I also really want to have the smaller PSone model just because it looks so cool and compact! Maybe even with the LCD screen for it..as a kinda portable version or something! But for the development phase of my Homebrew it will be basically pointless to have one! There is no parallel port...no serial port but that one can be soldered in! And when I get one I will definitely do that! I think I have seen that a parallel I/O port is also possible on the PSone...but that creates a spaghetti of wires everywhere and LOTS of soldering!
I have set the requirement for myself to have at least a working SDK and a compiled EXE that I wrote myself that will show the BatteryCheck title screen! It can be a static image for all I care! As long as it shows it on real hardware! I do think that is a fair requirement...right?
Not sure how long I can restrain myself from ordering one anyway! Especially since I have seen a listing of 4 consoles for about 90 euro's! Including controllers.! It's two original's and two PSone's! No games I think....but that's less than 25 euro's per console if you think about it. Sure...there are "some" issues with them. One of the big onces has no optical drive a all for example. But still...if the rest of the hardware functions well I don't care! I have looked up the model numbers and they both have the parallel port!
Yep, it's got long again. Thanks for reading.
The PS1's GPU had a few quirks that make the 3D it generates a little...unique I guess. But my homebrew game is a 2D platformer so I will not be having that problem. I think. The low amount of memory, vram and loading from CD-ROM (or other storage) will all be separate milestone's or challanges. On thing that will be impossible is my current method of unpacking the gamefiles from the original installer and storing them on some form of local storage medium. Usually on most of the consoles that is an SD card...or memorystick on the PSP. But the "challange" on the PlayStation 1 is that there is no writable storage that is fast enough for this purpose. Or big enough even!!! I need about 8MB of installed space for the original files and a memorycard is only 128KB!
But before any of that becomes and issue I need a PSX development kit that works on my (kinda) modern Linux Desktop PC. And that is currently where I am running into a few hickups! I have been running Xubuntu 18.04 for a long time...and recently updated to 20.04. But the SDKI really wanted to try (PSnoobSDK) even though it's not really finished I believe requires VERY updated recent versions of various system components! I am not blaming the SDk's creator(s) but it is really sad that I can't easily use it now!
I really tried hard with compiling from the git repository, needing a higher CMake that I installed trhough a Snap package ...eventually it workedm but now the mips GCC compiler binaries that I had to download require a higher version of GLIBC!!!!! Why they are not compiles a statically linked versions is beyond me....and for now I gave up for a few days. The main reason for wanting this SDK is that it promises to have "limited C++" support ...and my current code is all C++ using classes and stuff. But beyond that I don't really use much C++ specific stuff so far as I know. I never had to think about it as every platform so far...except GameBoy Color...had a C++ compiler available for it! I'll figure something out with either docker or a VM later.
I have also been learning more about the PlayStation 1 architecture and history. I already knew about how it came from a failed joined operation with Nintendo for a SNES add on. And I had watched other video's about original PlayStation 1 developers from back in the day. Most notably how Crash bandicoot worked around the Sony SDK libraries to get more speed...and clever tricks to load/stream level data from the CD-ROM allowing for a much bigger and more interesting looking level. (going to borrow that idea
)I also got most..if not all...components needed for testing homebrew on real hardware!
- I have a PlayStation 1 console...kinda obvious!
- And that PS1 is a model including the parallel I/O port
- In that parallel I/O port I have a "cheat cartridge" and flashed that with Unirom
- Just for completeness I also flashed unirom...or FreePSXBoot..to a memory card.
- And I got a Serial I/O cable (third party) that I cut in half and tested with an FTDI serial 2 USB board to my PC.
- Also to my suprise the system I received from a used retro console webshop was already fitted with a mod chip. So it can read CD-R's directly.
This whole contraption allows me to do the following:
- Boot into unirom in 1-2 seconds
- Select the serial interface....or maybe it's always listening, not sure yet.
- Download a memory card image from a card in the slot of the console to my PC.
- Dump the entire RAM
- And after I get the SDK issues resolved...upload a PlayStation EXE of my homebrew to execute on the hardware!
So I am not there yet to actually test anything on the real hardware related to my own homebrew yet. But as said I have the minimum required parts to make it happen. With the research I did I have a fairly good idea of how the PS1 hardware is working and what would be required to get something to show on screen. My plan is to convert the tracker music files into WAV and then burn them to CD-ROM as audio tracks. This will give me the music in good quality and there will be almost no overhead in the playback as the hardware will take care of it. This is how most of the official PS1 games do their music actually. It's just CD Audio tracks that are played back and send straight into the audio chip without the CPU having to do anything to move the data.
When I was still prototyping my homebrew game on the PC in Python I had it unpack ALL of the original game files once. Every bit of ZLIB compressed stream was unpacked and the raw bytes were dumped into files. I am planing to burn these onto a CD-ROM and as said also make the music playable as CD audio tracks. This will take a bit of research on how to actually convert the .XM files into .WAV and then the WAV into .BIN to include in a .CUE that can then be burned.
If this PlayStation 1 version of BatteryCheck get's far enough it will be one of the first versions of my hombrew that will not require the download of the original installer. And also because of this I have the possibility to convert the graphics and level files into formats that are easier to use on the PS1 hardware loaded from CD-ROM.
I am still hoping to find out that the memorycard slot is actually fast enough to allow an alternative storage device like an SD card to be used! I am aware that "memorycard access" is really slow, but most of that is because it's the flash memory itself that is too slow to do it faster! And with my idea I won't be writing to a MemoryCard but to an SD card...or most likely to a RaspberryPi Pico that is wired to the memory slot and has an SD card too. If the Pico can "talk fast enough" I think the thoughput could be really high. But I so far have not been able to figure out the actual hardware limitations. and the "Baud calculation" examples are a bit above my math skills. or I am too lazy to really calculate. Or both!
There are enough projects already that use a Pico as a memorycard "emulator/simulator" that as far as I know do not do out of the box what I am talking about here. But that does not mean it won't be possible! Also the commercial MemCard Pro does not provide file level access to the SD card. So I hope I can modify the "Pico MemoryCard" code and add in some extra commands in the protocol...or another way...that will give PS1 homebrew access to a "mass storage" device like an SD card!
Besides writing/porting my homebrew game to the PlayStation 1 I also want to look into what cool games are available on it that I never played before. Crash Bandicoot is one of them! I also really want to have the smaller PSone model just because it looks so cool and compact! Maybe even with the LCD screen for it..as a kinda portable version or something! But for the development phase of my Homebrew it will be basically pointless to have one! There is no parallel port...no serial port but that one can be soldered in! And when I get one I will definitely do that! I think I have seen that a parallel I/O port is also possible on the PSone...but that creates a spaghetti of wires everywhere and LOTS of soldering!
I have set the requirement for myself to have at least a working SDK and a compiled EXE that I wrote myself that will show the BatteryCheck title screen! It can be a static image for all I care! As long as it shows it on real hardware! I do think that is a fair requirement...right?
Not sure how long I can restrain myself from ordering one anyway! Especially since I have seen a listing of 4 consoles for about 90 euro's! Including controllers.! It's two original's and two PSone's! No games I think....but that's less than 25 euro's per console if you think about it. Sure...there are "some" issues with them. One of the big onces has no optical drive a all for example. But still...if the rest of the hardware functions well I don't care! I have looked up the model numbers and they both have the parallel port!
Yep, it's got long again. Thanks for reading.
