 I'll talk about game development for some 8-bit systems, the ColecaVision and once made by Sega using modern free tools. So, I'll say a little bit about the devices, the hardware and maybe a bit about the community first. Then I'll go on about the small device C compiler, which is probably the most important tool. Here in particular with its Z80 back end, a bit about free library and less important smaller tools that work together with the library. Okay, so let's start with the ColecaVision. In previous talks I talked about bringing the arcade experience back to the home. When they were talking about these big systems that can run net BSD, also when the ColecaVision was introduced in the early 1980s, it's about 35 years ago, they were talking about the arcade experience. It has a 3.58 MHz Z80, a kilobyte of RAM. It has a reasonable graphics chip with 15 colors. It has a lot more graphics memory than other memory. It has a sound chip with about 3.5 channels, so three channels that you can give a frequency and a force one that's kind of a noise generator. It has a cartridge port that's kind of designed for eProm or Prom cartridges with up to 32 kilobytes. It's clear that it was only meant to read from those cartridges. They don't have a white-enabled line even exposed on the cartridge port. So that makes it hard to design something bigger for this cartridge port, because instead of just using the white-enabled stick and say, okay, I'll map this IO into the memory space, you'll kind of have to interpret read signals coming from the system if you want to do something fancy on the cartridge port. It however has an additional extension port at the front where you have a lot of signals available. There's a reasonably active community, mostly in the Atari age forums. They're, of course, in the Colecovision sub-forums that are developing games for the Colecovision and sometimes in C, sometimes a sampler, sometimes using the tools that I'll talk about, sometimes using other tools. Okay, there's a few peripherals, interesting ones at the very least. Okay, there's controllers with fire buttons. They tend to have a 4x3 key part, which is a bit unusual for video game systems, but it's really nice if you want to do a strategy game. There's a roller controller, which is essentially a trackball. If you disassemble it, clean it, reassemble it, tends to work well even today, even so it's over 30 years old. There's various expansion modules. One was an adapter that allows to plug in Atari cartridges into the system and play them. Then there came a steering wheel for racing games, and then they announced an expansion module. Three-year super game module with some kind of optical discorm that's supposed to bring like real video stuff and really a lot of storage memory to the system. Apparently prototypes existed, then they changed it to, instead of design, make it into this other computer, which was kind of, well, I mean, we have a society, we have memory and so on, and add a keyboard to it and a printer, and you kind of get a computer, which was not that reliable either. And then the community a few years ago created something with, I think, a somewhat better graphics chip and some extra RAM in it and also called the Super Game Module. The original manufacturer went bankrupt of the device long ago, so also in the 80s. Yeah, but there's not just Coleco, there's also Sega, which kind of made something that if you look at the specifications and the hardware, it looks like a clone of the Coleco vision. Yeah, so the first video game system, the SG-1000, same processor, same amount of memory, same graphics chip, same sound chip, the only cartridge port pinouts, it is a little bit better, and the other handset controllers were released as the first model, not detachable, but hard soldered to it. They later released the second version with external ports, and then came the SG-3000 computer, again with the keyboard and a bit more memory, but otherwise similar. And then came the big thing, namely the Mark III, which still has the same processor, it has 8 kilobytes of RAM, it has a custom graphics chip that's somewhat compatible with the one in the previous systems, but allows quite a bit more flexibility and essentially the same sound chip. And the Mark III originally was only sold in Asia, it has nearly the same cartridge port as the previous systems, but then they also made it into the Sega Master System, which hardware was very similar to the Mark III, has a bit of different case sensor on, but when they released the Master System in the West, they made an even better cartridge port pinout, which means the Asian and the Western systems, or Western in this case means the US and Europe, are incompatible in terms of cartridge port pinout, basically because in Asia they wanted to keep compatibility with games originally made for the previous consoles, but they didn't bother about that with the release in the West. So hardware is still around, it doesn't have any lasers or moving parts or whatever, it tends to be more reliable than let's say a Dreamcast or something like that, both the Sega and the Colecovision stuff, and if you want a nice graphics output for France, both the Colecovision and the Sega Master Systems were made with RGB output. The first generation of the Master System always had an RGB output, it didn't depend on the Mark III for Japan or for Europe or the US, but in the second generation Master System they wanted to cut costs and remove everything except one of the output ports, and the French models, they left the RGB one for most other countries, they cut the other one, yeah. Okay, again there's an active community at SMSPowerOrc, mostly, I don't really remember, an active development community, home programs, but there's not that much cooperation between the Colecovision and the Sega one, despite the similar hardware. Sometimes the Colecovision developer has a big project and they say, okay, I can't do it within the restriction of the hardware, let's go to the Sega, they have a bit of better graphics and more memory. This had happened maybe once or twice, but in general there's people who develop games for the Colecovision and those who develop for the Sega things, and well, I did a few games that now with these tools that I'll talk about that are kind of portable between those systems. Okay, let's talk about this multi-byte C compiler. What is it? It's a standard C compiler, it supports current standards such as EZO C11, not perfectly, there's a few gaps here and there, we don't support double in that compiler for example, we only have float, but most of the stuff is there. Typically on these systems you'll use it as a freestanding implementation, so the standard library won't provide file systems or stuff like that, but the basics of the standard C library are there, including everything required for freestanding implementation and a lot of the stuff that's offered for freestanding implementations. The supporting tools such as the Samplus link simulator for the target architectures, it works on many host systems, it targets a lot of 8-bit architectures, what matters for us here is the Z80 target, because that's what we want on those systems, but there's other back ends. It has a few nice optimizations that make sense for these targets, in particular in register locations, because these 8-bit architectures, including the Z80, often have a highly irregular register set, some instructions only work on some registers and so on, and the standard graph-coloring register locator, like titans, would have trouble dealing with that. SDCC has a different register locator that can then do register allocation optimally, under the condition that there's not too many go-to statements per function in C. It's lower than typical register locators, but with a small number of registers and the small devices that we're targeting, it's worth it. It gives substantial improvement in code quality compared to the register locator that SDCC had, let's say, five years ago, and one can control the compilation speed code quality trade-off during development. One sets this to a low value, like maybe a thousand or 3,000, and then when it really matters to get the last bit in performance and code size out of it, you can set it to a million and have your game compile for 40 minutes and then fit into 30 kilobytes or something. Okay, so, of course, if you use a compiler, you want it to be reliable. You don't want to run into compiler bugs. Well, we have regression testing of nightly snapshots. About 10,000 tests are compiled and executed on simulators. Most of the tests come from fixed bugs. Sometimes they come from when someone implemented a new feature and already came up with a test for it, and then we have nearly all of the tests from the GCC test suite, and we run them as well. Basically, we sorted out whatever tests the GCC implementation defined behavior, but most of the GCC tests are there in our test suite. We run it for the target architectures, for a few operating systems and host architectures. We used to have more machines in our compile farm. There could be a NetBSD machine on Spark, and there was a Solaris or an X86, but currently there's still a few machines around. Okay, one slide on this experimental LLVM plus SCCC toolchain. I mean, yeah, SCCC is an IC compiler, but you might want more. Maybe you are not satisfied with C as a language. Maybe you want another language that is supported by LLVM. Maybe you want more high-level optimizations. Yeah, SCCC has great machine, target-dependent optimizations at a low level, like in register location, but in high-level optimizations LLVM definitely has more. So this is an attempt to combine LLVM with SCCC. It uses the LLVM C front-end and back-end. The back-end is not officially part of LLVM anymore. It's maintained separately, but it's on GitHub. Basically, you compile things, compile it through this LLVM thing. You get our C code that then can be compiled with SCCC in turn for your target. You can freely combine, like, compile one file with SCCC and compile the other file directly with SCCC and link it together, that will work. But it's still experimental, and there's a few remaining issues, like the C back-end thing, sometimes drops volatile. And SCCC doesn't always deal that well with this C code output from this LLVM toolchain because it's quite different than what a human would write, so sometimes SCCC does not optimize this output from the LLVM stage as well as a typical code. So sometimes code size recations. Okay, so I also want to talk about the SET 8080K project. They are a big project for SET 80-based systems. So in terms of retro computing, they try to have basically support for a lot of systems. They have two compilers, just their own SCCC based on small C, which in terms of a compiler is not up to the standard of SCCC. But they also now use a fork of SCCC that you can use as a better compiler in this project. The emphasis is on a large set of libraries for various systems that provide a lot of features and are typically written in a sampler. And the old compiler, the SCCC, basically, the idea was to do everything that matters in a sampler and have the C code only as glue in between. But the SCCC fork situation is a bit better, but still the SET 8080K project now uses SCCC and the emphasis is still on a sampler. And then using the on top of a lot of sampler libraries. Okay, speaking of libraries, I now want to get to the libraries that also help us with portable development of games for both the ColecaVision and the Sega 8-bit systems. We already see we have the compiler for this target, which we can use for both. Now the library consists of two parts. And one is this libcv thing, which only provides a thin abstraction layer over the hardware. The support for accessing the graphics chip, for the sound chip, for sound. And sound at the level of, okay, a sound generator too should now do this frequency at this volume level. The input devices, yeah. It supports all the ColecaVision peripherals since it was originally written for the ColecaVision. It supports the basic stuff in the Sega 8-bit systems, but there's still some of the peripherals on the Sega side, like there, a roller controller. It's called the sports part, exactly. It's not as reliable as the ColecaVision one, but it's there. I think that one's not supported yet. But everything on the ColecaVision and the SG-1000 is supported. And in particular, this is very nice because with just a change of the brief of that sort of file, you can compile a game written for the ColecaVision for the SG-1000, and it works. Of course, if you also want to support the master system and not just support it in terms of your game will work there, but use the additional features, then it gets more complicated. If you want to use the graphics mode for, that's only on the master system, but not the other devices, you'll have to write separate code for that. But you can still make your game that if you plug it into a SG-1000, it will work with the graphics capabilities there. If you plug it into a Mark III or master system, it will use advanced features. And well, for the ColecaVision of yours, you have to recompile it because devices are different addresses and also the pinout is different. But yeah. Okay. Now, because this is a very thin hardware abstraction layer, it has a lot of work to directly write a game targeting that. There's another library on top, the LibCVU. It provides common functionality that one typically wants inviting a game. Again, graphics. Now we have music. Yeah, so this has support for playing some music instead of just setting some sound channel to a certain frequency. It has support for a bit of compression algorithm that one would want. Fixed point mass and so on. At the site of graphics, for example, with LibCV, you basically get access to the registers of the graphics chip and to the graphics memory. And these graphics chips also have some sprite support. But at the LibCV level, you don't see the sprite support. Of course, you can set the register and tell... There's a function to set, okay, the sprite table is here in memory and then you can transfer data to that memory and back. But at LibCVU, you have an abstraction layer that lets you treat these things as sprites and then transfer, like, okay, I want to set the X and Y coordinates of this sprite, update the sprite in memory and so on and decide what graphics should be there for that sprite. So this is an abstraction layer on top of LibCV. Yes. Together with these libraries also go some tools. Again, the graphics... I mean, these graphic chips have their own graphic format. So these tools allow you to, let's say, take a PNG image and convert it into a tile map for these game consoles. For example, on the ColecoVision, you have this restriction that the graphics are tile-based, except from the sprites that go on top. This is also true for the Sega systems, but for the ColecoVision and the first Sega system, like the SD1000, the restriction is that these tiles in the most powerful graphics mode, you can use pixels and per line in each tile you can use at most two colors. So out of your 15 or 16, if you count the transparent color, you have to choose for every line, eight-pixel long line, one of the two colors and so on. So the tool is kind of automatic that for you. You make your PNG, draw your PNG image, maybe in GIMP or whatever, and say, okay, I want to use this as a tile set, then they convert it into the binary data. And because of binary data, it still is like two bytes per eight-pixel line, one byte to select the two colors and one byte to select the colors that the individual pixels. You also want to compress it with some compression tools that do ILEs or run ILE and half-manning coding on it, so simple compression algorithms that can be run quickly on this hardware and then in the format that the libcvu library for its compression expects. There's the music format, also to make it relatively simple. Basically, there's a tool that converts ABC, I don't know if you're familiar with the ABC format, it's a music format originally intended for sheet music. So basically, it's not as complex as some other sheet music formats, but then this hardware is not that complex to really play complex music anyway, so you can basically set the score with at most three simultaneous notes at any time and then the tools convert. Do that in ABC. I mean, ABC is this company that has tools in Debian and so on. You can also get a PDF of your score out of the ABC format, but you can, with tools, convert it into some music formats and then the libcvu thing will be able to play on your Colecovision or Sega Master System or whatever. Okay. One feature, some of the better Sega devices have a better sound chip in them. Not all of the Master Systems, and I think not the Mark III, but I think the Master Systems sold in Japan have it. This is not yet supported by the library, so there is some potential for improvement. Okay, so I have nearly 10 minutes left, but I'm already at the summary, so let's see what are the important, the core of the free tools. It's certainly SDCC. We have a C compiler targeting to the Z80. It supports modern standards, modern optimizations and such. The Colecovision and the Sega 8B systems have similarities in hardware that make it possible relatively easily to write a game portable across both. Just compile it with different defines for both systems, maybe add a little bit of if-deaf in your code if you want to use the advanced features of the Master System versus the other systems. This is supported by the LibCV and LibCVU libraries, and I have started to write some games, and I think I entered one or two things in the context of the MS Power Arc once. I don't have enough time for really writing those games for those old systems because I'm probably spending too much time on improving the tools. But yeah, so basically from my side, that's it, so are there any questions? Yeah. Can you show me something? I want to know something. Show you a game. Let me see if I can get something. No, I can't show any dooms thing. Just a not really started unfinished project. This is about running a Salfa mine. Let's hope it just... Yep, there's still a ROM around. And here is it in the MES simulator, the one that comes with Debian. And it's currently running in the ColecoVision mode. So, let's see what the killer brings. So, it's a game where you basically run a Salfa mine. This is what the graphics can do on the ColecoVision and on the early Sega systems. There seems to be a problem now, because it's hanging. Okay, I haven't read this in a while because I wasn't intending. Let's maybe see if I can... Maybe the Sega Master System version will do. You can see it's basically the same game with only slightly changed. It's hanging at the same thing when this tornado is coming that's supposed to come and destroy some things. But, well, you can say it's a slightly different graphics on the Master System. I did not want to even use the full features of the Master System here. Some of the icons, like that shovel there, are slightly more detailed in the Master System version. Oh, that's the way I feel. Oh, it's next games. Next games are always popular on the Hobbit. Oh, I don't have the compiler installed at the moment and there's no ROM around. This one was re-compiled something, so something changed. One last attempt. Well, yeah. I mean, the transom tool is not installed in the compiler. But there's ROM files here. So, let me see. There should be some... There's a command-length transom emulator. There should be a test target somewhere. There. Mass BIOS pass card. Okay. Do we need the BIOS pass still? I'm not sure. Maybe it goes now automatically. Right. Ah, it's integrated into the mainbar now, I think. It used to be a separate... battery, but what does it make for? It's the... Ah, Coleco's dashboard card. Okay. Doesn't look that good either. Okay. So, either thing, some... string in the emulators change or... Well, it's been a while since I've worked actually in the game itself. Instead of on tools and some small test demo. Maybe I'll see if an older ROM works and I at least know if it's an emulator thing or... it looks a bit better. Okay. Yeah, we're the cursor. To be operated, we're the joystick. Or if you want a trackball. So, that's just the tutorial level. Yeah, this is like Baul-Dash-like a game. And... Yeah, this is... written with those tools. Libraries, compilers and so on. I'm from Kassel and I explore. Of course, let's go out again. And there's more interesting levels to see. In particular, it has a few two-player levels. Yeah, all those consoles have two ports for... to plug-in controllers. And, of course, it's natural to really use that to make multiplayer games. I mean, many of the old games were just one player alternating with the other one. But you can use it. And, for example, in this game, there's a few cooperative multiplayer levels. So, these two players have to cooperate to be able to solve this level. And, of course, you can make competitive for whatever games you want. Okay. So, any further questions? Maybe I can find my slides again. Excuse me. Yep. Is it possible to... if you write a game to produce cartridges for these consoles? Yes, I actually did. For some of those games back in the days. It's been a while since I made any. Yes, I did. The point is, okay, designing a PCB or whatever is... and getting the chips. I mean, if you know how to do it, you can do it. I used the... unlike everyone else, apparently at Foster, who seems to be using a key card. I used the older GEDA tools like GSM and PCB. And I did so. Then, of course, you need the cases. If you only want a few, you can 3D print it. But both myself and some guy in America also had a mold made, drilled, and kind of mass produced a few cases. They have different shapes, so mine are a bit shorter than the original while the guy in America puts more emphasis in making them the same shape as the original cartridges for the Colecovision. And for the Sega, I also... I don't have any numbers, but I designed an experimental one with a few 3D printed cartridges and a PCB on it. And I designed it so it's a double-ender. So one end, you can plug into the Sega systems released for Asia, so Japan and Korea and Taiwan, while the other end goes into the ones released in Europe and the US. And it's the same ROM chip is used by both sides, and it works on both types of Sega devices. Now, if there's interest, one could of course make a mold and have more PCBs made. For now, it's just a small project. And yes, when I did this spotting with the library stuff, I also did it with the games and I tested it and it works. But for now, it was just like a prototype on the Sega side. But on the Colecovision, many people have released games on cartridges by now. Let's say programmed themselves, yes. Yeah? Do you have any tools for debugging? Tools for debugging? There's no on-target debugging here. So you burn your ROM and to test it on the hardware in the end. Of course, first you can test it on emulators. The emulators are usually not always perfect. Sometimes there's some corner case where you have to be careful about timing so it doesn't fail on the real hardware. There's the Meka emulator. They're coming from the Sega side. It has kind of a horrible interface but it has an integrated debugger. So you can tell it, okay, breakpoint at this memory address or something like that and then look at the values of registers. So this is no high-level debugger so it's not integrated with its C-toolchain. It couldn't deal with, let's say, debugger output that could come out of the SDCC. SDCC gives debugger output on other targets like modern microcontrollers like the STM8. You can do on-target debugging with that but for those old systems, there's one emulator that I know that has debugging support but it's a bit odd to use. They even use their own basically Windows system and it looks like in the DOS days. But you can compile this emulator on modern UNIX systems and use it as a Meka emulator. So some debug support is there but most of my programming, when I write a game, first the trial and error thing and because it's some effort to get into this debugging, I mean I have to look up in the symbol table of the map file which function is at this address because the debugger only understands memory addresses for breakpoints. I use debugging but first I try to do it another way with some print statements or something like that or just display some message somewhere on the screen and things like that so the more primitive kinds. Further questions? How about making such a console on an FPGA? Oh yes. CollecoVision or Sega Master System on a chip? Yes, of course. I think there's projects that actually do that and dig it and we're able to get some graphics output. On the other hand, there's two aspects here. First, these old consoles are not as unreliable as modern ones. Oh, it's not absolutely... So a lot of people still... Okay, just for fun. Yeah? Yeah, okay. People write games. Yeah, but then you already have the powerful FPGA. Why not do a bit more with it than these relatively restricted systems? But of course, it's a nice project, especially if you want to combine it for the whole range or something like that and I know some people have done things like that but I'm not that familiar with them. I've seen they all reposted at the forum. Okay, there's some code and here's a picture of the first picture coming out on the screen. Yeah? You have to mist an FPGA arcade and it would surprise me if not for one of these systems that exist already. Well, it needs for the CollecoVision it exists. That someone did it, I don't know about the Sega systems. Okay, time is up or? Yeah. Okay, so if there's further questions you can ask me later.