4 ms·
A quick google turns up this disassembly of the ROM: https://gist.github.com/drhelius/6063288 https://gist.github.com/drhelius/6063288 You can see the comment
by hyperman1 4y ago
A quick google turns up this disassembly of the ROM:
https://gist.github.com/drhelius/6063288 https://gist.github.com/drhelius/6063288
You can see the comment of the last line is $00fe and the first line is $0000, so assuming the last instruction takes 2 bytes, that's 256 bytes.
Besides, it is a 16 bit machine, so it has 64K addressable space. Going above that requires bank switching. Here is the memory map:
https://gbdev.io/pandocs/Memory_Map.html https://gbdev.io/pandocs/Memory_Map.html
I see 32K cartridge ROM (at most), 8K work RAM (built in), 8K video RAM, and some memory mapped devices. At E000, almost 8K is actually wasted as an echo of another range.
As a kid, I once wrote a flame simulation in DOS. The resulting com file was about 100 bytes, so it was possible to write usable programs in <256 bytes. Presumably a very simple DOS text mode game might fit in 256 bytes
- fredoralive 4y agoMost Game Boy games use a bank switching chip in the cartridge, so can be larger than the 32k slot in address space.
- hyperman1 4y agoIf you browse a bit on the second link, it will give you a list of common cartridge models. See e.g. https://gbdev.io/pandocs/MBC5.html https://gbdev.io/pandocs/MBC5.html which gives you 8MB as peak ROM size, but it is all paged via the 2nd half of the cartridges address space, in blocks of 16K. Code used by the whole program preferably resides in the first (unbanked) 16K. This pushes program designs to prefer to either use banking mainly for data (maps/graphics/...), or split the program in independent 16K sized sub-programs that don't communicate too much. If code in bank A uses data from bank B, you'll have to switch back and forth a lot, mediated by unbanked code. You can go all the way, of course, but it is an annoying way to program.