Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

#1 2018-02-12 21:01:42

GuybrushThreepwood
Member
From: NYC
Registered: 2018-02-12
Posts: 13

Intro Post / Banks Questions

Hey GBDev!, this is my first post.

Unfortunately, I have yet ANOTHER banks question... neutral but the good news is that I actually have banks working already (mostly), but still kinda confused about some things.

I decided to make my first post a video post, especially since I think it's easier to explain things like this in video form.

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

So, to recap from the video, a few questions I have:

- do I always need to use RAM banks, if I want to load tiles from banks?
- can making tiles const keep them in rom only so I can load them?
- why does BGB tell me "RAM size and cart type 'has RAM' do not match."?
- why does adding a third bank tell me  "ERROR: address overflow (addr 9601 >= 8000)" if the point of using banks is to re-use address space?
- why does my rom only have "bank0" and "bank2" in the BGB debugger? SHOULD there be a bank1... or nah?
- I'm not using #pragma bank="n" or NONBANKED/BANKED because I prefer to manually switch banks. These are all unnecessary, correct?

Anyway, thanks for your time, and I hope to get rolling again!

- Greg

Offline

 

#2 2018-02-13 03:45:10

tobiasvl
Member
From: Norway
Registered: 2017-10-19
Posts: 26

Re: Intro Post / Banks Questions

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)


Discord: tobiasvl#6844 | GitHub: tobiasvl

Offline

 

#3 2018-02-13 04:06:23

Robbi_Blechdose
Member
Registered: 2017-12-10
Posts: 29

Re: Intro Post / Banks Questions

Soo, first of all, may I recommend you use this GBDK: http://www.rrsd.com/software_developmen … velopment/
Its banking seems a bit less wonky than that of the old GBDK (probably 2.95/2.96?) you're using.
Anyway, as tobiasvl said, you need to use one MBC type, which is correct. There's a list somewhere that says what argument to give the compiler for MBC5. The cart header is generated by GBDK, as far as I can tell, which is why BGB gives you that error: Your MBC type you  gave the compiler does not have RAM, but you told it in a second argument to have RAM.
The address overflow is because (I think) you allocated less banks than you need.

As for the pragmas, I'd use them. They work pretty well, even better on the new GBDK (although they are "#pragma bank CODE_x" there).
On the old GBDK, you don't need to bankswitch at all by hand if you use the pragma (IIRC), on the new one, the pragma only works for functions, not for data. You need to bankswitch manually there (as in, SWITCH_ROM_MBC5(bank) before accessing the data).
In general, I think using the pragma is better than the compiler options (-Wf-bo), at least in my experience.

Offline

 

#4 2018-02-13 07:49:36

Jonas
Member
From: Frankfurt, Germany
Registered: 2016-06-06
Posts: 112
Website

Re: Intro Post / Banks Questions

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.

Offline

 

#5 2018-02-13 15:46:41

GuybrushThreepwood
Member
From: NYC
Registered: 2018-02-12
Posts: 13

Re: Intro Post / Banks Questions

Hey guys, thanks for the answers and feedback.

The good news is, I got it compiling with the third bank, so I can continue onward with development!

Of course, I still have some questions, so here's a follow up video with what I had to do to get it working, and what I still don't understand.

https://youtu.be/25LUxjg413o

To recap the questions in the video:

- 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?

- 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?

Thanks,

- Greg

Offline

 

#6 2018-02-13 17:03:26

Jonas
Member
From: Frankfurt, Germany
Registered: 2016-06-06
Posts: 112
Website

Re: Intro Post / Banks Questions

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...

Offline

 

#7 2018-02-13 17:29:00

Jonas
Member
From: Frankfurt, Germany
Registered: 2016-06-06
Posts: 112
Website

Re: Intro Post / Banks Questions

And by the way: If you don't use additional RAM banks, you shouldn't have a -Wl-ya statement in your compiler options. For additional ROM banks you need -Wl-yo and not -Wl-ya. Take a look here, in the "Multiple Bank Images" section (bullet point no. 6).

