Proposal for #169: Add TRSE, restructure, expand hardware, add links#102
Proposal for #169: Add TRSE, restructure, expand hardware, add links#102
Conversation
nummacway
commented
Feb 21, 2026
nummacway
commented
- Moved development platforms below their language because there's a maximum of two.
- Added TRSE, which is a niche option, but it's still an option that might be viable to some.
- Expanded hardware overview, particularily on PPU limitations, but also mentioned cartridge limitations.
- Consistently used binary prefixes.
- Added some more information and more links where appropriate.
- Fixed some typos (and probably added the same number of new ones).
- Game Boy is now running at 60 FPS instead of 6 FPS.
- Moved development platforms below their language because there's a maximum of two. - Added TRSE, which is a niche option, but it's still an option that might be viable to some. - Expanded hardware overview, particularily on PPU limitations, but also mentioned cartridge limitations. - Consistently used binary prefixes. - Added some more information and more links where appropriate. - Fixed some typos (and probably added the same number of new ones). - Game Boy is now running at 60 FPS instead of 6 FPS.
|
(Reopening this because the discussion on gb-asm-tutorial, to which the number in this PR is erroneously referring and where some additions were suggested, seems to be dead.) |
|
Maybe you'd like to give this a quick look @bbbbbr ? |
avivace
left a comment
avivace
left a comment
There was a problem hiding this comment.
Looks okay to me and feels like an overall improvement. I'd remove the Pascal part though
|
|
||
|
|
||
|
|
||
| ## Pascal |
There was a problem hiding this comment.
I don't think the Pascal option should be mentioned here. It's niche and this guide should remain focused on the more supported (and adequate) options. We can think about moving this to another article , for example and mention it in the awesome-gbdev list.
|
I may have a different outlook on the article and it's purpose than as discussed in Broadly, I guess my philosophy is toward keeping the article as a relatively simple overview and guide, and not try to duplicate too much that might be available elsewhere in gbdev's resources. To help people of all skill levels and knowledge choose suitable tools in a mostly approachable way. (I think it might even be slimmed down some, for example removing the "tips for better code, etc" section if there are equivalents that could be linked to elsewhere instead).
|
| The original Game Boy, codenamed the DMG, has a 1 MHz CPU \[the CPU is actually clocked at 4 MHz, but every instruction takes up a multiple of 4 clocks, so it's often simplified to a 1 MHz CPU\]. Given that an instruction takes approximately 2 to 3 cycles, this gives the CPU a capacity of 333,000~500,000 instructions per second. | ||
| Its LCD boasts 60 fps \[it's actually 59.73 fps\], which rounds up to between 50,000 and 80,000 instructions per frame. Suddenly not so much, eh? | ||
| It also has 8 kB of RAM, and 8 kB of video RAM ; a 160x144 px LCD (thus slightly wider than it's tall), 4 colors, and 4-channel audio. | ||
| The original Game Boy, codenamed the DMG (for Dot Matrix Game), has a 1 MiHz CPU \[the CPU is actually clocked at 4 MiHz, but every instruction takes up a multiple of 4 clocks, so it's often simplified to a 1 MiHz CPU\]. Most instructions take approximately 2 to 3 cycles, this gives the CPU a capacity of 333,000~500,000 instructions per second. |
There was a problem hiding this comment.
This seems to be a lot of technical information we're already providing in other places (such as Pan Docs, gb-asm-tutorial, etc) - not sure how beneficial is it here
| - Four colors per background palette, three per sprite palette | ||
| - One background palette and two object palettes (eight each on the CGB); one is assigned to every tile where it is used | ||
|
|
||
| Games are stored on cartridges. Originally limited to 32 KiB of ROM, several so-called [Memory Bank Controllers (MBCs)](https://gbdev.io/pandocs/MBCs.html) have boosted this to up to 8 MiB of ROM and added up to 128 KiB of cartridge RAM (also used for savegames). Since the CPU can only access a 16-bit address space (64 KiB), you can guess that more sophisticated games will have to use a lot of banking, so does making use of virtually any CGB feature. |
There was a problem hiding this comment.
Same as before, this seems like a general information paragraph that may overwhelm readers here , maybe an article/ passage in gb-asm-tutorial is more adequate?
|
|
||
| ### C | ||
| C will typically be used with the SDCC compiler and GBDK-2020 or ZGB, though it can also be used on its own without a framework or with a different compiler/dev kit (such as [z88dk](https://github.com/z88dk/)). | ||
| RGBDS is an actively maintained suite of programs that allow building a ROM using ASM (assembly). It contains three programs that perform different stages of the compilation, as well as a program that converts PNG images to the Game Boy's tile format. RGBDS is available for Linux, Windows and MacOS. There is also a [simple browser-based IDE](https://gbdev.io/rgbds-live/) (beta) for small ad-hoc projects. |
There was a problem hiding this comment.
Maybe here I'd like the main RGBDS site and remove the line about RGBDS-live (which is mentioned anyway on the homepage of RGBDS)
The gb-asm-tutorial also should be mentioned here
| * Provides a limited amount of built-in code and functionality (does not include a large API like GBDK-2020 does), most of which revolve around macros and calculating constants at assembly-time (rather than on the Game Boy). | ||
|
|
||
| ### [WLA-DX](https://github.com/vhelin/wla-dx) | ||
| WLA-DX is also sometimes used when writing in ASM, mostly due to its better struct support than RGBDS. |
| WLA-DX is also sometimes used when writing in ASM, mostly due to its better struct support than RGBDS. | ||
|
|
||
| # Development Platforms | ||
| While RGBDS is made specifically for the Game Boy, WLA-DX targets many retro consoles. This means that if you're reading the docs, many things will not apply to the Game Boy. |
| ### [WLA-DX](https://github.com/vhelin/wla-dx) with ASM | ||
| WLA-DX is also sometimes used when writing in ASM, mostly due to its better struct support than RGBDS. | ||
|
|
||
| * The SDCC C compiler won't always generate code that runs as fast as skilled, hand-optimized assembly. It has matured a lot in the 20 years since the original GBDK, but bugs still turns up on occasion. On a platform with a slow CPU such as the Game Boy this can be a factor. |
There was a problem hiding this comment.
| * The SDCC C compiler won't always generate code that runs as fast as skilled, hand-optimized assembly. It has matured a lot in the 20 years since the original GBDK, but bugs still turns up on occasion. On a platform with a slow CPU such as the Game Boy this can be a factor. | |
| * The SDCC C compiler won't always generate code that runs as fast as hand-optimized assembly. It has matured a lot in the 20 years since the original GBDK, but bugs still turns up on occasion. On a platform with a slow CPU such as the Game Boy this can be a factor. |
| - *RGBASM `-E` and RGBLINK `-n <symfile>`*<br> | ||
| When you load `ROM.gb` or `ROM.gbc` in BGB, it automatically loads (if it exists) the file `ROM.sym` in the same folder as the ROM. This adds symbols to the debugger, which - believe me - helps *a ton*. | ||
|
|
||
| You can find snippets for common problems in the [GB ASM Tutorial cheat sheet](https://gbdev.io/gb-asm-tutorial/cheatsheet.html) and over at [pret's ASM optimization guide](https://github.com/pret/pokecrystal/wiki/Optimizing-assembly-code). |
There was a problem hiding this comment.
I'd avoid having such specific links at this point, gb-asm-tutorial should be the 'entry' point. Then those links are there if necessary
3 participants
