Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popular?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
User avatar
devmas
Posts: 23
Joined: Wed May 20, 2009 6:16 am
Location: New York City

Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popular?

Post by devmas »

So I wanted to write this post that's a bit aimless, but I hope you'll indulge me for a bit, and sorry in advance... I split it up into sections to hopefully make it easier to read.

Part 1.1: Game Boy emulator

So I made a Game Boy emulator in Java somewhat recently. While it doesn't have sound (I still need to figure out a good way to program sound), it works pretty well, and it can actually run some games better than any other Java Game Boy emulator I've seen on the Internet.

screenshot:
Image

Here's a video, with some lovely (read: bad, lol) music by yours truly: https://www.youtube.com/watch?v=JhX8ImUfUIc

Part 1.2: Making a Game Boy game

Inspired by the Game Boy emulator, I decided to try making a Game Boy game, purely for fun. I decided to port Celeste, the classic PICO-8 game, to it. For reference, here's a video of someone playing the official C# port of it: https://www.youtube.com/watch?v=VR3x5d8xIKk
and here's an image that I got off the Internet:
Image

Graciously, Celeste creators Maddy and Noel released the source of the C# port on GitHub. (Link: https://github.com/NoelFB/Celeste/tree/ ... rce/PICO-8) Therefore, my approach to creating the Game Boy version is simply to look at the code and translate it line-by-line to assembly. Here's what I have so far:

video: https://www.youtube.com/watch?v=Orloiyc6wS4

screenshot of super old version (above video is newer):
Image

Because I'm new to the Game Boy, I decided to fit the entire game within 32 KB, the size of the Game Boy's address space without bank switching.

I ran into the following technical challenges:
  • Compressing each screen's graphics. I came up with an encoding scheme I'm very proud of, that can compress a 20x16 tile screen into ~160 bytes, so about 50% compression. With 32 KB, I can fit more than 3x the rooms featured in the original game (which had 31 rooms).
  • Fixed point number representation. For the main character's X/Y position, I have two bytes - whole and fractional. (I bet that's standard.) For acceleration, however, at one point I had the same 2-byte representation, though with a signed whole component. But at some point I changed the acceleration code to use a 1-byte representation (1 bit sign, 3 bit whole component, and 4 bit fractional component). I semi-regret doing that now, but I feel like I'm currently too deep in to change it all back, lol.
  • An object system. I am still wrestling in my head about whether I should have a bunch of indexed variables (a "structure of arrays") or regular objects (an "array of structures"). I know of the saying, "if it's hard to decide between two things, then most likely it's because they're both good choices", but I'm still afraid I'll make the bad choice. As such, the player character is still my only object right now.

Two other thoughts:
  • The physics in my Game Boy version aren't the same as the original, despite my copying the code line for line... like, at all. To the point where the original game runs at 30 FPS and my Game Boy version runs at 60, and I barely noticed, lol. Darn floating point logic! lol. But I figure I will tweak the numbers later.
  • I've never written anything serious in assembly before, let alone anything for Game Boy. I always worry that my code will be too slow for Game Boy, but am constantly impressed by how seemingly little CPU all the character physics and collision uses.
In the meantime, I'm super happy with what I have so far, though trying to decide on how to implement the object system has been blocking me for months now.

-----

Part 2: Moving on to the NES

Because I wanted the same knowledge about the NES that I do of the Game Boy, I decided to try to write an NES emulator. But upon researching it, it seems like a far more complex system than the Game Boy, and that's not even including the mappers. With two different buses and some odd PPU quirks, it just didn't seem like as fun of a project. I still may do it in the future, but I can't say my research left me feeling excited and jazzed to do it.

Then, a couple days ago I decided to play with the "complete disassembly of Super Mario Bros." and made some small changes. in particular, I made it so when Mario gets hit with a Fire Flower, he goes back to Super Mario instead of straight to Small Mario. It was fun, but for some reason, I just got really annoyed with the 6502 assembly. It's nowhere as good as the Game Boy's Z80-like processor, with its many registers and more useful opcodes.

-----

Part 3: The point of this post?

Now I know I'm on NESDev.com, but I was curious about what you thought about Game Boy development vs NES development. Do you think it's easier? Or harder? More or less fun? And why do there seem to be fewer communities centered around GB development? Do you think it would be worth pursuing the NES over the Game Boy?

(In addition, feel free to talk about anything of mine from the post.)


