This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Approaches to emulating Classic GB on the NES

Approaches to emulating Classic GB on the NES
by on (#120490)
Has anyone ever considered making a GB emulator for the NES? It would obviously not run anywhere near 60fps, since no matter how you approach rendering the graphics, just emulating a (slightly crippled) Z80 on a (slightly crippled) 6502 will be painfully slow. Still, I think this would be interesting to see, but I wonder what the best way to handle the graphics would be...

Considering that the NES can do almost everything the GB can, the logical solution would be to use the capabilities of the PPU directly. There are a couple of small problems that are easily solvable (or can be ignored!), like the 32x32 tile maps (which can be done by making all palettes the same and forcing the vertical scroll past 240) and the 10 sprites per scanline limit (the result will be more flickery than on a real GB). There is however something I consider a big problem, which is the inability to mask the sides of the screen. Having garbage around the game play area is too off-putting IMO. Another big problem is the window, which can't really overlap the screen.

The other approach, which would make things significantly slower, would be to do everything in software. Reserve 360 tiles (a split will be necessary) for drawing the 160x144 gameplay area and dynamically render everything there. In addition to the speed issue, there's also the fact that 8KB of CHR is not enough to hold a second 160x144 off-screen buffer, but nothing stops us from using more CHR, even though that's not very common in iNES ROMs.

What are your thoughts on this? There are many points to consider regarding the CPU and audio as well.
Re: Approaches to emulating Classic GB on the NES
by on (#120496)
Perhaps the most viable solution is high level emulation (HLE). Rewrite the graphics and sound engines and statically recompile the game code. Chris Covell thinks this is how Balloon Kid was translated into Hello Kitty World. For example, both BK and HKW end up using the same music engine as the respective platform's version of Dr. Mario.
Re: Approaches to emulating Classic GB on the NES
by on (#120498)
But that's game-per-game conversion, I'm talking about actual emulation. Take any GB ROM and it will run with correctly represented graphics, no matter how slow (sound is most likely not necessary, because it will sound like crap at such low speeds). how would you approach that?
Re: Approaches to emulating Classic GB on the NES
by on (#120500)
By running the emulator on an N64 and doing everything in software. (See Pokemon Stadium.)

If you must stick with the NES to make your pure-software Wide Boy, you'd probably need to use software rendering and extra memory on the cart at $6000-$7FFF to represent the Game Boy's RAM and VRAM. The MMC5's window in SL mode may be flexible enough to represent the Game Boy's window for some games, but nowhere near for all games.
Re: Approaches to emulating Classic GB on the NES
by on (#120502)
tepples wrote:
By running the emulator on an N64 and doing everything in software. (See Pokemon Stadium.)

Doing things like this in a machine you KNOW can handle it is not fun, it's just convenient. The fun is all about trying the unusual. Emulating a GB on the NES is not about the goal (playing Game Boy games), but the means (NES simulating another machine). I thought of the Game Boy because it has slightly lower graphical capabilities than the NES, but other platforms with decent libraries of cool games would be interesting to see emulated as well.

Quote:
If you must stick with the NES to make your pure-software Wide Boy, you'd probably need to use software rendering and extra memory on the cart at $6000-$7FFF to represent the Game Boy's RAM and VRAM.

Yeah, to make things look right the video would have to be rendered in software. But I wonder if there's a way to make it look mostly correct while taking advantage of hardware graphics acceleration (i.e. make use of name tables and sprites instead of rendering pixel by pixel to a surface of 360 tiles).
Re: Approaches to emulating Classic GB on the NES
by on (#120503)
I would think the best idea would be to statically recompile the code (difficult, ideas here: http://andrewkelley.me/post/jamulator.html ) outside of NES and on the NES, intercept hardware access with drivers ( maybe not as difficult, ideas here: viewtopic.php?p=101771#p101771 )
Re: Approaches to emulating Classic GB on the NES
by on (#120504)
Does anyone have any ideas of other platforms that are relevant enough to be interesting to see emulated? I know there are many old text-only, monochrome or with hardwired tilesets that are easier to emulate but are incredibly uninteresting (no exciting software). Since the emulator itself would not be convenient at all, if the emulated platform isn't relevant, there's no point in considering this.
Re: Approaches to emulating Classic GB on the NES
by on (#120507)
Well, I have a retrovision but that isn't exactly emulating.
Re: Approaches to emulating Classic GB on the NES
by on (#120508)
There were GB emulator for MSX, NES emulator for SMD, ZX Spectrum emulator for ZX Spectrum, and few more. They all aren't really usable to play games, just programmer's fun.
Re: Approaches to emulating Classic GB on the NES
by on (#120509)
Shiru wrote:
There were GB emulator for MSX, NES emulator for SMD, ZX Spectrum emulator for ZX Spectrum, and few more.

There's a NES emulator for GBC. It was incredibly slow.

Quote:
They all aren't really usable to play games, just programmer's fun.

That's the idea.
Re: Approaches to emulating Classic GB on the NES
by on (#120511)
I would think that anything 6502 based would be a good place to start. Atari 2600 or 800? Apple II? I know the Atari 800 line had a display list feature that seems it would be hard to emulate with the PPU, but perhaps games that stuck to a more compatible mode for the entire screen wouldn't be too hard to run. There is also the problem of dealing with the BIOS that a lot of software would utilize as well (and I would assume the same for the Apple II).
Re: Approaches to emulating Classic GB on the NES
by on (#120519)
I want to see Chip-8 on NES so that I can extend an emulator stack one higher. Imagine Chip-8 emulator in PocketNES in VisualBoyAdvance GX in Dolphin in Wine in Virtual PC or VMware.
Re: Approaches to emulating Classic GB on the NES
by on (#120523)
Movax12 wrote:
I would think that anything 6502 based would be a good place to start.

It doesn't make such a difference if you're not recompiling, because you can't simply let the CPU run free, you have to intercept reads and writes, count cycles, etc., so you need to look up the opcodes even if it's 6502 code emulated in a 6502.

Quote:
Atari 2600

The little amount of RAM makes it tempting, but the video system is too different. The whole screen is redrawn every frame, and colors change every scanline... not easy on the NES.

One that might work well is the Bally Astrocade. The graphics are pretty basic and within the limitations of the NES.

tepples wrote:
I want to see Chip-8 on NES so that I can extend an emulator stack one higher.

From what I've read, there's nothing about it that would be particularly hard to implement on the NES. This one is perfectly doable IMO.

Quote:
Imagine Chip-8 emulator in PocketNES in VisualBoyAdvance GX in Dolphin in Wine in Virtual PC or VMware.

Now there's an interesting idea! The only problem I see is the lack of interesting games, because the Chip-8 itself is a novelty.
Re: Approaches to emulating Classic GB on the NES
by on (#120524)
tokumaru wrote:
But that's game-per-game conversion, I'm talking about actual emulation.


What if you cheated and did the conversion with the NES? Maybe just covert the main loop and put it into RAM and execute off of that. You could leave subroutines up to emulation though. That could probably go a long way to improving speed.
Re: Approaches to emulating Classic GB on the NES
by on (#120526)
infiniteneslives wrote:
What if you cheated and did the conversion with the NES?

That would be dynamic recompilation, right? I'd be fine with that. I was against tepples' idea of rewriting the graphics and sound engines, because that would require human intervention for each game.
Re: Approaches to emulating Classic GB on the NES
by on (#120530)
Frankly I'm not sure I see what there is to discuss? Of course a NES, extended with enough RAM, can run GB code. That ability is pretty much the definition of Turing completeness. So yeah, it's fully doable and not even difficult: Just compile any GB emulator's C code on a C compiler that supports the NES target for sufficiently big programs... or write the emulator from scratch in 6502 assembly if you have the time for it.

The real challenge would be to get any speed that gives a decent emulation experience... but if you've already sacrificed that criteria, then it's a no-brainer. So what are you trying to get at here? :)
Re: Approaches to emulating Classic GB on the NES
by on (#120531)
Bananmos wrote:
Frankly I'm not sure I see what there is to discuss?


Quote:
So yeah, it's fully doable and not even difficult: Just compile any GB emulator's C code on a C compiler that supports the NES target for sufficiently big programs...


Well, we could discuss how this will obviously not work, or is at a minimum not nearly as simple as you're suggesting...
Re: Approaches to emulating Classic GB on the NES
by on (#120536)
There aren't any C compilers that support sufficiently large non-linear program spaces. But the point is quite valid. If the only requirement is to accomplish X without regard to efficiency or accuracy, then it becomes a fairly mundane problem.
Re: Approaches to emulating Classic GB on the NES
by on (#120538)
Even though I don't think efficiency has the highest priority in an experiment like this (getting games running is the real goal), anyone attempting it should aim for the highest efficiency possible, so there's definitely room for discussion.

For example, the Game Boy has 8 KB of main RAM and 8KB of VRAM. If you implement that as 2 PRG-RAM pages on the NES, you'll spend a lot of time just bankswitching when the emulated CPU is copying data to VRAM. And then there would even be a third step, when the contents of the emulated VRAM are used to render tiles to CHR-RAM. Is there any way to optimize this process?
Re: Approaches to emulating Classic GB on the NES
by on (#120539)
tokumaru wrote:
The only problem I see is the lack of interesting games, because the Chip-8 itself is a novelty.

Chip-8 was released in 1977. I thought 'novelty' means a 'new thing', 'recently created', am I wrong?
Re: Approaches to emulating Classic GB on the NES
by on (#120541)
Perhaps "curiosity" would have been the better term.
Re: Approaches to emulating Classic GB on the NES
by on (#120543)
Shiru wrote:
Chip-8 was released in 1977. I thought 'novelty' means a 'new thing', 'recently created', am I wrong?

Yes, but it also means "unusual", AFAIK. But yeah, I might have used the word wrong and it might not be a novelty now, but I bet it was back when it was created!

What I meant is that the Chip-8 is a weird little thing that's mildly interesting but doesn't really capture people's attention for long, and since a sluggish emulator will certainly not have many fans either it will probably not even be noticed outside the circle of NES programmers... but a Game Boy running inside the NES CPU? That's big (even if it's unplayable)!
Re: Approaches to emulating Classic GB on the NES
by on (#120545)
tokumaru wrote:
For example, the Game Boy has 8 KB of main RAM and 8KB of VRAM. If you implement that as 2 PRG-RAM pages on the NES, you'll spend a lot of time just bankswitching when the emulated CPU is copying data to VRAM. And then there would even be a third step, when the contents of the emulated VRAM are used to render tiles to CHR-RAM. Is there any way to optimize this process?


Well a custom mapper would be able to lend a hand. Having a full 16KB of PRG-RAM visible at once perhaps. One trick/cheat would be to use dual ported RAM for VRAM.
Re: Approaches to emulating Classic GB on the NES
by on (#120546)
You'd need to bankswitch the ROM image too though. And the limit of "help from the mapper" is obviously Wide Boy or Retrovision.
Re: Approaches to emulating Classic GB on the NES
by on (#120558)
I think, unless you use something fancy like VRC7, emulated sound would be crap here... Better would be to write GB Emu for C64 (6502 as well), since GB sound is closer to SID really, in terms how it sound like, than 2A03.
Re: Approaches to emulating Classic GB on the NES
by on (#120569)
The emulated sound will be crap no matter what you do, because it won't play at full speed. =)
Re: Approaches to emulating Classic GB on the NES
by on (#120640)
This thread reminded me of an emulation approach I thought of a while back, if you want to hear my weird mapper-assisted idea. I always thought a Colecovision emu for NES would be amusing, so on with my Squeedo mapper I wondered how well it would work if the on-board PIC emulated the Z80. When doing video/sound/controller I/O it would trigger an IRQ for the NES to handle it. This PIC (18F family) has up to 64kB of ROM, and 3.9kB of RAM. One problem I can forsee is if the game does a lot of VRAM reading, the PIC would have to request it from the NES and that could bog down. I don't know how frequently, obviously it would vary widely. We all know that's almost never done on NES, but Coleco has 1kB of RAM and 16kB of VRAM, so it's not hard to imagine how it'd be useful. And it sorta helps that it can access VRAM during rendering, heh.

Can't say I ever wanted to write a Z80 emu for PIC, but I would probably try to use it if it existed (maybe compiling a C version could work, I never really considered that). I know someone who wrote a 6502 emulator for PIC, I've been telling him he should make it available for this kind of fun stuff. Then one could run their code on a faster emulated CPU, on the NES.

Also funny to note in this thread, is that the CopyNES debugger "Microbug" emulates a 6502 on the 6502. It's pretty nifty to see it in action.
Re: Approaches to emulating Classic GB on the NES
by on (#120642)
Memblers wrote:
I know someone who wrote a 6502 emulator for PIC, I've been telling him he should make it available for this kind of fun stuff.
Doynax's NSF-on-a-PIC project does that, and he released his source...
Re: Approaches to emulating Classic GB on the NES
by on (#120645)
I made GB emulator for PlayStation 1 some time ago. It was twice as slow as original GB (if not more).

http://psxdev.narod.ru/download/GBEMU_psx_bin.rar

Not sure you can even emulate it on NES, since GB use different memory mapping and RAM size. NES just have not enough RAM to emulate 8+8 KB of GameBoy's RAM and VRAM.

Although GB CPU can be emulated easily, just for fun.
Re: Approaches to emulating Classic GB on the NES
by on (#120647)
Well, NES has 32kb of RAM, isn't it? And 8+8kb = 16kb. Dedicating first (or last) 16kb of NES RAM for GB and using only first (or last) 16 for actual emulation (perhaps with custom mapper) we could do it. Granted 16kb isn't much, but so is 32kb (even if it is twice as large).
Re: Approaches to emulating Classic GB on the NES
by on (#120654)
No, NES only have 2K RAM and 2K VRAM, which is four times less than GB has. It could have any amount of extra RAM and VRAM on cartridge, though. Existing mappers allows up to 32K for both (in 4K or 8K pieces, with paging).
Re: Approaches to emulating Classic GB on the NES
by on (#120671)
org wrote:
Not sure you can even emulate it on NES, since GB use different memory mapping and RAM size.

It's definitely possible. Doesn't a PC have different memory mapping from that of the GB? By emulating the CPU you can always check which addresses are accessed and reroute them as necessary. RAM size can be handled with extra RAM on the cart, which is supported by current ROM formats.

Quote:
NES just have not enough RAM to emulate 8+8 KB of GameBoy's RAM and VRAM.

The NES can have more than 8KB of VRAM if you use CHR-RAM, but you'd probably need even more space to double-buffer everything, since the mulator won't be fast enough to perform all updates necessary from one frame to the next. It's doable, it's just slow.

What I'm really not sure is whether using the PPU features directly would work reasonably well for a decent number of games, because there are 3 very significant incompatibilities:
1. There's no way to mask the sides of the background, so you're going to see garbage tiles;
2. The NES can only display 8 sprites per scanline, while the GB can do 10, so there might be some additional flickering;
3. The NES will not be able to properly overlap the window on top of the background;

To help with problem number 1, you could maybe assign all black palettes the the tiles that should be outside of the visible area and mask *most* of the garbage, but that would get in the way of treating the 32x30 name table as if it were 32x32 (which requires all palettes to look the same). Mid screen scroll changes also would ruin this solution.

Flickering is not such a big issue, we're used to flickering sprites. There could be a few games that use sprites for static objects that could look weird when flickering, but I don't expect that to happen very often.

The window is also a big issue, but most games I can think of use it like a background scroll split, and don't really require actual overlapping of the layers. Some games certainly do though, and those will look slightly broken.

If this approach is used, the overhead will be all in emulating the CPU and the memory map, and we'd get better performance, but there would be a few graphical issues. To get a perfectly clean display, you'd have to emulate the VRAM in PRG-RAM and periodically render the entire screen in software, which would be significantly slower!

Memblers wrote:
This thread reminded me of an emulation approach I thought of a while back, if you want to hear my weird mapper-assisted idea.

Mapper assistance is cool and all, but if you're gonna go that route you might as well go all the way and put an entire Game Boy in the cartridge.

Quote:
I always thought a Colecovision emu for NES would be amusing

I don't know how I'd approach the coloring of the background in that one. Each tile can have 2 colors per line, and the mapper can manipulate the attributes per tile, but you can't really predict or expect that all 2 color combinations will fit in the limited number of palettes the NES has.

Quote:
Also funny to note in this thread, is that the CopyNES debugger "Microbug" emulates a 6502 on the 6502. It's pretty nifty to see it in action.

I didn't know that. Sounds interesting.
Re: Approaches to emulating Classic GB on the NES
by on (#221432)
Bump
Re: Approaches to emulating Classic GB on the NES
by on (#221436)
Please don't bump threads if you don't have anything to add.