 So, I will talk about something even older than DOS, which is this machine, my Oric Atmos. Yeah, it's my first computer, and people are still using it. So, I don't, maybe some of you know, but there are things that are called demo parties, where people gather and write programs to impress others and show them how they can do stuff on those things that shouldn't be possible like 3D and stuff like that. I'm naturally able to do 3D on this one. People write assemblers and compilers for these platforms because they need them. So, I'll show you the OSDK, it's a really Oric-specific compiler, and what we can do with it. Just a few words about the platform. So, the Oric Atmos is the second machine of the brand. There was the Oric one, so that's the second one. So, it's from 1983, it has this 6502 CPU, which runs at 1 MHz, and it only has 64 kilobytes of RAM. Actually, you can only use 48 kilobytes because the rest is used by the ROM chip, so it's hidden. And it has a Microsoft basic, but well, it's quite buggy, I heard. But nowadays, we can use SD cards with those. So, for other machines, there are things like HXC, if I'm correct, which is a floppy emulator. You can plug it in and replace the floppy drive. On Oric, the controller was outside of the computer, so we also have to emulate the controller. So, this cumulus device does it, so you can actually emulate floppies with it. We had a lot of Oric emulators with funny names. So, euphoric, ex-euphoric, which it was ported to XORG, it wasn't called XORG at the time. Caloric, which used SDL but still had some assembler, so it was not very portable. And then, someone wrote Oriculator, which was later renamed into Oricutron, because the former name was a bit too much. And Oricutron is written in C and it uses SDL or SDL2, so it's really portable. And it even has OpenGL effects, so you can get scan lines, the cathode ray tube scan lines on your screen. So, Oricutron is GPL, it's almost on par with the original emulator now. It has been ported to many platforms, I ported it to Haiku, AmigaOS also and many others. And it emulates most of the known hardware. And it even has a debugger, so we can do stuff with it. As for the SDK, it's written by Debug. Well, basically it's a set of tools he ported and changed. But he's a Windows guy, so when I tried to use it on Linux, it was like, oh, there are many I have to fix, because he said, oh, just use wine, you know. And so he puts patch files everywhere, which are not really fancy. So I started porting it to Linux, I got sidetracked, and JLM who's in the room, raise your hand. Thanks. I did some other fixes. But, well, since Debug also commits code, we also have to fix it again sometimes. But it's becoming usable. So it has several tools, the assembler of course, and the C compiler. It's decently NC compliant, so sometimes you have, it is weird stuff, so you have to change the syntax and oh, it just works. And a linker, which just produces the binary and some other tools that you can use to convert a text file to tokenize basic and read it as a tape file. So you can also write basic and use Git to see the diffs, which is much better. And other stuff, and Floppybiller can create an image which is used with a specific loader. It doesn't use the regular dose from the machine, but it's simpler for GMOS, which only needs to load resources once. And some other stuff, like Pick Conf, which takes a PNG file and tries to do something that looks not too bad on the Aurek, because the graphics format on the Aurek is really weird. And we can even play Yamaha chiptune files. So yeah, we can do some funny things. So I told you I didn't really like batch files, because they don't run on GNU Linux or Haiku as well. So I wrote a make file engine, which was inspired by the one we have in BOS, which we also use in Haiku, so basically you just copy the template and you just fill the application name, the list of files and some options and you just run make, you don't have to know the make syntax to use it. And I use a little trick and it even works with end make and windows, so we should be able to drop the batch files and it might be able to extract the info from the batch files from existing projects. It's not really finished yet, so I have to merge it in the main branch. If you want to have a look and comment on it, that would be a welcome. Installation should be as simple as getting the source and running make in the correct folder. It's not really finished yet. I think the install target itself is really not implemented yet, but just copying the files manually should work. And then to use it, you just need to explore the OSDK environment variable and then the make files should just be able to find the tools from it. Some day I might try to make a DBN package for it. So that's still some stuff to do. First, the documentation still doesn't mention Linux. Well, it mentions Linux saying we should use wine. And then we should try to check the license thing because, well, it's written by a demo-signer and the demo-signers just don't care about licensing in general, so they just put sources out there and, well, when you say, maybe we should choose a license for it, I don't care. But I'll try to handle it. And then, of course, make a proper Linux release someday. So I made a little example, especially for FOSDEM. I wanted to show the dev room schedule. So I thought, hmm, there's an ICS file for each dev room. So let's double get it and filter and generate some text. But I also wanted a logo. So I took the ones from the banners. And I had to spend some sometimes finding the correct flags for the PICT-conjutility because it also handles Atari ST formats and other things. But it worked in the end. You might, well, it doesn't really show on the beamer, but it actually tried to put a red line here. I don't really know why, but it kind of worked. So let's write in C. Write in C. There's a video on YouTube, actually, with that song. So here we just have a simple function which sets up the graphics mode. Then copies the logo. It should be possible to compact it and uncompress it on the fly, but it wasn't large enough to require it. So I just bled it to the frame buffer and then put a little text. And then we wait for a key press. And then we throw the whole day room schedule there. So here we are. So there it just builds the disc image. And of course it starts the emulator on the wrong screen. So here it is. I could just start it again. Yeah, okay. And then I press a key and there we are. Yeah, I don't have that. Anyway, yeah. So the sample code is here in the subversion repository. So it's a link so you can click in and go there. And voila. And it was quite short. So we have some time for questions, if you want. Yep. What? G-A-S-M? Yeah. So the question was why not use CC-65 or G-A-S-M, which is more generic indeed. Well, it just happens that this thing is really specific to the auric and so it was just usable well. I still have a Windows VM around. So at the time I was using Windows just for that. So I had my setup, my thing set up so I just tried to port it. But yeah, I'm not sure. I didn't really check the differences in produced binary size or whatever for CC-65. I'm not sure. I think I tried using it for the Kentucky port. I don't know if everyone knows about Kentucky. It's an IoT operating system which actually started as an operating system for Commodore 64 computers. And so the guy who wrote it made a PhD about it and now it's being used for IoT and sensor networks. So it even has an IPv6 networking stack. Yes, that's usable on the Commodore. It's certified by Cisco. But I didn't really finish the Kentucky port so I probably might have a look at this one again. Yep. A few years ago there was a presentation during a CPP con a process that would allow you to transpile XA86 bytecode into 6502 and as a demonstration they wrote a modern C++ game that would run on Commodore 64. Maybe that could be another option that would allow you to piggyback on it and for compilers in Intel platforms and would constantly keep the SDK updated. I don't know, maybe it's another possibility. Yeah, so that was using LLVM or? I'm not sure. What was the set itself? But they even displayed the assemble and it was quite lean actually. People expected it was supposed to be heavy but you actually mapped everything to registers and everything was very compact code. Yeah, so the question was what about tools that could transpile, that converts XA86 instructions to 6502 instructions that do exist because there were some demos about it. And it's possible we might have some working things with LLVM maybe. Yeah, I didn't really look into it but that could be a finite option and yeah, it could be used for C++. Yeah, C++ is not that large if you disable stuff like runtime type checking or whatever. It really has that much overhead. Yeah, I didn't really look into it yet. Thanks. In special reason why you still... Well, we all love C, right? But why you see when you are trying to place the machine in more than one kind of operating system? So why not use something like Java with code of some other language that can run in more than one operating system? The emulator, why isn't the emulator not running inside? The emulator, okay. So the question is why is the emulator written in C and not in Java which runs everywhere? Well, everywhere where you have JVM and all the classes. Well, yeah, I didn't write it myself. Yeah, I do use Java sometimes but it's quite portable. I think someone ported it to Android so I don't really know exactly how but yeah, it's probably harder to do it when it's in C than when it's in Java, of course, for Android. Yeah, but well, you can try to write one in Java if you want. Okay, well, thanks. I'll call the next speaker.