Another Saturn SDK

GCC has been updated to 4.9.1 and GNU Make has been added (re-download the installer to get GNU Make). You can check out the build status here: https://ci.opengamedevelopers.org/view/SEGA Saturn SDK

I have also added an IRC plugin to Jenkins to allow for a real-time update for those in the IRC channel. It shouldn't clutter the chat too much, unless you issue one of the Jenkins commands. If you want to see what's currently in the build queue, issue: !jenkins q. There are more projects than just the SEGA Saturn SDK on this instance, so be aware of that if you issue a command like the status command. All of the commands can be displayed with: !jenkins help.
 
Thank you for the update ! My development laptop is now using your latest gcc 4.9.1 🙂
BTW, everything is displayed in white color, so is there some setting to change on windows side to enable color display ?
 
cafe-alpha: Do you mean the installer is all white? I'm not sure if I can change the colour scheme, though I'll look into it.

Speaking of colour; it looks like getting colour output from non-mintty Windows command prompts is possible. I have yet to scour the GCC mailing list archives for other attempts at getting colour output on Windows-based command prompts.

Currently, the IDE is being worked on, which is based on Code::Blocks and this presents an interesting problem of installed versions of Code::Blocks possibly getting confused and existing installations confusing the Saturn IDE. The main reason for this is that the directory names for configuration information is the same and I'm not sure how easy it will be to use ~/.saturn-ide instead of ~/.codeblocks. Anyway, that's where I'm at right now, I still have yet to figure out how to compile the Windows versions of Code::Blocks from the command line and set up script wizards properly. There is currently no roadmap for the IDE, other than just getting it to a stage where you can create a blank Saturn Game project with a main entry point.
 
Sorry for the misunderstanding. Installer is OK, I was speaking about gcc output, like in this picture.
Gcc outputs something, but it seems that it is not compatible with cmd.exe ?
Do you confirm that color output is not possible under cmd.exe ?
 
Unfortunately it doesn't work at all in the default Windows command prompt. It will work with Cygwin, or MSYS + mintty. As suggested by vbt, I have added a patch so that you can use colours when compiled for Windows, though it doesn't use the Windows command prompt's colour API, instead terminal colour commands are used.

This reminds me that for Windows I'll have to add MSYS to the SDK.
 
I've started working on one of the samples and realised that there is no IP building tool in the SDK. I'm looking at creating one which is command-line driven to better allow for automation (version numbers could be easily modified and it would benefit multi-disc games). Being more used to Dreamcast/Katana development than Saturn, am I right in assuming that the IP does not need to reference the binary executable by name as long as it's the first file on the ISO?

The Disc Format Standards Specification Sheet does not mention anything about the IP file naming the binary to be loaded (other than the section about the Application Initial Program and 1st Read File). Currently, I'm naming my file 0.BIN to put it ahead of the other files for reading.
 
If you want to modify IP header information, you can use my tool that allows to do the job from command line. You can find its sources here, in tools -> ip_header folder.

I don't know if it is good to include IP binary file itself in SDK, because it uses code copyrighted by Sega ... I never heard them causing troubles about old licensed code, but who know what they can do in the future.
Personally, I use IP binary file from SaturnOrbit folder when calling mkisofs, then call ip_header in order to personalize header infos.

Being more used to Dreamcast/Katana development than Saturn, am I right in assuming that the IP does not need to reference the binary executable by name as long as it's the first file on the ISO?

The Disc Format Standards Specification Sheet does not mention anything about the IP file naming the binary to be loaded (other than the section about the Application Initial Program and 1st Read File). Currently, I'm naming my file 0.BIN to put it ahead of the other files for reading.

There's no naming convention, it only needs to be the first file in root folder. So that file name differs from a game to another, like 0.BIN, 0BIOS.BIN, 0WHATEVR.AAA, etc.
 
That should be all you need to do. Currently the process is to manually navigate to the directory the installer asks you to install to (it should be your current user's home directory) where it will create a saturn directory and other directories, including toolchain_elf, which contains bin/saturn-sh2-elf-<program> executables. It's very user-unfriendly at the moment, I'm afraid.
 
just to say there is a new newlib version 2.2.0

- multiple functional/performance enhancements for arm/aarch64
- new nano formatted I/O support
- replacement of or16/or32 with or1k platform
- qsort_r support
- additional long double math routines
- ito/utoa/ltoa
- restructuring of gmtime/localtime so tz functions only linked by localtime
- unlocked I/O functions
- various warning clean-ups

ftp://sourceware.org/pub/newlib/index.html
 
Red Ring Rico has already updated the saturn sdk with the latest newlib
don't miss it ! :ridinghorse::ridinghorse:
 
It's been a while. Sorry about being so quiet recently. I'm working on a game (not for the Saturn, unfortunately) at the moment, which is taking up a lot of my time (research and development, tools, deciding on the game to make).

GNU make has been updated to 4.1 and will Newlib will be updated to 2.2.0.20150323 soon. GCC 5.0 is coming out soon and the Qt Installer Framework 2.0 just launched, so I'll update to the new installer as soon as I can. In addition to updating the tools, I'm working on getting Code::Blocks working for both Windows and Linux (the Windows version needs you to run the Code::Blocks IDE, which isn't ideal when I'm using Jenkins). Documentation is pretty much non-existant at the moment, which really sucks and I should do something about that.

I'm looking at getting a USB development cartridge in the near future (possibly at the end of the month), so hopefully that will be a major help instead of the current process of copying binaries over to my DOS machine, then deploy them on the Saturn. It would be neat to have a "Deploy to Saturn" option in Code::Blocks =D.
 
I'm not really sure what can be done with Code::Blocks, other than creating a Saturn template (library/game), deploying the executable to Yabause or hardware, and integrating documentation with it. Getting remote gdb working would be a good next step, though I am entirely uncertain of how feasible it is. Currently, the main bottleneck to progression is getting Code::Blocks built on a headless server for automated builds. It's more difficult on Windows, as the recommended way is to build it through Code::Blocks and I haven't been able to successfully build the Windows version via Linux (though it was around four months since I last tried).

A few days ago, I set up a Windows machine for automatic builds. Currently, Cygwin's sshd is used to access the server and I may be able to use the standard Windows cmd Command Prompt to build with.

Do you have anything to suggest for improving Code::Blocks? My main development environment is gVim and a terminal, so I'm not as experienced with Code::Blocks.

EDIT: I just found a tool called cbp2make, which may be useful for creating makefiles which can then be run from a headless server.
 
Thank you for updating Saturn development tools :]
I got a question : when I will release something new for Saturn, I would like to release development environment (= zipping whole saturn_sdk folder, and uploading it on my homepage) too, so that Saturn developer can rebuild everything without messing with compatible gcc version, etc.
Does gcc licence / your licence / other licence allows this ?