I don't know the purpose of this post, except that I (for some weird reason) visit specifically the General Stuff subforum on NESDev as part of my daily Internet rounds, and I kinda just wanted to talk about the Game Boy, lol. But if you read it all, thanks!
Last edited by devmas on Tue Jun 14, 2022 8:32 pm, edited 1 time in total.
User avatar
Dwedit
Posts: 4612
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by Dwedit »

6502 is very different when you're used to the Z80. Just keep looking at the instruction set a few times. Know what the instructions can do, and what they can't. Just like how Z80 can't do "ld e,(bc)", the 6502 can't do "LDX nnnn,Y" (edit: whoops, that instruction does exist. *stands in the corner*). The zeropage is like a set of 256 more registers on the 6502.
I learned Z80 before learning classic ARM and 6502. (Modern ARM is significantly different from classic ARM)

---

As for level compression, the simplest are RLE-based. You can get a lot out of having "Take a tile from above" as a possible choice to do runs of.
Some other options include predictor-based systems, or the LZ-based systems. Either back-references, or an explicit dictionary. Back references are simple, but restrict random access to your silding window. Explicit dictionary systems are more complicated, but allow random access.

---

As for audio synthesis, first skim Blargg's guide about bandlimited synthesis a few times. In particular, the little part about adding differences. When your square wave synthesizer only has to generate a few points where the wave changes, it becomes much simpler to design.

You don't necessarily need to make an audio synthesizer that's fancy enough to do all those cool ripples around the square waves, even simple linear interpolation can sound pretty good.

You can also use a really cheap and simple DC cancellation/highpass filter when you use a difference based audio system, it just uses subtraction and bit shifting.
Last edited by Dwedit on Tue Jun 14, 2022 7:55 pm, edited 1 time in total.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
devmas
Posts: 23
Joined: Wed May 20, 2009 6:16 am
Location: New York City

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by devmas »

Thanks very much for the response!

I think, as this kind of programming is my hobby, a lot of this stuff is a bit like a puzzle to me... I like to try to figure it out on my own first. But I've never talked with others about my findings, and I guess in a way I was craving that, lol. So thanks!
Dwedit wrote: Tue Jun 14, 2022 4:57 pm 6502 is very different when you're used to the Z80. Just keep looking at the instruction set a few times. Know what the instructions can do, and what they can't. Just like how Z80 can't do "ld e,(bc)", the 6502 can't do "LDX nnnn,Y". The zeropage is like a set of 256 more registers on the 6502.
I learned Z80 before learning classic ARM and 6502. (Modern ARM is significantly different from classic ARM)
A few things stand out to me...

First, I didn't know there was a distinction between modern and classic ARM. I've read up on the ARM instruction set before, mostly ARM7 and ARM9 because GBA and DS (and it really seems like an amazing and fun instruction set that I want to play with one day), but I didn't know it had significant changes. I suppose the distinction comes from ARM Neon? Or maybe ARMv8 when they went 64 bit?

But yeah, I figured learning 6502 would just be a case of "study the instruction set more". For some reason it just felt more difficult to me, which put me off a little, but I'll persevere. It's really good to know that the zero page is often used as extra registers; I thought it was mostly used to store specific often-used things in fast memory, like the player object, especially as the NES has very little RAM. But it makes sense to use it as registers, too.
Dwedit wrote: Tue Jun 14, 2022 4:57 pmAs for level compression, the simplest are RLE-based. You can get a lot out of having "Take a tile from above" as a possible choice to do runs of.
Some other options include predictor-based systems, or the LZ-based systems. Either back-references, or an explicit dictionary. Back references are simple, but restrict random access to your silding window. Explicit dictionary systems are more complicated, but allow random access.
That's great info! My system is basically RLE with a "copy/take a tile from above" tile. A bit in the level header also determines if the RLE is horizontal or vertical (thus, "copy/take a tile from the left"). However, I packed everything into one byte:

- If the two high bits are 11, then the remaining 6 bits are one of 64 non-RLE tiles.
- Otherwise, the high 3 bits equal the length from 1-6, and the remaining 5 bits are one of 32 RLE tiles, which includes the "copy" tile.

So, a total of 96 tiles are representable. It works out because the game only really uses 66 or so unique tiles.

