Gameboy Development Forum

bbbbbr · 2020-10-08 17:20:07

UPDATE: See below about new version that performs a per ROM/RAM bank actual calculation with merged areas/etc.

I converted my shell script for estimating Game Boy ROM bank usage to a small, portable C command line utility.

Runs on Linux and Windows.

You can find it here:
https://github.com/bbbbbr/romusage/

Caveat: Usage estimates are for a given Area only. It **does not** factor in whether multiple areas share the same bank (such as HOME, CODE, GS_INIT, etc). That should be do-able, but is not a priority right now.

For example:

Code:

romusage gbdk/examples/gb/new_banks.map

Area        Addr                Size       
-----       -----------------   -----------
_BASE          1287 ->   20f2    3692 bytes
_BSS           c0b6 ->   c105      80 bytes
_CODE           200 ->   111a    3867 bytes
_CODE_1       14000 ->  14012      19 bytes
_CODE_2       24000 ->  24012      19 bytes
_DATA          c0a0 ->   c0b5      22 bytes
_DATA_1       1a000 ->  1a015      22 bytes
_DATA_2       2a000 ->  2a01b      28 bytes
_GSINIT        20f3 ->   219c     170 bytes
_GSINITTAIL    219d ->   219d       1 bytes
_HOME          111b ->   1286     364 bytes
_HRAM10           0 ->      0       1 bytes

Edit: fix project url, update title

Last edited by bbbbbr (2020-11-19 19:59:06)

toxa · 2020-10-10 07:47:25

more interesting is to determine how much rom or ram is free. from the last address occupied to the end of the bank.

bbbbbr · 2020-10-10 14:07:37

toxa wrote:
more interesting is to determine how much rom or ram is free. from the last address occupied to the end of the bank.

Yeah, that is available as an option for CODE* (-u16k or -u32k). I haven't added it for RAM. Since it doesn't yet try to merge Areas that share the same bank it's not fully accurate, though it is still useful.

https://github.com/bbbbbr/romusage/

Code:

$ romusage.exe /ReleaseColor/Petris.map -u32k
Area        Addr                Size         Used  Remains
-----       -----------------   -----------  ----  -------
_BASE          6d4f ->   6ff1     675 bytes
_BSS           d725 ->   d765      65 bytes
_CODE           200 ->   6c61   27234 bytes  %83    5533
_DATA          c0a0 ->   d724    5765 bytes
_GSINIT        6ff2 ->   71ea     505 bytes
_GSINITTAIL    71eb ->   71eb       1 bytes
_HOME          6c62 ->   6d4e     237 bytes
_HRAM10           0 ->      0       1 bytes

Last edited by bbbbbr (2020-10-10 14:08:18)

bbbbbr · 2020-10-12 01:36:59

I've built an improved version that is more accurate.

It produces a trimmed, sorted output of ROM/RAM banks, their usage and optionally the Areas located in them. The usage calculation will attempt to merge overlapping areas within the same bank to avoid counting shared space multiple times (such as HEADER areas).

If you use it and find any errors, let me know!

Some example output:

Code:

$ romusage.exe /ReleaseColor/Petris.map -u32k

Bank             Range               Size    Used  Used%    Free  Free%
----------       ----------------   -----   -----  -----   -----  -----
ROM              0x0000 -> 0x3FFF   16384   15989    97%     395     2%
ROM_0            0x4000 -> 0x7FFF   16384   12780    78%    3604    21%
WRAM             0xC000 -> 0xCFFF    4096    3936    96%     160     3%
WRAM_1_0         0xD000 -> 0xDFFF    4096    1893    46%    2203    53%

And another example, with display of areas in the banks enabled:

Code:

romusage gbdk/examples/gb/new_banks.map -a

Bank             Range               Size    Used  Used%    Free  Free%
----------       ----------------   -----   -----  -----   -----  -----
ROM              0x0000 -> 0x3FFF   16384    8211    50%    8173    49%
│
└─_CODE          0x0200 -> 0x111A    3867
└─_HOME          0x111B -> 0x1286     364
└─_BASE          0x1287 -> 0x20F2    3692
└─_GSINIT        0x20F3 -> 0x219C     170
└─_GSINITTAIL    0x219D -> 0x219D       1

ROM_1            0x4000 -> 0x7FFF   16384      19     0%   16365    99%
│
└─_CODE_1        0x4000 -> 0x4012      19

ROM_2            0x4000 -> 0x7FFF   16384      19     0%   16365    99%
│
└─_CODE_2        0x4000 -> 0x4012      19

XRAM_1           0xA000 -> 0xBFFF    8192      22     0%    8170    99%
│
└─_DATA_1        0xA000 -> 0xA015      22

