[Dev journal] Pseudo Saturn Kai game loader weird bug, and its bugfix
Written by cafealpha
3 comments
Classified in : Saturn, Programming
)First : of course, old versions of Pseudo Saturn (versions up to 0.832) work
But who knows what may happen when doing software engineering (and any other engineering in fact) : it's very common to break something without directly modifying anything to it !
So it happened : in December 2015, Pseudo Saturn Kai beta tester reported that it wasn't possible to load CD-R game.
What game loader bug looks like.
disc_type=0x0003 means that CD-ROM authentication failed
As usual, I first asked if something was wrong on tester side
"Bad game dump ?", "Bad burn to CD-R ?", "Did you do something else bad ?", etc.(I know that's a bad habit to suspect beta testers doing something wrong, but it sometimes help in fixing problems)
Beta tester was actually doing his job well, and bug couldn't be reproduced in next beta version, so I though it was caused by outdated intermediate file in build process (this happens, for example when I modify header file only : I'm too lazy to fix makefiles about this
) : cleaning up whole project and rebuilding everything prevents such kind of problem.But I wasn't satisfied with such "half-baked" bugfix, and actually could hear it saying to me "I'll be back"
And, two months after that time, I receive same bug report from same beta tester ...
Well, at least, I didn't had to re-ask him if he tested correctly or not : it was clear that this was December 2015 bug returning back.
First, let's verify do simple things and try to reproduce the bug here : my "main" dev Saturn is a modchipped one that plays CD-R, even when firmware is reported not working. Trying with a "plain" (unmodded) Saturn actually reproduces the bug : cartridge boots, but definitely doesn't want to play CD-R.
In same conditions, let's try with an old version of the firmware : oh, it can play CD-R
So I could "feel" the bug, and its capricious nature.
"Typical" capricious bug is "uninitialized global variable" one, that reproduces after doing the same action twice, or after going to a given screen, returning back to another screen, and doing a given action.
Saturn has relatively few RAM available, and I don't want to use dynamic memory allocation on such "low specs embedded device", so such "uninitialized global variable" happens from time to time.
But this bug was even more capricious than "uninitialized global variable" one : same action reproduces the bug with a given firmware, but can't reproduce the bug with another firmware
First, since I have no idea about the cause of such bug, I added some debug screen that displays few details (= the return values of each functions called when unlocking the CDROM unit), and also some text-based logs, plus RAM dumps stored SD card : that was one of the reasons why I made SD card-based cartridge for Saturn : it allows to prepare bug report on user side
So I "just" have to wait until bug is reproduced with next versions, and beg for logs/dumps/etc on that time.
Of course, the bug reproduced, and of course ... logs/dumps/etc didn't helped a lot
Game loader failure screen.
Basically, it shows that something is wrong after
calling cd_move_sector_data_cd_auth function.
Fortunately, there are some explanations about Pseudo Saturn CD unlock exploit on assembler forums :
"Immediately" : firmware have to be fast on step 4.
And what changes in CD-ROM unlock code from a firmware beta version to another is basically its execution start address.
So I started to think : "maybe CD-ROM unlock code will work better if loaded from a constant address ?" : to do this, I moved all CD-ROM code to a separate stub, loaded from a constant address (0x06004000).
And bug didn't reappeared so far
Okay, this way of fixing things without a proper verification is a bit dirty
But it works, and that's the most important
(I suspect the cause of this bug related to SH2 cache : if SH-2 have to refresh cache during time critical section of CD-ROM exploit, code takes too long to execute, and CD-ROM exploit fails ... it's just a guess, and I realized about it after fixing it.)
Special thanks to Stac, Shazz and A Murder of Crows for beta testing
And special thanks to jhl and CyberWarriorX for detailing Pseudo Saturn's CD-ROM exploit ! This helped a lot in fixing this bug
1. Use the Put Sector Data command to put a whole bunch of sectors into the CDB - all with FAD 150, Mode 2 in their headers.
2. Call End Data Transfer to push them into the selector.
3. Call Copy Sector Data, starting a copy of all those fake sectors into the selector that the Authenticate Disc command will be using.
4. Immediately (like 15 microseconds later immediately) call the Authenticate Disc command, specifying the same selector.
"Immediately" : firmware have to be fast on step 4.
And what changes in CD-ROM unlock code from a firmware beta version to another is basically its execution start address.
So I started to think : "maybe CD-ROM unlock code will work better if loaded from a constant address ?" : to do this, I moved all CD-ROM code to a separate stub, loaded from a constant address (0x06004000).
And bug didn't reappeared so far
Okay, this way of fixing things without a proper verification is a bit dirty
But it works, and that's the most important
(I suspect the cause of this bug related to SH2 cache : if SH-2 have to refresh cache during time critical section of CD-ROM exploit, code takes too long to execute, and CD-ROM exploit fails ... it's just a guess, and I realized about it after fixing it.)
Special thanks to Stac, Shazz and A Murder of Crows for beta testing
And special thanks to jhl and CyberWarriorX for detailing Pseudo Saturn's CD-ROM exploit ! This helped a lot in fixing this bug
Read more [Dev journal] Pseudo Saturn Kai game loader weird bug, and its bugfix
