Gameboy Development Forum

Mills wrote:

This looks promising.

How do you get a game boy cartridge and everything?

I'm interested in getting one or two to have my games in a real cart just for fun!

Thanks! There are a few different ways. You can get a flashcart and put games on it yourself. The Everdrive would support multiple games (potentially all the games). Or something like this would let you put one game on it.

All games are a bit different. They have different ROM sizes, battery requirements. Pokémon Silver/Gold have a real-time clock that keeps track of the time of day IRL so they need a large battery, whereas Zelda DX only needs a basic battery for storing your save files. And older games like Tetris were super tiny while later games

I'm planning on ordering a custom circuit board from China. There are lots of places online (you can check Alibaba) that make them to any specification you want. They'll even flash a ROM on it for you.

Last edited by esotericsean (2018-01-14 15:25:44)

Sounds nice, but a litle ambitious ^^
Don't hesitate to post about the game progress, it's always nice to see other people projects

@Mills: You must flash the cart, but I don"t know how it works. Otherwise you can go here: https://catskullelectronics.com/32kcart
No tried yet but soon, I will give you my feedback if you are interested. If I'm right, you buy a cartridge to catskull and you send him your ROM. He will flash the cartridge and send it to you. So you buy a cartridge already flashed with your ROM.

MBC on gb cartridge are not generic hardware, so it is no more in production nowaday
The only method I know to have Memory Bank Controllers on a cartridge is to modify a game cartridge, so you need to destroy an original GB game using MBC to put your game on it. But I have no idea on how to do it, I just know its is more complicated than just falshin a cartridge, you need welding skills too.

But the link esotericsean gave seems to be good yor you: "Custom ROM's can be flashed at customers request.". If I understand you can ask them to flash it with your custom ROM for you.

Yes I think we should start a new thread before we start to really flood this one.

@esotericsean : thanks forBennVenn's Shop link, I didn't know it

Last edited by Hell_666 (2018-01-15 12:33:38)

Hell_666 wrote:

MBC on gb cartridge are not generic hardware, so it is no more in production nowaday
The only method I know to have Memory Bank Controllers on a cartridge is to modify a game cartridge, so you need to destroy an original GB game using MBC to put your game on it. But I have no idea on how to do it, I just know its is more complicated than just falshin a cartridge, you need welding skills too.

Well, that's not the only way. You can replace the MBC chip by parts that are available (and inexpensive) today. It depends on the PCB layout you use. But maybe it's indeed a topic for a thread of its own.

tobiasvl wrote:

Welcome! Looks like you have a solid game planned here, but yes, you will have to learn a lot about how the Game Boy works before you can make it work

Depending on your level of ambition here, I would suggest looking into doing it in assembler instead of C.

There's another Link's Awakening-like RPG in the making, called Aevilia: https://github.com/ISSOtm/Aevilia-GB/

Regarding resources, check this out: https://github.com/avivace/awesome-gbdev

Thanks for the info Tobias! I'll definitely be checking out Aevillia.

Any reason for suggesting Assembler instead of C? I have a ton of experience in C, C++, and C# and I couldn't even tell you what Assembler looks like, heh. I'm sure I could learn, but with GBDK and ZGB, it seemed like making a game was somewhat feasible.

esotericsean wrote:

Any reason for suggesting Assembler instead of C? I have a ton of experience in C, C++, and C# and I couldn't even tell you what Assembler looks like, heh. I'm sure I could learn, but with GBDK and ZGB, it seemed like making a game was somewhat feasible.

ZGB is cool and easy to use (for a noob like me), but it is a bit slow for the DMG when you use a lot of sprites and collisions. In CGB it works much better.

The main problem I see with assembly (my oppinion) is you get lost in the code .
I can think of a mixture of custom assembly functions called from gbdk as the best option, but gbdk has a lot of bugs and this will delay your development.

Last edited by Mills (2018-01-16 04:36:22)

Hello !
I'm the programmer of Aevilia, the RPG tobiasvl just linked.
We're a small team of six, but I'm talking from my point of view only.

First, the big problem with C is that the libs that you may use (mostly GBDK) try to abstract the hardware. Thus, a lot of people have issues that they don't get, because the documentation is vague.
Besides, you don't get what happens, why the console is doing this. For example, a LOT of people use "printf" in their games, but it clobbers graphics a lot, and is generally intended for debugging purposes only.
C is also depriving you of debugging using BGB. BGB's a very good emulator (sharing first place in accuracy with Gambatte), which also has an excellent debugger. But due to the nature of the emulator, it only debugs the compiled ASM.
Due to the way it works, C adds some overhead compared to hand-optimized ASM. On modern computers, this is not much, especially because the stdlib removes a lot of hassle. But on the GB, you don't have power to waste on overhead.
(You can still make a very good game using GBDK, though : Imanolea originally made Last Crown Warriors in GBDK, and then switched to ASM. He published screenshots showing that ASM could support a much larger load [number of enemies] for the same CPU time.)

I want to debunk what Mills said : you don't get lost, if you segment your code well enough. In Aevilia, I write a lot of "utilities" functions. Such as `TransferTilesAcross`. I write a clear documentation for these functions ("Transfer c tiles from b:hl to de.").
Learning ASM is doable. It's actually fairly easy (imo). It requires you to think way differently, however. You're dealing with much more elementary instructions :

if(cameraYPos != 0) {
    cameraYPos--;
}

    ld a, [cameraYPos]
    and a
    jr z, .lockTop
    
    dec a
    ld [cameraYPos], a
.lockTop

This requires thinking much differently than in other languages. It's also more verbose. On the other hand :
You gain full control of the machine. You're interfacing directly with the hardware, which has defined behaviors, so when you tell it to do X, it does that.[1] (Also, GBDK puts a lot of restrictions on what you can do, for example set_bkg_tiles restricts you to a small section of VRAM)
This also greatly simplifies debugging and helping - you know what's wrong : your code. GBDK is quite buggy (ask it "a = b * [power of 2]", you'll see).
You can use BGB to debug your code. It's really practical, and I must say that it helped a TON when debugging Aevilia. It's an emulator, and even though it's a very accurate one, I still found a couple inaccuracies while developing Aevilia. beware was very helpful, though, and they have almost all been patched.


Overall, ASM does require some extra work from you, but it's both worth it and doable. It's still your choice, though, you can make your game in C, or decide to give ASM a shot.
By the way, if you want help, aside from the forums, we are on IRC and Discord, so feel free to join us there.



[1] : Actually, the Game Boy has small quirks that aren't always documented. So, *sometimes*, you'll encounter a bug that isn't really your fault. However, it would also have happened with C code - but you wouldn't have known why !

There are lots of people using GBDK too (especially here on the forums, it seems), so I'm sure you can get help if you go down that route. Most of the people on the Discord use assembler (RGBDS) though.

And no matter if the rest of us are comp sci majors or not, when it comes to Game Boy programming we're all enthusiast amateurs! The most important thing is having fun and learning, so pick what makes sense for you out of GBDK or RGBDS and just get cracking and make a game.

Of course, it'd also  be a shame if you halfway through development want to change from C to ASM and stop working on the game because of that hurdle, so you should probably make an informed initial decision on the programming language. Perhaps make a few smaller games first in GBDK and ASM just to get acquainted with them. Up to you!