Gameboy Development Forum

Hey, great-looking game!

I've never used GBDK and don't really know the nitty-gritty about banking, so I can't really help with your main questions. However, I think most of your problems probably come from a misunderstanding of MBCs.

You're mixing usage of MBC1 and MBC5 here. You're invoking the lcc linker with the MBC1 argument (if I understood you correctly; I've never used lcc for Game Boy), but in your code you switch ROM banks using the MBC5 method. Since you were wondering in the video what the difference between MBC1 and MBC5 was, check out this wiki article which has details on the different MBCs.

why does BGB tell me "RAM size and cart type 'has RAM' do not match."?

What does your cartridge header say? Most likely your cart type (address $0147) says that you're using MBC1 (1–3) or MBC5 (value between $19–$22), but your RAM size (address $0149) is 0 when it should be something else (probably 3, for four banks, or 4 for 16 banks).

As BGB says and as you experienced, a real Game Boy (and accurate emulators like BGB) don't care about that discrepancy, but it's another symptom of oyu not fully understanding the MBCs I think.

do I always need to use RAM banks, if I want to load tiles from banks?

No. Your understanding in the video is correct. The tile data is constant, and it's not loaded into RAM unless you load it into RAM yourself. You don't need RAM banks unless you need more RAM.

Last edited by tobiasvl (2018-02-13 04:08:26)

Welcome. Just a few quick answers to some of the questions:

GuybrushThreepwood wrote:

- do I always need to use RAM banks, if I want to load tiles from banks?

No, you don't. Generally, you will only need additional RAM banks if your game needs to keep track of a lot of variables that can change at runtime. You normally don't want to change tile data at runtime, so you should store it in the ROM.

As a rule of thumb, the Game Boy's built-in RAM is sufficient for most games. Additional RAM banks should only be required for very large and/or unusual projects. Additional ROM banks on the other hand will be required for any game that is larger than "very small".

GuybrushThreepwood wrote:

- can making tiles const keep them in rom only so I can load them?

Yes. As a general recommendation, you should declare all your tile data arrays as "const". They will then be stored in ROM. It is often said that GBDK has trouble with large arrays in RAM, so you should avoid these wherever possible.

GuybrushThreepwood wrote:

- why does my rom only have "bank0" and "bank2" in the BGB debugger? SHOULD there be a bank1... or nah?

As far as I remember, BGB's debugger only shows you the ROM banks that are currently switched in. What you see in the debugger depends on the precise moment in which you interrupt the program flow and open the debugger window. You seem to interrupt your game when bank 2 is switched in.

GuybrushThreepwood wrote:

- I'm not using #pragma bank="n" or NONBANKED/BANKED because I prefer to manually switch banks. These are all unnecessary, correct?

I made a game that manually switches banks in GBDK and never used any of these. So maybe they're useful, but they are certainly not necessary.

GuybrushThreepwood wrote:

- As Tobias pointed out, I was using SWITCH_ROM_MBC5(n) in code, but using -Wl-yt1 in the lcc flags. I thought the easiest solution would simply be to switch -Wl-yt1 to -Wl-yt5, so the banks match. Also, AFAIK MBC5 should support RAM and get rid of the error. But when I compile this, the error goes away but the rom is corrupt, why?

-Wl-yt5 means that you have an MBC2. What you probably need is -Wl-yt0x19 for an MBC5 with no additional RAM.

Take a look here to decode the meaning of the numbers.

GuybrushThreepwood wrote:

- why are RAM banks tied to ROM banks at compile-time? RAM generally doesn't seem to be linked like this elsewhere. Does this just mean that, variables defined in that bank's ROM will auto magically goto that banks RAM? Because as it stands, I am using ROM banks but not RAM banks, and stuff is just going to regular RAM. I am unclear on why ROM and RAM are linked at compile time, and how that RAM is defined or comes into play... How do I know what goes in which RAM? Can other ROM banks access other RAM banks?

You have to switch the RAM banks manually and separately from the ROM banks with the SWITCH_RAM_MBC5() instruction. But as long as you don't use additional RAM, you shouldn't need that...

Jonas wrote:

For additional RAM banks you need -Wl-yo and not -Wl-ya.

(You mean ROM)

And since you asked about this in the video: The RAM is dependent on (or associated with) the ROM in the way that when you're using the MBC5 controller you need to balance them. MBC5 gives you access to a lot of memory, but you have to tell the Game Boy if that memory is ROM or RAM (because on real hardware, that memory would literally be different kinds of physical memory).

The more ROM banks you use, the fewer RAM banks you can use, and vice versa. MBC5 gives you up to 8 MB of ROM (banked) or up to 128 kb of RAM, but not the max of both at the same time. Now, as far as I understand, GBDK sets this up for you so you don't have to deal with it. As I said I've never used GBDK so I'm not sure, but normally you'll have to set the correct values in the cartridge header to have the correct amount of ROM and RAM banks available; presumably that's what the linker flags do for you.

I didn't really understand what you were asking around 7:30 there, but no, one specific RAM bank does not have any relationship with the "corresponding" ROM bank. You can't move things directly between different RAM banks, that's true, but only because only one RAM bank can be switched in at the same time. You can move things between two RAM banks if you load stuff from one RAM bank into registers, switch banks, and then load it back into that RAM bank.

I'm not sure if that makes it clearer, or if you had already understood this concept, but that's how the ROM and RAM is interlinked. Since you don't need extra RAM for your game, you can just max the number of ROM banks and be done with it.

By the way, Greg, I just have to say that I was initially sceptical about the concept of posing your questions in video form instead of just asking directly and succintly in text, but it worked out really well! You're good at explaining and showing your problem visually.

Last edited by tobiasvl (2018-02-13 18:41:48)

More updates!

Things are still going smoothly, I got a few mile-stones accomplished tonight. Thankfully for your guys help I was able to get banking working with the correct flags, as I discussed in my previous video.

You can see my progress, and clarified WRAM questions, here:

https://www.youtube.com/watch?v=LGPkauq … e=youtu.be

But as I mentioned in the video, I'm still a bit confused on the RAM stuff.

As per ISSOtms post, I am now going to refer to RAM banks as WRAM banks, since I'm not talking about SRAM.

To recap questions from the video:

- how do you know "what" things go into a particular WRAM bank?
- are you always supposed to use explicit pointers for WRAM only?
- why are WRAM banks told to lcc with -Wf-ba<n> when compiling .c files to ROM banks?
- when switching a WRAM bank, what variables are you able to access and how do you know?

Thanks again for all your guys help, I'll keep posting as I make progress!

- Greg

Last edited by GuybrushThreepwood (2018-02-13 23:03:41)

ISSOtm wrote:

Let's clear something right away : there isn't "RAM" on the GB(C).

The console itself has built-in RAM, called WRAM.
A cartridge may have onboard RAM, called SRAM, since it's often used for saving data.

Honestly, I'm not sure whether that terminology is mandatory or generally accepted. It's not consistently used in the Game Boy Programming Manual (download the Holy Bible here). It also doesn't seem accurate to me since SRAM generally refers to "Static RAM" and the Game Boy Programming Manual states that the built-in working RAM of the Game Boy and Game Boy Color is SRAM (see pg. 10). So all the WRAM would be SRAM... But let's put that aside and use ISSOtm's terminology in the following, just to make sure that we're all talking about the same things.

In these terms, all I stated above refers to SRAM. I personally focus on the classic DMG Game Boy which doesn't allow switching WRAM banks. Therefore, I'm afraid can't really help with issues that are specific to the Game Boy Color.

How to use and switch SRAM banks is explained in the "banks.c" example that comes with GBDK. To put it in short terms, you first have to declare a variable in a .c file that is compiled with the -Wf-ba option (and the bank number you want to use). In your main file you declare the same variable as "extern". Finally you use the -Wl-ya option to link your files. You can then access the variable as long as the respective SRAM bank is switched in with the SWITCH_RAM_MBC5() instruction.

If you want to switch the WRAM banks of the Game Boy Color as you indicate in your last post, I can't help for the reasons mentioned above. But from my experience with GBDK, I'd rather doubt that it will do any of this for you automatically...

One last remark: Should you reach a point where you really need more than the 8kB of WRAM that are available without RAM bank switching on any of the Game Boy models, your project has probably grown to a size and degree of complexity that makes it sensible to start using assembly language. GBDK is fine for smaller games but if you want to use the full scope of the Game Boy's hardware capabilities, assembly is the way to go. How to switch the WRAM banks of Game Boy Color in assembly for example, is explained conveniently on just a half page of the document I linked above (see pg. 34).

I came accros that: https://videlais.com/2016/07/09/program … m-banking/
Maybe it can help