PPCenter :: devblog

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

Bit shift in Saturn minimalistic C program

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

Read more Bit shift in Saturn minimalistic C program

Gamer's Cartridge out of stock :]

Written by cafealpha 5 comments
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

data/images/20170215_sgc_v33b_gerber_preview.tb.png
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
data/images/20170512_escalated_quickly.jpg
Cartridges are assembled by hand, hence stock is small, but I'm impressed anyway

Read more Gamer's Cartridge out of stock :]

[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

Be No Sqr

Written by cafealpha no comments
Just a quick article about a Sega Master System demo made by a good friend : Be No Sqr

data/images/20160328_be_no_sqr_top.tb.png
data/images/20160328_be_no_sqr_bottom.tb.png
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

Be No Sqr is one of the participants of smspower's 2016 coding competition , so don't hesitate to vote for it

Read more Be No Sqr

Pseudo Saturn Kai : still WIP ...

Written by cafealpha 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)

data/images/20160225_nothing_to_see_here.jpg
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

Read more Pseudo Saturn Kai : still WIP ...

Rss feed of the tag