Tag debug - PPCenter

Pseudo Saturn Kai 6.074 released !

Written by cafealpha 04 august 2017 2 comments

Pseudo Saturn Kai 6.074 released ... more than three months ago

Sorry for the late news, but that's still some quite acceptable delay in comparison to frequency I post articles in this blog

The release was initially announced on SegaXtreme forums, because it is my favorite forums for Saturn things (more than 11 years I registered to it !
Big thanks to the forum moderation/maintenance/support team for their steady good work

). Also the news was announced on SegaXtreme first ... because writing an article there takes less time than writing an article on my blog

So since I'm a lazy person, let's slightly arrange this article from what I wrote on SegaXtreme forums !

What's new in this version ? Well, there's basically, not a lot of major features (sorry !), but fix of a critical bug affecting Gamer's Cartridge, and addition of some "minor, but that I wanted to add someday" features.

＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Features for Gamer's Cartridge users

Indirect Dump : Dump cartridge (boot cartridge, or official memory cartridge, or any other cartridge) by compressing its contents to internal backup memory, and then extracting it to SD card when Gamer's Cartridge is inserted.
Because of small size of internal backup memory, it may be required to repeat the "insert memory cartridge → Indirect Dump → Turn off Saturn → Insert Gamer's Cartridge → Indirect Dump → Turn off Saturn" cycle several times, but at the end cartridge is dumped

Requires some motivation and free time on user side (It took me 45 minutes in order to dump my good old very first official memory cartridge), but this way of dumping doesn't requires to unsolder cartridge memory chips, which is the most important for me !
Note : if you are the lucky owner of Saturn FDD, then floppy disc is used instead of internal backup memory, and consequently dump is significantly faster and simpler.

Left : Screen display after compressing dump data
to internal backup memory
Right : Screen display after writing dump data from
internal backup memory to SD card
Theses pictures were taken on Indirect Dump's first successful test

One extra application of this feature was to dump ROMs from legacy cartridges such as X-Terminator, Satellite, ST Key and "8MEG memory cartridge". Curious people wanting to test theses cartridges theses ROMs can found them available for flashing (at your own risks) in Pseudo Saturn Kai Save Data Manager.
Special thanks to A Murder Of Crows, AtariBorn and SaturnGuru who dumped their cartridges ... and reported many bugs from early versions of Indirect Dump feature

Indirect Dump development : the cut scenes
Left : dump data corruption (see below for details)
Right : Dump file CRC check error. Fortunately, only dump
computation routine was buggy, and dump feature itself was working

Save Data corruption bugfix : This corruption problem concerns saves on Saturn internal memory, with save data size making save sector allocation table finishing exactly at the end of a sector. Very few games are concerned, and the only example I could find so far is Albert Odyssey.

I found this problem when testing Indirect Dump : data compressed then written to internal save memory wasn't then correctly read and decompressed to SD card.
I initially thought this problem to be caused by Indirect Dump itself, because at the time I had this problem, I just finished to mess with data alignment error when preparing indirect dump's compressed data, so thought that this was the next bug to fix regarding Indirect Dump

Quick investigation showed that contents of read data wasn't as expected, with a small portion of data being same as data at unrelated offset ... so maybe a problem when compressing and adding header etc to Indirect Dump save data ? It took me then a around one hour of testing and code review until I was sure that culprit was actually not Indirect Dump itself, because re-read of save data didn't matched with written save data !
Then, testing Indirect Dump with same input data and virtual memory cartridge disabled worked as expected, which 99% confirmed that problem was located on virtual memory cartridge side !

So yes, "virtual memory cartridge" actually manages save data handling for all backup devices (internal save memory, memory cartridge, and even Saturn FDD too) : this is possible because Gamer's Cartridge hooks Saturn backup library at relatively high software level.
In comparison with 1:1 hardware emulation of save memory cartridge, this has the advantage of being free of capacity limitation inherent to memory cartridge's chips, and also allows to store save data individually on SD card (two files per save, vs big file containing all saves for 1:1 cartridge emulation). On the other side, all the save data handling software has to be re-written, so care has to be taken when re-implementing it

So, this is quite an uncomfortable bug I have to face : save data are corrupted when being written to internal save memory, and Gamer's Cartridge was released around 6 months before, with consequently cartridges potentially corrupting save data in the wild.
Fortunately, while being hard to find, the bug wasn't hard to fix

Basically, this was a timing error when updating current save data block ID, as described below :

Internal Save Data corruption related source code
Left : before fix
Right : after fix

