Okay, cool, cool.
Okay, so up next is Falko Gurgis telling us I'm sure an entertaining story about Sega
Dreamcast, how did you get this idea?
I have an entertaining story about Sega Dreamcast Homebrew with GCC.
That's true.
Not this standard thing you would do.
You ready?
Alright, so I'm talking today on behalf of the Sega Dreamcast community.
I'm actually a developer on the Homebrew independent SDK, SDK called Callisty iOS.
And we're talking about how basically...
Yeah, no problem.
We good?
Okay, yeah.
So basically this entire Homebrew community is powered by GCC.
And I'm just showing you kind of what the kind of stuff that being part of the GCC ecosystem is allowing us to do.
So first of all, what is the Sega Dreamcast?
Maybe some of you don't know because it had two years in the limelight.
It was released in 1999 and it was only commercially viable until 2001.
Despite that fact it had a substantial effect on the gaming industry.
It left a huge legacy and it competed directly with the PlayStation 2.
A little bit less the GameCube and Xbox because it didn't last that long.
And then a little bit about it, it had Hitachi, which...SH4 CPU, which is now owned by Renaissance.
An imagination PowerVR 2 GPU, which was the predecessor to what eventually got used in the iPhone.
So that same technology actually for the GPU went on to do quite a lot of fancy stuff.
And then there's a little bit extra about it.
But the key thing here is the Hitachi SH4 CPU.
And that's what has made our destinies intertwined with GCC.
Because GCC is the only compiler that supports the Super-H architecture.
So why the Sega Dreamcast?
What's the big deal?
So I think there's a lot of strong arguments for doing it.
I think in like an era where people are into Raspberry Pi programming and embedded systems,
it offers a really good middle ground between high performance because it's good at graphics,
it's good at floating point operations and embedded programming.
We have a lot of established tools that are really good.
As you'll see we have really modern compiler support.
We have a lot of language support.
Thanks to Matt Godbolt we have SH4 and compiler Explorer.
So you can actually check, look at what the disassembly of your Sega Dreamcast code looks like
to make sure it's optimized.
And as a beginner you can treat it like just kind of a weak PC using cross-platform APIs.
Or as you mature in advance you can go down to the hardware level and optimize for it.
There's also a lot of cool toys and peripherals.
There's light guns, Samba De Amigo Maracas.
There's the visual memory unit.
And visual memory unit itself, the little VMU, has its own little homebrew scene.
So as I was saying we have a pretty decent community and because our independent SDK uses no Sega code
we're actually able to release our homebrew commercially and sell it online through retail stores and stuff like that.
So this is how many we've released each year commercially and there's just a collage of different commercial games.
So as you can see you're not going to get rich on Dreamcast,
but you know if you're making a PC game within that spec range maybe you should check it out.
So this is a little bit about Callisty iOS before I get really deep in some code stuff.
This is a little bit about the architecture.
So it's Callisty iOS, it's like a big SDK but it also is like an operating system.
We have a kernel.
We integrate with NewLib 440, which as far as I know is the latest one that's out there.
That's where we do file I O, date time, malloc.
We have a really cool virtual file system which abstracts the way the PC CD-ROM.
You can stream from your PC.
You can use the new SD card readers.
Networking, we even have IPv6 on this thing.
We have examples.
We have add-ons and ports for OpenGL, OpenAL.
The tool chains as you'll see we have GCC 1321, latest Benutils, GDB going on it.
We're trying to take this retro game console and let you use the latest and greatest versions of the languages of your choice on it.
That's kind of a little bit of what we're going to touch upon.
This is a little bit about my Dreamcast.
It's not going to go into too much detail but as you can see it's like a car.
You can totally spend all your money on it if you want and go to town on it.
You don't need to do any of this though to develop for it.
That's another big point of it is as long as you can burn a CD-ROM,
90% of the Dreamcasts out there can boot your homebrew game as long as it's burned a certain way.
That's part of why the homebrew scene became so big.
The first thing we're going to look at is C23.
We wanted C23 on the thing.
What did it take to get there?
It didn't take as much as we thought.
One of the first things that we had to do was support Atomics from C11 so that you can say atomic int, atomic bool,
and have, since we have a preemptive multi-threading scheduler,
you want to be able to have atomic variables that aren't interrupted and stuff.
Unfortunately the SH4 is old so there's no hardware support for Atomics.
But since it's single core it's not a big deal.
You just disable interrupts around it, you load or store your value,
and then you enable interrupts afterwards.
So this is actually offered by the compiler, the SH compiler,
as the soft imask model.
What it did not offer is 64-bit and generic Atomics.
So we had to implement that and there's the C code for,
it's kind of an ugly C macro to do it, but you can basically see.
We just disable the IRQ, we load or store a type, and then we enable it later.
And that's the basis of our Atomic model.
So if the scheduler can't get interrupted when you're accessing Atomic, then it's Atomic.
Then we validated the Atomics.
You'll see a bunch of the output there is from my Dreamcast.
So we have a bunch of tasks we ran through, a bunch of different Atomics,
an Atomic buffer, and yeah, the Atomics work now on the Dreamcast.
It's pretty nice.
Something that was much harder was adding thread local storage support.
So in C and C++ there's a thread local keyword,
and there's a lot of stuff you have to do for that.
It's a delicate interplay between the compiler and the operating system.
On the operating system end, don't worry if this code is a little dense,
that's the whole point, this was actually a pain,
and that's code just there to show you what a pain it was.
You have to allocate with every thread,
you have to allocate extra block for thread local storage with the T data
and T BSS segments for thread local, and then you have to swap every time you swap context,
you have to swap the thread pointer to point to a new thread chunk.
So we did that, and this is some of the validation tests for it.
What actually makes it hard is you can align your TLS storage arbitrarily,
so we had to compensate for arbitrary alignment,
that was all the extra logic that was more than just a malloc with a fixed size,
you have to also align those segments.
So yeah, now TLS works on the Dreamcast.
And then that was pretty much it, we got C23,
we have no pointer, auto, type of, all the cool stuff that C23 added.
VAopt is now in C23, Align As, Static, Constexpr, Compound Literals,
one of my new favorite things to use right there.
This is just me throwing in a bunch of C23 with a Breakpoint API.
Oh, Binary Literals, pretty nice, C23 edition.
This is a little video, uh-oh, was a little video, it's not working.
Okay, well, cool.
Maybe after you can check out my Twitter, all the videos are on there in case they don't work.
So C plus plus 20 and 23 is up next.
What we got for free, we actually got a whole lot for free, it's kind of cool.
Concepts, constraints, modules are not fully supported by GCC yet,
but hey, everything that was supported worked fine for SuperH, we were pretty shocked.
Ranges, look at that crazy range stuff that we can do with C plus plus 23 on the Dreamcast.
Pretty sweet, standard format, and this thing, a static,
variadic, multi-dimensional, overloaded subscript operator.
You can do that on your Dreamcast now, it works.
That was pretty awesome.
What we had to earn with this, standard async did not just work for us
because our kernel had a serious bug with once in it
that nothing had exercised that code path with the ferocity that modern C plus plus did,
and we found a race condition there.
Standard random device took a little bit of work, I'm going to get into that.
Standard file system is not quite supported.
Yeah, that's a sore point for me right now, we're working on that, that's our fault.
We're not propagating error now properly with NewLib, working on that.
Standard time zone, well Dreamcast doesn't really have a time zone,
so not much we can do about that, although I will say we gracefully don't support it,
so it's not a big deal.
Stack trace is one that doesn't look like there's much we can do about that.
Yeah, C plus plus 20 stack trace, I got the library compiling for it,
but it looks like deep within the library where it's trying to look for the binary path
for reflecting over the L for executable to unwind the stack and look up the symbols
there's just not really any way for us to tell it where to look over the network
for a Dreamcast, so yeah, there's no stack trace right now.
Maybe we can hack something up for that later.
Standard random device, it actually works fine, so you can do all this crazy random stuff.
This is the NewLib hook where we actually hooked into,
we supplied the entropy from a bunch of uninitialized RAM,
and that's what the entropy is coming from uninitialized RAM,
which goes to standard random device, and then this is just a uniform distribution
getting generated on the Sega Dreamcast and showing, you know, looks pretty uniform.
Yeah, C plus plus concurrency meets the Dreamcast, this is pretty exciting.
Yeah, there's a bunch of interesting C plus plus 20 stuff there,
so I made a huge test thing that we're running on Dreamcast,
which is just, it is running a bunch of standard, it's generating a bunch of standard async threads,
testing everything from semaphores, latches, share locks, condition variables, barriers, and everything.
And at this point, I guess I can't show it because the video is not loading,
but it would just be like a big printf printout showing that all the tests are passing.
So, yeah, as far as I know, including code routines, everything from the support for GCC up to C plus plus 23
is working fine on the Sega Dreamcast because you definitely need that level of concurrency to work with this machine here.
Alright, let's see. Yeah, I had another little video that's not, I don't know why they're not loading,
but they're all on my Twitter. Alright, Objective C, there's a little more to this
because there's a couple reasons. GCC, it looks like, doesn't quite support the latest version of Objective C.
Objective C, too, I guess that's because Apple didn't want to fund it anymore, I'm not sure.
So, we had to make do with what we had. It looks like Objective C might be a little broken right now for cross compilation.
We had to patch a build script right now to get to cross compile for bare metal.
It was failing a compilation stage and we just basically commented it out in one of the config files and then it worked.
We were able to build LibObjective C. The problem with, you know, building plain Objective C is,
LibObjective C is a C library that lets you access all of the object-oriented features of Objective C.
It's not very pretty, it's not very idiomatic of Objective C, but that's the raw runtime.
In order to do anything useful with Objective C or do anything that you normally associate with Objective C,
you need the foundation standard library, which is typically associated with Apple.
That's where your NS string, NS object, all that comes from.
Luckily, GNUSTEP has an open source implementation of that.
So, we tried to port that to the Sega Dreamcast to give you, you know, this very big, nice Apple API that you definitely want for your Sega Dreamcast homebrew.
Oops, that went pretty well.
So now you can, you've got data structures, you've got auto-release pool, you've got NS string, NS log, all that kind of stuff on the Sega Dreamcast.
You know, that's just basically some Hello World stuff doing that from Objective C and that's the Dreamcast output.
Now, what gets a little more interesting is the concurrency model for Objective C is actually pretty cool.
We support the NS run loop, which has NS timer, which lets you schedule periodic timers.
They're used for, like, GUI updating, you can use it for game engine logic.
And then we're firing NS notification events asynchronously from that event loop.
And the video was really just showing, like, a bunch of events firing asynchronously on a Dreamcast.
I don't know why it's not working.
But anyway, so you've got the Objective C concurrency model as well.
And for the record, if you need Objective C++23 to get everything, that works too.
If you want to mix both of them.
Okay, so then we tried to get D on the Dreamcast.
This was not done by me, this was done by someone who goes by Luna on the Luna Fox girl on Twitter.
Thankfully, she helped us because I didn't know really much of anything about D.
She did a great job.
What was involved with bringing D to Dreamcast?
Well, we used the GDC front end for GCC.
We cross-compiled it for SHL.
She wrote a custom run time to do some of the stuff that the D run time does, which I'm a little sketchy on.
But I believe it's stuff like lifetime management, like allocation, deallocation, entry point.
She did not use the garbage collector, not because it won't work on the Dreamcast,
because we run Lua and it's fine, but she wanted manual lifetime management.
And at this point, we did not try to do libfobos for the standard library.
We actually are just binding to libc for that kind of stuff.
And then that's kind of a folder view of what the project looks like.
It's called DKOS, which is the D bindings for what we did.
And as you can see, I was worried that a bunch of the low-level stuff we were doing in C
and Callisty iOS would have to change.
Like, hey, can you bind to inline assembly?
Like, what are you going to do about the C macros?
And actually, a D is quite capable.
And here's some of the crazy stuff that she either rewrote or bound to from D.
So there's inline assembly.
It can handle flexible array members, inline functions, macros, versioned enumerations.
I started getting a little jealous there as a C and C++ programmer, actually.
It's really good stuff.
So yeah, D meets the Dreamcast.
So here's some fairly idiomatic looking D that had a video there that all it was doing was basically changing the color of the...
It was animating the background color with the PowerVR on the Dreamcast, the frame buffer,
and printing some stuff to standard out.
And it worked great.
And let's see.
Here was one more video, which was a bunch of animated cubes showing 3D accelerated graphics with the D language.
That's on her Twitter, actually.
And then finally, everyone had been asking the entire time we were doing this on Twitter,
hey, what about Rust?
Hey, what about Rust?
And we're just like, hey, man, I don't know what to tell you.
LLVM doesn't support SH, SH4, like, take it up with them.
And then GCCRS came along and happened.
We weren't having any luck with Rust C at the time.
We couldn't get it cross-compiling properly for SHL.
So we started playing with GCCRS, even though it's like very, very new in its infancy.
I mean, we were seeing like four loops being added almost in real time, you know,
like we pulled down like, oh, you can use a loop now.
It was pretty cool, you know?
So this is not stuff that necessarily is ready to be played with, but we don't care.
It's what we do here.
There's no bar checker yet, so you'll notice everything is just unsafe,
but it's still fun and it's still Rust.
So this is, oh man, the video's not there.
It's a rotating cube that is driven predominantly by Rust.
It's unsafe, as you'll see.
The main control flow is Rust.
The OpenGL API is calling in to C for that.
And then there's a mystery third language that you're about to see,
which we implemented miscellaneous support utility functions for things that GCCRS wasn't able to cope with just yet.
So, all right, we're going to go into that demo here.
All right, so on the left we have the Rust, which is calling in to C.
On the right we have the utility functions, which are Fortran.
So we had C, Rust, and Fortran, all on the Dreamcast.
And yeah, here was the rotating cube.
So, yeah, I would say we inherited quite a good deal from the GCC ecosystem.
And yeah, may your homebrew be powerful and good and fast, and yeah, that's it for us.
I just want to say thank you to everyone who contributes to GCC,
and to our GCC in general for supporting us, for supporting the SH backend.
If you're interested in looking into any of this stuff, that is a link to our Wiki page,
which is everything on how to set this up.
You can do it from Windows, Mac, Linux.
It's mostly just running a script that works in any POSIX environment that sets up the cross compiler.
And I wanted to say that we are just one community that's powered by GCC and is modern.
I'm friends with the guys who do the PSPSDK, the Sega Saturn stuff,
Lib Dragon for Nintendo 64, SGDK, Sega Genesis, and the Vita SDK.
I can tell you right now we're all using GCC.
So, yeah, you guys are, there's a lot of people out there who owe you a lot.
And if you like this kind of stuff and are interested in hearing more,
you can follow me on X or Twitter or GitHub.
And that's it. Any questions?
Over there you have actually sitting, or one of the Fortran main tables.
Really? Oh, it's awesome.
We have a couple more in the room shortly.
Oh, yeah, but...
No, no, no, that's...
Oh, I'm sorry.
Our application at the moment is targeting the Lib Rome, basically.
Oh, yeah, yeah. Which is a good library, but why that over Callistae OS?
Because our app has been targeting the Dreamcast for that last 12, 15 years.
It's developed by Marx, I think, in North Marx.
Oh, my gosh. Oh, okay.
Yeah, I know. Yeah, yeah.
Accesses. I was wondering, it's fairly easy to install your GCC chain
because trying to patch up GCC to a bit of Lib Rome character is a pain.
Oh, you should totally use our tool chain.
Yeah, our tool chain should definitely work.
And our scripts, there's so many people in the Dreamcast community
that by now they're pretty battle tested.
Like, people will want it for Mac, Ubuntu, every flavor of Linux,
Windows with StigWin versus Windows with WSL.
You know, ours is pretty solid at this point.
You should definitely check it out, actually.
I'll definitely be trying to pull it.
It's pretty nice, yeah, yeah.
But, oh, that's really cool, though.
Very nice.
Anyone else? Yeah.
Which version of NGL are you supporting?
All right, so the latest you can get on the Sega Dreamcast is 1.1
because we don't have any shaders.
It's all fixed function.
But I will say, it's one of the most epic end-
end-late-stage kind of GPUs that's fixed function.
We have a lot of the stuff that went into shaders in hardware.
Like, we have hardware accelerated bump mapping.
We have some things called modifier volumes,
which are really cool that you can use for cheap shadows and stuff like that.
So there's a lot of cool stuff you can play with,
despite being an OpenGL 1.1.
You guys ever heard of Raylib?
Yeah, we actually just got a port of Raylib that sits on top of GL 1.1.
So it's really cool being in the Raylib community right now.
And like, someone makes a game for like PC and you're like,
hey, sick out your game on my Dreamcast.
It looks pretty good.
And they're like, what's a Dreamcast?
But yeah.
Anyone else? Yeah.
Well, as you know, I'm the SuperH Conal maintainer.
I do know that.
My hero, man.
There's actually the SuperH backend and GCC is actually still in a questionable state.
Oleg Endo is watching this.
So yeah.
Well, he hasn't been doing on it so much recently.
Yeah, yeah, yeah.
There used to be two people working on it.
So if I'm seeing now there's so many people like working on SuperH,
it would be nice if like kind of people came to the Debian community
or like there's also a Linux SH RSE channel on my barrel.
Because like doing this all alone, like what I'm doing in Debian is quite a burden.
So there's like some people that would like to help like also improve GCC.
Absolutely.
So the Linux kernel almost dropped the SuperH architecture and he saved his life.
So yeah, we owe this man a great debt.
And yeah, I meant to reach out.
Definitely.
Anyone else?
Oh, yeah.
I wanted to ask, as I know the Dreamcast had sort of support for Windows C for Dreamcast.
Yes.
And was there any plan or something about that?
Because I remember the vertical system run on the Windows C platform
and if I'm not 100% mistaken, GCC might have a Windows C target.
I'm not sure about that because when the Dreamcast was released, there were two SDKs.
You could use the one that was Windows CE, which a lot of games used and it was very impressive.
It supported a lot of the Windows kernel and there was one that was pure Sega.
But the thing is we try to distance ourselves from that because those are official proprietary SDKs.
They're not independently developed so you can't really sell your home brew with that stuff.
So I don't know too much about that, to be honest with you.
Yeah, sorry.
Anyone else?
Yeah.
We have actually, there's a giant chart on that wiki page that I linked to.
There's a giant chart going back to like GCC4, looking at, we are running one of our polygon benchmarks,
looking at performance versus binary size versus a few other variables
and it's kind of interesting how it's varied across versions of GCC.
Definitely GCC 13 is not the best or the worst and it's not like a linear trend either.
But yeah, you can definitely take a look at that and that's a very good question too.
Yeah, please. If anyone wants to port anything else, we are very interested.
Okay, thank you.
Thank you.