Home	Forums	What's new	Resources

Windows Dev Environment for Saturn

VladR - Sep 26, 2018

		VladR		Sep 26, 2018
			Hi, Not sure if anyone here follows Jaguar development, but I'm currently a full-time Atari Jaguar developer (took a break in my SW engineering career, to follow my passion), with my first game to be released around January 2019. Here's a very old vid of the game, originally inspired by StunRunner, running on the engine I've been developing in my free time these past few years (before going fulltime recently): https://youtube.com/MOAmcvyRbFE Since Jag & Saturn are so close, HW-wise, I have put a great deal of thought into porting my games to Saturn too. Initially, I was considering Dreamcast, but that's too far, technologically, and visually, so Saturn makes much more sense from that standpoint. And, given its VDP1/2 capabilities, adding texturing should be very easy. As Saturn has a fully working C compiler for SH-2s, it should be very easy for me to support Saturn as a second platform, compared to the development hell on Jaguar. Of course, the initial learning curve will be steep, but as I'm quite proficient in RISC and 68000 assembler, I know exactly what to focus on, so I really only need the initial nudge towards proper dev env. From some initial lurking around here, I noticed one thread about the dev env set-up (Red Rico's, I believe) that mentioned exactly same environment that I did 6 months ago when I was considering Dreamcast - to be more specific: - mingw-64 - texinfo - newlib - kos - gcc-4.73 - sh4-binutils - sh4-gcc - sh-elf - genromfs All that was done under MSYS. Am I going to be able to reuse this environment for Saturn ? The sh compiler supports multiple targets anyway, so SH-2 should be targetable, I presume ? Or is there a different, better alternative right now, in 2018 ? Note, that while I have working Saturn at home, it's unmodded, so initially, all my dev would be against emulator. For the developer, is yabause best or are there other emulators that would be better suited (say, with debugging, dump, or other dev functionality) ?

		SaturnTeam		Sep 26, 2018
			I'd say the most modern option is using Jo Engine with Yabause and Pseudo Saturn Kai. But there are certainly different ways of going about it.

		VladR		Sep 26, 2018
			I certainly wouldn't want to use someone else's 3D engine. The cut-off, in using other code, for me, is a sound library, that's probably the extent I would go to, although in all honesty, that's what I did with Jaguar - I opted to take Atari's audio library and I certainly burnt more time just figuring out all its quirks, issues , workarounds, and crashes, than it would have cost me to implement a basic MIDI player by myself from scratch. Just goes to prove that it's definitely better to take your time, but roll your own code. No nasty surprises that way. But, I suspect the tools from Sega are different quality, so their audio lib should actually be useable. right ? But, that's way too far ahead. For now, a Hello World program running on emulator that allows me to draw pixels to framebuffer, while setting up VDPs properly, would be sufficient.

		VladR		Sep 26, 2018
			SaturnTeam said: Thanks, just googled it and researching it. Haven't encountered it before, though noticed being mentioned in forums...

		mrkotfw		Sep 26, 2018
			Yaul... has support for ROMDISK (and its related tools), as well as other features that would help you in development. The major downside is that it doesn't have sound support. Yaul is also open source, and it's license friendly for any commercial projects. There's also a MinGW 64-bit installer available here... with the cross compiler and all tools. I'm the author of Yaul, by the way. I have a few things under a private repo at the moment, which (should) help you. 1. Functions to synchronize both VDP1 and VDP2 2. DMA queue manager with per-request customization 3. Simpler approach to creating linked lists of VDP1 commands There's a few bugs I'm trying to iron out before I merge to the public repo. One thing to consider is that Jo is built on top of SGL. SGL/SBL are Sega's official libraries. There is Iaepetus..., but it hasn't been worked on quite a while.

		VladR		Sep 26, 2018
			Yaul looks interesting. From a very quick browsing through the git (link to documentation does not work, and neither to Downloads - it's an empty page), it's not a 3D engine, is it ? It would definitely be a big help, initially, to have all the HW registers set up with proper values (though, I presume a default example from Saturn should do the same) for initial experimenting. I must have missed that SGL is official Sega lib. I always thought, it's not. Then again, between the 20 PDFs from Sega that I had open this last week, it's easy to get lost in names and terms Question - given this is gcc we are talking about (and not some Atari compiler), is it far-fetched to do coding for parallel execution on both SH-2s and DSP just from C ? Or do I just go straight to Assembler for that ? Also, is the breaking of code into 4 KB chunks handled in some way via compiler, or is it completely up to the coder to swap chunks back and forth ?

		mrkotfw		Sep 26, 2018
			There is no 3D support. You'll have to write that yourself. It has support for fixed-point math (unoptimized), and the SCU-DSP. There is support for SH-2 dual CPU usage. You can hook in your slave entry function right away. I haven't checked in the examples from my private repo yet. As for DSP from C, you can only emit instructions via macros, and outputting those to a buffer. Then you take that buffer and upload it to DSP's program memory. Or you write in straight assembler, copy the compiled DSP program to your romdisk, open it, then upload it to DSP's program memory. It's complicated. You're talking about the main program or the DSP? If you're talking about the main program, breaking code into 4KiB chunks is something you handle yourself. If you're talking about cache optimization, that is. You'll find that a lot of your concerns may be pushed to the way side (for now) just based on the complexity of the Saturn. If you need any help, let me know. Edit: The way Yaul is designed is that it (tries) to provide a clean, but fast interface to the hardware so you don't have to deal with writing directly to the HW registers. It's a thin layer that does some of the lifting for you.

		XL2		Sep 26, 2018
			You could also take a look at SBL (Sega basic library) : it handles pretty much everything the Saturn can do and includes the source code, so you can modify everything. Also SGL (Sega graphic library) can give you very good results quickly, so if you don't want to spend too much time on this I suggest you just use it to start. The SCU DSP is free for you to use on SGL, so you could still have fun with assembly, and the audio cpu/dsp is barely used in most projects, so you could also have fun with it without bothering too much about handling the slave (SGL does it for you when you issue draw commands) and other stuff.

		mrkotfw		Sep 26, 2018
			As XL2 pointed out, you can hit the ground running with Sega's libraries. If you want to prototype on the Saturn, go with SGL, then port it to Yaul

		VladR		Sep 26, 2018
			I wouldn't mind absence of fixedpoint. I spent a great deal of research and effort to make sure my 3d engine is integer-only, hence the performance Since the Sh-2 is 32bit too, the math will work without changes. Only problem is that Saturn seems to have just 16 registers, so some refactoring will be needed... On other hand, on jaguar I had to break each quad into scanlines, e.g. follow the edges and switch once one is used. Saturn can flatshade quads for me out of the box, so I might not need more than 16 registers per loop... The main reason I ask for multicore support is rhat I already have that in jaguar engine. I split engine workload between: 68000 gpu dsp blitter Since Saturn doesn't have blitter and directly accessible 68000, I am already short one core Can Sh-2 execute code reliably from outer slow Dram? Jaguar has multiple issues with that, hence why I ask about breaking up code into 4 kb chunks. Thin layer right above hw registers sounds just right I will now go look into Sgl, as it's official Sega lib. How about my dev environment from Dreamcast?

		antime		Sep 26, 2018
			If your SH4 toolchain was built using the KallistiOS build scripts, it only supports SH4 little-endian. It also has some KOS-specific modifications.

		VladR		Sep 27, 2018
			It's been 6 months since I set it up, but yeah, I remember the kos-specific patches. I was hoping to avoid messing with all the linux-style dependencies, but I suppose there is no wzy around that. Given how much work it was, I want to preserve the dreamcast Msys environment. I am sure, given how fragile msys is, it would corrupt the sh4 dependencies. I actually tried it before. Easy stuff that works under debian or other distros, does not under msys... Can you have two separate installations of msys? I really haven't used msys prior to this. From work, I was exposed to about halfdozen linux distros. Is there a reason this toolchain wouldn't compile under cygwin? I figure I would ask before spending 2 days fighting some missing dependencies...

		antime		Sep 27, 2018
			GCC can certainly be built under Cygwin, it just runs slower.

		mrkotfw		Sep 27, 2018
			You can probably use the Yaul MSYS64 installer for SGL. That'll get you up and running the fastest. But in my toolchain, I removed support for Newlib.