Since I really didn't want to fix half of the bug (and having to fix the remaining half on other release), next step is to add a test bench tool for internal save data memory access !
"Test bench" is a program that automatically tests a lot of patterns for a given function or module. Ideally, all major modules should have their test bench, but in the real world, making test bench programs takes time, so programs are usually manually tested with 2 or 3 patterns, and then developer prays for all other patterns being bug-free

... And to tell you the truth, this test bench was the largest one I wrote so far

It's not impossible a bug to be still hidden in an untested pattern, but anyway I'm quite confident about the reliability of internal save data support now

Here is how test bench screen looks like on my dev environment :

SatLink and Yabause couple showing test bench screen.
SatLink and Yabause : my best friends when testing Saturn programs

Screen copy above was taken after fixing internal save data support, and I forgot to take a similar screen copy when bug wasn't yet fixed ... latest Save Data Manager CDROM's + Gamer's Cartridge with firmwave 6.037 should display error in test bench screen, so it would be funny to try it ... maybe someday

BTW, Test Bench is still available in Save Data Manager CD-ROM (it took me a bit of time to add test bench screen, so didn't wanted to remove it after fixing internal save data corruption bug !), but this test bench screen requires a trick in order to be accessed : did you found it ?

That's all about internal save data corruption : I fixed it, and checked a lot of patterns about internal save data access, so similar problem shouldn't happen in the future !
Additionally, I didn't received any feedback from users about this bug, so let's hope it didn't corrupted game saves elsewhere than on my dev laptop

Autodump : Automatically dump saves from internal backup memory to SD card, so that they can be restored in the case they are lost because of depleted CR2032 battery, or save data manipulation error, etc.
With this feature, you won't have to say anymore "I lost all my saves because of that $%QTY@!#% CR2032 battery"

Since this feature uses SD card, it is available on Gamer's Cartridge only. And no, I won't write save data into Action Replay's cartridge flash ROM : flash ROM chips are not designed in order to be written frequently, hence using flash ROM as read/write storage area may prematurely brick your Action Replay cartridge.
If you're not convinced about flash ROM limited write cycles, I can make some "cartridge self destruction" feature that would continuously write and erase random data to flash ROM, but don't claim that your cartridge no longer boots after that

An alternate solution in order to keep internal save data change the chip holding internal save memory to a FRAM one that doesn't requires battery to retain saves data, as detailed in db-electronics.ca.
(there are maybe other alternate solutions, so please let me know in the comments if I missed one)

The advantage of this FRAM mod is that saves are not lost when CR2032 battery is depleted. There are however several disadvantages :
- This is an hardware mod, which requires to remove a chip, then solder another one, hence quite difficult to do.
- CR2032 battery is still required in order to keep clock and language informations.

For being the developer of Pseudo Saturn Kai and Gamer's Cartridge, my opinion is a bit biased, but autodump is a better solution, because autodump is not an invasive mod (plug cartridge vs change chip on Saturn motherboard), and the FRAM solution doesn't allows to dump save data to modern media device. Anyway, I don't force you to like my projects, so if you don't like autodump, then don't use it

Virtual Floppy Disk Drive. Simulate Saturn Floppy Disc Drive (FDD) behavior, with save data stored on SD card.
This feature Worked fine with Dezaemon 2, which can now handle 10 saves at once (5 saves from cartridge, and 5 other saves on FDD

), but I didn't tested for other games using FDD, so any feedback is welcome.
This is a feature available on Gamer's Cartridge only too. Thanks to this feature, floppy disk access is available without having to plug any floppy disk drive to Saturn

＿＿＿＿＿＿＿＿＿＿＿＿＿＿

Features for Action Replay and Gamer's Cartridge users

Proper support of FDD in Save Data Manager : Save Data Manager now supports both two partitions of Saturn floppy discs for all common operations such as copy, move, delete, import, dump, etc.
Special thanks to Dezaemon DB for big assistance in beta testing

Backup devices informations from Save Data Manager :
First device is internal backup memory : the easiest to handle
Second device is backup memory cartridge,
unconnected (zero partitions detected) in this picture
Third device is FDD : two partitions, wrong unit ID returned,
and always set at third position in devices information
array, even when cartridge is not available.
Basically, FDD is a real trouble-maker when trying to handle backup devices

Save Data Manager development cut scenes : trying to format FDD
(format for both two partitions is displayed in a single picture)
Don't worry about the horrible display of error
messages : it's (finally) improved in version 6.074

Soft Reset Patch : Change the "A+B+C+Start key combo" soft reset from "exit to multiplayer screen" to system reset. This idea is not from me, but from neuroacid (rmenu developer).

More saves to import from Save Data Manager. The most noticeable addition is saves from Urawaza Dataro cartridge, containing quality saves for Japanese games. Special thanks to Madroms for dumping the cartridge, and providing me its dump file

Other : Fixed many bugs, and added other bugs ... the usual routine

(Not a software feature, but) future users of Gamer's Cartridge may appreciate the couple of new labels, designed by beebaraka-sensei (twitter) for artwork itself and Dezaemon DB (twitter) for the final editing of the labels. Many thanks to them for the very good work !

Dezaemon-themed labels ... could you find out the odd label ?

The design on theses labels is themed on Dezaemon 2, and as you can see, the Dezaemon character on the game cover grew in the right way

I personally do appreciate the white themed one

Before being asked "where are the cheat codes ?", please let me reply :)
Cheat codes support is still under development. Menu in order to select game and its cheat codes is 90% done, but the bit of code in order to apply codes is still TBD. I didn't touched this feature for around half a year mostly because of lack of free time, motivation, and being busy in developing other features. I plan to finish this for "next-next release" however.
Update three months after writing the explanation above : cheat codes on Pseudo Saturn Kai are working on few games !!