Last edited by Jonas (2018-02-13 18:10:35)

Offline

 

#8 2018-02-13 18:07:53

tobiasvl
Member
From: Norway
Registered: 2017-10-19
Posts: 26

Re: Intro Post / Banks Questions

Jonas wrote:

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

(You mean ROM)


Discord: tobiasvl#6844 | GitHub: tobiasvl

Offline

 

#9 2018-02-13 18:10:17

Jonas
Member
From: Frankfurt, Germany
Registered: 2016-06-06
Posts: 112
Website

Re: Intro Post / Banks Questions

tobiasvl wrote:

Jonas wrote:

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

(You mean ROM)

Correct. Sorry.

Offline

 

#10 2018-02-13 18:33:04

tobiasvl
Member
From: Norway
Registered: 2017-10-19
Posts: 26

Re: Intro Post / Banks Questions

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)


Discord: tobiasvl#6844 | GitHub: tobiasvl

Offline

 

#11 2018-02-13 19:17:16

ISSOtm
Member
From: Somewhere in Echo RAM
Registered: 2017-04-18
Posts: 160
Website

Re: Intro Post / Banks Questions

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.

Only the CGB has WRAM banks, and that's independent from the ROM.
Any cartridge may have SRAM (at all), or SRAM banks, but you have to define that.
Now, the question is whether what you are talking about is WRAM or SRAM ; thus, I recommend you re-state your trouble, but using either SRAM or WRAM, and not just RAM -- there's a lot of confusion in this thread.

(Also, I can't help with GBDK. Only ASM, sorry.)


The French Lord Of Laziness.
Legend of Zelda and Undertale fan, I also tend to break Pokémon R/B/Y a little too much.

Twitter | Me on GCL | Discord : ISSOtm#9015 | Skype : isso.tm (I don't login anymore)

Offline

 

#12 2018-02-13 23:03:01

GuybrushThreepwood
Member
From: NYC
Registered: 2018-02-12
Posts: 13

Re: Intro Post / Banks Questions

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)

Offline

 

#13 2018-02-14 04:05:51

ISSOtm
Member
From: Somewhere in Echo RAM
Registered: 2017-04-18
Posts: 160
Website

Re: Intro Post / Banks Questions

From what I know, you're not supposed to have to do that yourself, GBDK is supposed to, but hey, that's GBDK we're talking about...


The French Lord Of Laziness.
Legend of Zelda and Undertale fan, I also tend to break Pokémon R/B/Y a little too much.

Twitter | Me on GCL | Discord : ISSOtm#9015 | Skype : isso.tm (I don't login anymore)

Offline

 

#14 2018-02-14 07:51:09

Jonas
Member
From: Frankfurt, Germany
Registered: 2016-06-06
Posts: 112
Website

Re: Intro Post / Banks Questions

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).

Offline

 

#15 2018-02-14 17:43:43

GuybrushThreepwood
Member
From: NYC
Registered: 2018-02-12
Posts: 13

Re: Intro Post / Banks Questions

Jonas wrote:

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.

Ah, okay. I think I get it now. So, the variables you declare in the banks, that you use the -Wl-ba option will use that corresponding ram bank. Then you declare the variables as extern, but you must switch to the ram bank before accessing them, but you don't necessarily need to switch the rom bank. Got it.

Jonas wrote:

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).

Good to know. I've never written assembly before (well, I've hacked around on some games adding jumps and so fourth, but never written anything from scratch). So I have a general understanding of how it works.

I would like to learn one day, and after this game I might take the time to learn ASM and use CGB as my vehicle!

Offline

 

#16 2018-02-17 08:33:03

sofzilog
Member
From: Brussel
Registered: 2018-02-16
Posts: 10

Re: Intro Post / Banks Questions

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


If you are kind enough to answer me, lower your expectation because I suck at everything (^_^)

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson