(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
Read more [Dev journal] Pseudo Saturn Kai game loader weird bug, and its bugfix
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
Read more Pseudo Saturn Kai development : USB dev cart support
Today was a nostalgia day : I uploaded program to my good old TI-89 via "$4 parallel link cable" I made around 15 years ago, when I was high school student
My TI-89 and its "$4 parallel cable", still working
First, I wanted to use my 7 years old desktop PC with parallel printer port available ... but it stopped to work after 2 minutes of usage. However heavy washing of CPU fan (yeah, "washing" : I put it in the water, then used my hair dryer to dry it) solved this 
I then tried to install TILP program, but I was lost in installing GTK (
), and link related DLLs ... a real nightmare, and it didn't worked too ... (Sorry Lionel and other TILP authors ! Your soft is great, but its installer is a real piece of crap)
So I tried even older W32Tran8x, a program made under Win9x era.
Except DlPortIo that needed to be updated to work under Windows7, everything worked fine !!!
The simpler the better 
I will try to keep this way of thinking when creating Saturn programs or cartridges
Edit : I successfully installed GTC, an oncalc C compiler. Thank you Pollux (GTC author) for your great work
It's funny to program on a machine where sizeof(int) equals 2.
Read more Long time without using my TI89
During a while (one month or so), it wasn't possible to access page to post comment, but this is fixed now.
Sorry for the trouble caused, and thanks a lot to people in PluXml support forums
Read more Comments feature restored !
So I'm currently making a Saturn Backup Data Manager utility.
What's this ? It is a remake of "Memory Manager" utility present in Saturn BIOS.
Sega Memory Manager utility : main screen
It already exists, and can be used from BIOS, so why making such an utility ?
I have some reasons that pushed me making this, and one of theses is that Memory Manager user interface is very cheap, especially, it doesn't allows to select multiple backup data and copy/delete them. (Dear Sega, why didn't you developed this feature ??)
Also, there are some new features I would like to add, such as hex-edit of memory data ... I have very few time to play now (real life, children, cancer, etc), so 999 lives in Backup data is a must-have feature
This utility is currently WIP, so no download link is available right now, but it is WIP enough to publish screens on my blog
So here is what it looks like now :
Backup Data Manager Main Screen
Don't trust the development progress only by looking at the main menu : everything behind is far for being finished
But at least, menu library itself is more or less completed, and I'm very glad about this point.
Here is a comparison of data selection screens :
Data Selection (Sega)
Data Selection (this utility)
Yeah, I know that Japanese text is not displaying properly ... this will be fixed, but the priority for this is low, so please be patient.
And what is the green text display on Backup Data Manager screen ? This is multiple items selection
As a bonus, here are screens of Backup Manager running on real hardware.
Pictures were taken last September, when I still had a modchipped Saturn ready for use ... after that I was busy with medical stuff, and moving to a new apartment, so my Saturn I used for testing is currently hidden in a cardboard ...
Early version of Backup Manager, picture was taken 4 months ago.
Can you spot the differences with current version ? ^^
SatLink running on my 8 years old laptop, connected to my Saturn via USB dev cart.
This development environment is by faaar more convenient than $500+ vintage
development hardware/carts/whatever floating on ebay ♪
Among the things I would like to add before a release, there is the Saturn FDD support ... but I don't own Saturn FDD unit, and the cheapest unit I could find on auction sites costs 10'000 Yens, and the seller doesn't guarantee that it still works ...
I won't pay 10K Yens for a vintage objet I will only use once a year (and I fear my wife would trash it if she founds it ), so if somebody is ready to give some time for beta testing with Saturn Floppy Disk Drive, please let me know in the comments
Read more Backup Manager - Early Version #1
