Hacker News Reader

Comment by ilikehurdles | Hacker News Reader

I believe you mean 256kilobytes? Even at 90s handwritten assembly standards, 256 bytes seems too small for basic games.

This isn't a game rom, this is the boot rom, included on the cpu, that runs the boot logo / audio, and does some checks on the cartridge rom.

Ah, that makes way more sense.

A quick google turns up this disassembly of the ROM:

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

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

Most Game Boy games use a bank switching chip in the cartridge, so can be larger than the 32k slot in address space.

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

I'm guessing it's the ROM for the system. Poke various hardware bits, map the cartridge and jump to a certain address within it.

If memory serves, it also checksums the Gameboy logo-intro at the start of every game cartridge -- subjecting non-licensed game publishers to additional copyright claims.

>> If memory serves, it also checksums the Gameboy logo-intro at the start of every game cartridge -- subjecting non-licensed game publishers to additional copyright claims.

That is quite clever! Don't run without a valid logo, and therefore violate a trademark or copyright if your game is to run without permission. It's like DRM but enforced legally not technically.

It's clever, bur probably doesn't hold water legally, see https://en.wikipedia.org/wiki/Sega_v._Accolade

Seems like you could easily find some random garbage image that also happens to pass the checksum.

It doesn't actually checksum, but instead has a verbatim copy and does a memcmp over both.

It reads the image twice, once for the checksum test then again when actually displaying it - so it's even possible to show a different logo by replacing that data in-between

No, it's 256 bytes of platform boot ROM.

"Loaded 128x x 16 h => 2048 bits (256 words)"

The 256 bytes is the boot loader? You do not need much for that. Basically enough to init the cpu, setup a couple of interrupt tables, and kick it running. For example the 80s/90s version would be the first sector on a floppy that inits the OS. In addition to the BIOS setup that probably put the read of that floppy in motion.

If I remember my GB history right this was a DRM measure to stop companies from copying the rest of the game rom and it still work on the actual hardware. Most emulators did not really need it as they had basically figured out what that area was doing anyway. Think in the GBA they even had an animation in there (which you can tweak going by setting a few HW registers) and the ROMS checked to see if the screen memory was correct at startup.

Reply on news.ycombinator.com