Best Little Emulator Ever Made! - part 3/3 + Live Q&A
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Linden, Randal
Abdelghany, Mahmoud
In this interview/conversation, acclaimed emulator programmer Randal Linden takes us on a journey down the depths of reverse engineering and emulator development. Rather than editing this conversation to fit a smaller time-slot, it is split across 3 parts, with a Live Q&A at the end of part 3. Part 3 highlights: Windows 95 Bleemcast! Learning reverse & emulator engineering
 you I'm very curious how we did this with Windows because Windows would have gotten in the way, I think, right? It does, and it did. Okay. And, and BLEEM did a bunch of ugly tricks. And I say ugly, but BLEEM ran portions of its code in what's known as Ring Zero through a couple of backdoors and bugs in Windows. Yeah. And it did. And it did. Yes, effectively. The dynamic recompiler generated. Optimized x86 code. Then flushed caches and. Did. It used Windows. But yes, it, that's why BLEEM never ran on Windows NT. Because the backdoors and the hacks work on NT. Okay, okay. That's, that's a good one. And you mentioned jitting. And so do you, did you use also the same strategy? Like, you know, you profile the hotspots and then you recompile that in a certain way and then you decompile. Okay. No, no, what it did is it literally did dynamic recompilation while the program was running. So it, it was effectively just in time a jit compiler that knew which portions of the code had executed and which portions of the code hadn't yet executed. And when it went to execute them, it compiled them. Then it ran. All on the fly. Yeah, okay. That's very interesting. That's very, that's very elegant and beautiful. I mean, I thank you. No, it's complicated code. Yeah, exactly. And it's, it's complicated code for, for. Yeah, how did I say this, you know, it's, it's like straightforward for a purpose, right? It's not there for fun. It's not there for show. It's, you have a purpose you do it. You do it very well. And the result is excellent, right? And this is like the discussion from, yeah, or the discussion we didn't go into about, you know, the difference between high level emulation and like, like, so low level emulation, right, and high level, we want to run this game. We want to run it well, we want to, you know, enhance the game. Boom, right? So that's, that's how it goes. And the other way, which is also very nice and that's usually what you do for a hobby project, right? Yeah, sure, you want to emulate every like, you know, illegal opcode and, and, and like the thing with the V blank you mentioned. Yes. So, so yeah, dynamic compilation. Nowadays, everybody does it of course because. Yes, because you, because you can because it's, it is a commonplace technique. The beam is a blend of low level emulation and high level emulation. Blem sort of crosses the line between the two. There's the low level emulation of the processor, but higher level emulation of the graphics co processor and of the motion. And then there's the high level emulation of the sound chip, but high level emulation of the bios, for example. And then sort of a weird mix of both. And that's what allowed it to, that's, that's why on the Dreamcast, you could use the Sega Dreamcast VMU. Store PlayStation save games. Yeah, okay. Yes, that's true. Yeah, sorry. Yeah, okay. I'm thinking. Yeah. Yeah, okay, that is hard. So, yes, small question or so. So when you guys like, did you at any point like get a PlayStation development gets. No. Why not. I read. Because for obvious reasons we want to keep everything completely clean. Clean room. Didn't want. Sony to turn around and say, well, you've had access to all of our whatever technical information and hardware and so on. And I'm sure that if we had asked, no, so we just sort of did it independently. Yeah, okay. All right. I think the yeah, I have too many questions but you know, I told myself I'll try to keep this two hours and I think we're more than two hours now. So, so let's let's say I just have one more question. And after after that, you can you can talk about anything you want and we will see. I have all the time in the world, right so I can sleep like I said I'm too excited to sleep so no problem I've got I've got lots of time like I said I blocked off my whole afternoon. So we can just keep talking. And edit. Never portions. What, well, actually I'm thinking because because because this year fast them is is virtual. And they said because usually in fast them when you like have a development room. You say, okay, I want it for like half a day a day because of location a physical location. But this year they said so everybody's virtual so in principle, you can have as long as you want. So, because it fits between 10 and 6pm or 10am and 6pm. So technically speaking, we have two days, right and we already have exactly right so. No but it's like, this is too much too much to talk about this is just this is. My pleasure and my distinct honor to be able to talk at length. So I, I'm always amazed somebody has any interest in what I have to say. And so, if people want to hear, then I'm more than happy to talk. I'm always amazed at people that don't have interest in these kind of things and people like you, right. And to give you a short example, I was trying to explain to my wife. I have this amazing, you know, call I have to make and I'm trying to explain to her why and my wife is the least technical person on earth I think right so it didn't register with her but my enthusiasm did so she's happy for me. But that's about it right but I mean. Yeah, I mean, so, because. So yeah, so for your is for example the source code of doom right but blame for for obvious reasons wasn't released. So, you see this kind of interaction is more useful than the source code itself right because source code shows you the end result it doesn't tell you about the journey. It doesn't tell you about all the stuff you went through right and these and this this is this is amazing so right so. So if I end up, or we end up editing this, the full video should be posted somewhere and this will be done of course with your permission and such, right, because even I think somebody will find something useful in one of the jokes we made. And hopefully we won't be sued by Sony and right and or I don't think we made anybody else mad. I mean, but, but especially Sony less that's not that's not good super Sony, but. But, but one thing I was really curious about and this is gets it's basically right so. So it's actually next for BLEEM right before it stopped right so the things you had in your mind you wanted to implement right and I'm not sure if you can talk about this or not but. The next set. We're going to do more. BLEEM for Dreamcast. Final Fantasy seven. Spyro the dragon crash bandicoot. Crash Crash is one of those games that's very known for for how do I say this politely. There was recently one of the creators of crash he did like a video for ours, Technica, and he mentioned all the stuff they did to get the game working. And I'm not really certain most of the stuff is not the official way of doing things on the PlayStation so it would have been a very. Yeah, you're exactly. That's what I'm preaching for you. Yeah, yeah. Yes. Yes, that's exactly why I think that it would have been one of the great great games also one of my favorites was medieval. Because the graphics, the caliber of the game was just so, so high. It's a shame the Dreamcast died. I still have my dream cast. I don't use it but I do have it. I think a year ago or two years ago. Excuse me. There was something on the internet like like a hype because the website Dreamcast to was registered by Sega or something like that. And everybody was hopeful, but we haven't heard anything yet so who knows who knows. Everything is possible. Everything is possible. Everything is possible. And recently Shenmue 3 came out. No, I know Shenmue was one of my favorite games ever me to me to. So, it was the reason I got it. No, it wasn't a reason to cut the green cuts but that's something else. And with a for BLEEM, were there any like things on the roadmap for BLEEM, you know, because, like you said you started to interpret it, then compiled, re compiled and then jitted, so to speak. Was there like something after that. Yep, give me one second. Oh, sorry. Sorry. No problem. At that point. BLEEM had largely run its course. And by that I mean it was a challenge. How can I put this. It was a challenge to sell. Because stores were concerned about carrying the product. And so BLEEM for the PC sort of had run its natural course and then there was Connectix Virtual Game Station. And so we were at that point shifted and focused mostly on BLEEM for Dreamcast. And so the next set of games that we were going to do were Final Fantasy 7, Spyro, those games, because they were, we wanted games that were the pinnacle of each of their genres. Yeah, okay. But that's that's more from a business point of view and from the technical challenging point of view. What was your next Mount Everest so to speak. My next one was as it turns out to be Cyboyd. When I say, you know, think quake. It's a full 3D engine that was written. There is a video. There's a video online that shows I had it running on a Game Boy Advance. So yeah. Okay. It used a lot of self modifying code. It was all optimized arm assembly. Oh, we're talking assembly again. Okay. Yes. As a matter of fact, Cyboyd, you can get the game on Android phones. And Amazon Fire TV and Fire TV stick and it's a free game to download. But chunks of the game are from the original engine that's 1015 years old now. And so they're written in arm seven assembly. Okay. Yes. That's interesting. So that was the next, the next level, I think it was originally, as I said, designed for Game Boy Advance. I got it working on iPod video. I got it working on Cindy and cell phones. This was before cell phones had 3D graphics cards. Yeah. So to see a full 3D game on a cell phone. Nowadays, it's commonplace to see a full 3D game on the cell phone but back then, it was unheard of. Back when the phones weren't so smart. Exactly. When the phones weren't so smart. Nokia was everywhere. So we can use. So all the graphics and then have to be done in software. So Cyboyd was a sub pixel sub textal accurate high speed 3D engine. And mostly on arm. Arm is by far one of my favorite processors. Okay, let's let's hope they stay. They stay. They stay so. So, exactly. Well, now with with Mac using what they what they call Apple Silicon, which is basically arm. Yeah, they're here to stay. They're doing some cool stuff with emulation I heard so. Yes, exactly. They emulate x86 x64. Microsoft is doing the same on their on their surface and windows on arm that emulates. Yeah, yeah, I read a blog post about that. Yeah. But emulation is everywhere. Exactly. I kept keep telling people that but they don't believe me. So, yes. Yeah, no these days emulation truly is everywhere back. And when when BLEEM on the PC came out, emulation was rare. It was, it was exceptional. In the sense that it was very rare to come across something that needed emulation. And these days emulation is everywhere it's in backwards compatibility, it's in forwards compatibility it's in the average PC these days has not only emulation built into it, but emulators that run on it. And I think that's a good thing. Oh, absolutely. It's a good thing but one thing that still puzzles me. So it's, it's like, so emulation is everywhere. It's part of most things. And yet, if you go to Amazon and search for emulation books, you will find absolutely zero. I don't know if it's zero but a couple of years ago it was zero right if you go and search for papers on emulation. Okay, it's not zero but it's not papers on. I don't know what's something popular. You know anything, any graphics. Yeah, exactly any graphics thing or whatever right. If you go to conferences or YouTube and you search for emulation talks and conferences. And that's also not that much I have a playlist of all the videos I could find. I think it's like 10 videos, and like five of them talk about the same thing, right, and they're good videos but right so that's something that still puzzles me I'm not sure why that's the case but sorry, I'm just eventing I don't know emulation is one of the black arts of technology and programming emulation is sort of a niche. It's not like graphics. Where, you know, everybody Oh graphics. You know, the latest thing is now retracing with graphics and I remember back on the Amiga, where they had the bouncing ball juggler with the retrace balls and, and now that that could be done in hardware, but emulation is I think it's a technology that that it's a calling your either really into the emulation. seen as it were. Or you're using emulation and oftentimes people don't even know it. Like I said, backwards compatibility for games. So a good example. Apple's new Max that let you run the old software, transparently. I think emulation is one of those things where there isn't really a book on it. And it's not because it would have to sort of be more about the generic here's what you're trying to accomplish, rather than here's a concrete example of an emulator. Yeah. Yeah, yeah, yeah, you have a point. You have a point. I'm sad to say you have a point. Yeah, there isn't a big calling for for how to. Yeah, what you just said made me think about all those books on games and there are a lot of books on games, and yet they don't teach you much about games right so No, they don't they teach you. They'll teach you 3D math or they'll teach you 2D math and transformations and but it's harder to find a good book on games on writing games and all the complexity. It's sort of like the proliferation of games and apps on cell phones these days. They really sort of fall into one of a few categories one is the standard match three game, like Candy Crush. You've got the choose your outcome game with match three, like home scapes, you've got puzzle games like word combination games and then you've got card games. Often you'll have something like a call of duty or fortnight or something like that, which is tough to play on a cell phone anyway. But you won't have games that were from like back in the commuter 64 days like Broderbund. Games like Zeppelin or load runner or frantic Freddy on the commuter 64 just finding books about making those kinds of games is is harder. The latest project I'm working on is built on mono game, but before mono game was the platform of choice. I went through a couple of weeks of I looked at Unreal I looked at Unity. I don't even remember all of the platforms and libraries and tool sets and tool chains that I looked at before I finally ended up settling on mono game. And it's nice that there's all of these things that are that are available. I mean the, the, the Unity example comes with a full 3D platform game as a sample. Something like that would would, you know, take somebody a couple of years to build but here it is you just point and click and now you've got a Lego platform game with physics and 3D and everything and then it's, it's not particularly fun to play it. But it's nice that the technology is there. Somebody discovered that fun doesn't necessarily mean sales but yes, let's let's not get into that. That's a very frustrating discussion so it is it is today's independent developer is screwed. It's a different ways from Sundays. It is as an independent developer myself, it is very, very difficult to, to earn a living. Basically, people don't like ads. People don't like paying for games. And people don't like in app purchases. So, you're sort of stuck between a rock and a hard place. Yeah, I guess. And the last thing about what you just mentioned when we were talking about the books and such. So, so I'm not, you know, I'm not going to ask you how you learned so that's because it's different times of course and different mindsets but how do you think people can get better at reverse engineering or emulation developments. I don't know how do how can people practice. That's a good question. I would say that people should look at existing a lot of existing emulators are open source open source is wonderful. It's phenomenal. I can't say that enough that's why I released the source code to doom for the Super Nintendo on the Super FX chip. Because I think it's important to give back. I've been very, very fortunate to work on some, some great projects. I've been very, very blessed. I wanted to share the knowledge. And I think that if people would look at existing emulators and the source that's available. They'll get an idea of the complexities involved. Emulation of a given system. Oftentimes is the same you've got your processor, you've got some co processors you've got some extra chips. So find out as much as you can about the chips about the system about how things fit together. Look at existing emulation software technology, especially stuff that's open source. And read a lot of it is is reading. I mean reading code or reading literature. Both. Both. Code, I think you're right. In the code sort of shows you the end results. It doesn't show you the steps that it took to get there. But sometimes it's okay to, to know the answer. If you're in the right mindset, you can figure out what the question is. If you're looking at existing code and how existing code operates, you get the answer. But then you can go in and you can tweak it and see how things change. And I think that that's important. There aren't really books on emulation but there are books on the processor and and these days, as I said, most people don't have a processor manual because they've got a C compiler or they're writing in C sharp and it's in interpreted language or intermediate language. But one of the most interesting videos that I had seen recently for me personally was like I said, the process that this team of two or three people took to delaminate the data here, a 6502 processor. And it showed here's all the gates and here's how the gates operates and I, in my mind, because I had programmed it in machine language. I mean I still know low to immediate accumulator is a nine and X to zero is jumped to sub routine and hex six years return from sub routine and and so I programmed, knowing all of these op codes. But to see how the bits are actually implemented in the silicon was amazing. The technology that's 30 plus whatever years old now for the system over to is nothing compared to today's chips. But never stop learning I guess is the best advice I can, I can offer. It sort of goes back to there's always a better way of doing something there's always more efficient code cleaner code, more robust code or smaller code or whatever. But if you've got that quest for knowledge in that, that interest. It will keep you going and that, I think, is one of the key things that sets apart emulation programmers from other programmers. Yeah, okay. I was I was just triggered by something you said. I wasn't actually was my intention that this was the last question but this will keep going on. Unfortunately. But, but, so I was actually thinking did you actually worry about cycle accuracy during the BLEEM developments. No. Okay. Okay. cycle accuracy is There are pros and cons to cycle accuracy. The BLEEM is not cycle accuracy. But that doesn't matter. And it matters even less these days. Because games aren't like they were back on the 6502 or 62816 with the NES and the Super NES and the Sega Genesis and, and the PlayStation where you have to have lots of really complex code and it had to be timed and it had to be efficient and, and these days, your, your code. Your code is typically not the bottleneck in a given system. So, you know, the polygons you're trying to push or something else, and your code is running faster than the frame rate anyways and so generally speaking. No, BLEEM was not cycle accurate and it wasn't intended to be. Yeah, okay. We actually have a talk about the cycle accuracy. It's a short talk, but it's amazing. But, but, but you didn't have cycle accuracy is tricky. It's tricky, but so I don't want to spoil anything because I don't know in which order the talks will be but actually the speaker he kind of said, because I watched part of his talk because they should be uploaded and such. And he actually argues that cycle accuracy is. Yeah, kind of like a. It's not the most important metric you should try to adhere to. Let's leave it at that. I would agree. I would agree. And BLEEM is a good example of cycle accuracy being a measurement. But when it came to the enhancement of the games and the full screen, by linear filtering and and multi sample anti aliasing on BLEEM for Dreamcast cycle accuracy wasn't even part of the equation. But the results I think speak for themselves. Yeah, okay. That was almost most definitely. But you did you like. So like I said the questions just keep. Anyway, so, so did you like, like come across any bugs that were caused by the cycle accuracy of the PlayStation. And yes. Oh, yes. Yes, especially in later games. Later games are much more difficult to emulate at a high level, because programmers started writing directly to the hardware. And the code was much less efficient. And the code was much less efficient. But later games were much more efficient and they knew that if they did this sequence of operations, it would take this many clock cycles, and then they could do this sequence of operations. And it's sort of like the, the Pentium where you had your floating point pipeline and your integer pipeline and all these pipelines could be interleaved if you did certain things in certain order. And so yes, the, the later games in particular were tricky to emulate because BLEEM was not cycle accurate. Okay. And what about BLEEMcast because you're talking about too far and you know you don't have as much control as the PC of course right. So, actually had more control. Really. Mm hmm. BLEEMcast was actually nice because we had complete control of the system. Okay. And no, no OS security. Okay. I always assume because you know they have the Windows CE logo that it was like secured to hell and back right but No, everything was written to the lowest level straight to the metal. Really. Oh yeah. That's very interesting. Yeah, BLEEMcast was was all low level talking directly to the chips. I mean because at least those GD ROMs you couldn't read them really properly on the PC, right. Because. Well, you could. There were ways of reading them. Yeah. Okay. But I don't want to like inspire people to go in there. We did a lot of weird stuff with the dreamcast and. Yes. Okay. It was a misspent. Underlying operating system on the dreamcast even for dreamcast titles. You basically would write your title and link with Sega's libraries. But there was there wasn't really a low level like on Windows where there's an operating system that's running all the time. Okay, that's interesting. So for BLEEMcast we had complete control of the system, complete control of the hardware. It was it was a lot more work. Because there wasn't an operating system and because we couldn't use Sega's libraries. How did you actually. Okay, so how did you compile for the dreamcast without Sega's libraries. By writing straight to the hardware. And the structure. Oh, you wrote the executable for. Okay, that's amazing. And it's all SH4. Yeah. Okay. Hitachi thing or something. Yes, Hitachi SH4. And we had all the documentation to the PowerVR chip set. And to the Sega Dreamcast chip set. And we knew what registers to write what values to do certain things and it was all written in low level assembly language. Uh huh. Because because Sega, Sega provided all of the information, but said, we can't endorse you we can't really support you. We can't publish your title. So we have no level hardware documentation that we don't give to anybody else. For all the different chips that are in the dreamcast. Enjoy. Okay. And psycho accuracy was never a problem that or it was. No, it wasn't. It wasn't a problem because the game was running faster. And it was waiting for vertical blank rather than the emulation running slow. The same dynamic, dynamic optimizing the recompiler that I wrote for the PC that took MIPSR 3000 code and generated x86. I wrote one that took MIPSR 3000 code and generated optimized SH4. Really. Yeah. Let me write that down. Are you allowed to do that? I mean, does the dreamcast allow you to do that because you're basically changing the running code. Yes, exactly. Wow. And then the dreamcast I don't remember how much ram they had but it wasn't a lot. It was enough. Yeah, there was more than enough for writing optimized SH4 code. Because the PlayStation was very limited. Yeah, compared to the dreamcast and a PC. Okay. Yeah. There was never more than if the dynamic recompiler ran out of memory, it would just flush everything and start again. And so there wasn't really ever running out of memory. Yeah, okay. It basically recompiled blocks of code. And it just kept it in a big buffer. Yeah. And when it ran out of space, it started from scratch again and said okay pretend that none of the code is compiled yet. Start recompiling. Your game would like slow down for a bit till it like warms up again and Imperceptibly because it happened so fast. But yes. This is, you would never imagine all that was going on. Exactly. On a totally totally foreign system. Yeah, yeah, that's amazing. Thank you. It's truly is the shame. So, you know, we will never see the code, but who knows. Maybe somebody out there will reverse engineer it for us and I guess I saw your doom code right and and one thing that really so I haven't threw all the code and I'm not that good at assembly but one thing that really jumps out at me it was how well it was documented. Thank you. No really because so and I'm not trying to offend anybody but because the principal has been complimented on my code. I mean, it was, but you know because undocumented C code I don't have a problem with okay I have a problem with that but it's still C code but undocumented assembly code right that's that's, and it's very well structured very well documented and so I thank you. I hope whoever reverse engineers blame documents and structures it in the same way so let's just say. The code is. Well, that's what you get when you spend 38 years writing code, you sort of build up a degree of self documentation because eventually you'll go back and it makes it more maintainable. And the code from, I want to say it was 9596 was the super effects code I think roughly a long time ago. But still, it was very nice and I'll look through it and see how it works out. Well, thanks. Well, like I said, there's an even better way of doing it now. Yeah. So with emulation so that's always nice. You meant running it. Sorry, or at least that's what I meant. Right. So yeah, I don't. Yeah. I'm looking at my list of questions, because I wrote a lot of questions beside the questions that I sent you, you know, like I said, I couldn't sleep so I kept writing stuff and whatever but yeah. So do you have anything that you think we should have talked about and we didn't talk about. I don't think so. I think we covered a whole bunch of different things. Yeah, okay. Yeah, yeah. Yeah, I can always come up with questions but I think, you know, enough should be enough at some point. Okay, I've kept you for a very long time now and no trouble at all. I'm very, very grateful. I think a lot of people will be grateful. I mean, you mentioned you will be, or you will try at least to be available for Q&A. I will. I will be available for Q&A. As soon as you tell me when it's scheduled, I will make sure that I'm up either very early or very late. Yeah, we will set it up. And I hope, so yeah, this is our first time doing this at FOSDOM. FOSDOM usually has like a lot of rooms, developer rooms and we usually have like a retro computing room and there's some, there's some emulation talks there but this year we thought let's try to do a dedicated emulator room. So it's the first edition and so far the talks have been good, like the proposals and I hope a lot of people attend and have a lot of cool questions for you, right? So that's what I'm building up towards. You've been great. You've been awesome. I don't know how to thank you actually. My pleasure. My pleasure. It's been an honor. The honor was all mine really. So thank you very much again. I don't know. That's that's the end. Yeah, okay. It's very sad to say that. So I'll probably stop, you know, cut the video at this point and this. Sure. Well, if you come up with more questions and you want to have another hour chat or something. You're spoiling me. You're spoiling me. Right. Not at all. Yeah, so I'm taking a quick look and seeing if we went. I think we got to. I think we got through all of the questions that you'd written down but I'm sure that there's a whole bunch more that are always are the always are this. It's a problem right so and that's good though that's good it's. I don't know if you're going to share the. Yeah, but you know right like so so you're a very kind person and I don't want to like miss you that you're such a kind person and just keep you talking for a couple of hours or just bug you out of nowhere and that kind of stuff so no problem. It's thank you very much for that. This is awesome. I don't know how it is going to work out. We will plan the Q&A of course and we'll see how it goes. Thank you very much again. I look forward to being online and answering some questions and chatting with the audience. I'm very sure there'll be a lot of questions but we'll see. So, and a lot of more advanced questions because you know I'm not that active in emulators more as I used to be, but some of the more advanced people will ask questions that you will enjoy more than my questions I think so. I have enjoyed your questions immensely. Thank you. Thank you. Thank you. Thank you so much. Thank you. Thank you. So thank you again. Enjoy the rest of your day and I will keep you in the loop. I guess for the things. What about the super FX chip for a while, right? I think we're doing live Q&A, by the way. Let me just get one second here, see how we're doing. Yeah, I'm just waiting for the bot to announce that channel thing again. Yep. Hey, we're getting some questions as well. Have you been eating as well? It's been a long day. It's been a long day. I have. In between, I've been eating and I've had by my coffee and my tea and... All right, good. Good. Yeah, I've also been running back and forth between sessions. Okay. And we are live. Yes, we're live. Excellent. Now, if that bot would just do that one message, right? Otherwise, we can just go ahead, but I think it's a bit nicer to wait. Yeah, yeah. What are we waiting for? I thought the bot would give our links in the chat again. No, no, no, no, no. This is part of the live Q&A. This is on the live feed. Gotcha. We have like 40 minutes on the live feed, I think. That's perfect. All right, so let's just go ahead then. Sure. Welcome back, everybody. This time we've got Mahmood in the video as well. I think we're just going to do some audience questions and then... Dressed as Waldo for the people who know who Waldo... Yeah, that's amazing. So, let's start strong and then just sort of fizzle out. I'm going to do some audience questions here. And some of them have already been asked, but just now we got a new one. Let's start with the fresh one. Pegasus Ryder asks, how is the machine language translation implemented? For BLEEM, it was done in Pentium, all assembly code, where it took each instruction and dynamically optimized the MIPS op codes into Pentium x86 instructions. And on the Dreamcast, on the BLEEMcast, it took the MIPS R3000 and generated optimized SH4 for the Hitachi processor. Does that answer? We'll have to wait for Pegasus Ryder's response, but in the meantime, we'll move on. Another relay question that you've answered in the chat, but let's put it here for posterity. What was source control like back in those days? Yeah, back then, none. There was none. There was no source control because it was just me on the PC, so there wasn't any source control. And on the BLEEMcast, there was just myself and there was Rod. And so between the two of us, we didn't really need source control either. But if there were more developers or if there was a lot of art assets, things like that, we would have definitely needed some sort of source control. But back then, this was around the time when there was, I want to say SVN and Tordis. And I want to say there was Microsoft Source Safe, because I remember there was some big bug where all of a sudden you lost all your code. There was no source code version control. Nothing ever was wrong? No, nothing ever went wrong. Usually I'm a fairly organized person. So yeah. We also saw the notes, so we know how organized you are. Yes, those are real notes from the Dreamcast development process. So yeah, you can see I did this to this day, still use a pencil and a notebook with written notes on it. So in theory, we can rebuild BLEEM from your notes? Theoretically, yeah. Okay, but a follow up question for the source control question is because when you got to BLEEMcast, you had somebody working with. Did you guys do code reviews of each other's code? Not really. We were working on different areas of the code. I was doing the vast majority of the code and Rod was helping out. So pretty much it was coming from BLEEM on the PC. A lot of it, I don't want to say was translating, but it was a lot of it was translating because I had already done the majority of the reverse engineering. So it was sort of like doing a port, I guess is the best way of describing it. It was more like doing a port. There was still some reverse engineering. Like I said, when Metal Gear Solid, beautiful game, even by today's standards, some of the special effects that they used, I needed to do some reverse engineering to figure out exactly how they were sending down certain types of polygons and things like that. But the vast majority of the hard work of reverse engineering, the PlayStation system, that was already done. Alright, we're getting a really nice questionnaire from Phil. I'm just going to paraphrase it. You've talked about reverse engineering. And Phil wonders, how could you bring this mentality or curiosity to a new generation? Do you think it can be taught at schools or universities? Good question. I hope it is. I hope because technology moves so quickly that without emulation in particular, we're going to lose a huge amount of our history. It's only been 30 or 40 years for video games. And if we don't preserve video games, we're going to lose all of that early history. Everybody knows Pac-Ban and everybody knows Space Invaders. But if we don't have some way of bringing that history forward, it's sort of like studying art. Now, I don't know very much about art. But universities teach art appreciation and art respect and they teach painting classes and things like that. And I think that especially for computer science and technology, it's important that we not only preserve the past, but we teach about the past. And so I don't know that there's going to be an emulation course per se. I think a lot of courses teach processors, for example. FIENSE, that kind of stuff. Exactly. And I think that that's a very good start. Machines these days are, they're very advanced, especially when you get to PS5 and Xbox series. They're very, very advanced machines. But the APIs, the programming interface to them is much, much higher level. Whereas compared to like the Super Nintendo and the Nintendo 8 bit, you wrote everything in assembly language and you had a hardware manual that explained how all of the different hardware registers worked. And these days, you don't really need to do that, which is good. But now everything is, you have to have the latest, most complex mathematics for doing ray tracing and things like that. And it's different trade-offs. It can be quite daunting. Yeah. Yes, exactly. The scope of knowledge required is much, much larger than it used to be. The university is still four years. So it's all very tricky to fit. Anyway, you just said the word Super Nintendo again. I keep forgetting to ask the question, but you mentioned, or I read it somewhere that for the Super FX chip, when you were doing doom, there were no development systems available. Yes. So how did, how did they expect you to reasonably do a job there? Well, they didn't. Oh. So we received at Sculptured. Sculptured received the, here's the list of op codes. But Nintendo was still developing the development system itself and they didn't really make it available. And so I came up with the idea of, hey, let's hack the Star Fox cartridge. Let's replace the ROM with RAM. I mentioned this, right? Yeah, it was, it was literally a big breadboard with RAM on it and a little tiny boot ROM. And I wrote an interface that connected between the joystick ports. It was a serial protocol. So it was only two or three bits. And then I was working on the joystick ports on the Super Nintendo and the Amiga parallel port. The whole development system was all done on Amiga. So that's why when I released the source code to the Super Nintendo version of doom, I released the development tools as well, but they're all compiled for the Amiga but if you've got when you a e. It actually builds. It's a nice thing. So they did not expect you to properly do that. No, no, they didn't. At the end, towards the end of development when I had had the prototype operational. Nintendo sent over a custom hardware development system. It was a big box that had the super effects chip inside of it. Did that help at all or were you finished with that? Oh yeah. Yeah, yeah. Oh yeah. Immensely. But it took a lot of work to get it operational. It was a SCSI based interface. And I had a SCSI card on my Amiga and so I had to write low level I had to reverse had to reverse engineer Nintendo's development system. In order to make it work with my development system. And when that was done, it was possible to complete the project. I think it was quite well received as well. Have you ever worked not only in the Nintendo area, but you ever worked with any of the later enhancement chips like the DSP series. No, nothing. Yeah, my experience was just limited to the super effects. Gotcha. Okay. So audience questions. If you want to chime in just go ahead. You're here now. No, no, no. Great questions. Great questions. Let's see other people that are pleasure of asking and answering and getting this. This is a quite a valuable question. You asked one was if you friend look at give us a one on one. What's done. I reckon it's exactly. Yeah, we had a couple of discussions yesterday and some people talked about it and, and, you know, we were interested in, you know, how to get people, you know, started there actually, and what it is and how it works that kind of stuff right so. Okay. Well, typically, an emulator is an, an interpreted emulator, which means that you've got your program. And sort of like the way the processor works, you read one instruction. You figure out what the instruction is, and then you perform the operation so it might be addition, it might be subtraction, it might be exclusive or, but you do it one step at a time by reading the instruction from from the memory, interpreting it. That's why it's called an interpretive emulator, and then running code that does the actual operation. A recompiling emulator can be generally one of two forms ahead of time, where basically you take the program as a whole. And you translate instead of interpreting each opcode reading one opcode interpreting it, and then performing the operation, you translate it it's sort of like taking a book and translating the book into a different language you start at the beginning at the very first word of the very first page. And you translate word for word, and you translate from from one language like English into another one like, and say. And then you've got a book that's completely on call say, which you can read a dynamic compiler. Does this translation, instead of doing it ahead of time, it does it word for word, while the program is actually running. The dynamic recompiler will dynamically as the program is executing, instead of interpreting each opcode, it will translate from English to French, as somebody speaking it's sort of like having a translator in between the two processors. And then you've got the original code that was written in one language like MIPSR 3000. You've got the program which is the emulator, and it translates while the program is actually doing the running and the operation. And the dynamic recompiler is at the end stage is where you've got an optimizing recompiler, where, if you've got multiple sequences of operations, the dynamic recompiler can see the data flow where data is going sources and destinations and what kind of operations are being performed. And it can combine these operations together. And then you can do multiple certain operations like multiplying by zero always gives you a zero so you can skip the step of doing the multiplication. So, sort of an obscure example but there are cases like that, where if your original language has an instruction for addition. A translated language might have multiple ways of doing addition. If you only want to add one. Usually there's an opcode to increment. And that opcode is a smaller more efficient opcode because it knows that it's only going to be incrementing by one. So you can see, oh, this, this one processor has an addition instruction and it's adding one. So instead of writing the generic translation of using the addition in the target processor of adding the value one, I'm going to use the increment instruction instead and so it ends up generating optimized version of the original code. Does that sort of help flipping a single bit instead of doing the whole generic. Instead of adding generically, it can use the special opcode which is typically a smaller opcode to increment. That makes sense. A couple of years ago they had at the first time they had a talk. I think they were doing research about something called super optimization. I've never heard about it before. It's, it's, it's what you just, you know, the last part you just explained that but on steroids. And I couldn't really see it working in real life, maybe for small snippets of code, right. It does. No, no, but what they did know what you mentioned. Okay, that I believe but what they did that was like brute forcing all the, all the possibilities and then seeing which ones are the best, you know, and then using that type of code and speculative stuff. Yeah, but the way they explain it was very interesting. Yeah, research university stuff so cool stuff. Yes. Sorry. I'm going to jump right in here again. Sure. Which assembly giant likes. Have you enjoyed the most. Good question. That's a good question. I think by far my favorite is arm. Assembly. Original on assembly, because, well, it's a toss up. I've enjoyed super effects, the GSU to because it's it's sort of a largely a risk processor. And as it can combine it's like the arm processor that they're very, very similar. The arm processor can take multiple source operands do an operation and put the result into a destination register. So you can do things like take one number in a register, add it to another register that is shifted by a certain number of bits, combine the result and store it in a third destination register, all in one opcode. So it's very, very powerful. That's why arm is used in most cell phones in most handhelds in low powered devices, because it's it's a very, very, very powerful instruction set that is also very compact. Yeah, so I'd have to say definitely it's a it's a tie between arm and the super effects GSU because it also could do similar kinds of operations you could see from this source with another source register so you had to operation to source operations, combine the result and store it into a third destination register, very, very elegant. To be honest, I have expected you to say 6502, but oh I'd like 6502. Really a dialect of course but I like 6502, but I think that arm and the super effects are just so much more powerful. So you got 6502 and 650816 because they're simple. You've really you've got three registers you've got your accumulator you've got your your x index, and you've got your your y index, but on the arm processor you got 15 registers you've got all these registers, and on the super effects you've got 15 registers. There's a lot of flexibility. And, and it's nice because it allows you to do some very, very powerful things these days compilers take care of that for you. You write your C code and the compiler generates really nice optimized code, but back then the, the, the average programmer, who was an assembly language programmer could out optimize a compiler. And these days that's not really the case anymore. I see I see in a comment here, I guess the answer would include Motorola 68 K or is that 80 perhaps right so. Yes, it would I like I like 68,000. I think 68,000 is a little more cumbersome. But loved the Amiga Amiga is is, I think, by far one of my my favorite platforms ever. I've done 68,000 for sure. Yes, and I've done very, very little z80. Z80 is one of the one of the very, very popular processors that I don't have very much experience with. Yes, also very popular at this conference. So, yes, today alone there were like three or four talks and yesterday it was mentioned a couple of times it's generally very, very popular at Fossum so. Oh yeah. Alright, sorry, Neil's take it away. Let's see what else I have. I was looking at the bleemannual. Yes, since I have it here now. And one of the things on page 22, it says a game that used to work fine is now freaking out. If you're, if you're getting random graphic glitches in games that normally render fine. It usually means memory has gotten stepped on somewhere. I don't know, you could explain what that is. I'm not quite sure. It has been so long since I've seen that marketing language right so that's that's marketing speak. Yes. I don't even know what to say. Well, then we'll leave it at that. I just want to say that this is really nicely written. David, David Herplzheimer, my business partner from BLEEM did that. He did. He did all the graphics. He did all the marketing and the sales and oh yeah. When people think of BLEEM they think of the emulator. The emulator was just one small part. There was a lot of people that, like I said, like David or like Will Kep or Scott or John Hengartner, our attorneys who made BLEEM possible. I'll highlight another thing that I really like and then we'll get back to the questions on page 5 launching BLEEM because we know you're probably not even reading this. We hate manuals too. We've preconfigured BLEEM to let you start playing right away. It's all really nice and I also saw somewhere like an advertisement. It says 400 new games for your dream cost. Yes. It's just really, really nice. Whoever thought of those things. Yes. An audience question again from C Creighton. A question from an uninitiated about the Dynarec. Do you take into consideration the timing of certain operations and how? Yes and no. For BLEEM, BLEEM didn't really take into account that certain operations took longer than other operations. And so that caused potentially all sorts of issues. For example, multiplication is typically an operation that takes more than one clock cycle. But on BLEEM, multiplication wouldn't necessarily take more than one clock cycle, depending on the processor that it was running on. And so there were estimates of how long each operation should take. But BLEEM wasn't cycle accurate. And so it didn't really take into account things like latency and hardware latches and op codes that took multiple clock cycles. I think that answers it. I have a relay question. I want to run PS5 games on my PC. Where do I begin? You relay that from yourself, Nils. Yes. Where do you begin? Okay, so get a big PC case and empty out the PC. Put the PlayStation 5 inside it. Close it up again. So just give up, basically. Well, at the moment, give up. Maybe go for PS4 first. Exactly. Go for PS4 first. Like I said, these days the machines are so complex and so fast that it usually takes a general, that was one of the, that was one of the things that was rare, I think about BLEEM, that the need for a generational leap wasn't quite there yet. So you could run on a reasonably low end PC, a PlayStation game that had all of these custom chips and custom hardware in it. These days PS5 and the new Xbox series are state of the art. So you could buy a very, very high end PC to run games comparably. And to emulate them, I think that that's probably a couple of years out. I'm seeing some comments here, because this is something that's, you know, people discuss this a lot is because most of the hardware of the new Xbox and PlayStation 5, it's all x86. Yes, it's all x86. I'm pretty sure that it's Ryzen. Yeah, I think so, yeah. Yeah. So the assumption is usually it should be actually easier to implement. Yes, emulate right so. Yes. Yeah, I would agree. The, the, it should be easier. I think that especially, as I said, games these days are writing to a higher level API. You're not writing to the low level hardware as much. And so I think that emulation of later systems is in fact easier to use an example for the Dreamcast. I would personally were I to write a Dreamcast emulator, I wouldn't emulate all of the Dreamcast hardware. I would emulate the software libraries, because all the developers have to use the software libraries. And so if you, if you knew that the software libraries were there. You would use the software libraries and do the same kind of enhancements that Blean does for Dreamcast games on PC. Oh, sorry, I was muted because my neighbor is drilling because he likes to drill. So, but because you just mentioned PlayStation 4. Have you looked at any of the, I don't know how many places for emulator projects are but there are I think at least two. So have you looked at any of those. Have it looked at them at all. And this is another curiosity of me back in the day after BLEEM, well, you know, after Sony happened, did you at any point, sorry, take a look at the EPSX or PCSX or the other PlayStation emulators that were coming up around. And no, I know that PlayStation emulation has come a long way since BLEEM by far, but never really looked at the other the other emulators that were out there. Here's a question I shouldn't forget. If I can interject again. Yeah. What does BLEEM mean? That's a good question. Okay, you're ready for the answer. I think so. BLEEM doesn't mean anything. I know disappointing, but BLEEM has no meaning. It's just a made up word. It's not best little emulator ever. No, it's not best little emulator ever. It literally has no meaning. I was asked this. Once many, many years ago. And so now, now the world knows BLEEM really doesn't have a meaning. This is a big highlights, I think. Where did, where did the whole thing come from the whole best little emulator ever made? I don't know. A number of people. There was a big question around what, what did it mean? And I wouldn't tell anybody that it didn't mean that doesn't mean anything. And so people started coming up with acronyms. I think it was from an article because there was an article. It was titled best little emulator ever. It was very popular. So that's at least where I got the name from. I know it's not an official name because it wasn't in any of the documentation, but exactly. But yeah, so you've held on to that quite long. Yes, yes. Since we first released, way back in 1998, 99, something like that. Yeah. I think you've been programming longer than I've been alive. And there's a good question here. No. From Pegasus again, you mentioned the organized your organized person. Would you care to share any organization tips if you have anything? Good. Good question. I'm an organized person. You have to sort of be when you're, when you're looking at code, when you're designing code, when you're architecting. They, they say for a carpenter measure twice cut once with programming. The best advice I could give is don't start typing. A lot of people are anxious to, to get into programming and start typing and get some results. But what you'll hit is what is typically known as the 80 20 rule. It takes 20% of the time to get 80% of the way there. It's another 80% of the time to get to your 20% to finish something off. So by being organized by, by making notes, by thinking things through carefully by considering possible alternatives. And in the long run, we'll save you coding. It's rare that it's rare that I'm happy with with. I don't want to say that I'm unhappy with the code that I've written. But there's always room for improvement. There's always better code. And so I always come across different ways of doing things. And, and that's one advantage of having taken notes. I can look back at my notes and think, oh yeah. This was another way of doing something. I also keep what I call a to do file. It's literally just a text file. And so when I think of something, I put it in my to do file, and then I come back to it later and sometimes things never end up getting implemented. But, but other times, it allows me time to think about how I would go about doing something. And then I come back to it afterwards. And I just say one thing because I do both the notes and the to do file and I can neither understand my notes or understand my to do files. But, but, but on the more serious side, because you know, we talked about, you know, how your code was documented, especially the doom code or doom code, right. And I wanted to ask something, because this is always a discussion in the programming world. So do you start with documentation or start with code. I actually document while I'm coding. I once remember writing some code and somebody was watching me as I type I'm a fast type is I can do typically 140 words a minute. I mean, you program assembly, you have to be a fast like this. Otherwise, you would be a program for years. Exactly. Exactly. So I'm a very, very fast coder. But I will typically know what I want to accomplish before I actually go ahead and start typing. So that when I'm typing, I'm typing and I'm commenting at the same time. A lot of the the the doom for super effects code is a good example. And I've gotten better at code coding and documenting since then. But, in inevitably, you'll end up going back and having to modify code or change code. And I've found that every so often I'll write something that's complicated, and then I'll have to go back to it. And even though it's complicated because I've documented what's going on or my thought process as part of the code itself. It makes it possible for me to add some new feature or or make some change that's that's necessary. In the past when I thought to myself, oh, I'll just whip something up and get it running and then I'll tweak it later. Invariably, I end up having to rewrite the code because it it it worked for what I wanted it to do. But I've often found that the code rarely is in a fixed state you sort of you, you know what you want to accomplish. If you've accomplished it, there's always something that in the future you come back to check. Yeah, actually, this relates to the final prepared question that I had. And after that, it's just silly things. So you released the doom effects code on the GitHub and I had a look and it looks really neat. And I was wondering how much like tidying up that you do or was it just this is this was the code and you released it as is. I released the code as is nice. Yeah, thank you. Yeah, a couple of people have commented on some some people that I respect very much. Like Becky Heineman, Bard's Tale. She did do them for the 3DO. Somebody that I respect tremendously has looked at the code and she said wow it's very nice and it's well organized and it's a real tight code base. Yeah, I literally took the code as is and put it out there. We keep getting back to doom so I want to ask something very quick while Neil's finding the question. No, because you know, because you basically reverse engineer doom to implement it. So because there's a lot of stories back then about somebody just emailing it. Hey guys I want to port doom to whatever, and they get a reply with the source code so why didn't that happen for you guys. Or did you try that. I don't know how did that. I basically wrote the development system and worked on the the the platform that was used by another team that was writing dirt tracks effects. And while they were working on that in my spare time. I was working on doom. And I came into Sculptured one day and I had a prototype that was fully operational and I said, here it is. Let's approach in software and see if they're interested. I have a comment from somebody that is writer when you were talking about the documentation he commented, literally programming is it's not. Then I asked him, you mean like the Knuth concept and he said yes. So are you familiar with that concept. I'm not. I'm not familiar with it what what what is it. Yeah, I'm not quite about this actually. Sorry. I know quite a bit about this subject actually take it away. I'm interested. I love learning something new all the time. So check out what Knuth wrote about it. But the nicest thing that I know is usually the code will contain, for example, markdown format format its documentation. And you'll be reading the markdown file, like for example in your browser, and I will say by the way, this code can be executed, because it's also the source code for the program. And just the blocks of documentation they're just separated. And then sort of we've all the source code together at the end and you can just run it but it's the same file which is beautiful I think. Yes, my code. If you see my code, it is very much like that it's sort of the comments describe the flow in general. And then, in addition, on specific lines of code, I describe the specifics of why I'm doing certain things, but I'll also have big blocks of here's the, you know, what this huge block of code is about to do. And here's a couple of steps that it's going to take and then in the code itself there'll be additional comments on individual steps, especially if the steps are, like I said, with arm assembly where you can do a bunch of complicated operations. Also avoid magic numbers. Avoid sticking constants in your code always have them as definitions equate some things like that. That's another, just another useful tip. Yes, exactly. And at the end of that discussion. Yeah, I have to add something because, you know, I can't help myself but I mean because somebody with with your, how do I say this nicely with your affinity for precision you know and for for for detail and such. I mean, why would you program an assembly I mean right definition assembly is not really the most readable language on the planet right so it was largely a function of requirements. Especially with a project like BLEEM, or like Cyboyd. The target platform was such that assembly was the only way to really accomplish what needed to be done. You could write it you can write in C these days a dynamic optimizing recompiler. Absolutely. But back then when your target hardware was a Pentium 100 with with a voodoo 3D effects graphics card. It's such a low end machine that writing an assembly was really the only way to do it I got my start writing in 6502 on the Commodore 64. And just stuck with it. These days, it is an absolute pleasure to write in C sharp. You
 you  I'm very curious how we did this with Windows because Windows would have gotten in the way, I think, right?  It does, and it did.  Okay.  And, and BLEEM did a bunch of ugly tricks.  And I say ugly, but BLEEM ran portions of its code in what's known as Ring Zero  through a couple of backdoors and bugs in Windows.  Yeah.  And it did.  And it did.  Yes, effectively.  The dynamic recompiler generated.  Optimized x86 code.  Then flushed caches and.  Did.  It used Windows.  But yes, it, that's why BLEEM never ran on Windows NT.  Because the backdoors and the hacks work on NT.  Okay, okay.  That's, that's a good one.  And you mentioned jitting. And so do you, did you use also the same strategy? Like, you know, you profile the hotspots and then you recompile that in a certain way and then you decompile.  Okay.  No, no, what it did is it literally did dynamic recompilation while the program was running.  So it, it was effectively just in time a jit compiler that knew which portions of the code had executed and which portions of the code hadn't yet executed.  And when it went to execute them, it compiled them.  Then it ran.  All on the fly.  Yeah, okay.  That's very interesting. That's very, that's very elegant and beautiful. I mean, I thank you.  No, it's complicated code.  Yeah, exactly. And it's, it's complicated code for, for.  Yeah, how did I say this, you know, it's, it's like straightforward for a purpose, right? It's not there for fun. It's not there for show. It's, you have a purpose you do it.  You do it very well. And the result is excellent, right? And this is like the discussion from, yeah, or the discussion we didn't go into about, you know, the difference between high level emulation and like, like, so low level  emulation, right, and high level, we want to run this game. We want to run it well, we want to, you know, enhance the game. Boom, right? So that's, that's how it goes. And the other way, which is also very nice and that's usually what you do for a hobby project, right?  Yeah, sure, you want to emulate every like, you know, illegal opcode and, and, and like the thing with the V blank you mentioned.  Yes. So, so yeah, dynamic compilation. Nowadays, everybody does it of course because.  Yes, because you, because you can because it's, it is a commonplace technique.  The beam is a blend of low level emulation and high level emulation. Blem sort of crosses the line between the two. There's the low level emulation of the processor, but higher level emulation of the graphics co processor and of the motion.  And then there's the high level emulation of the sound chip, but high level emulation of the bios, for example.  And then sort of a weird mix of both. And that's what allowed it to, that's, that's why on the Dreamcast, you could use the Sega Dreamcast VMU.  Store PlayStation save games.  Yeah, okay.  Yes, that's true.  Yeah, sorry. Yeah, okay.  I'm thinking.  Yeah.  Yeah, okay, that is hard. So, yes, small question or so. So when you guys like, did you at any point like get a PlayStation development gets.  No.  Why not.  I read.  Because for obvious reasons we want to keep everything completely clean. Clean room.  Didn't want.  Sony to turn around and say, well, you've had access to all of our whatever technical information and hardware and so on.  And I'm sure that if we had asked, no, so we just sort of did it independently.  Yeah, okay.  All right.  I think the yeah, I have too many questions but you know, I told myself I'll try to keep this two hours and I think we're more than two hours now.  So, so let's let's say I just have one more question.  And after after that, you can you can talk about anything you want and we will see.  I have all the time in the world, right so I can sleep like I said I'm too excited to sleep so no problem I've got I've got lots of time like I said I blocked off my whole afternoon.  So we can just keep talking.  And edit.  Never portions.  What, well, actually I'm thinking because because because this year fast them is is virtual. And they said because usually in fast them when you like have a development room.  You say, okay, I want it for like half a day a day because of location a physical location. But this year they said so everybody's virtual so in principle, you can have as long as you want.  So, because it fits between 10 and 6pm or 10am and 6pm. So technically speaking, we have two days, right and we already have exactly right so.  No but it's like, this is too much too much to talk about this is just this is.  My pleasure and my distinct honor to be able to talk at length. So I, I'm always amazed somebody has any interest in what I have to say. And so, if people want to hear, then I'm more than happy to talk.  I'm always amazed at people that don't have interest in these kind of things and people like you, right. And to give you a short example, I was trying to explain to my wife. I have this amazing, you know, call I have to make and I'm trying to explain to her why and my wife is the least technical person on earth I think  right so it didn't register with her but my enthusiasm did so she's happy for me.  But that's about it right but I mean.  Yeah, I mean, so, because.  So yeah, so for your is for example the source code of doom right but blame for for obvious reasons wasn't released.  So, you see this kind of interaction is more useful than the source code itself right because source code shows you the end result it doesn't tell you about the journey. It doesn't tell you about all the stuff you went through right and these and this this is this is amazing so right so.  So if I end up, or we end up editing this, the full video should be posted somewhere and this will be done of course with your permission and such, right, because even I think somebody will find something useful in one of the jokes we made.  And hopefully we won't be sued by Sony and right and or I don't think we made anybody else mad. I mean, but, but especially Sony less that's not that's not good super Sony, but.  But, but one thing I was really curious about and this is gets it's basically right so.  So it's actually next for BLEEM right before it stopped right so the things you had in your mind you wanted to implement right and I'm not sure if you can talk about this or not but.  The next set. We're going to do more.  BLEEM for Dreamcast.  Final Fantasy seven.  Spyro the dragon crash bandicoot.  Crash Crash is one of those games that's very known for for how do I say this politely.  There was recently one of the creators of crash he did like a video for ours, Technica, and he mentioned all the stuff they did to get the game working.  And I'm not really certain most of the stuff is not the official way of doing things on the PlayStation so it would have been a very. Yeah, you're exactly. That's what I'm preaching for you. Yeah, yeah.  Yes. Yes, that's exactly why I think that it would have been one of the great great games also one of my favorites was medieval.  Because the graphics, the caliber of the game was just so, so high.  It's a shame the Dreamcast died.  I still have my dream cast. I don't use it but I do have it. I think a year ago or two years ago. Excuse me. There was something on the internet like like a hype because the website Dreamcast to was registered by Sega or something like that.  And everybody was hopeful, but we haven't heard anything yet so who knows who knows.  Everything is possible. Everything is possible. Everything is possible. And recently Shenmue 3 came out.  No, I know Shenmue was one of my favorite games ever me to me to. So, it was the reason I got it. No, it wasn't a reason to cut the green cuts but that's something else.  And with a for BLEEM, were there any like things on the roadmap for BLEEM, you know, because, like you said you started to interpret it, then compiled, re compiled and then jitted, so to speak.  Was there like something after that.  Yep, give me one second. Oh, sorry.  Sorry.  No problem.  At that point.  BLEEM had largely run its course. And by that I mean it was a challenge.  How can I put this.  It was a challenge to sell.  Because stores were concerned about carrying the product.  And so BLEEM for the PC sort of had run its natural course and then there was Connectix Virtual Game Station.  And so we were at that point shifted and focused mostly on BLEEM for Dreamcast.  And so the next set of games that we were going to do were Final Fantasy 7, Spyro, those games, because they were, we wanted games that were the pinnacle of each of their genres.  Yeah, okay.  But that's that's more from a business point of view and from the technical challenging point of view.  What was your next Mount Everest so to speak.  My next one was as it turns out to be Cyboyd.  When I say, you know, think quake.  It's a full 3D engine that was written.  There is a video.  There's a video online that shows I had it running on a Game Boy Advance.  So yeah.  Okay.  It used a lot of self modifying code. It was all optimized arm assembly.  Oh, we're talking assembly again.  Okay.  Yes. As a matter of fact, Cyboyd, you can get the game on Android phones.  And Amazon Fire TV and Fire TV stick and it's a free game to download.  But chunks of the game are from the original engine that's 1015 years old now.  And so they're written in arm seven assembly.  Okay.  Yes.  That's interesting.  So that was the next, the next level, I think it was originally, as I said, designed for Game Boy Advance.  I got it working on iPod video. I got it working on Cindy and cell phones.  This was before cell phones had 3D graphics cards.  Yeah.  So to see a full 3D game on a cell phone. Nowadays, it's commonplace to see a full 3D game on the cell phone but back then, it was unheard of.  Back when the phones weren't so smart.  Exactly. When the phones weren't so smart.  Nokia was everywhere.  So we can use. So all the graphics and then have to be done in software.  So Cyboyd was a sub pixel sub textal accurate high speed 3D engine.  And mostly on arm.  Arm is by far one of my favorite processors.  Okay, let's let's hope they stay.  They stay. They stay so. So, exactly. Well, now with with Mac using what they what they call Apple Silicon, which is basically arm.  Yeah, they're here to stay.  They're doing some cool stuff with emulation I heard so.  Yes, exactly. They emulate x86 x64.  Microsoft is doing the same on their on their surface and windows on arm that emulates.  Yeah, yeah, I read a blog post about that. Yeah.  But emulation is everywhere.  Exactly. I kept keep telling people that but they don't believe me. So, yes. Yeah, no these days emulation truly is everywhere back.  And when when BLEEM on the PC came out, emulation was rare. It was, it was exceptional.  In the sense that it was very rare to come across something that needed emulation. And these days emulation is everywhere it's in backwards compatibility, it's in forwards compatibility it's in  the average PC these days has not only emulation built into it, but emulators that run on it.  And I think that's a good thing.  Oh, absolutely. It's a good thing but one thing that still puzzles me. So it's, it's like, so emulation is everywhere. It's part of most things. And yet, if you go to Amazon and search for emulation books, you will find absolutely zero.  I don't know if it's zero but a couple of years ago it was zero right if you go and search for papers on emulation. Okay, it's not zero but it's not papers on.  I don't know what's something popular. You know anything, any graphics. Yeah, exactly any graphics thing or whatever right. If you go to conferences or YouTube and you search for emulation talks and conferences.  And that's also not that much I have a playlist of all the videos I could find. I think it's like 10 videos, and like five of them talk about the same thing, right, and they're good videos but right so that's something that still puzzles me I'm not sure why that's the case but sorry, I'm just eventing  I don't know emulation is one of the black arts of technology and programming emulation is sort of a niche. It's not like graphics.  Where, you know, everybody Oh graphics.  You know, the latest thing is now retracing with graphics and I remember back on the Amiga, where they had the bouncing ball juggler with the retrace balls and, and now that that could be done in hardware, but emulation is  I think it's a technology that that it's a calling your either really into the emulation.  seen as it were.  Or you're using emulation and oftentimes people don't even know it.  Like I said, backwards compatibility for games.  So a good example.  Apple's new Max that let you run the old software, transparently.  I think emulation is one of those things where  there isn't really a book on it.  And it's not because it would have to sort of be more about the generic here's what you're trying to accomplish, rather than here's a concrete example of an emulator.  Yeah.  Yeah, yeah, yeah, you have a point.  You have a point. I'm sad to say you have a point.  Yeah, there isn't a big calling for for how to.  Yeah, what you just said made me think about all those books on games and there are a lot of books on games, and yet they don't teach you much about games right so  No, they don't they teach you.  They'll teach you 3D math or they'll teach you 2D math and transformations and  but it's harder to find a good book on games on writing games and all the complexity.  It's sort of like the proliferation of games and apps on cell phones these days.  They really sort of fall into one of a few categories one is the standard match three game, like Candy Crush.  You've got the choose your outcome game with match three, like home scapes, you've got puzzle games like word combination games and then you've got card games.  Often you'll have something like a call of duty or fortnight or something like that, which is tough to play on a cell phone anyway.  But you won't have games that were from like back in the commuter 64 days like Broderbund.  Games like Zeppelin or load runner or frantic Freddy on the commuter 64 just finding books about making those kinds of games is is harder.  The latest project I'm working on is built on mono game, but before mono game was the platform of choice.  I went through a couple of weeks of I looked at Unreal I looked at Unity.  I don't even remember all of the platforms and libraries and tool sets and tool chains that I looked at before I finally ended up settling on mono game.  And it's nice that there's all of these things that are that are available. I mean the, the, the Unity example comes with a full 3D platform game as a sample.  Something like that would would, you know, take somebody a couple of years to build but here it is you just point and click and now you've got a Lego platform game with physics and 3D and everything and then it's, it's not particularly fun to play it.  But it's nice that the technology is there.  Somebody discovered that fun doesn't necessarily mean sales but yes, let's let's not get into that. That's a very frustrating discussion so it is it is today's independent developer is screwed.  It's a different ways from Sundays. It is as an independent developer myself, it is very, very difficult to, to earn a living.  Basically, people don't like ads.  People don't like paying for games. And people don't like in app purchases.  So, you're sort of stuck between a rock and a hard place.  Yeah, I guess.  And the last thing about what you just mentioned when we were talking about the books and such. So, so I'm not, you know, I'm not going to ask you how you learned so that's because it's different times of course and different mindsets but how do you think people can get better at reverse  engineering or emulation developments.  I don't know how do how can people practice.  That's a good question.  I would say that people should look at existing a lot of existing emulators are open source open source is wonderful. It's phenomenal.  I can't say that enough that's why I released the source code to doom for the Super Nintendo on the Super FX chip.  Because I think it's important to give back.  I've been very, very fortunate to work on some, some great projects. I've been very, very blessed.  I wanted to share the knowledge. And I think that if people would look at existing emulators and the source that's available.  They'll get an idea of the complexities involved.  Emulation of a given system.  Oftentimes is the same you've got your processor, you've got some co processors you've got some extra chips.  So find out as much as you can about the chips about the system about how things fit together.  Look at existing emulation software technology, especially stuff that's open source.  And read a lot of it is is reading.  I mean reading code or reading literature.  Both.  Both.  Code, I think you're right.  In the code sort of shows you the end results. It doesn't show you the steps that it took to get there.  But sometimes it's okay to, to know the answer.  If you're in the right mindset, you can figure out what the question is.  If you're looking at existing code and how existing code operates, you get the answer.  But then you can go in and you can tweak it and see how things change.  And I think that that's important. There aren't really books on emulation but there are books on the processor and and these days, as I said, most people  don't have a processor manual because they've got a C compiler or they're writing in C sharp and it's in interpreted language or intermediate language.  But one of the most interesting videos that I had seen recently for me personally was like I said, the process that this team of two or three people took to delaminate  the data here, a 6502 processor.  And it showed here's all the gates and here's how the gates operates and I, in my mind, because I had programmed it in machine language.  I mean I still know low to immediate accumulator is a nine and X to zero is jumped to sub routine and hex six years return from sub routine and and so I programmed, knowing all of these op codes.  But to see how the bits are actually implemented in the silicon was amazing.  The technology that's 30 plus whatever years old now for the system over to is nothing compared to today's chips.  But never stop learning I guess is the best advice I can, I can offer.  It sort of goes back to there's always a better way of doing something there's always more efficient code cleaner code, more robust code or smaller code or whatever.  But if you've got that quest for knowledge in that, that interest.  It will keep you going and that, I think, is one of the key things that sets apart emulation programmers from other programmers.  Yeah, okay.  I was I was just triggered by something you said.  I wasn't actually was my intention that this was the last question but this will keep going on. Unfortunately.  But, but, so I was actually thinking did you actually worry about cycle accuracy during the BLEEM developments.  No.  Okay.  Okay.  cycle accuracy is  There are pros and cons to cycle accuracy.  The BLEEM is not cycle accuracy.  But that doesn't matter.  And it matters even less these days.  Because games aren't like they were back on the 6502 or 62816 with the NES and the Super NES and the Sega Genesis and, and the PlayStation where  you have to have lots of really complex code and it had to be timed and it had to be efficient and, and these days, your, your code.  Your code is typically not the bottleneck in a given system.  So, you know, the polygons you're trying to push or something else, and your code is running faster than the frame rate anyways and so generally speaking.  No, BLEEM was not cycle accurate and it wasn't intended to be.  Yeah, okay. We actually have a talk about the cycle accuracy.  It's a short talk, but it's amazing.  But, but, but you didn't have  cycle accuracy is tricky.  It's tricky, but so I don't want to spoil anything because I don't know in which order the talks will be but actually the speaker he kind of  said, because I watched part of his talk because they should be uploaded and such. And he actually argues that cycle accuracy is.  Yeah, kind of like a.  It's not the most important metric you should try to adhere to. Let's leave it at that.  I would agree.  I would agree.  And BLEEM is a good example of cycle accuracy being a measurement.  But when it came to the enhancement of the games and the full screen, by linear filtering and and multi sample anti aliasing on BLEEM for Dreamcast cycle accuracy wasn't even part of the equation.  But the results I think speak for themselves.  Yeah, okay. That was almost most definitely. But you did you like. So like I said the questions just keep.  Anyway, so, so did you like, like come across any bugs that were caused by the cycle accuracy of the PlayStation. And yes.  Oh, yes. Yes, especially in later games.  Later games are much more difficult to emulate at a high level, because programmers started writing directly to the hardware.  And the code was much less efficient.  And the code was much less efficient.  But later games were much more efficient and they knew that if they did this sequence of operations, it would take this many clock cycles, and then they could do this sequence of operations.  And it's sort of like the, the Pentium where you had your floating point pipeline and your integer pipeline and all these pipelines could be interleaved if you did certain things in certain order.  And so yes, the, the later games in particular were tricky to emulate because BLEEM was not cycle accurate.  Okay. And what about BLEEMcast because you're talking about too far and you know you don't have as much control as the PC of course right. So, actually had more control.  Really.  Mm hmm.  BLEEMcast was actually nice because we had complete control of the system.  Okay. And no, no OS security.  Okay. I always assume because you know they have the Windows CE logo that it was like secured to hell and back right but  No, everything was written to the lowest level straight to the metal.  Really. Oh yeah.  That's very interesting.  Yeah, BLEEMcast was was all low level talking directly to the chips.  I mean because at least those GD ROMs you couldn't read them really properly on the PC, right.  Because. Well, you could. There were ways of reading them.  Yeah. Okay. But I don't want to like inspire people to go in there.  We did a lot of weird stuff with the dreamcast and.  Yes. Okay. It was a misspent.  Underlying operating system on the dreamcast even for dreamcast titles. You basically would write your title and link with Sega's libraries.  But there was there wasn't really a low level like on Windows where there's an operating system that's running all the time.  Okay, that's interesting.  So for BLEEMcast we had complete control of the system, complete control of the hardware.  It was it was a lot more work.  Because there wasn't an operating system and because we couldn't use Sega's libraries.  How did you actually. Okay, so how did you compile for the dreamcast without Sega's libraries.  By writing straight to the hardware.  And the structure. Oh, you wrote the executable for.  Okay, that's amazing.  And it's all SH4. Yeah.  Okay.  Hitachi thing or something. Yes, Hitachi SH4.  And we had all the documentation to the PowerVR chip set.  And to the Sega Dreamcast chip set.  And we knew what registers to write what values to do certain things and it was all written in low level assembly language.  Uh huh.  Because because Sega, Sega provided all of the information, but said, we can't endorse you we can't really support you. We can't publish your title.  So we have no level hardware documentation that we don't give to anybody else.  For all the different chips that are in the dreamcast.  Enjoy.  Okay.  And psycho accuracy was never a problem that or it was. No, it wasn't.  It wasn't a problem because the game was running faster.  And it was waiting for vertical blank rather than the emulation running slow. The same dynamic, dynamic optimizing the recompiler that I wrote for the PC that took MIPSR 3000 code and generated x86.  I wrote one that took MIPSR 3000 code and generated optimized SH4.  Really.  Yeah.  Let me write that down.  Are you allowed to do that?  I mean, does the dreamcast allow you to do that because you're basically changing the running code.  Yes, exactly.  Wow.  And then the dreamcast I don't remember how much ram they had but it wasn't a lot.  It was enough.  Yeah, there was more than enough for writing optimized SH4 code.  Because the PlayStation was very limited.  Yeah, compared to the dreamcast and a PC.  Okay.  Yeah.  There was never more than if the dynamic recompiler ran out of memory, it would just flush everything and start again.  And so there wasn't really ever running out of memory.  Yeah, okay.  It basically recompiled blocks of code.  And it just kept it in a big buffer.  Yeah.  And when it ran out of space, it started from scratch again and said okay pretend that none of the code is compiled yet.  Start recompiling.  Your game would like slow down for a bit till it like warms up again and  Imperceptibly because it happened so fast.  But yes.  This is, you would never imagine all that was going on.  Exactly. On a totally totally foreign system.  Yeah, yeah, that's amazing.  Thank you.  It's truly is the shame. So, you know, we will never see the code, but who knows. Maybe somebody out there will reverse engineer it for us and  I guess I saw your doom code right and and one thing that really so I haven't threw all the code and I'm not that good at assembly but one thing that really jumps out at me it was how well it was documented.  Thank you. No really because so and I'm not trying to offend anybody but because the principal has been complimented on my code.  I mean, it was, but you know because undocumented C code I don't have a problem with okay I have a problem with that but it's still C code but undocumented assembly code right that's that's, and it's very well structured very well documented and so  I thank you. I hope whoever reverse engineers blame documents and structures it in the same way so let's just say.  The code is.  Well, that's what you get when you spend 38 years writing code, you sort of build up a degree of self documentation because eventually you'll go back and it makes it more maintainable.  And the code from, I want to say it was 9596 was the super effects code I think roughly a long time ago.  But still, it was very nice and I'll look through it and see how it works out.  Well, thanks. Well, like I said, there's an even better way of doing it now. Yeah. So with emulation so that's always nice.  You meant running it. Sorry, or at least that's what I meant.  Right.  So yeah, I don't.  Yeah.  I'm looking at my list of questions, because I wrote a lot of questions beside the questions that I sent you, you know, like I said, I couldn't sleep so I kept writing stuff and whatever but yeah.  So do you have anything that you think we should have talked about and we didn't talk about.  I don't think so.  I think we covered a whole bunch of different things.  Yeah, okay.  Yeah, yeah.  Yeah, I can always come up with questions but I think, you know, enough should be enough at some point.  Okay, I've kept you for a very long time now and no trouble at all. I'm very, very grateful. I think a lot of people will be grateful.  I mean, you mentioned you will be, or you will try at least to be available for Q&A.  I will. I will be available for Q&A. As soon as you tell me when it's scheduled, I will make sure that I'm up either very early or very late.  Yeah, we will set it up.  And I hope, so yeah, this is our first time doing this at FOSDOM. FOSDOM usually has like a lot of rooms, developer rooms and we usually have like a retro computing room and there's some, there's some emulation talks there but this year we thought let's try to do a dedicated emulator room.  So it's the first edition and so far the talks have been good, like the proposals and I hope a lot of people attend and have a lot of cool questions for you, right? So that's what I'm building up towards.  You've been great. You've been awesome.  I don't know how to thank you actually.  My pleasure. My pleasure. It's been an honor.  The honor was all mine really. So thank you very much again.  I don't know. That's that's the end.  Yeah, okay. It's very sad to say that. So I'll probably stop, you know, cut the video at this point and this.  Sure. Well, if you come up with more questions and you want to have another hour chat or something.  You're spoiling me. You're spoiling me. Right.  Not at all. Yeah, so I'm taking a quick look and seeing if we went. I think we got to.  I think we got through all of the questions that you'd written down but I'm sure that there's a whole bunch more that are always are the always are this. It's a problem right so and that's good though that's good it's.  I don't know if you're going to share the. Yeah, but you know right like so so you're a very kind person and I don't want to like miss you that you're such a kind person and just keep you talking for a couple of hours or just bug you out of nowhere and that kind of stuff so  no problem.  It's thank you very much for that.  This is awesome. I don't know how it is going to work out. We will plan the Q&A of course and we'll see how it goes.  Thank you very much again.  I look forward to being online and answering some questions and chatting with the audience.  I'm very sure there'll be a lot of questions but we'll see. So, and a lot of more advanced questions because you know I'm not that active in emulators more as I used to be, but some of the more advanced people will ask questions that you will enjoy more than my questions I think so.  I have enjoyed your questions immensely.  Thank you.  Thank you. Thank you. Thank you so much. Thank you. Thank you. So thank you again. Enjoy the rest of your day and I will keep you in the loop. I guess for the things.  What about the super FX chip for a while, right?  I think we're doing live Q&A, by the way.  Let me just get one second here, see how we're doing.  Yeah, I'm just waiting for the bot to announce that channel thing again.  Yep.  Hey, we're getting some questions as well.  Have you been eating as well? It's been a long day.  It's been a long day. I have. In between, I've been eating and I've had by my coffee and my tea and...  All right, good. Good.  Yeah, I've also been running back and forth between sessions.  Okay.  And we are live.  Yes, we're live.  Excellent.  Now, if that bot would just do that one message, right?  Otherwise, we can just go ahead, but I think it's a bit nicer to wait.  Yeah, yeah.  What are we waiting for?  I thought the bot would give our links in the chat again.  No, no, no, no, no. This is part of the live Q&A. This is on the live feed.  Gotcha.  We have like 40 minutes on the live feed, I think.  That's perfect. All right, so let's just go ahead then.  Sure.  Welcome back, everybody. This time we've got Mahmood in the video as well.  I think we're just going to do some audience questions and then...  Dressed as Waldo for the people who know who Waldo...  Yeah, that's amazing.  So, let's start strong and then just sort of fizzle out.  I'm going to do some audience questions here.  And some of them have already been asked, but just now we got a new one.  Let's start with the fresh one. Pegasus Ryder asks,  how is the machine language translation implemented?  For BLEEM, it was done in Pentium, all assembly code,  where it took each instruction and dynamically optimized the MIPS op codes into Pentium  x86 instructions. And on the Dreamcast, on the BLEEMcast,  it took the MIPS R3000 and generated optimized SH4 for the Hitachi processor.  Does that answer?  We'll have to wait for Pegasus Ryder's response, but in the meantime, we'll move on.  Another relay question that you've answered in the chat,  but let's put it here for posterity.  What was source control like back in those days?  Yeah, back then, none. There was none.  There was no source control because it was just me on the PC,  so there wasn't any source control.  And on the BLEEMcast, there was just myself and there was Rod.  And so between the two of us, we didn't really need source control either.  But if there were more developers or if there was a lot of art assets, things like that,  we would have definitely needed some sort of source control.  But back then, this was around the time when there was,  I want to say SVN and Tordis.  And I want to say there was Microsoft Source Safe,  because I remember there was some big bug where all of a sudden you lost all your code.  There was no source code version control.  Nothing ever was wrong?  No, nothing ever went wrong.  Usually I'm a fairly organized person.  So yeah.  We also saw the notes, so we know how organized you are.  Yes, those are real notes from the Dreamcast development process.  So yeah, you can see I did this to this day, still use a pencil and a notebook with written notes on it.  So in theory, we can rebuild BLEEM from your notes?  Theoretically, yeah.  Okay, but a follow up question for the source control question is because when you got to BLEEMcast, you had somebody working with.  Did you guys do code reviews of each other's code?  Not really.  We were working on different areas of the code.  I was doing the vast majority of the code and Rod was helping out.  So pretty much it was coming from BLEEM on the PC.  A lot of it, I don't want to say was translating, but it was a lot of it was translating because I had already done the majority of the reverse engineering.  So it was sort of like doing a port, I guess is the best way of describing it.  It was more like doing a port.  There was still some reverse engineering.  Like I said, when Metal Gear Solid, beautiful game, even by today's standards,  some of the special effects that they used, I needed to do some reverse engineering to figure out exactly how they were sending down certain types of polygons and things like that.  But the vast majority of the hard work of reverse engineering, the PlayStation system, that was already done.  Alright, we're getting a really nice questionnaire from Phil.  I'm just going to paraphrase it.  You've talked about reverse engineering.  And Phil wonders, how could you bring this mentality or curiosity to a new generation?  Do you think it can be taught at schools or universities?  Good question.  I hope it is.  I hope because technology moves so quickly that without emulation in particular,  we're going to lose a huge amount of our history.  It's only been 30 or 40 years for video games.  And if we don't preserve video games, we're going to lose all of that early history.  Everybody knows Pac-Ban and everybody knows Space Invaders.  But if we don't have some way of bringing that history forward, it's sort of like studying art.  Now, I don't know very much about art.  But universities teach art appreciation and art respect and they teach painting classes and things like that.  And I think that especially for computer science and technology, it's important that we not only preserve the past,  but we teach about the past.  And so I don't know that there's going to be an emulation course per se.  I think a lot of courses teach processors, for example.  FIENSE, that kind of stuff.  Exactly. And I think that that's a very good start.  Machines these days are, they're very advanced, especially when you get to PS5 and Xbox series.  They're very, very advanced machines.  But the APIs, the programming interface to them is much, much higher level.  Whereas compared to like the Super Nintendo and the Nintendo 8 bit, you wrote everything in assembly language and you had a hardware manual that explained how all of the different hardware registers worked.  And these days, you don't really need to do that, which is good.  But now everything is, you have to have the latest, most complex mathematics for doing ray tracing and things like that.  And it's different trade-offs.  It can be quite daunting.  Yeah.  Yes, exactly.  The scope of knowledge required is much, much larger than it used to be.  The university is still four years. So it's all very tricky to fit. Anyway, you just said the word Super Nintendo again.  I keep forgetting to ask the question, but you mentioned, or I read it somewhere that for the Super FX chip, when you were doing doom, there were no development systems available.  Yes.  So how did, how did they expect you to reasonably do a job there?  Well, they didn't.  Oh.  So we received at Sculptured.  Sculptured received the, here's the list of op codes.  But Nintendo was still developing the development system itself and they didn't really make it available.  And so I came up with the idea of, hey, let's hack the Star Fox cartridge.  Let's replace the ROM with RAM.  I mentioned this, right?  Yeah, it was, it was literally a big breadboard with RAM on it and a little tiny boot ROM.  And I wrote an interface that connected between the joystick ports.  It was a serial protocol. So it was only two or three bits.  And then I was working on the joystick ports on the Super Nintendo and the Amiga parallel port. The whole development system was all done on Amiga.  So that's why when I released the source code to the Super Nintendo version of doom, I released the development tools as well, but they're all compiled for the Amiga but if you've got when you a e.  It actually builds.  It's a nice thing.  So they did not expect you to properly do that.  No, no, they didn't.  At the end, towards the end of development when I had had the prototype operational.  Nintendo sent over a custom hardware development system. It was a big box that had the super effects chip inside of it.  Did that help at all or were you finished with that? Oh yeah. Yeah, yeah. Oh yeah.  Immensely.  But it took a lot of work to get it operational. It was a SCSI based interface.  And I had a SCSI card on my Amiga and so I had to write low level I had to reverse had to reverse engineer Nintendo's development system.  In order to make it work with my development system.  And when that was done, it was possible to complete the project.  I think it was quite well received as well. Have you ever worked not only in the Nintendo area, but you ever worked with any of the later enhancement chips like the DSP series.  No, nothing. Yeah, my experience was just limited to the super effects.  Gotcha. Okay.  So audience questions. If you want to chime in just go ahead. You're here now. No, no, no. Great questions. Great questions. Let's see other people that are pleasure of asking and answering and getting this.  This is a quite a valuable question. You asked one was if you friend look at give us a one on one. What's done. I reckon it's exactly.  Yeah, we had a couple of discussions yesterday and some people talked about it and, and, you know, we were interested in, you know, how to get people, you know, started there actually, and what it is and how it works that kind of stuff right so.  Okay. Well, typically, an emulator is an, an interpreted emulator, which means that you've got your program.  And sort of like the way the processor works, you read one instruction.  You figure out what the instruction is, and then you perform the operation so it might be addition, it might be subtraction, it might be exclusive or, but you do it one step at a time by reading the instruction from from the memory, interpreting it.  That's why it's called an interpretive emulator, and then running code that does the actual operation.  A recompiling emulator can be generally one of two forms ahead of time, where basically you take the program as a whole.  And you translate instead of interpreting each opcode reading one opcode interpreting it, and then performing the operation, you translate it it's sort of like taking a book and translating the book into a different language you start at the beginning at the very first word of the very first page.  And you translate word for word, and you translate from from one language like English into another one like, and say.  And then you've got a book that's completely on call say, which you can read a dynamic compiler.  Does this translation, instead of doing it ahead of time, it does it word for word, while the program is actually running.  The dynamic recompiler will dynamically as the program is executing, instead of interpreting each opcode, it will translate from English to French, as somebody speaking it's sort of like having a translator in between the two processors.  And then you've got the original code that was written in one language like MIPSR 3000. You've got the program which is the emulator, and it translates while the program is actually doing the running and the operation.  And the dynamic recompiler is at the end stage is where you've got an optimizing recompiler, where, if you've got multiple sequences of operations, the dynamic recompiler can see the data flow where data is going sources and  destinations and what kind of operations are being performed. And it can combine these operations together.  And then you can do multiple certain operations like multiplying by zero always gives you a zero so you can skip the step of doing the multiplication.  So, sort of an obscure example but there are cases like that, where if your original language has an instruction for addition.  A translated language might have multiple ways of doing addition. If you only want to add one. Usually there's an opcode to increment.  And that opcode is a smaller more efficient opcode because it knows that it's only going to be incrementing by one. So you can see, oh, this, this one processor has an addition instruction and it's adding one.  So instead of writing the generic translation of using the addition in the target processor of adding the value one, I'm going to use the increment instruction instead and so it ends up generating optimized version of the original code.  Does that sort of help flipping a single bit instead of doing the whole generic.  Instead of adding generically, it can use the special opcode which is typically a smaller opcode to increment.  That makes sense. A couple of years ago they had at the first time they had a talk. I think they were doing research about something called super optimization. I've never heard about it before.  It's, it's, it's what you just, you know, the last part you just explained that but on steroids. And I couldn't really see it working in real life, maybe for small snippets of code, right.  It does.  No, no, but what they did know what you mentioned. Okay, that I believe but what they did that was like brute forcing all the, all the possibilities and then seeing which ones are the best, you know, and then using that type of code and  speculative stuff.  Yeah, but the way they explain it was very interesting. Yeah, research university stuff so cool stuff.  Yes. Sorry.  I'm going to jump right in here again.  Sure.  Which assembly giant likes. Have you enjoyed the most.  Good question. That's a good question. I think by far my favorite is arm.  Assembly. Original on assembly, because, well, it's a toss up.  I've enjoyed super effects, the GSU to because it's it's sort of a largely a risk processor.  And as it can combine it's like the arm processor that they're very, very similar. The arm processor can take multiple source operands do an operation and put the result into a destination register.  So you can do things like take one number in a register, add it to another register that is shifted by a certain number of bits, combine the result and store it in a third destination register, all in one opcode.  So it's very, very powerful. That's why arm is used in most cell phones in most handhelds in low powered devices, because it's it's a very, very, very powerful instruction set that is also very compact.  Yeah, so I'd have to say definitely it's a it's a tie between arm and the super effects GSU because it also could do similar kinds of operations you could see from this source with another source register so you had to operation to source operations, combine the result and store it into a third  destination register, very, very elegant.  To be honest, I have expected you to say 6502, but oh I'd like 6502. Really a dialect of course but I like 6502, but I think that arm and the super effects are just so much more powerful.  So you got 6502 and 650816 because they're simple. You've really you've got three registers you've got your accumulator you've got your your x index, and you've got your your y index, but on the arm processor you got 15 registers you've got all these registers, and on the super effects you've got 15 registers.  There's a lot of flexibility. And, and it's nice because it allows you to do some very, very powerful things these days compilers take care of that for you.  You write your C code and the compiler generates really nice optimized code, but back then the, the, the average programmer, who was an assembly language programmer could out optimize a compiler.  And these days that's not really the case anymore.  I see I see in a comment here, I guess the answer would include Motorola 68 K or is that 80 perhaps right so.  Yes, it would I like I like 68,000.  I think 68,000 is a little more cumbersome.  But loved the Amiga Amiga is is, I think, by far one of my my favorite platforms ever.  I've done 68,000 for sure. Yes, and I've done very, very little z80.  Z80 is one of the one of the very, very popular processors that I don't have very much experience with.  Yes, also very popular at this conference. So, yes, today alone there were like three or four talks and yesterday it was mentioned a couple of times it's generally very, very popular at Fossum so.  Oh yeah.  Alright, sorry, Neil's take it away. Let's see what else I have.  I was looking at the bleemannual. Yes, since I have it here now. And one of the things on page 22, it says a game that used to work fine is now freaking out.  If you're, if you're getting random graphic glitches in games that normally render fine.  It usually means memory has gotten stepped on somewhere.  I don't know, you could explain what that is.  I'm not quite sure.  It has been so long since I've seen that marketing language right so that's that's marketing speak.  Yes.  I don't even know what to say.  Well, then we'll leave it at that. I just want to say that this is really nicely written.  David, David Herplzheimer, my business partner from BLEEM did that. He did.  He did all the graphics. He did all the marketing and the sales and oh yeah.  When people think of BLEEM they think of the emulator.  The emulator was just one small part. There was a lot of people that, like I said, like David or like Will Kep or Scott or John Hengartner, our attorneys who made BLEEM possible.  I'll highlight another thing that I really like and then we'll get back to the questions on page 5 launching BLEEM because we know you're probably not even reading this.  We hate manuals too. We've preconfigured BLEEM to let you start playing right away.  It's all really nice and I also saw somewhere like an advertisement. It says 400 new games for your dream cost.  Yes.  It's just really, really nice. Whoever thought of those things.  Yes.  An audience question again from C Creighton. A question from an uninitiated about the Dynarec. Do you take into consideration the timing of certain operations and how?  Yes and no.  For BLEEM, BLEEM didn't really take into account that certain operations took longer than other operations.  And so that caused potentially all sorts of issues.  For example, multiplication is typically an operation that takes more than one clock cycle.  But on BLEEM, multiplication wouldn't necessarily take more than one clock cycle, depending on the processor that it was running on.  And so there were estimates of how long each operation should take.  But BLEEM wasn't cycle accurate. And so it didn't really take into account things like latency and hardware latches and op codes that took multiple clock cycles.  I think that answers it.  I have a relay question.  I want to run PS5 games on my PC.  Where do I begin?  You relay that from yourself, Nils.  Yes.  Where do you begin? Okay, so get a big PC case and empty out the PC.  Put the PlayStation 5 inside it. Close it up again.  So just give up, basically.  Well, at the moment, give up.  Maybe go for PS4 first.  Exactly. Go for PS4 first.  Like I said, these days the machines are so complex and so fast that it usually takes a general, that was one of the, that was one of the things that was rare, I think about BLEEM, that the need for a generational leap wasn't quite there yet.  So you could run on a reasonably low end PC, a PlayStation game that had all of these custom chips and custom hardware in it.  These days PS5 and the new Xbox series are state of the art.  So you could buy a very, very high end PC to run games comparably.  And to emulate them, I think that that's probably a couple of years out.  I'm seeing some comments here, because this is something that's, you know, people discuss this a lot is because most of the hardware of the new Xbox and PlayStation 5, it's all x86.  Yes, it's all x86. I'm pretty sure that it's Ryzen.  Yeah, I think so, yeah. Yeah. So the assumption is usually it should be actually easier to implement. Yes, emulate right so. Yes.  Yeah, I would agree.  The, the, it should be easier.  I think that especially, as I said, games these days are writing to a higher level API. You're not writing to the low level hardware as much.  And so I think that emulation of later systems is in fact easier to use an example for the Dreamcast.  I would personally were I to write a Dreamcast emulator, I wouldn't emulate all of the Dreamcast hardware.  I would emulate the software libraries, because all the developers have to use the software libraries. And so if you, if you knew that the software libraries were there.  You would use the software libraries and do the same kind of enhancements that Blean does for Dreamcast games on PC.  Oh, sorry, I was muted because my neighbor is drilling because he likes to drill.  So, but because you just mentioned PlayStation 4. Have you looked at any of the, I don't know how many places for emulator projects are but there are I think at least two. So have you looked at any of those.  Have it looked at them at all.  And this is another curiosity of me back in the day after BLEEM, well, you know, after Sony happened, did you at any point, sorry, take a look at the EPSX or PCSX or the other PlayStation emulators that were coming up around.  And no, I know that PlayStation emulation has come a long way since BLEEM by far, but never really looked at the other the other emulators that were out there.  Here's a question I shouldn't forget.  If I can interject again.  Yeah.  What does BLEEM mean?  That's a good question.  Okay, you're ready for the answer.  I think so.  BLEEM doesn't mean anything.  I know disappointing, but BLEEM has no meaning. It's just a made up word.  It's not best little emulator ever. No, it's not best little emulator ever.  It literally has no meaning.  I was asked this.  Once many, many years ago. And so now, now the world knows BLEEM really doesn't have a meaning.  This is a big highlights, I think. Where did, where did the whole thing come from the whole best little emulator ever made?  I don't know.  A number of people.  There was a big question around what, what did it mean?  And I wouldn't tell anybody that it didn't mean that doesn't mean anything.  And so people started coming up with acronyms.  I think it was from an article because there was an article. It was titled best little emulator ever.  It was very popular. So that's at least where I got the name from.  I know it's not an official name because it wasn't in any of the documentation, but exactly.  But yeah, so you've held on to that quite long.  Yes, yes. Since we first released, way back in 1998, 99, something like that. Yeah.  I think you've been programming longer than I've been alive. And there's a good question here.  No.  From Pegasus again, you mentioned the organized your organized person. Would you care to share any organization tips if you have anything?  Good. Good question.  I'm an organized person. You have to sort of be when you're, when you're looking at code, when you're designing code, when you're architecting.  They, they say for a carpenter measure twice cut once with programming.  The best advice I could give is don't start typing.  A lot of people are anxious to, to get into programming and start typing and get some results.  But what you'll hit is what is typically known as the 80 20 rule.  It takes 20% of the time to get 80% of the way there.  It's another 80% of the time to get to your 20% to finish something off.  So by being organized by, by making notes, by thinking things through carefully by considering possible alternatives.  And in the long run, we'll save you coding. It's rare that it's rare that I'm happy with with.  I don't want to say that I'm unhappy with the code that I've written.  But there's always room for improvement. There's always better code.  And so I always come across different ways of doing things. And, and that's one advantage of having taken notes. I can look back at my notes and think, oh yeah.  This was another way of doing something. I also keep what I call a to do file.  It's literally just a text file.  And so when I think of something, I put it in my to do file, and then I come back to it later and sometimes things never end up getting implemented.  But, but other times, it allows me time to think about how I would go about doing something. And then I come back to it afterwards.  And I just say one thing because I do both the notes and the to do file and I can neither understand my notes or understand my to do files.  But, but, but on the more serious side, because you know, we talked about, you know, how your code was documented, especially the doom code or doom code, right.  And I wanted to ask something, because this is always a discussion in the programming world. So do you start with documentation or start with code.  I actually document while I'm coding.  I once remember writing some code and somebody was watching me as I type I'm a fast type is I can do typically 140 words a minute.  I mean, you program assembly, you have to be a fast like this. Otherwise, you would be a program for years.  Exactly. Exactly. So I'm a very, very fast coder.  But I will typically know what I want to accomplish before I actually go ahead and start typing.  So that when I'm typing, I'm typing and I'm commenting at the same time.  A lot of the the the doom for super effects code is a good example.  And I've gotten better at code coding and documenting since then.  But, in inevitably, you'll end up going back and having to modify code or change code.  And I've found that every so often I'll write something that's complicated, and then I'll have to go back to it.  And even though it's complicated because I've documented what's going on or my thought process as part of the code itself.  It makes it possible for me to add some new feature or or make some change that's that's necessary.  In the past when I thought to myself, oh, I'll just whip something up and get it running and then I'll tweak it later.  Invariably, I end up having to rewrite the code because it it it worked for what I wanted it to do.  But I've often found that the code rarely is in a fixed state you sort of you, you know what you want to accomplish.  If you've accomplished it, there's always something that in the future you come back to check.  Yeah, actually, this relates to the final prepared question that I had. And after that, it's just silly things.  So you released the doom effects code on the GitHub and I had a look and it looks really neat.  And I was wondering how much like tidying up that you do or was it just this is this was the code and you released it as is.  I released the code as is nice.  Yeah, thank you. Yeah, a couple of people have commented on some some people that I respect very much.  Like Becky Heineman, Bard's Tale.  She did do them for the 3DO. Somebody that I respect tremendously has looked at the code and she said wow it's very nice and it's well organized and it's a real tight code base.  Yeah, I literally took the code as is and put it out there.  We keep getting back to doom so I want to ask something very quick while Neil's finding the question. No, because you know, because you basically reverse engineer doom to implement it.  So because there's a lot of stories back then about somebody just emailing it. Hey guys I want to port doom to whatever, and they get a reply with the source code so why didn't that happen for you guys.  Or did you try that. I don't know how did that.  I basically wrote the development system and worked on the the the platform that was used by another team that was writing dirt tracks effects.  And while they were working on that in my spare time. I was working on doom.  And I came into Sculptured one day and I had a prototype that was fully operational and I said, here it is.  Let's approach in software and see if they're interested.  I have a comment from somebody that is writer when you were talking about the documentation he commented, literally programming is it's not.  Then I asked him, you mean like the Knuth concept and he said yes. So are you familiar with that concept.  I'm not. I'm not familiar with it what what what is it.  Yeah, I'm not quite about this actually. Sorry. I know quite a bit about this subject actually take it away. I'm interested. I love learning something new all the time.  So check out what Knuth wrote about it. But the nicest thing that I know is usually the code will contain, for example, markdown format format its documentation.  And you'll be reading the markdown file, like for example in your browser, and I will say by the way, this code can be executed, because it's also the source code for the program.  And just the blocks of documentation they're just separated. And then sort of we've all the source code together at the end and you can just run it but it's the same file which is beautiful I think.  Yes, my code. If you see my code, it is very much like that it's sort of the comments describe the flow in general.  And then, in addition, on specific lines of code, I describe the specifics of why I'm doing certain things, but I'll also have big blocks of here's the, you know, what this huge block of code is about to do.  And here's a couple of steps that it's going to take and then in the code itself there'll be additional comments on individual steps, especially if the steps are, like I said, with arm assembly where you can do a bunch of complicated  operations.  Also avoid magic numbers. Avoid sticking constants in your code always have them as definitions equate some things like that. That's another, just another useful tip. Yes, exactly.  And at the end of that discussion. Yeah, I have to add something because, you know, I can't help myself but I mean because somebody with with your, how do I say this nicely with your affinity for precision you know and for for for detail and such.  I mean, why would you program an assembly I mean right definition assembly is not really the most readable language on the planet right so  it was largely a function of requirements.  Especially with a project like BLEEM, or like Cyboyd.  The target platform was such that assembly was the only way to really accomplish what needed to be done. You could write it you can write in C these days a dynamic optimizing  recompiler. Absolutely. But back then when your target hardware was a Pentium 100 with with a voodoo 3D effects graphics card.  It's such a low end machine that writing an assembly was really the only way to do it I got my start writing in 6502 on the Commodore 64.  And just stuck with it. These days, it is an absolute pleasure to write in C sharp.  You