There are many things remaining until reaching an "OK to release" state, but at least the cheat codes core feature seems to work, which is quite a relief for me :)

By the way, there's a trick cheat codes selection menu in Pseudo Saturn Kai 6.074 : did you found it ? It won't do anything else than showing games list and cheats for each games, so it's not worth spending more than 10 minutes in looking for the appropriates key(s) combo and timing however.

Yes, this release have (at least) two Easter eggs available

Coincidence with release timing during Easter period ? I think not

Apart from cheat codes, there are many other things scheduled for future releases : I initially planned to release everything at once, but had to make this intermediary release in order to fix the save data corruption bug on Gamer's Cartridge, so stay tuned

PS : Special thanks to Stac for beta testing

All the features above wouldn't exist without his help !!!

Bit shift in Saturn minimalistic C program

Written by cafealpha 14 june 2017 4 comments

While making a Saturn program running directly from ROM, constraint is usually to have program as small as possible. Why ? Because I would like to make Pseudo Saturn Kai continue supporting Action Replay, which have limited ROM size

So, in that situation, I use homemade, minimalistic stdlib, containing usually only memcpy and memset functions, and everything goes well.
But for some reason, current program was begging for __ashlsi3 and __ashrsi3 functions.
... What's these things ? __ashlsi3 is an assembly function doing left shifts of data, and as you probably guessed, __ashrsi3 does the same, but with right shifts

No problem, let's ask my friend google, and copy & paste theses functions without minding about their contents

Theses functions are standard functions provided by C library, so sources can be found here and there.

An example of what __ashrsi3 function looks like

A day after that, here comes the time to do basic testing of this ROM code

Let's first start with simple things such as screen display ...

Text display ... not as expected ?!

Hrm, it's probably a problem in my printchar routine ?

printchar source code : this is the core thing
behind text display in my programs

But that's a very long time I didn't touched this routine, which works well on Pseudo Saturn Kai, and works even better in vdp1ex from Charles MacDonald sample programs, because all my printchar routines come from there

But just in case of, let's try to tune one " <<3 " into " *8 " in the code above, and see if that changes something. Theses two operations are equivalent, so this should give the same result, but ... Saturn screen becomes all black

Okay, there's definitely something weird regarding that printchar, but I just re-used it as-is from other project, so what's going wrong with my it ?!
[...]
And then (finally) a light-bulb above my head appears

Maybe there's something wrong regarding the __ashlsi3 and __ashrsi3 routines ?
And, yes there was something wrong regarding theses routines ... I wrote a paragraph about them on the first half of this article, so it would be surprising the problem came from somewhere else

In more accurate words, routines are OK, which is normal since they are written by people smarter than me

But the calling convention of __ashrsi3 was not as my gcc was expecting ?
Well, that's just a guess from the display results, because it seems to display the same pixel 8 times on each row of a given character, which may happen when ignoring shift parameter in __ashrsi3 function.

Anyway, rather than finding in details what's wrong, let's fix the problem

First, with assembly by hand, in desperately trying to change input parameter handling ... I don't remember exactly what I wrote, but that was something like pushing a register to stack, moving parameter to it, finally restoring register, putting nop instructions everywhere, etc ... nothing difficult, but over my extent in assembly programming

The result is ... a mixed success :

Trying to modify __ashrsi3 routine by hand ... well, it seems that
some shift values are not correctly handled

Okay, so let's re-ask google about that __ashrsi3 routine ... and a different implementation arrives in search results. Let's try it

