Luke

I started work on the MDEC (Macroblock Decoder / video decoder), and It’s going pretty well so far. Emulating it is pretty simple since it only has three commands, and all the decoding logic is documented as pseudocode on PSX-SPX, so it was straightforward to translate that to rust code.

So far I’ve only implemented decoding 4bit and 8bit colour-depth (monochrome) frames, and I ran into an issue where the test I was using was either outputting garbage or a white square. After A few hours of debugging I eventually figured out that this was causing by:

1. Not writing to the quant tables and scale table properly (I wasn’t converting u32 input words into u8s and i16s properly)
2. Not clipping the output to 9bit range correctly

After fixing those two issues I’m now decoding video properly! Unfortunately not a single PS1 game actually uses the 4bit/8bit modes, so I cant actually play any videos yet :/. At least now I can run the 4bit/8bit MDEC tests (which just prints a tiny heart to the screen).

Next I’m going to work on the 15bit and 24bit colour modes so I can actually play FMVs in my emulator (which should fix the majority of games that have issues atm).

Image: the 8bit MDEC test running correctly

Still haven’t had a lot of time to work on this because of school but I have made a bit of progress.

I finally figured out why CD audio was making a buzzing noise, it was a really stupid bug lol: When I was reading the audio sector, I wasn’t including the first 12 bytes, since in data sectors those bytes aren’t included in reads, but CDDA audio uses the entire sector, so I was skipping 12 bytes of every 2352 byte sector, causing a high-pitched buzzing noise. I thought it was something complicated like an issue with volume clamping or the SPU (PS1’s sound chip), but no it was super simple and was just a 4 line fix lol.

Another stupid bug that I’ve been stumped by for months is this issue where a game will start sending garbage data to the GPU, overwriting all the textures. Again, I thought it had to be something super complicated, so I combed through all my CDROM code to try and find an issue with how I was reading data from the disc, and I found a few minor bugs but it didn’t fix what I was trying to fix (I was stuck on this for ages lol). I Also looked at the DMA controller but still nothing (although I did find some clues).

