Forums

If in assembly, I’d guess it would be on the order of 100 cycles extra. I wouldn’t worry too much about it unless somehow you do it in a “hot” code path, eg calling a paged function once for a very byte of VRAM to clear it, which would of course be madness.

You might also add that banking code is a non-issue for a majority of projects, as you will have a hard time filling up the freely accessible 32K with code.

Unless you’re making a game of epic proportions with many bespoke parts or for some reason you clog up your lower banks with art and sound assets, you shouldn’t need to worry about banked pieces of code.

pw wrote

Is there a large performance hit when calling a banked function?

native SDCC trampoline functions are not very efficient, they imply use of system dependent bank switching functions like:

get_bank:: ; get current code bank num into A
ld a,(#0xfffe) ; (read current page from mapper)
ret
set_bank:: ; set current code bank num to A
ld (#0xfffe),a ; (restore caller page)
ret

it is possible to write own trampoline functions as, for example, made in the SMS/GG library port of the GBDK-2020.

So:
1. yes, there is a performance hit.
2. It depend on how frequently you call banked functions.
3. situation may be improved on the library side
4. situation may be even more improved on the SDCC codegen side (push word instead of byte to stack, as made in the GB port).

Kagesan wrote

You might also add that banking code is a non-issue for a majority of projects, as you will have a hard time filling up the freely accessible 32K with code.

My very first game coded entirely in C fills the 32 KB and I had to optimize several times to not go beyond it. It was actually a bit constraining.

But this is an adventure game with quite a bit of content. Of course things can always be handled differently to gain space, but when you have tenths of events that are all specific in how the text is displayed (depending on adventure switches), making something "generic" is not always possible.

I have started my next project and being able to bank code is a relief honestly. I am currently working out the best way to handle maps, transitions between screens and teleporters with a "generic" approach. This is not trivial actually, as there are many possibilities. I would be curious to see how SEGA managed this for a game such as Phantasy Star II for example, that has a lot of map, all different sizes, containing tons of teleporters and exits to the borders.

cireza wrote

But this is an adventure game with quite a bit of content. Of course things can always be handled differently to gain space, but when you have tenths of events that are all specific in how the text is displayed (depending on adventure switches), making something "generic" is not always possible.

That does fit the description of a "game of epic proportions with many bespoke parts" quite nicely, doesn’t it? ;)

Anyway, I’m in no way against banked code. It can be very useful, obviously. I just think it’s not exactly the first thing someone who’s just starting out with SMS development needs to worry about.

... an obvious yet invaluable advice based on experience....

If you keep the functions which use/call/decompress into memory banked assets in the bank 0 or 1..... you Will avoid a bunch of headaches.

But 32kb, even after including the libs, is many space!

Kagesan wrote

"game of epic proportions with many bespoke parts" quite nicely, doesn’t it? ;)

It is not as large as a full fledged RPG like Phantasy Star though. But I was certainly not meaning to contradict you :)

I was simply surprised that I reached that quickly this 32 KB limit because I thought my game was quite reasonable in its initial ambitions.

For a very first project, it definitely sounds reasonable to leave code banking aside and make something that fits into 32 KB. This was personal conclusion upon starting my first game, and I would recommend this to anybody making a first project for sure. Especially if this is an assembly project, because I suspect that working in C generates a lot more code.

No suspicion, it's a fact ;)

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Sep 07, 2023 8:31 am
	If in assembly, I’d guess it would be on the order of 100 cycles extra. I wouldn’t worry too much about it unless somehow you do it in a “hot” code path, eg calling a paged function once for a very byte of VRAM to clear it, which would of course be madness.

Kagesan Joined: 01 Feb 2014 Posts: 878	Posted: Thu Sep 07, 2023 1:05 pm
Kagesan Joined: 01 Feb 2014 Posts: 878	You might also add that banking code is a non-issue for a majority of projects, as you will have a hard time filling up the freely accessible 32K with code. Unless you’re making a game of epic proportions with many bespoke parts or for some reason you clog up your lower banks with art and sound assets, you shouldn’t need to worry about banked pieces of code.

toxa Joined: 09 Aug 2021 Posts: 131	Posted: Thu Sep 07, 2023 1:52 pm
toxa Joined: 09 Aug 2021 Posts: 131	pw wrote Is there a large performance hit when calling a banked function? native SDCC trampoline functions are not very efficient, they imply use of system dependent bank switching functions like: get_bank:: ; get current code bank num into A ld a,(#0xfffe) ; (read current page from mapper) ret set_bank:: ; set current code bank num to A ld (#0xfffe),a ; (restore caller page) ret it is possible to write own trampoline functions as, for example, made in the SMS/GG library port of the GBDK-2020. So: 1. yes, there is a performance hit. 2. It depend on how frequently you call banked functions. 3. situation may be improved on the library side 4. situation may be even more improved on the SDCC codegen side (push word instead of byte to stack, as made in the GB port).

cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Posted: Thu Sep 07, 2023 6:52 pm
cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Kagesan wrote You might also add that banking code is a non-issue for a majority of projects, as you will have a hard time filling up the freely accessible 32K with code. My very first game coded entirely in C fills the 32 KB and I had to optimize several times to not go beyond it. It was actually a bit constraining. But this is an adventure game with quite a bit of content. Of course things can always be handled differently to gain space, but when you have tenths of events that are all specific in how the text is displayed (depending on adventure switches), making something "generic" is not always possible. I have started my next project and being able to bank code is a relief honestly. I am currently working out the best way to handle maps, transitions between screens and teleporters with a "generic" approach. This is not trivial actually, as there are many possibilities. I would be curious to see how SEGA managed this for a game such as Phantasy Star II for example, that has a lot of map, all different sizes, containing tons of teleporters and exits to the borders.

Kagesan Joined: 01 Feb 2014 Posts: 878	Posted: Fri Sep 08, 2023 7:00 am
Kagesan Joined: 01 Feb 2014 Posts: 878	cireza wrote But this is an adventure game with quite a bit of content. Of course things can always be handled differently to gain space, but when you have tenths of events that are all specific in how the text is displayed (depending on adventure switches), making something "generic" is not always possible. That does fit the description of a "game of epic proportions with many bespoke parts" quite nicely, doesn’t it? ;) Anyway, I’m in no way against banked code. It can be very useful, obviously. I just think it’s not exactly the first thing someone who’s just starting out with SMS development needs to worry about.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Fri Sep 08, 2023 8:32 am
	... an obvious yet invaluable advice based on experience.... If you keep the functions which use/call/decompress into memory banked assets in the bank 0 or 1..... you Will avoid a bunch of headaches. But 32kb, even after including the libs, is many space!

cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Posted: Fri Sep 08, 2023 4:19 pm
cireza Joined: 27 Feb 2023 Posts: 136 Location: France	Kagesan wrote "game of epic proportions with many bespoke parts" quite nicely, doesn’t it? ;) It is not as large as a full fledged RPG like Phantasy Star though. But I was certainly not meaning to contradict you :) I was simply surprised that I reached that quickly this 32 KB limit because I thought my game was quite reasonable in its initial ambitions. For a very first project, it definitely sounds reasonable to leave code banking aside and make something that fits into 32 KB. This was personal conclusion upon starting my first game, and I would recommend this to anybody making a first project for sure. Especially if this is an assembly project, because I suspect that working in C generates a lot more code.

ichigobankai Joined: 04 Jul 2010 Posts: 542 Location: Angers, France	Posted: Fri Sep 08, 2023 5:44 pm
	No suspicion, it's a fact ;)

Forums

View topic - devkitSMS banking code questions