Gameboy Tiles, How did they work?

[ShadowBlitz16]

I'm making a gb zelda game in gamemaker and wanted the engine to work similar to the gameboy game so I have a few questions.

1) how big were tile sheets in the game boy color?
2) did the gameboy color swap out tile sheets during runtime? if so did it swap the entire page of just a few tiles?
3) how did mini tiles and big tiles work? did they clip when they are drawn from a source outside the tilesheet or did they wrap around to the next tiles?

[FAST6191]

Had you asked for the GBA I have a bunch of stuff with nice worked examples (for a start http://www.coranac.com/tonc/text/video.htm which is not entirely irrelevant to the GB/GBC) but the GB/GBC had less homebrew interest and thus less of that sort of thing.
http://bgb.bircd.org/pandocs.htm#videodisplay / http://problemkaputt.de/pandocs.htm#videodisplay if you want the original does answer most of the questions you have, however the way you frame your questions makes me wonder if you are not more used to older and more limited systems. Later Nintendo handhelds went whole hog into this but generally things were dynamically loaded into VRAM (split between a BG and OAM/sprites) as necessary, the GB/GBC did have so called memory bank controllers (MBCs) but they were not as graphics focused as some of the stuff you might have read about for the NES and SNES. To that end I don't actually know the exception behaviours and if they are not in the pandocs I am going to have to do some research to find out but it likely not terribly relevant. Similarly if you can build a handler for it then you could probably have near infinite sizes for some of the things mentioned, the GBA did slightly more here (the zooming through space effect in the tetris advance menus being my usual go to example for something interesting).

[elmer]

however the way you frame your questions makes me wonder if you are not more used to older and more limited systems.

Me, too. I suspect that the OP really needs to do some more research about how the old systems actually worked.

He's learning/using terminology and expectations from modern hardware that has very, very different limitations (i.e. practically none).

It sounds like he's describing modern hardware drawing quads from a texture map, and that is totally different from how the old hardware worked, and the limitations that were inherent in the old tech.

Had you asked for the GBA I have a bunch of stuff with nice worked examples (for a start http://www.coranac.com/tonc/text/video.htm which is not entirely irrelevant to the GB/GBC) but the GB/GBC had less homebrew interest and thus less of that sort of thing.

The GBA (as a handheld SNES) is very similar to the GB/GBC in the basic concepts of how the screen display is processed by the VDC.

It's just that the GB/GBC uses a different and slower processor, much less RAM, and has a much more limited VDC.

So (IMHO), your examples might be useful to the OP in order for him to understand the basic concepts.

****************

But ... since I want to at least *try* to be helpful ... the simplest thing to say would be that you're limited to 256 8x8 tiles for backgrounds, and 40 8x16 sprites (the things that move).

Let's say that there's a maximum of 128 different sprite frames/tiles.

The graphics that are displayed by those tiles can be changed at runtime, but only appoximately 8 tiles chan be changed in every 1/60s.

The realities are a lot more complex than that, but if you could live within those limits, then you'd have a somewhat-accurate representation of a GB/GBC game.