By this point its 4am so I went to bed, but in the morning I discovered the actual cause of the bug, and it was literally two characters that were causing this whole thing. In the GPU, I was storing the length of the transfer in a u16 instead of a u32, so if the transfer length was two large it would just truncate the value to 16 bits and the GPU would go out of sync with the DMAC, causing it to interpret DMA data as GPU commands, corrupting VRAM. To fix this I just changed it from u16 to u32. I stayed up all night trying to fix this and the fix was just 2 characters >:(

This fixing this one issue fixed most of the games that weren’t working before (to some degree at least)! Next I’m going to work on the video decoder (MDEC).

The results for the game jam are in (actually voting finished months ago but i’ve been too busy with school to write a devlog lol), and we actually did really well!

Out of 95 entries / 84 new games, we came:

• 6th for theme integration
• 7th for innovation
• 12th for art
• 14th for sound design
• 18th for presentation
• 28rd for accessibility
  …and 14th overall!

The jam is over (actually it ended a few days ago but i forgot to post a devlog so im doing it now)! I managed to get a few more minigames done before the deadline by reusing code from previous minigames (which led to me accidentally overwriting the code of one minigame with another accidentally lol), and we actually ended up with 16 minigames, (originally we were aiming for 15). Also, while i was at work one of my friends who did most of the art for the game composed a soundtrack which gets more intense as the in-game time ticks down, which sounds great imo.

The main thing that needed to be done on the last day of the jam was the intro cutscene, which explains the premise of the game. My friends did all the art for it then I put it all in godot and scripted it, which was suprisingly simple thanks to godot’s super flexible animation system.

I said in the last devlog that I might need to sacrifice my sleep schedule to get the game done in time, and that did end up happening :(. We stayed up till around 3am getting everything finished, and I had to export the game like 5 times because each time I exported it I found some game-breaking bug that needed to be fixed. We did eventually get everything exported and working properly and submitted the game to the jam! I’m really happy with the way it turned out (its WAY better than the last game jam me and my friend did). You can play it in a web browser or on windows (I was too tired at the time to export it for MacOS or Linux but it’s open-source so you can do it yourself if you want)

Heres what the intro looks like:

We’re in the final 24 hours of the jam! The game is nearly done now and we’ve made a heap of progress. Right now we’ve made 13 minigames, 4 distractions, and gotten pretty much the entire gameplay loop done. Right now all thats left to do is adding some sound effects (and hopefully a soundtrack), finishing off the last few minigames, and making the introduction. I’m pretty confident we can get it done in time (although I have a 5 hour shift tonight so that might mean sacrificing my sleep schedule lol).

Heres a sneak peak of some of the gameplay:

the jam is halfway done! Since this is my first devlog I’ll give you a rundown of what the game actually is:
The theme for the jam is “out of time”, and after a few hours of brainstorming (mostly about time travel lol), we came up with the premise for the game: you have ADHD and have to manage your time effectively to complete tasks (writing an essay for homework, stocking shelves at work, etc) in the form of minigames. You need to keep an eye on your concentration (which goes down when completing boring tasks and up when doing fun tasks) otherwise you will get distracted.

My friends are doing all the art/sound/music while im going all the coding and stuff in Godot. I spent the first few days getting the main structure of the game down (i.e the core gameplay loop and ui and stuff). The idea is that for each tasks you need to complete a series of minigames (e.g for going to work: get to work, stock shelves, serve customers, etc), and during those minigames if your concentration goes down you start getting distracted (things that popup on your screen which obscure the minigame, e.g your phone).

Right now we’ve done 5 minigames and two distractions (we’re thinking we’ll need like 15 minigames total), so theres still plenty of work to do but its starting to come together.

I haven’t really made much progress over the holidays (lack of motivation), but I have gotten controllers almost fully working! This means instead of using my keyboard to use the emulator I can use an actual controller (e.g a dualshock 4).

Getting basic controller input was pretty simple, although it took a while since i was a bit rusty from doing basically no coding since SoM. Initially I made Gilrs (the gamepad input library) select the first controller that connects to receive from, but for some reason my computer has a non-existent gamepad called HID-compliant game controller which always connects first, so annoyingly I had to hardcode it to not connect to controllers with that name :/.

Getting analog input to work was a bit more complicated, as in the emulator i was emulating the digital controller (which doesnt have joysticks). I decided to instead emulate the dual analog joypad (which was only on sale for a year before it was replaced with the dualshock 1), which has two joysticks but doesn’t have vibration motors. I chose not to emulate the dualshock 1 because it uses a different communication sequence which can stop games from booting if not implemented perfectly.

After that i wanted to start improving the CDROM drive emulation - in particular I wanted to improve CDDA audio sound quality (there is a buzzing noise in the background of every CDDA track for some reason), and get the BIOS CD player/audio visualiser working. For now I have hacked in support for the CD player by making the bios think all CDs are audio CDs. To get the audio visualiser working I needed to implement a weird edge case where 16-bit writes to the DMA controller are treated like 32-bit writes (the BIOS writes 16 bits when it should be writing 32 bits). Getting all this working should hopefully make debugging CDDA audio easier.

Video: the BIOS CD player / audio visualiser (i’m also using a controller in this clip, but you cant see that obviously).

I haven’t had a chance to work on my emulator for about 3 months (since SoM finished), so im hoping to make progress towards actually finishing this emulator over the winter holidays (you can’t really ever finish an emulator though - you can always improve the accuracy).
\n

What im hoping to get done:

• physical controller support
• analog/dualshock controller emulation
• improving the accuracy of the CDROM drive
• FMV decoding (MDEC)
• CD-XA audio
• memory cards (maybe - there super painful to emulate because of timing quirks)