XRAM_2           0xA000 -> 0xBFFF    8192      28     0%    8164    99%
│
└─_DATA_2        0xA000 -> 0xA01B      28

WRAM             0xC000 -> 0xCFFF    4096     102     2%    3994    97%
│
└─_DATA          0xC0A0 -> 0xC0B5      22
└─_BSS           0xC0B6 -> 0xC105      80

toxa · 2020-10-12 06:21:56

i suggest you to use *.noi instead of *.map

bbbbbr · 2020-10-13 17:36:06

Added support for .noi files.
Also added manually specifying ranges via arguments (such as Shadow OAM and the Stack, and to optionally warn if they overlap with others).

toxa · 2020-10-14 11:07:09

you cant check that something gets overwritten by stack, because it grows down from that .STACK address and has unpredictable size (at compile time, i mean) so you actually might get troubles long before it gets overlapped with something at compile time.

Last edited by toxa (2020-10-14 11:07:53)

bbbbbr · 2020-10-16 17:25:53

The command line arguments allow you to specify base addresses along with ranges. So while you can't check for all scenarios, it's possible to cover a usage case that might be expected (or more than expected) and then to check whether there might be conflicts with that.

It isn't meant to be perfect, just some improved checking (over none).

bbbbbr · 2020-10-19 01:05:11

OK, the feature bloat should now be complete for a while: optional small and large graphs have been added.

For example:

Code:

$ romusage.exe /ReleaseColor/Petris.map -g -e:STACK:DEFF:100 -e:SHADOW_OAM:C000:A0

Bank           Range             Size   Used   Used%   Free  Free%
----------     ----------------  -----  -----  -----  -----  -----
ROM            0x0000 -> 0x3FFF  16384  15989   97%     395     2% |-###########################|
ROM_0          0x4000 -> 0x7FFF  16384  12843   78%    3541    21% |#####################-......|
WRAM           0xC000 -> 0xCFFF   4096   4096  100%       0     0% |############################|
WRAM_1_0       0xD000 -> 0xDFFF   4096   2150   52%    1946    47% |#############.............-#|

And, a subset of the output for large graphs: (16 bytes per character)

Code:

Start: WRAM    0xC000 -> 0xCFFF
################################################################
################################################################
################################################################
################################################################
End: WRAM


Start: WRAM_1_0  0xD000 -> 0xDFFF
################################################################
######################################################-.........
................................................................
................................................################
End: WRAM_1_0

bbbbbr · 2020-11-13 16:42:19

The tool now supports IHX files in addition to .map and .noi.

It also has a quiet mode (-q) that just reports errors and warnings, and can return an error on exit (-R) if any are present. This allows it to be used as part of the build process if you want.

Code:

romusage banks.map -R -q

* WARNING: Area _DATA    at  c0a0 -> 115a4 extends past end of address space at  ffff (Underflow error by 5541 bytes)
* WARNING: Area _DATA    at  c0a0 -> 115a4 extends past end of memory region at  dfff (Overflow by 13733 bytes)
* WARNING: Area _CODE_1  at 14000 -> 1c023 extends past end of memory region at 17fff (Overflow by 16420 bytes)
* WARNING: Area _CODE_12 at c4000 -> c801f extends past end of memory region at c7fff (Overflow by 32 bytes)

GBDK 2020 is getting a tool (ihxcheck) that can test for multiple writes in the ihx ROM output file, but that cannot always detect overflows in ROM and cannot detect any in RAM. The SDCC toolchain will not currently warn if ROM or RAM is over-committed for the GameBoy.

Last edited by bbbbbr (2020-11-13 16:44:14)

bbbbbr · 2020-11-19 20:01:30

Small update - added RGBDS map file support.
https://github.com/bbbbbr/romusage

Format detection between GBDK/SDCC vs RGBDS should be automatic.

Didn't do a lot of testing, so if you use it and there are errors then let me know!

Gameboy Development Forum

#1 2020-10-08 17:20:07

Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

Code:

#2 2020-10-10 07:47:25

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

#3 2020-10-10 14:07:37

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

toxa wrote:

Code:

#4 2020-10-12 01:36:59

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

Code:

Code:

#5 2020-10-12 06:21:56

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

#6 2020-10-13 17:36:06

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

#7 2020-10-14 11:07:09

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

#8 2020-10-16 17:25:53

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

#9 2020-10-19 01:05:11

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

Code:

Code:

#10 2020-11-13 16:42:19

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

Code:

#11 2020-11-19 20:01:30

Re: Tool to estimate usage/free space of ROM/RAM banks for GBDK and RGBDS

Board footer