Out of stock ":]". I'm glad to have finished this batch I don't plan to sell Gamer's Cartridge for a while, because stock of parts to build theses cartridges (electronics components, PCBs, labels, etc) is currently very low here. I'm even lacking of bubble paper used when shipping cartridges
So, what's next ? Of course, Saturn stuff I plan to use this "break" in cartridges manufacturing and sales in order to continue Pseudo Saturn Kai development. Main feature to add is cheat codes, which is a bit "heavy" one to implement, because processing in order to make cheat codes working isn't documented in details. But that will be done ! Also, there are some side quests here and there regarding Pseudo Saturn Kai features. I plan to implement as far I can, so it will be limited only by my free time, my motivation, and flash ROM remaining on cartridge
Gerber preview before ordering PCB on Seeed Studio, very classy and realistic
Edit (2017/05/11) : finally back in stock I catched the occasion to make some minor improvements to my homepage, such as adding anchor link to some sections, adding some directions for Japanese users, etc ... and I'm already full up with writing HTML
Edit (2017/05/12) : half of the stock already reserved oO
Cartridges are assembled by hand, hence stock is small, but I'm impressed anyway
(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.
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 :
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
Pseudo Saturn Kai Release Candidate 1 : flasher utility wasn't very intuitive to use → fixed. Release Candidate 2 seems to work fine, so ...
I officially declare Pseudo Saturn Kai version 6.036 as first publicly released version
Want to upgrade your cartridge firmware ? No problem, firmware installer, source code, and many other things are available from /pskai/#download address
Many thanks to beta testers who could make this project mature enough to be releasable And of course, many thanks to Pseudo Saturn team too
Note : this doesn't means that Pseudo Saturn Kai is bug-free ! But, I consider that Pseudo Saturn Kai is stable enough to open it to circle wider than beta testers. If you find a bug, please report it in Pseudo Saturn Kai official thread .
On my side, releasing Pseudo Saturn Kai was the occasion to : - Release Gamer's Cartridge (page is still not up-to-date, I shall update it soon) - Delete beta builds for testers : here is the delete log as a souvenir :
Completely unrelated : I'm experiencing troubles with my email provider (*1), and consequently plan to change to another one soon. (*1) : mail provider is sometimes messing up with email titles, such as
using neighboring (unrelated) conversation title when sending email ...
Y U NO MAIL ?
If you're waiting for one week or more for a reply from me, please re-contact me Email timeout value is "one week" : I'm not a machine, so please don't mailbomb me if I can't reply you soon
It's a long time USB dev cart is supported on Pseudo Saturn Kai, but it wasn't tested seriously elsewhere than my development environment. ... Until now
(Well, in fact, it was "until a couple of months ago", because I didn't had time to write this article earlier.)
So, a USB dev cart new user (Shazz) wanted to do some Saturn development : great
USB dev cart demonstration video (youtube). I used Shazz's USB dev cart to make this video, in order to be sure it worked well before sending it to him.
His dev PC runs under Linux ... I personally use Windows only, so I can't guarantee USB dev cart + Pseudo Saturn Kai will work correctly. "Maybe it will run fine with antime's ftx tool". "Maybe" Of course, it didn't worked
My first suggestion was "please use an old PC with Windows installed lol", but Shazz don't like such half-concession, and really wanted his USB dev cart to work directly on his Linux dev PC. As an USB dev cart manufacturer, I agree with him. As a programmer already busy with other projects and real life, I disagree ^^
But, Okay, Shazz is actually a cool and chatty guy, and sharing same mother tongue with me, so I will do it for him
The cause of the problem happening when using Linux + USB dev cart with Pseudo Saturn Kai is actually still unclear. With original USB dev cart firmware (nicknamed as "blinking screen", or sometimes "epileptic screen"), executing a Saturn program with "ftx" utility works fine. However, with Pseudo Saturn Kai installed, the same operation didn't worked and Pseudo Saturn Kai main screen was freezing (? or continuing doing menu things ? I already forgot about details about this bug It's really time to write it on this blog before I forget it completely ...) instead of switching to uploaded program.
I suspected Pseudo Saturn Kai ignoring two successive commands from USB dev cart ("executing" a program is actually sending an "upload" command, then "execute from specified address" command), especially because Pseudo Saturn Kai can't check for USB I/O continuously : it "just" does it once every frame.
Since I really couldn't understand why this could cause that "upload, then execute" problem, I decided to countermeasure it by adding a new "upload and execute" USB dev cart command. And on the same occasion, I also added the "à la carte" reset flags in this command : "one stone, two birds", as people in Japan would say ... I suppose that other people would rather say "one USB dev cart command to rule them all" :D
One more problem about this "Linux + USB dev cart + Pseudo Saturn Kai" problem was that I couldn't verify if everything is working fine or not. Shazz was OK to do some beta testing, but he can only upgrade his USB dev cart via USB link, so "breaking" USB transfer would brick his development cartridge. Around software development, I experienced enough Murphy's law and its corollaries to be sure it won't work on first try : - "If it can break, it will break" - "The less you test, the more likely it will fail on basic pattern" - "The more you test, the more likely it will fail on unexpected pattern"
So I added Pseudo Saturn Kai "demo" version As its name suggests, it actually doesn't do anything special else than showing menus, but that's enough in order to test communication with PC. Additionally, I also displayed some debug messages to screen when doing USB related stuff.
Pseudo Saturn Kai demo version showing USB activity logs on screen First two lines logs USB dev cart firmware version verification : even if used with old (not Pseudo Saturn Kai) version of firmware, transfer utility works
After testing many buggy versions of the firmware, Shazz tried the "20160323_test4" test pattern with his "parallax" test program, and ...
Could upload and execute libyaul example program from Linux via USB dev cart and Pseudo Saturn Kai !
Thank you Shazz for testing Pseudo Saturn Kai + USB dev cart Linux support !
USB debug port related support is always a hell for me and cartridge users (may not work on a given OS, etc), hence there are no plan to add it in release version of my cartridges. But even if it requires drivers and custom transfer software on PC side, debug USB connectivity is a must have when developing things on Saturn, so rather than dropping USB debug port, I plan to make a "USB + SD card interface" cartridge for Saturn developers only. And of course, I still continue to manufacture USB dev cart
Just a quick article about a Sega Master System demo made by a good friend : Be No Sqr
Be No Sqr description page screenshot Cut in two halves, because ... my laptop screen is wide type (10 years old laptops had larger and taller screens ... what a pity)
I didn't participated in this project ... in fact, I don't know anything about Z80 assembly, but that's cool to see my own nick listed in the credits page
)
) : cleaning up whole project and rebuilding everything prevents such kind of problem.