__ashrsi3

And the execution result :

Execution result with second version of __ashrsi3 function

Yeah, it works this time !!! And don't ask me why, because I didn't took time in understanding what's different in that second version of __ashrsi3 function

And, rather than understanding why it works ... let's close that assembly pandora box before some other mystic bugs pop from it

I will probably see about this in the future, but that was absolutely out of the scope of today's programming, and in software world, too much digression leads to freeze of projects, which I would like to avoid in order to go forward to next pending project

As a example, I started to adapt yeti3d engine to Saturn in 2010 (7 years ago !), and this ended in ... developing a SD card based memory cartridge for Saturn !

The point above is is not a joke : menus used in my yeti3d adaptation are the origin of menus used in Pseudo Saturn Kai, which shows the continuity (co-consanguinity ?

) in my projects. And after getting yeti3d working a bit, I really would like to load levels from something else than CD-ROM, which was from PC (via adequate link cable) on a first time, and which will (should ?) then evolve to SD card.
That would be cool to make a Saturn game not requiring to burn CD-ROM somedays, but before that I need to finish neighboring side quests

Evolution of my Saturn projects

To conclude this article, let's say it was terribly fun to see some bits of the internals behind C language

By the past, I remember I did something similar with my yeti3d adaptation, but remained at "C language level" : optimization done at that time was (IIRC, ) to avoid 4 bits shifts, because theses are not available in a single SH-2 CPU instruction. Avoiding 4 bits shifts was simply done by merging two fixed point operation in a single one (or something like that : I did this 7 years ago !), and this actually gave some improvements in 3D scene rendering

Theses were the good times ... I sometimes think "I'm Getting Too Old For This Shit", but that's only to motivate to finish my old projects

But before that, Pseudo Saturn Kai, and then Kicad and Quartus are waiting for me

BTW, in the case you wondered about what was today's programming session, you probably guessed it was about exception handler addition to Pseudo Saturn Kai. This not a new feature, since it was available in Pseudo Saturn 0.83x ... in fact, I grabbed some sources from Pseudo Saturn 0.83x in order to implement this exception handler (thank you CyberWarriorX !)

This exception handler will be available as a small add-don to cheat codes feature in Pseudo Saturn Kai next major release.

Pseudo Saturn Kai no longer working on Action Replay ... and its rebirth !

Written by cafealpha 03 august 2016 2 comments

So TehNewParalyzer told me he likes Pseudo Saturn Kai and plans to put many Pseudo Saturn Kai videos on his youtube page.
Very good ! That's great to see people still enjoying using Saturn nowadays

data/images/20160803_action_replay_metal_slug.tb.png

Metal Slug with Action Replay cartridge,
compatible until you press Start button
(Click in order to see youtube video)

At that time, his last video was about Uno DX, and was experiencing issues with it.
That's a bit weird, because this game shouldn't cause compatibility/problems ... maybe a bad burn or bad dump of the game ?

By looking at the problem in details (everything is explained in his videos, which is very convenient

), I see that CWX loader doesn't works anymore for all his games, even the ones that played well before, but JHL loader still works well.
Very weird : CWX hasn't the best game compatibility, but should work on all known models of Saturns

So I request TehNewParalyzer to give details about this problem :

1. From loader selection menu, press B button, select "Self Test", and select "Test once only".
Please let me know if error message is displayed in "Main prgm" or "Bootstub" lines.
2. Please try CWX loader with an original game, and tell me if it booted or not.
3. If possible, please try with game burned on another CD-R brand and/or burned a different (lower or higher) speed than usually, and tell me if it boots with CWX loader or not.
4. If possible, please try with another Saturn and tell me if you can get games booting.
5. If you have a spare Pseudo Saturn cartridge (Action Replay, or Game Shark, or Memory Cart Plus, or any other clone), please give a try with it and tell me if you can get games booting.

Fortunately, there wasn't need to test after step 1 : self test feature was throwing a CRC error on when checking firmware's main program.
Okay, so it looks like cartridge flash ROM is corrupted, and consequently few areas in main program code can't longer be executed.
Why Action Replay's flash ROM would corrupt ? I don't know exactly, but I suspect :
1. Extra feature in Uno DX, corrupting cartridge's firmware in the case you use too much +4 cards

2. Poor quality of Action Replay flash chips.

Rather than thinking too long about causes, let's take measures in order to fix the problem : re-flashing the cartridge should do the job.
And it did the job : no more CRC error

data/images/20160803_pskai_self_test.tb.png

Correct self-test results after firmware re-flash.
(Click in order to see youtube video)