I figured all that out on my own, but I'll have to look into the other options you presented. In particular, I don't know anything about LZ compression, it would probably be fun to study. Dictionary-based compression has always seemed daunting to me, but I'm sure it would show huge benefits with certain types of levels.
Dwedit wrote: Tue Jun 14, 2022 4:57 pmAs for audio synthesis, first skim Blargg's guide about bandlimited synthesis a few times. In particular, the little part about adding differences. When your square wave synthesizer only has to generate a few points where the wave changes, it becomes much simpler to design.

You don't necessarily need to make an audio synthesizer that's fancy enough to do all those cool ripples around the square waves, even simple linear interpolation can sound pretty good.

You can also use a really cheap and simple DC cancellation/highpass filter when you use a difference based audio system, it just uses subtraction and bit shifting.
Ah, audio... I really need to figure out a good way to handle it in my emulator's code, just in general. I've actually not really built anything meaningful yet.

How I'm trying to implement it is basically to add a getAudioSample() function that can be called to calculate what the audio sample would be at any point, with clock rate precision. That way, it could easily be adapted to a 44,100, 48,000, or whatever sample rate by just calling that function when necessary. Though as someone who's pretty much done zero audio programming ever, getting there is not easy!

Thanks for the resources, I'll be sure to take a look at them! I read the "adding differences" portion, and it really seems like it may be helpful to represent, or at least think of, the audio in that way. I figured I would implement a simple synthesizer, and THEN think about all the fancy audio filtering.
User avatar
org
Posts: 105
Joined: Tue Aug 07, 2012 12:27 pm

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by org »

To program sound, you have to rearrange your mind a little bit. If emulation of processor and video is discrete and more or less constant in time (1 instruction at a time, 1 dot on the screen), then sound is a time-varying process.
It's kind of like comparing ordinary equations and differential equations.
Going into the "time domain" is not easy for everyone.
Good luck :beer:
calima
Posts: 1535
Joined: Tue Oct 06, 2015 10:16 am

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by calima »

Why is NES more popular for homebrew than GB?

Tools: NES has far more tools. This is a positive loop with popularity. One tool in particular is important, a C compiler. NES has had a decent C compiler for years, while the GB side situation has been bad (though seems to be improving recently).

Distribution: If I was to distribute a GB game, I'd be limited to 32kb or poor quality Chinese boards. For NES, every popular mapper is available, in high quality, from multiple vendors.

Capabilities: GB has a small screen, and it's grayscale. Multiplayer is slow, cumbersome and not widely available.

Alternatives: For GB, both GBA and DS are easier to target and far more capable. For NES, this is not so: SNES, N64 and GC have bigger barriers to entry. Wii and WiiU are easier, but they have the barrier of higher expectations. To find an easier and more capable target you'd have to jump manufacturers to Sega Genesis and Dreamcast; and indeed, both are more popular for homebrew than NES.

GBC would have color yes, but all the other points apply to it.

Homebrew in general: for new devs starting now, all the current consoles offer easy to obtain Unity licenses. This diminishes the shine of homebrew for older consoles a bit.

--

As for what you should do, do what you feel like. I don't think there's much point to making a new emulator, other than for your own learning. For games, depends what you're after.
User avatar
devmas
Posts: 23
Joined: Wed May 20, 2009 6:16 am
Location: New York City

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by devmas »

org wrote: Wed Jun 15, 2022 12:29 am To program sound, you have to rearrange your mind a little bit. If emulation of processor and video is discrete and more or less constant in time (1 instruction at a time, 1 dot on the screen), then sound is a time-varying process.
It's kind of like comparing ordinary equations and differential equations.
Going into the "time domain" is not easy for everyone.
Good luck :beer:
Thanks very much for the encouragement! Will keep that in mind.
calima wrote: Wed Jun 15, 2022 2:49 am Why is NES more popular for homebrew than GB?

Tools: NES has far more tools. This is a positive loop with popularity. One tool in particular is important, a C compiler. NES has had a decent C compiler for years, while the GB side situation has been bad (though seems to be improving recently).

Distribution: If I was to distribute a GB game, I'd be limited to 32kb or poor quality Chinese boards. For NES, every popular mapper is available, in high quality, from multiple vendors.

Capabilities: GB has a small screen, and it's grayscale. Multiplayer is slow, cumbersome and not widely available.

Alternatives: For GB, both GBA and DS are easier to target and far more capable. For NES, this is not so: SNES, N64 and GC have bigger barriers to entry. Wii and WiiU are easier, but they have the barrier of higher expectations. To find an easier and more capable target you'd have to jump manufacturers to Sega Genesis and Dreamcast; and indeed, both are more popular for homebrew than NES.

