What is Reddit's opinion of
BGB?
From 3.5 billion Reddit comments
33 reviews of this app found across Reddit:
Hey! I did this with a few friends and made a gameboy emulator in C++ (It's actually a Sharp LR35902 Chip, which is a mix between a Z80 and the 8080). We used the main gameboy documentation and https://cturt.github.io/cinoop.html to help write it. Cinoop did it in C, we did chose to do it C++ and used SDL2 for the graphics. You could really do it in anything though. Just dive into the documentation and read as much as you can on the bootstrap of the gameboy. See if you can actually run the gameboy bootstrap code. There are a ton of instructions for the gameboy, it's super easy to have small mistakes. Half the time was spent debugging and looking for small mistakes in the instructions.
What is also helpful is to use something to look at the ROM running through some gameboy debugger like http://bgb.bircd.org so you can see what an actual running emulator is doing with the instructions, and where your code is going off track, if your emulator is running correctly, you should be doing the exact same steps as this debugger when you load a rom.
I recommend doing a 32kb game like Tetris so you don't have to deal with bank switching yet. There's a few 32kb games you can try first, and it is a bit easier to get going then jumping into the much more common 64kb gameboy games. Shoot me any message you want with more questions! I could share our project repo with ya if you'd like to see it in pm.
0x0000 to 0x7FFF are assigned to the cartridge hardware and further subdivided by memory mappers, if present. 0x8000 through 0x9FFF are assigned to Video RAM, the video got that wrong. 0xC000-0xDFFF is the actual Work RAM.
See this for more info
So how do you fit 2mb of memory into 32kb of address space? Surely it's impossible you must say, but the answer is actually quite ingenious.
First lets visualize the memory issue. Each block represents 16kb of memory.
Memory Addresses on the Game Boy on boot (Last two blocks reserved for video ram,i/o and such) [_][_][][] Memory Blocks On the Cartridge [1][2][3][4][5][6][7][8]...[125]
Looking at the diagram above you might already have an idea of the solution.
Memory Addresses on the Game boy [1][2][][] Memory Blocks On the Cartridge [1][2][3][4][5][6][7][8]...[126]
And then when we progress to a different level we reference a different part of memory in our address range
Memory Addresses on the Game boy [1][7][][] Memory Blocks On the Cartridge [1][2][3][4][5][6][7][8]...[126]
Keep in mind we aren't moving the memory, it's still in the same place, we are just giving it a temporary address in our address bus.
This is a technique known as bank switching. It's used extensively in early consoles to deal with 16 bit memory limitations.
The Game Boy's Memory Bank Controller is located on the cartridge itself and is a cool example of how the cartridge was used to extend the limitations of the machine. The next video will probably do a better job of explaining this and it might go onto some other hacks used by the cartridges.
>I once read about some Memmory Mapping chip in some games .. what's it doing?
http://bgb.bircd.org/pandocs.htm#memorybankcontrollers
I would just add that, if you don't have a solid background in electrical engineering (it's hard to gauge from your post), designing a flash cartridge would be a pretty daunting task. The people that do this typically have years of experience, including deep knowledge of the console they're making the cartridge for.
Most of my hardware reference came from the Pan Docs, which are quite simply excellent, though not fully complete once you start getting into the nitty gritty of things: http://bgb.bircd.org/pandocs.htm
It's tempting to think the gameboy has a z80 and start implementing those opcodes and flag behaviors, but it's actually a much more limited sharp80 cpu. I found the following reference to be the best general jumping point, and had to google lots of obscure behavior (the stack adjustment opcodes and DAA among them) to get my CPU working: http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html
Finally, I found an amazing tool, blargg has put together a set of tests for the CPU. Once your gameboy emulator is working well enough to boot some games, try running this through it. It'll test all the opcodes and either report errors or break, depending on how well your CPU is actually working, and debugging to get it to pass all of these tests will help you ensure that your CPU is no longer the source of your gameplay bugs: http://gbdev.gg8.se/wiki/articles/Test_ROMs
Good luck on your emulator, and remember to post progress. :)
Romhacking.net is another great resource as well full of tools and guides and other goodies. Mostly focused on translating video games but there is documentation for various games and how to hack them as well.
For debugging tools:
As mentioned FCEUXDSP is the best for the NES.
For gameboy I recommend BGB
For gamegear I would recommend Meka
If you are interested in other systems let me know as I do a lot of translation hacking and can recommend various other emulators/tools for hacking on the various systems out there.
- Read the Pan Docs. They explain everything about the GameBoy and GameBoy Color, which will become very useful knowledge when programming for it.
- Find an instruction list if the one in the Pan Docs isn't clear enough for you, and start reading actual codebases. There are plenty of them around; the pret repositories are a good starting point, and so is the Prism source code.
- Join us. By "us" I mean any of the few groups that discuss this stuff. You'll be able to get help when you're stuck.
Don't use mGBA, while it is fantastic for GBA emulation it's GB/GBC emulation is not very accurate at all as it is in very early stages. Use either http://bgb.bircd.org/ or https://sourceforge.net/projects/gambatte/
Read the available hardware documentation, e.g. pandocs and gbdev wiki. Using an existing emulator's debugger to analyse games/demos might also help.
>" (even the GB documentation is all complete shit." )
Wasn't this really complete?
marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Among with this:
http://bgb.bircd.org/pandocs.htm
EDIT: I say this because the GB would be the next step over the CHIP8, because I know a bit of the Z80 thanks to some experience with the Speccy and some ASM toys.
I can't find any details about "hi-color" mode. But I can make a guess.
I assume it's based off switching out the colour pallette during horizontal blanking period. According to pan docs you get 278-290 clocks (or double that in 8mhz mode?) every line to swap out the pallette.
If you swap out all 56 colours (32 background colours, 24 sprite colours) every row that will give you 8064 colours over the entire screen.
Only swapping the 32 background colours and using 24 fixed sprite colours would give you 4632 colours.
Lets check how many colours we can swap per hblank. An unrolled copy loop of:
ldi A, (HL) ; Load byte from HL, increment HL by one (8 cycles) ld (FF00+C), A ; Store byte to register FF69 (C is $69) (8 cycles)
will take 16 cycles per byte, so in 8mhz mode you can copy in 34-36 bytes of colour data every hblank, which will allow you to swap 16 (or 18 at a stretch) colours every line.
16 colours per line works to to 2304 colours (with an extra fixed 24 sprite colours) on the screen at one time, which is very close to the advertised modes.
There are a few possible modes that could be achieved with this, such as:
- 8x8 cells with a choice of one of 4 sets of four colour palettes which are fixed over whole frame or one of 4 dynamic pallet which have 4 colours per line, changing every line. You also get 40 sprites, from eight additional 3 colour palettes to sprinkle over your screen.
- 8x8 cells with a choice of 8 sets of dynamic palettes. Each dynamic pallet gets 4 colours which are swapped every two lines. The updates are interleaved so the first 4 palettes will be updated one line and the second 4 palettes are updated on the next line. You also get the 40 sprites and their extra 24 colours to sprinkle around.
- you could update colours less often to give your self more time to update other things.
Exactly what do you mean by "make cartridges"? There are two parts really, making the game or application that goes on the cartridge, and making the cartridge itself.
When it comes to the cartridge itself, it's a question of scale. If you only want one or two cartridges, you are better off just buying a pre-existing flash cart and loading whatever you want on it. If you actually want to mass produce it at scale, that's kind of out of my area of expertises.
With a large enough scale I guess you could order actual mask roms, you would still need a mapper IC (unless you can fit everything in 32kb). Creating the case would require large setup costs, to create tooling for injection moulding.
At a medium scale, you might be better off buying old games to steal the case and mapper IC, putting in your own PBC and pre-programmed flash chip.
As for the software itself, that's several comments worth of information, but pandoc covers a lot of it. Development is usually done in an emulator for fast turnaround times and easy debugging, but you are to be careful about the accuracy of the emulator. It's possible to create games which work on some emulators and not the real hardware.
For debugging your best bet is http://bgb.bircd.org/ and for programing using c you best bet is http://gbdk.sourceforge.net/ but as killing_buddhas said Gameboy programign is no walk in the park and if you want to achieve any sort of optimization you will need to learn to write in ASM.
For starting out, you can just use LSDJ on a Game Boy emulator. I think BGB has the most accurate sound.
So download the LSDJ ROM, grab BGB, and try it out. Follow some tutorials on youtube. Experiment.
LSDJ has a definite learning curve, so just keep at it.
If you stick with it and want to go with real hardware, get a Game Boy and a USB cart.
With a USB cart you can load the .sav file from your computer on to the cart (so all that music you made on the emulator can be played on your actual Game Boy).
From the dev:
> You will need to download an Emulator to run Deadeus. For PC I recommend BGB Emulator (http://bgb.bircd.org/) and for Android devices I recommend MyBoy! Emulator. When you have downloaded your emulator load your zipped Deadeus folder and enjoy!
(I don't have the ROM to check in its case, but: just because it's a GBC game doesn't mean it runs in double-speed mode/requires the MBC5. Double-speed mode uses more battery life so unless it's necessary I'd hope the devs wouldn't use it...
at any rate, you should use whatever MBC the header tells you to use. Look at address 147h in the ROM and cross-reference to the list in the pandocs)
VGB is very dated so I wouldn’t recommend using it. It gets an accuracy score of 19%. What I prefer is BGB which gets a score of 89% and has debugging tools so you can make your own cheats.
If you don’t want to bother with separate emulators you can use BizHawk which supports 17 systems in total and is easy to use.
If you want to help out, feel free to inspect the code and document the protocol for us. You can find Pokémon Crystal's disassembled source code on https://github.com/pret/pokecrystal. (Prism's source code is bundled in the .rar with every version, but the link code is the same as Crystal's, and the latter is likely to be at least slightly better documented.)
The main issue is that we simply don't understand the protocol the games use. The hardware protocol is documented in the Pan Docs quite well (http://bgb.bircd.org/pandocs.htm), but that's a simple serial byte protocol; the issue is the software protocol (layer 7, if you want) that is overlaid upon it. The code is a mess and we frankly don't have the time to go through it thoroughly until we figure it out.
Any help will be appreciated.
From the looks of this:
https://realboyemulator.wordpress.com/2013/01/03/a-look-at-the-game-boy-bootstrap-let-the-fun-begin/
The boot rom appears to simply clear the VRAM, set some audio register values, then do the checksum. Which begs the question, on an actual game boy, what sets all the other initial values (such as 0x01 for reg A) on power up?
For the time being, I will go ahead and set these initial values (from pan docs) myself and skip the boot rom entirely.
BGB (http://bgb.bircd.org) appears to do it in the same way. It doesn't have a boot rom, and instead launches games at 0x100 with everything set.
Fortunately, I do have links on hand. This one, for the GBA, supports easily linking via LAN. And this one, for the GBC, has over-the-internet connection just fine.
And seeing as Nintendo has proven they will never want to release GBA games for 3DS Virtual Console, the simpler GB/GBC cables will probably be easier to mange.
Especially when you're dealing with ad-hoc console to console rather than over the internet, which is where you start getting lag.
To be fair, PC emulators already have the ability to link, so why is it so hard to imagine adding that as part of the emulation shell. "Add a wifi cable" as part of the buttons on the lower screen, next to the save states.
Examples: This one, for the GBA, supports easily linking via LAN. And this one, for the GBC, works via TCP/IP.
If anyone was wondering, I was able to File>import my .srm file from Retroarch to VisualBoy advance, then save inside VisualBoy advance and export that battery file (this exported to a .sav), I then was able to open this .sav into BGB which allows EASY linking.. And I mean easy.
If anyone needs a more detailed explanation please feel free to comment or message me!
I'm using v1.1. v1.0 is an old version with a different Music-A -- not sure what else is different.
Yes, the base of the first RAM bank is at 0xC000.
I'm using this and this for quick reference. The former is handy for GB-specific I/O Ports and so on -- for example, it looks like the piece generation function uses the divider register (see ROM location 0x2043).
EDIT: I think I misremembered the number that was used for modulus earlier given how this loop works.
We strongly advice against using Visual Boy Advance. It's a bad emulator, it's inaccurate, and you will run into problems when using it to play Prism, since it is a very demanding game from a hardware point of view.
My best recommendation is to use BGB. (Right-click on the emulator window to access the menu.)
I've been trying to setup bgb 1.5.7 on Linux. It says it works with wine, and setting it up manually or using lutris to set it up and then supplying the .exe, will let me run the emulator and start up a game.
The issue I am running into is that when trying to configure the controller the dpad doesn't seem to be recognized. The shoulders and face buttons a, b, x, y all register but the d pad will not. When I look at the wine control panel and test the controller it seems to register the dpad just fine.
I have also tried to run it in a VM and it will register the dpad fine on there. This is a really power hungry and not optimal solution though.
If anyone has run into this and has fixed it or has any ideas please let me know. Or if there is a specific way to successfully set it up to run in wine I would appreciate info on that too. Thanks for the help in advance!
How do they not work? Do they not load the ROM at all, or does it crash?
Things that can go wrong:
- The downloaded file is corrupted.
- If you downloaded an .ips patch, you need to apply it to the correct ROM.
- The emulator is buggy. Try BGB, it's very accurate.
I don't use Macs, but those are the cross-platform issues I can think of.
Anyone have any experience with BGB command line arguments? I manage to get bgb.exe -r "rom.gb" to autoload a rom, but I was trying to figure out how to automatically connect to certain IP addresses or listen on certain ports. There's no documentation that I can find on command line parameters, but maybe I've missed something.
As an aside, the bgb.ini has the following variables:
LinkListenAddr=8765 LinkConnectAddr=127.0.0.1 LinkAutoConnect=1 LinkAutoListen=1
Am I to assume that if I specify the address or port, and have these other values set to 1, that it'll attempt to automatically make the connection?
NES or GB. Always where I recommend starting. The architectures are documented amazingly well: Gameboy, NES; they're dead simple MMIO-based designs and the CPU's have fairly basic opcode tables + timing.
Whereas a good SNES emu would take a beginner months to get to a decent level, they could be running diagnostic + basic ROMs on one of those in a few weeks to a month.
Last I heard bgb had timing issues that gambatte didn't. That was years ago, so it could be better now.
http://bgb.bircd.org/#features
It doesn't mention full clock cycle accuracy here. Is there anywhere I can read more about it?
Turns out there is a gameboy emulator with netplay.
I haven't got much time either, but with this we could play red/blue! I've also got advanced skillz in networking, and can guarentee it'd be as simple as entering my IP into the connection window for the program. So how about it? Do you want to be a pokemon master, too? Like I said, we could find a way to schedule it out to about a half hour of play or more per day, with simple level / story progression limit rules to ensure we can battle / trade effectively with one another. I'll even throw in another service: I'll be the dude who has to make up a new game to trade the starter we'll be missing. Let me know, I haven't played this game in about ten years and honestly never completed the pokedex.