Episode: 3358
Title: HPR3358: BlastEm! A wicked awesome Sega Genesis/Megadrive emulator
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3358/hpr3358.mp3
Transcribed: 2025-10-24 21:37:19

---

This is Hacker Public Radio Episode 3358 for Wednesday, the 16th of June 2021.
Tid's show is entitled, Blast Him, a wicked awesome Sega Genesis Slash Megadrive Emulator.
It is hosted by Sig Flop and is about 22 minutes long and carries a clean flag.
The summary is, this is an interview with the author of Blast Him, a Sega Genesis Slash Megadrive Emulator.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the author code HPR15.
That's HPR15.
Better web hosting that's honest and fair at AnanasThost.com.
Hello everyone and welcome to another episode of Hacker Public Radio Episode 3358 for Wednesday, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th, the 16th,
the 16th, the 16th, the 16th, the 16th, the 16th,
the 16th, the 16th, the 16th, the 16th,
Oh, yeah, and I think the first release was roughly a year after I started. It was pretty rough though.
Oh, okay. Have you written any other emulators? This is your first one.
Ah, sort of. Um, so my first attempt at an emulator was for the master system, um, but it wasn't,
like I got like, I wrote some Z80 emulation code, but at the time I was pretty young. I didn't really
get most graphics APIs, so I was struggling to like, community other parts. Um, and then in college,
I was talking with Nemesis, who's a, I don't know his real name, but you know, he's pretty notable
in like the Sonic acting community, in the Sega retro community, and we talked about collaborating
on a Dreamcast emulator. This is probably like 2002, 2003, sometime around then.
And, uh, I still didn't know too much about graphics APIs, so I was like, the idea was I would take
on the CPU, and he was going to work on the GPU stuff. Um, that's an, that's an SH4, is it on the
Dreamcast? Yeah, okay. Exactly. So I wrote like an interpreter, so you know, it's probably wouldn't
have been fast enough back then since, you know, the computers weren't quite as fast since 2002.
Oh, yeah. Yeah. Um, the SH4, and it worked well enough to like, there's just one demo that
just writes directly to the frame buffer. Uh, no, no, okay. Those are the plasma effects,
so it wasn't good enough for that, but so those are the only two like emulator projects I've worked on
before blast em. Well, okay. Yeah, I found blast em to be very accurate and very speedy, which is,
it's, it's always a compromise, uh, speed versus accuracy. And, uh, I've noticed that it plays
the overdrive demos. Yeah. Um, those, those were kind of the thing. Yeah. Um, so, yeah, a lot of ways,
like I, I think, you know, there's definitely a tension between accuracy and speed, but it's sort
of more like a triangle where, you know, there's accuracy, speed, and then like, there's another
dimension that's sort of like effort or complexity of the implementation. Um, yes.
That, that's, that's interesting. Um, yeah. Erg 866 is DMATric. It runs that where you, you, you
write a, um, DMAT transfer with an increment of zero from the, um, CRAM to, uh, to the, to the,
to the frame, like to this picture. So that's, I'm amazed that that works. That's pretty cool.
Yeah. Um, you know, trickiest part about that is, um, all the factor, the timing factors that
get like to make the synchronization part work like once it starts, it's pretty simple because
the DMAT engine just goes at a certain speed and it replaces the background color. Yeah.
And that's pretty easy to get once you know, like, you know, where the refresh slight cycles are,
that interrupts the transfer. Um, but the tricky part is like getting,
make sure all the things that affect CPU timing are correct and then, um,
you know, making sure that how they interact with the VDP for like the, the synchronization aspect
where it like fills up the FIFO and is depending on those, you know, external slots being in
sort of particular places to free up the CPU. You know, that was, that was a little tricky.
I imagine, I imagine. Um, what did you, how did you debug this? Did you have like a, uh,
Genesis, like an average drive cart or something like that? I'm wondering, um, because for me,
I go through like, right test debug, right test debug, that sort of iteration. And I'm wondering,
um, what tools you use to debug things? Yeah, Jerry's quite a bit depending on the problem. Um,
yeah. Like, uh, like the toughest thing that debug and sort of recent memory was, um,
someone reported that in like, I think Road Rash 3, when you're in like the bike shop menu,
um, and you switch between categories, there's like this little artifact on the screen. It's like
only there for like one frame. And it's like, so first off, it's like, this is actually only
happening blast. And does it happen in the hardware? So it's like, I had to get like my capture cards
kind of, buddy. Yeah. Uh, it doesn't really support 240p properly. So I have like, you know,
like do a capture and then pull out, you know, the interlace the frame so I could get, it treats
it like it's 4EDI if it's 240p. So it's interlacing it. Yeah. So like, you know, pull the frame
together and it's like, okay, yes, this is not happening. Um, and then it's, and so then I'm like,
you know, going disassembling the game and trying to figure out what it's actually doing during this.
And so there's like, it's sort of back and forth between looking at the disassembled code. Yeah.
Possibly like, so blast, it has a little debugger built into it. It's not great, but it generally
works for my needs. So using that debugger to sort of trace through it and then, like sometimes
actually, you know, running the emulator in itself at a debugger, sometimes at the same time
that I'm using the debugger in the emulator as well. Yeah. Um, and trying to figure out what
happened is going on. And eventually what it became clear is that, um, you know, uh,
when it does this position between categories, it's not very careful about when it updates
the name tables. So, you know, for those that aren't familiar with the like, the genesis graphics
system, you know, it's like, it's a bunch of little, eight by eight tiles in the background layers
have like specified which tile they use. And so when I was updating that mapping, which tile is
used, it ended up doing it while it's in the middle of the display. So basically, there was like a race
between, um, you know, the updates from the CPU and in the display scanning out. Um, yeah.
But for some reason, on the console, this didn't cause the same artifact I was seeing on blast,
and the question was why. Yeah. And, um, there were exactly how I figured this, but eventually
it occurred to me that the, the main table entries are 16 bits wide. Yeah. But the, the VRAMs
only eight bits wide, so it only right half of each entry at a time. Okay. And I'm like, well,
under, I wonder if it's because it actually is doing the two bytes of the words in the opposite
order, which the most things doesn't matter all because it's, you know, uh, and it turns out that
was the problem. Oh, okay. Yeah, it seems, it seems hard to figure out. I noticed that you have,
it does you, um, are doing multi-pugging through GDP or G, G at DB. Yeah. I mean, that one,
that one isn't so much for me. That was sort of like, um, because generally speaking,
when I have a problem, I don't have the source code. I just have like a, here's a game or a demo
that's like a binary. And so I have, you know, so having GDB access isn't super helpful. But,
yeah. But for, um, you know, one of the nice things about having an accuracy factor at emulator
is that, um, when you're developing new code for the, to do the genesis of the negative drives,
you're more much more likely to run into the same bugs that you're running in hardware than,
an inaccurate emulator. Yeah. And it's easier to debug the emulator than it is on hardware. So,
um, I realized it wouldn't be that hard to take the debugger I already had and then adapt it so
it could support GDB remote stuff. Um, so that's super useful if you're using, you know, SGDK or some
other CE toolchain, um, develop for the, for the mega drives. Yeah. I, uh, I noticed, um,
it seems to be very heavy on x86. Um, you have files in the source code like, uh, m68k to x86
and, and, and stuff like that. I'm wondering why is it so dependent on, on x86? Well, um,
um, so when I, when I set up to make last end, there were sort of like a few different motivations
in mind. So, so one of them was, um, uh, near who used to go by view at the time, wrote this article
for ours technical.bs and yes and how, you know, accuracy takes all this power and I'm like, uh,
I'm, you know, typical arrogant programmer stuff. I'm sure I could, I could make it fast and,
and accurate, right? Yeah. And I, I focus on the genesis because that's what I grew up with rather than
the SNS. Um, so, so partly I wanted to, so I wanted to pursue, you know, more advanced
techniques that could potentially make it faster in a dinerack or, or jit, you know, where you
dynamically generate some machine code at runtime. Yeah. One potential way to do that.
I also like, I wanted to learn about how those worked. Um, because like, generally speaking,
it's considered not to be worthwhile to do a dinerack or a jit for old CPUs, like, you know,
the model, the original 68,000 or the Z80. Yeah. Um, but I wanted to learn it anyway. So I figured,
well, let me, let me try to, let me try to figure out how to do this. Um,
yeah, so I, so I run a dinerack and, and, um, and I didn't use an existing like cogen library,
so I'm doing my own cogen, so if I want to support multiple CPUs, I have to write that code.
Yeah. Um, I did try to port to arm at one point, um, but I think at some point I decided that I
wasn't really happy with the way I'd written my dinerack at all, and I was going to sort of put
off the whole arm question until I got around to rewriting the whole thing. Okay. So,
so yeah, there is actually a branch where I like yank out my dineracks, and I, I pulled, um,
um, Musashi, which is a open source, uh, permissively licensed 68,000 emulator, and the Z80 emulator
from her name, which I think was licensed via DSD as well. Okay. So there's like a, there's like a,
sort of like a unsupported branch that that'll run on non-X86 CPUs, um, but it's a little janky,
and it's sort of like a temporary hack until I get around to it, like doing it properly. Okay.
All right. So you're using name Z80, Z80 code in your project is what you're saying.
Only in this sort of hacky branch. Oh, okay. So if you go down, if you go download the official
releases of Blastand, they'll be using my, my dinerack, um, the vibrone. Oh, yeah, yeah. I'm
noticing like Z80.CPU, which looks like a machine description. And so yeah, I, I assume that you
wrote a parser for that too, to, to, to, to do your thing. Yeah. So it's not like part of like,
so sort of what I'm thinking for like replacing my diner X as I want to have like,
some kind of domain-specific language that describes how the CPU works. And then I want to
generate both interpreter and a dinerack from that one description. Yeah. Sounds good.
And for those that are familiar with like, with, with diner X, it's like, why would you
use an interpreter too? And, and the answer is as, generally speaking, like generating code
and then executing it is slower than just interpreting it. Yes. And so, you know, it's helpful to
have both so that you can code that's only run once or twice. You can run it for the interpreter
and then road code that runs a lot of time. You can, you can translate it. Okay. My, my dinerack
doesn't have that right now, um, which sometimes causes problem, causes some performance problems. But,
yeah. Yeah. So that's sort of the idea of the Z80 that's used. It's supposed to be a DSL.
So it works well enough that I have a Z80 implementation that works. I started on a 68K1,
but it's not done. Oh, okay. And right now it only generates interpreter. It doesn't generate a
dinerack, so. Oh, okay. All right. Cool. Um, yeah. I don't remember what I heard this from,
but GCC uses machine description. And it's the C parser and the machine description parser.
And they kind of meet up where the tree like the parse tree matches, which is kind of interesting.
But that's, that's neither here nor there. Um, so, okay. So you're using an interpretive
68,000 in your, in the version right now, right? Uh, no. So it's, so like the stable release,
there's a dinerack for the Z80 and the dinerack for the 68,000. Okay. It's x86 only. Okay. Now,
there's this branch called maiminterp, um, which uses the new Z80 core. It used to use the
maim Z80 core. I misspoke earlier. And it uses Musashi, which maim also uses for 68,000. Yeah,
Musashi. That's what I was thinking about Musashi. Okay. Go ahead. Yeah. So that's only in this sort of
maim, this weird maiminter branch. Um, okay. Yes. So if you want to build for arm, you have to use
a sort of funky branch that I only update sometimes. Um, but like the main releases are still using
my, the dineracks that I wrote. Okay. For both CDs. Cool beans. Um, how is, uh, how is the 26th
trove? How is emulating for that? Uh, you know, it's, I think the most painful part is that it's,
like, just audio emulation in general. Oh, it's, it's hard, hard to know what's wrong when something
is wrong, right? Oh, yeah. Totally. I completely agree.
Like, you know, okay, if it's graphics, it's like, okay, here's this, you know, the,
this area, like, there's these pixels look wrong, right? So it's like, well, I can say what
layer generated those pixels pretty easily? Yep. And, you know, what part of the, you know, um,
for everyone listening that the 26th trove is the YM 26th trove, it's the sound chip.
And the second genesis, which is a six channel FM chip, but that.
Yeah. So, so debugging that when something's wrong, it's really hard to figure out where it's
coming from. Is what I was saying. Yeah. Yeah. Yeah. It's really, it's really tough to debug.
I mean, fortunately, a lot of the hard stuff was figured out by the time I started. So,
um, uh, Nenesis, who I mentioned before, if we were, you know, originally we're going to
collab on that Dreamcast simulator a long time ago. Um, yeah, he was also working on another
inaccurate, uh, genosibularical exodus. Okay. Uh, and I, I think I must have missed it.
Well, at the time when I was decided to start blast them, but, um, anyway, so we get a bunch
of reverse engineering work and I, I, I've really benefited a lot from all the work he did.
Um, I mean, I had to do a bunch of reverse engineering myself, but it definitely saved me a lot of,
all the work he did saved me a lot of time, especially on the YMZ612. Um,
I mean, the documentation is like hard to like go through because it's basically, there's this
giant thread on this, uh, forum called Sprite's Mind. Yeah. And it's like, I don't know, like,
200 pages or something and it's, I had to go through all the pages and like bookmarked the ones
that actually had like real info and then sometimes like, you know, a few pages later. It's like,
oh, wait, that was all wrong. Here's the real, yep. Yeah. Yeah. And then, and then there
was still some stuff that was broken that I couldn't figure out. And so I ended up making this
little program that basically for each parameter, it would iterate through all the settings.
Um, you know, and I compared a recording of that running on the real hardware to running on
my end-way, and it's like, okay, at this particular point, when I change this setting, this,
that's when it gets messed up. Um, yeah. And I fixed a lot of issues for that. Um, okay.
Yeah. And since then, I've occasionally, but there's a couple of attempts to, to look at like,
like a photograph of the Vasilicondi in reverse engineer the chip from that. Um, okay. So in
Sprite's Mind, there's like, so I know how to pronounce it. He's like, sorry, and there's something
like that. He made a, I think a DHTL or Verilog, which are hard word description languages,
um, implementation of just the operator unit. Oh, okay. Cool. That's awesome. And then,
and then this Russian developer, um, goes by, uh, Nuke-YT or Nuke-T,
I'm not sure I, uh, he made like sort of a, like, if this could be, she had not sure I'd
know they're pronounced, but whichever, um, they made a, uh, like sort of like a very literal,
like, sea translation of the hardware. Um, okay. So I've used both of those as reference,
occasionally, to find like the last, you know, some of the last few bugs. Still not 100% perfect.
I've got to actually, you got a couple of bugs I'd still need to track down. Um, but it's in
pretty good shape now. Okay. Cool. Are there, um, are there any games or, uh, cartridges or
ROMs or whatever that, uh, you are working on right now? Like what, what's your, what's the
compatibility rate now, uh, nowadays? Is it close to 100% or what, what do you think?
It should be pretty close to 100%. Um, I think probably the biggest issue, there's a few games
that you need certain peripherals to use. Like, I don't have any lightgun support because I haven't
gotten around to it. Um, and so for instance, like the Miniser 6 game cartridge, you can't play that
at all unless you have a lightgun attached. So that doesn't really work. Um, a game, I've been collecting
carts, you know, since I started this project and I, one game I randomly picked up, uh, I think
it's like championship bowling or something. I might have an issue. I have to verify that I,
I dumped it correctly and I'm just not misunderstanding how the game works, but it seemed like it,
for you, froze up so that, um, but other than stuff like that, it's pretty close to 100%.
I actually just, uh, this is not released yet, but I recently added support for
a very rare game called Outback Joey, which has this, uh, goofy exercise peripheral that's
required to make it run. Okay. Um, yes, so that was, that's probably the latest game that I've,
I've made works. Uh, and that's not fully released though. It's, it's sort of in the light
lease, not that anybody has the thumbs yet. Okay. The, the thing I like about the Sega Genesis is
it's just roms. It's, it's not like the Nintendo where you have roms and you have mappers and stuff
like that. So you don't have to emulate different cartridges. Um, oh, what's the, what's the graphics
cartridge with the graphics chip, um, virtual racer or something like that? Yeah, virtual racer guy,
that's another game I don't support because I haven't, I haven't finished
emulating the SVP chip, which is like a DSP. It's in the cart. Oh, okay. All right. Cool.
Well, um, do you have anything that, uh, you want to say to the, the people with hacker
problem radio? Um, happy to talk to everyone. Uh, uh, last time's been a very rewarding project to
work on. Uh, I, I hope it's, it's useful for people in the future. Yeah. Okay. So the website is
RetroDev.com slash Blastem. Is that correct? Yep. Okay. All right. All right. All of that will
be in the show notes and, uh, yeah. Thank you for, thank you for the interview. Thank you.
You've been listening to HackerPublic Radio at HackerPublicRadio.org. We are a community podcast
network that releases shows every weekday Monday through Friday. Today's show, like all our shows,
was contributed by an HBR listener like yourself. If you ever thought of recording a podcast,
then click on our contribute link to find out how easy it really is. HackerPublic Radio was
founded by the digital dog pound and the infonomicon computer club and it's part of the binary
revolution at binref.com. If you have comments on today's show, please email the host directly,
leave a comment on the website or record a follow-up episode yourself. Unless otherwise stated,
today's show is released on the creative comments, attribution, share a life, 3.0 license.