PPCenter :: devblog

PPcenter. Arts and craft for my Sega Saturn. Since 1847 :D

[Dev journal] Pseudo Saturn Kai game loader weird bug, and its bugfix

Written by cafealpha 3 comments
(Note : this bug was fixed something like 3 months ago. Pseudo Saturn Kai I first released last month works well  )

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.

data/images/20160325_loader_bug.tb.jpg
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

data/images/20160408_sakura_6008.tb.jpg
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 :
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

Iso/Cue "loader" works on real hardware :]

Written by cafealpha no comments
(For more informations, you can also read this old article.)

I finally had time to use my Saturn, and I could verify that iso/cue "loader" works on real hardware !
Of course it works well when reading from RomFs, and it works also well when reading file from SD card

data/images/20150626_iso_loader.tb.jpg
My test environment ... sorry for the mess
(Micro SD card is located on top-left of the cartridge)

I lost some time to understand why data transfer from SD card was slower than expected, but finally understand why : some debug/whatever delay routine was called when accessing cartridge registers ...
Just putting some #if 0 around this delay code solved the "problem" ^^;

Read more Iso/Cue "loader" works on real hardware :]

Iso/Cue "loader" works :)

Written by cafealpha no comments
So I am making an enhanced version of Pseudo Saturn firmware.
And, as an extra feature of this firmware, I added an iso/cue "loader".
data/images/20150603_dr.evil.laser2.tb.jpg

Why the quotes around "loader" ? Because it doesn't emulates CD-block
So, it only loads few homebrew games, but it's enough for me, and I don't want to waste more time on adding CD block software emulator while better solutions (rhea, jhl's "mpeg" cart, etc) already exist.

As an other bonus, I also added RomFs support to my Saturn library
It is like romdiskfs that is widely used on linux, DS homebrew, etc, but it allows file compression, some other features, and ... is probably buggy because I coded it from scratch

(*) Virtual file system is not really new on Saturn homebrew scene, because Piratero already implemented one in libyaul a while ago


data/images/20150603_romfs_filelist.png
RomFs root folder contents. I will load sl_elf.iso file in the next paragraph.

So here is a capture of yabause running sl_elf.iso, after decompressing it from virtual file system stored in Flash memory.
sl_elf.iso is "satdemo" made by CharlesDoty, grabbed from SaturnOrbit's examples (Thank you Rockin'B for making SaturnOrbit ! After 10 years, it still have it installed on my laptop's hard disk ).

data/images/20150603_isocueloader.png
yabause running Saturn demo from iso file, near SatLink software I use in order to debug my Saturn programs.

Very big thanks to the yabause team ! I grabbed the iso/cue loading routines from yabause sources, and it was very easy to port them

Edit : I removed unused code (CD Block emulation routines, etc) from iso loader module, and .o size dropped from 74KB to 18KB oO

Edit (2015/06/26) : I tested this code on real hardware, and it works too ! Please see this article for more details.

Read more Iso/Cue "loader" works :)

Rss feed of the tag