bleemcaster_part3_0_1775.png bleemcaster_part3_1776_2447.png bleemcaster_part3_2448_5255.png bleemcaster_part3_5256_6791.png bleemcaster_part3_6792_12131.png bleemcaster_part3_12132_15683.png bleemcaster_part3_15684_15995.png bleemcaster_part3_15996_18191.png bleemcaster_part3_18192_18455.png bleemcaster_part3_18456_18527.png bleemcaster_part3_18528_19259.png bleemcaster_part3_19260_20567.png bleemcaster_part3_20568_22019.png bleemcaster_part3_22020_23831.png bleemcaster_part3_23832_23879.png bleemcaster_part3_23880_23927.png bleemcaster_part3_23928_31655.png bleemcaster_part3_31656_42731.png bleemcaster_part3_42732_43283.png bleemcaster_part3_43284_46991.png bleemcaster_part3_46992_51155.png bleemcaster_part3_51156_52235.png bleemcaster_part3_52236_53951.png bleemcaster_part3_53952_54023.png bleemcaster_part3_54024_55247.png bleemcaster_part3_55248_57539.png bleemcaster_part3_57540_57863.png bleemcaster_part3_57864_58979.png bleemcaster_part3_58980_59735.png bleemcaster_part3_59736_59795.png bleemcaster_part3_59796_64487.png bleemcaster_part3_64488_66371.png bleemcaster_part3_66372_67919.png bleemcaster_part3_67920_68471.png bleemcaster_part3_68472_71567.png bleemcaster_part3_71568_73127.png bleemcaster_part3_73128_73691.png bleemcaster_part3_73692_79235.png bleemcaster_part3_79236_85175.png bleemcaster_part3_85176_85715.png bleemcaster_part3_85716_85799.png bleemcaster_part3_85800_88715.png bleemcaster_part3_88716_90047.png bleemcaster_part3_90048_90263.png bleemcaster_part3_90264_91919.png bleemcaster_part3_91920_92123.png bleemcaster_part3_92124_92279.png bleemcaster_part3_92280_92675.png bleemcaster_part3_92676_92771.png bleemcaster_part3_92772_93095.png bleemcaster_part3_93096_93167.png bleemcaster_part3_93168_93515.png bleemcaster_part3_93516_93671.png bleemcaster_part3_93672_93827.png bleemcaster_part3_93828_93923.png bleemcaster_part3_93924_94199.png bleemcaster_part3_94200_94319.png bleemcaster_part3_94320_94895.png bleemcaster_part3_94896_95051.png bleemcaster_part3_95052_95735.png bleemcaster_part3_95736_95951.png bleemcaster_part3_95952_98891.png bleemcaster_part3_98892_99155.png bleemcaster_part3_99156_99251.png bleemcaster_part3_99252_100523.png bleemcaster_part3_100524_105431.png bleemcaster_part3_105432_107291.png bleemcaster_part3_107292_108455.png bleemcaster_part3_108456_109547.png bleemcaster_part3_109548_109691.png bleemcaster_part3_109692_110375.png bleemcaster_part3_110376_112811.png bleemcaster_part3_112812_112895.png bleemcaster_part3_112896_113207.png bleemcaster_part3_113208_113531.png bleemcaster_part3_113532_115751.png bleemcaster_part3_115752_115895.png bleemcaster_part3_115896_117071.png bleemcaster_part3_117072_118055.png bleemcaster_part3_118056_119195.png bleemcaster_part3_119196_119267.png bleemcaster_part3_119268_119351.png bleemcaster_part3_119352_120983.png bleemcaster_part3_120984_122459.png bleemcaster_part3_122460_122999.png bleemcaster_part3_123000_123275.png bleemcaster_part3_123276_124199.png bleemcaster_part3_124200_124271.png bleemcaster_part3_124272_128075.png bleemcaster_part3_128076_130631.png bleemcaster_part3_130632_131015.png bleemcaster_part3_131016_131087.png bleemcaster_part3_131088_131147.png bleemcaster_part3_131148_131255.png bleemcaster_part3_131256_131831.png bleemcaster_part3_131832_131915.png bleemcaster_part3_131916_134243.png bleemcaster_part3_134244_135143.png bleemcaster_part3_135144_135266.png