I recently added 32X support to my Sega Genesis emulator. While I’d say it was definitely easier than Sega CD overall, it wasn’t without difficulty, and much like Sega CD there’s very little public documentation aside from Sega’s poorly translated official docs from the 90s.
Sega released two hardware add-ons for the Genesis in an attempt to expand its hardware capabilities to enable more advanced gaming experiences. The first of these was the Sega CD, obviously a response to the PC Engine CD (which was fairly successful in Japan despite very poor sales in the rest of the world).
This is the fourth and final post in a series on the PlayStation SPU which will cover the remaining major features that were not covered in previous posts. This includes the noise generator (pseudorandom white noise), pitch modulation (dynamic pitch adjustment using another voice’s output), SPU IRQs (trigger IRQ when a specific sound RAM address is accessed), and the capture buffers (record recent samples from CD audio and two specific voices).
This is the third part in a series of posts on the PlayStation SPU (Sound Processing Unit). This post will focus on the SPU’s reverb feature, which can simulate echoes or reverberations. In short, it’s a much more advanced version of the SNES APU’s echo filter.
Where the last post focused on the PlayStation SPU’s audio format and how to implement ADPCM decoding, this post will focus on volume and envelopes. The SPU supports a number of different volume multipliers: some as constant volumes, and some as volumes that automatically adjust themselves over time using what are called envelope generators.
The PlayStation’s SPU (Sound Processing Unit) is definitely not the most logical next thing to work on after implementing a basic triangle rasterizer, but it’s what I feel like discussing next. With my own projects, I don’t feel like an emulator is really online until it supports audio, so here we go!
While the GPU tests I mentioned at the end of my last post are very helpful for validating a lot of GPU rasterization functionality, a new emulator might want the early satisfaction of getting the splash screen’s diamond to render mostly correctly. This post will overview what’s required to make that happen.
This post will overview what is required for a PS1 emulator to get any graphical output from test programs. PS1 test programs are typically designed such that they don’t use most (if any) of the GPU’s rasterization capabilities - they’ll either render their output pixel-by-pixel, or they’ll just copy the frame directly into VRAM using the CPU.
Two of the most useful things for a new PlayStation emulator to implement are EXE sideloading and TTY support. Supporting EXE sideloading makes it possible to load programs before any CD-ROM functionality is implemented, and supporting TTY output makes it possible to see debug output from the BIOS and from test programs.
I recently (ish) started to work on a PlayStation emulator. Compared to the previous systems I’ve worked on, it’s very different! It definitely feels like jumping forward a generation compared to the Genesis and the SNES. I’ll start off by covering the core of the system, the CPU.