One of the purposes of Pseudo Saturn Kai's self test feature is to help Action Replay users : by the past, I had few reports from other users having their Action Replay no longer working, so I thought about a feature in order to check the integrity of their flash ROM.
I'm glad this feature was useful to at least one Pseudo Saturn Kai user

For those who want more details about Action Replay flash chips :
First, Action Replay cartridges (and their clones) are using old flash chips no longer produced, which means theses chips are either old, or counterfeit. In both cases that means the quality of this chips is a bit shady.
Moreover, Action Replay original firmware may shorten flash ROM life length, because it writes to flash ROM when cheat codes selection is changed, or when cartridge internal save functionality is used : the more you store save data, or select Action Replay codes, the more likely it is to be damaged.

There are ways to improve this problem : the simplest one is to use SST39SF flash chips (5V logic, still produced

), but that requires changes on Action Replay PCB, and to make several changes Action Replay firmware (because write access to new flash chips is not compatible with old ones).

Changes in PCB is probably not a real problem for Action Replay manufacturers, since Action Replay PCB is shrinking year by year (in order to reduce manufacturing costs) so I suppose that Action Replay manufacturer still have at least one guy capable of designing PCB ...

Changes in Action Replay firmware is probably what's preventing manufacturers from using new flash chips : people who wrote Action Replay original firmware (around 20 years ago !) are probably retired now, and I doubt there are still people fluent with SH2 assembly working in Action Replay manufacturing field

A little unrelated (but I'm too lazy to create an article just for that) : Pseudo Saturn Kai compatibility list is growing little by little

There are currently 259 games available in the compatibility list, so there are high chances to find your favorite game listed in it

Special thanks to people who contributed to this list, especially Thales Peres, who provided test reports for around 150 games !

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

Written by cafealpha 05 july 2016 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.

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 : still WIP ...

Written by cafealpha 25 february 2016 no comments

Still WIP, and last week was a busy one !

First, I fixed USB dev cart legacy firmware-like screen that wasn't working at all. Well that's a developer-oriented feature that I seldom use, but that needs to be fixed anyway

The fact I seldom use this feature was the starting point of the problem : modifying a module apparently not related with that feature caused major bug ... software development in a nutshell

Thank you Shazz for beta testing my firmware

There are still other bugs remaining, and I plan to fix theses soon

And, (what's more important), game loader was sometimes loading game, sometimes not. Loading game backups is Pseudo Saturn Kai main feature, so I really don't want it to fail

Origin of this bug was unclear, but I fixed/improved many things at once, and game loaded every time after that, so let's hope I won't have to face with it in the future

One additional "bug" was game loader being kicked to multiplayer screen, and it was caused by ... game corrupted dump

First half of the game IP header was filled with zeros, so Saturn couldn't even recognize it as a Saturn game ...
I "fixed" what I could on firmware side by displaying something like "bad game dump/burn ?" message before kicking to multiplayer screen.
Let's hope it will reduce the amount of "can't load xyz game ! Hurry up to fix your bloody firmware !!" kind messages after release

And of course, there were many, many minor fixes, for example :
- Added scrolling help messages under menus
- Credits screen ... stub (names missing), and only in Save Data Manager for the moment
- Added alternate menu exit keys : it is now possible to do something like "A/C:select, X:delete, Y:info, Z:whatever" in a single menu. This is preliminary work for Action Replay codes addition

So firmware development is continuing ! Everything is in good way :

data/images/20160225_please_disperse.jpg

Pseudo Saturn Kai development is going well. Please disperse.
(Screenshot from The Naked Gun)

Nothing to see here
(Mr Nielsen, you're missing us )

On a positive note, I tested Bubble Bobble (listed as incompatible in Pseudo Saturn compatibility list), and it worked fine

I absolutely don't know why it works fine. I suppose that registers cleanup and running RAM cleanup code from ROM just before loading game helped a bit ... well at least it works

Completely unrelated note : I uploaded 10+ years old videos of me playing Tetris Attack puzzle mode ! You can enjoy the videos in my Tetris Attack page , or directly in the appropriate youtube playlist for theses videos.

data/images/20050105_ta_puzzle_ending.jpg

Tetris Attack puzzle mode ending screen

Rss feed of the tag

PPCenter :: devblog

PPcenter. Arts and craft for my Sega Saturn. Since 1847 !

Pseudo Saturn Kai 6.074 released !

Bit shift in Saturn minimalistic C program

Pseudo Saturn Kai no longer working on Action Replay ... and its rebirth !

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

Pseudo Saturn Kai : still WIP ...