GBC would have color yes, but all the other points apply to it.

Homebrew in general: for new devs starting now, all the current consoles offer easy to obtain Unity licenses. This diminishes the shine of homebrew for older consoles a bit.

--

As for what you should do, do what you feel like. I don't think there's much point to making a new emulator, other than for your own learning. For games, depends what you're after.
That's interesting. I didn't realize the SNES was so much more difficult to develop for than the NES. Though I do recognize that the GBA is very easy to develop for... I didn't write it in my post, but I also tested making a GBA Celeste port as well, based on my GB one (same black-and-white graphics, etc.), and it was shockingly easy to make. But it wasn't as fun as making the GB version.

Interesting that there aren't a lot of high quality mapper chips available for Game Boy games, I would've thought a good FPGA-based implementation would've existed, at least. It's not like a mapper needs complex logic that requires a big FPGA chip, or someone particularly skilled at Verilog. (Though I say that as someone with very little FPGA knowledge.)

As for my goals, programming is my hobby, so I'm really just doing all of this to have fun, become comfortable with new tools + a new language, and learn a little something in the process.
User avatar
jsburke
Posts: 4
Joined: Fri Jun 10, 2022 11:55 am
Location: Boston

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by jsburke »

devmas wrote: Thu Jun 16, 2022 8:16 pm Interesting that there aren't a lot of high quality mapper chips available for Game Boy games, I would've thought a good FPGA-based implementation would've existed, at least. It's not like a mapper needs complex logic that requires a big FPGA chip, or someone particularly skilled at Verilog. (Though I say that as someone with very little FPGA knowledge.)
FPGAs are something I work with pretty much daily, so maybe I can pitch in here?

I think I'm following this convo correctly, if you're talking about using a tiny FPGA as a mapper where other physical ones are not often available, it should be possible, but would present new challenges. I'm thinking of something like this https://store.tinyfpga.com/products/tinyfpga-a1 with 256 4LUTs it would be able to do some pretty decent work; however everything I say comes with the big caveat of having never used this element myself before, so please keep it in mind.

I only did a quick look around, and I can't find the FPGA separate from the board it's on, so it might be tricky to fit in a cartridge; it would be nice to be able to just have the FPGA to put on a custom PCB. Assuming the sizing issue is met the next concern I'd have would be electrical. I don't know the voltages driven in Game Boy Cartridges, but if it differs a lot from 3.3V you could damage the fpga.

Finally, the boot up of the game would have to include configuring the FPGA itself. You need to store the bitstream for it in something non-volatile, and my go to would be the GB's PRG ROM somewhere. Effectively, the boot section will have to configure the FPGA everytime it powers on and then probably run some test to ensure it was done correctly. I'd avoid storing the bitstream in a dedicated batter backed RAM as well since if the battery goes, so does all the functionality.
lidnariq
Posts: 10862
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by lidnariq »

As far as I can tell, the reason we aren't seeing more interesting GB carts is space.

1- NES, SNES, SMS, and SMD games can all be DIP. Even GG carts are large enough. So these all afford convenient end-user-buildable designs.

2- GB is unique in that it's 5V, CMOS thresholds, and the shell is comparatively small, so fitting in 3V memories and programmable logic and active voltage translation is a bit of a challenge.

3- With the exception of the MBC3 RTC interface, the mappers are very simple, to the point of feeling a little awkward using a whole CPLD for it. It's a decoder, a few latches, and some AND gates.

3b- on the other hand, the MBC3 RTC interface is so different from any now-affordable RTC that you basically can't make anything suitable at all without exceeding your cost or power budget


InsideGadgets.com is selling programmable GB carts. Some use GreenPaks.
calima
Posts: 1535
Joined: Tue Oct 06, 2015 10:16 am

Re: Made Game Boy emulator and working on GB game. Moving on to NES. Is NES harder or something? Why isn't GB more popul

Post by calima »

lidnariq wrote: Fri Jun 17, 2022 2:50 pm InsideGadgets.com is selling programmable GB carts. Some use GreenPaks.
Oh, a new option *checks*. Their MBC3 carts use donor chips, but others are new. The prices however are nonviable (50$ CIB for a game can't have 30$ go to the board and case; even less so for cart only).
Post Reply