If you want USB dev cart, but don't have enough time to build one, please let me know. I can prepare one unit for you on next week.

BTW, please note that USB dev cart doesn't emulates Saturn CD-ROM unit, so it can't be used in the case Saturn executable reads files from CD-ROM.
However, it is a very powerful tool when testing "RAM only" programs.

Hence, if you plan to allow testing on yabause or real hardware (which is a very good idea), I would recommend to make both executable ("0.bin") file and iso file available for use by respectively yabause and USB dev cart software.

> Getting remote gdb working would be a good next step, though I am entirely uncertain of how feasible it is.
Piratero did it 🙂 You should check his libyaul project.

> Do you have anything to suggest for improving Code::Blocks?
I'm sorry I don't have any suggestion. I'm not experienced with Code::Blocks too.
 
After a few hours of waiting for the build to complete without issues, Code::Blocks on Windows has successfully (as far as I can tell) been built with the help of cbp2make.  Some manual changes were required (appending another \ for zip to pick up \*.<ext>) which will be automated.  The next thing to do is build Code::Blocks from the Saturn SDK with the changes applied automatically, then get it working on Jenkins.

cafe-alpha said:
Thank you for updating Saturn development tools :]
I'm embarrassed that it took so long to get back to it =P.

cafe-alpha said:
I got a question : when I will release something new for Saturn, I would like to release development environment (= zipping whole saturn_sdk folder, and uploading it on my homepage) too, so that Saturn developer can rebuild everything without messing with compatible gcc version, etc.
Does gcc licence / your licence / other licence allows this ?
If the project I'm using (or creating) allows for it, the GPLv3 license is used.  So you can go ahead and archive the SDK for release if you want.  The only caveat is that changes made to the source have to also be made available, but I'm assuming that you won't be changing the source, so don't sweat it.

cafe-alpha said:
If you want USB dev cart, but don't have enough time to build one, please let me know. I can prepare one unit for you on next week.
I don't mind soldering, it's getting all the components together that I'm no good at.  Am I right in assuming that this is your site http://ppcenter.webou.net/satcart ?  If so, which revision of the PCB is in the Electronic parts and PCB?

cafe-alpha said:
BTW, please note that USB dev cart doesn't emulates Saturn CD-ROM unit, so it can't be used in the case Saturn executable reads files from CD-ROM.
However, it is a very powerful tool when testing "RAM only" programs.
At the moment I'm only interested in loading and testing programs with minimal content, so CD-ROM emulation isn't required at this stage.  Making the USB dev. cart ideal.

cafe-alpha said:
Hence, if you plan to allow testing on yabause or real hardware (which is a very good idea), I would recommend to make both executable ("0.bin") file and iso file available for use by respectively yabause and USB dev cart software.
Now that you mention it, I completely forgot to add ISO creation tools to the SDK.

cafe-alpha said:
> Getting remote gdb working would be a good next step, though I am entirely uncertain of how feasible it is.
Piratero did it 🙂 You should check his libyaul project.
Thank you for pointing that project out.  I'm sure someone (probably vbt) mentioned libyaul has an implementation of the gdb server stubs before.
 
> but I'm assuming that you won't be changing the source, so don't sweat it.

You guessed right, I didn't modified gcc sources 🙂
Thank you for the clarifications. I will release development environment next time I release something.

> I don't mind soldering, it's getting all the components together that I'm no good at.  Am I right in assuming that this is your site http://ppcenter.webou.net/satcart ?  If so, which revision of the PCB is in the Electronic parts and PCB?

Yes, this is my homepage. I recommend revision 2e (picture).
If you want, I can send you one bare PCB by airmail (cheap, but no warranty if lost/whateve).
In order not to mistake components sourcing, I can provide a list of links to mouser pages for each components if you need.
 
cafe-alpha said:
If you want, I can send you one bare PCB by airmail (cheap, but no warranty if lost/whateve).
In order not to mistake components sourcing, I can provide a list of links to mouser pages for each components if you need.
Now that I think about it; I don't even have a way to program the chips on the board, anyway. That was a major oversight. I'd appreciate it if you could populate the board.
 
Back
Top