Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing tools for Game Boy development

gbdev.io

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Choosing tools for Game Boy development

#21

Post by lostgame »

user-the-name wrote: post #7
klodolph wrote: post #6

If you are interested in retro game development, I highly recommend the Nintendo Game Boy or Game Boy Color as a development target. You can develop games with either Z80-ish (Sharp SM83) assembly or C. The system has most of the features of the NES, but has a ton of kinks worked… I like to think of it as a dream version of the NES.

It's really limited, though. Sometimes that is nice, but if you want a bit more of a comfortable environment, the GBA is wonderful . It's got a decently fast processor and enough RAM to not have to worry too much about it, and it's got some really interesting hardware that is easy to use but also allows lots of interesting trickery.

Oooh! I’d also love to recommend GBA homebrew development, especially if you’re a little wary of learning Assembler.

I had a fantastic time in high school, grade 11 or so (2005?) - playing with the homebrew development kit at the time…

The joy of GBA is a much broader palette - well - any colours whatsoever, if you’re just talking straight GB (no GBC) - and access to some fun hardware tricks like scaling, extra background layers; honestly - it’s like an SNES pro or something. I love it.

Also a shout out for DS homebrew. Hella fun.

Re: Choosing tools for Game Boy development

#22

Post by fartcannon »

svendahlstrand wrote: post #17

The official Game Boy Programming Manual [0] leaked and is available at the Internet Archive. It's a great resource. If you're just getting started with assembly and want to look at a short program, my maze generator [1] is available on GitHub with annotated source code. [0]: https://archive.org/details/GameBoyProgManVer1.1 [1]: https://github.com/svendahlstrand/10-print-game-boy

Delightful! Is it 6502?

Edit: It appears to be Z80. Have you done any NES ASM?

Re: Choosing tools for Game Boy development

#24

Post by PaulHoule »

Jensson wrote: post #19
jepler wrote: post #16

Earlier quoted context omitted.

It's good to distinguish between general-recursive and tail-recursive functions. Tail-recursive functions can be transformed into code that uses a bounded amount of stack (no more than a single call worth). The latter kind of functions could be used freely on systems where general recursion is forbidden, and sometimes are a clearer or more succinct way to specify the required behavior (and sometimes not) Some lisp-ad…

Tail recursions are just very badly documented while loops. In a while loop it is very clear if you use memory or not, in a tail recursion you have to inspect the code and realize if it is tail recursive or not, and if you do it wrongly you just accidentally used a lot of memory for the stack. And tail recursions doesn't do anything you can't do in a while loop, recursions only power is the power to use the stack, wi…

There are other sorts of data structures that interest me.

A number of my Arduino projects break down into definitive layers such as something that spools several threads of graphical data out of the program memory, processes it to make a line for a persistence of vision display, then either flushes pixel data via SPI to a lightstrip or sends the data via the serial line to my PC for testing.

If I recoded it in AVR8 assembly I would have no stack or reenterant or recursive subroutines. Everything would be allocated statically or would go in a register, depending on the graphic data you need a variable number of cursors allocated (like the way dimensions of arrays were set in the configuration of a FORTRAN program long ago.)

I haven't recoded it in assembly because I'm still thinking I might need to switch to a more capable board with a different CPU and the portability makes up for C being a very annoying language (e.g. the stack, calling conventions, and all of that is a problem instead of a solution for the programs I write)

(I think maybe... If performance isn't good enough I'll run a soft AVR8 inside an FPGA and offload the hard parts to the FPGA but that is going from the frying pan to the fire.)

Another alternative to the stack is the approach used by asyncio in Python and many similar frameworks where you maintain flat contexts of execution that can be managed at arms length by some kind of dispatcher but that are executed intimiately by coroutines.

Re: Choosing tools for Game Boy development

#25

Post by klodolph »

lostgame wrote: post #21
user-the-name wrote: post #7

Earlier quoted context omitted.

It's really limited, though. Sometimes that is nice, but if you want a bit more of a comfortable environment, the GBA is wonderful . It's got a decently fast processor and enough RAM to not have to worry too much about it, and it's got some really interesting hardware that is easy to use but also allows lots of interesting trickery.

Oooh! I’d also love to recommend GBA homebrew development, especially if you’re a little wary of learning Assembler. I had a fantastic time in high school, grade 11 or so (2005?) - playing with the homebrew development kit at the time… The joy of GBA is a much broader palette - well - any colours whatsoever, if you’re just talking straight GB (no GBC) - and access to some fun hardware tricks like scaling, extra backg…

It's like an SNES pro, with the caveat that the audio capabilities of the GBA are much less than the SNES.

That said, the audio capabilities on the SNES are difficult to use.

Re: Choosing tools for Game Boy development

#26

Post by kaoD »

fartcannon wrote: post #22
svendahlstrand wrote: post #17

The official Game Boy Programming Manual [0] leaked and is available at the Internet Archive. It's a great resource. If you're just getting started with assembly and want to look at a short program, my maze generator [1] is available on GitHub with annotated source code. [0]: https://archive.org/details/GameBoyProgManVer1.1 [1]: https://github.com/svendahlstrand/10-print-game-boy

Delightful! Is it 6502? Edit: It appears to be Z80. Have you done any NES ASM?

It's actually Z80-ish with some features missing and some new ones included. It's a Sharp LR35902 SoC with an SM83 core (not sure if it has been used in non-GB SoCs).

I can recommend The Ultimate Gameboy Talk for details on it (and much more).

https://m.youtube.com/watch?v=HyzD8pNlpwI

EDIT: I had the SoC and the core names the wrong way around. Thanks svendahlstrand.

Re: Choosing tools for Game Boy development

#27

Post by svendahlstrand »

kaoD wrote: post #26
fartcannon wrote: post #22

Earlier quoted context omitted.

Delightful! Is it 6502? Edit: It appears to be Z80. Have you done any NES ASM?

It's actually Z80-ish with some features missing and some new ones included. It's a Sharp LR35902 SoC with an SM83 core (not sure if it has been used in non-GB SoCs). I can recommend The Ultimate Gameboy Talk for details on it (and much more). https://m.youtube.com/watch?v=HyzD8pNlpwI EDIT: I had the SoC and the core names the wrong way around. Thanks svendahlstrand.

I believe the LR35902 SoC is exclusive for the Game Boy, but the actual CPU core, SM83, is probably used elsewhere. Sharp's datasheets [2] mention home appliances as intended application.

[2]: https://duckduckgo.com/?q=sharp+sm83+datasheet

Re: Choosing tools for Game Boy development

#28

Post by svendahlstrand »

fartcannon wrote: post #22
svendahlstrand wrote: post #17

The official Game Boy Programming Manual [0] leaked and is available at the Internet Archive. It's a great resource. If you're just getting started with assembly and want to look at a short program, my maze generator [1] is available on GitHub with annotated source code. [0]: https://archive.org/details/GameBoyProgManVer1.1 [1]: https://github.com/svendahlstrand/10-print-game-boy

Delightful! Is it 6502? Edit: It appears to be Z80. Have you done any NES ASM?

Yes, I've dabbled around with the NES as well. But the Game Boy is close to my heart as I had one as a kid. So most of my projects [3] revolve around that old gray brick.

[3]: https://hackaday.io/project/167042-joy-boy

Re: Choosing tools for Game Boy development

#29

Post by bbbbbr »

pkdpic wrote: post #3

Recently got an EZ Flash Jr to get into playing homebrew gameboy games on my (unmodded) GB pocket from middleschool. Itch.io has more fun GB games than i'll ever have time to play and its felt like a really positive community. https://itch.io/search?q=gameboy Then while bored in a meeting at work I started looking into coding a hello world for it and quickly found my way to some Assembly tutorials which Ive never had…

Great recommendations.

In order to filter out "Game Boy-like" material on itch.io, you can also use the tag "gamboy-rom". Then it should only show you entries that will run on actual hardware (such as a flash cart or in an emulator):

https://itch.io/games/tag-gameboy-rom

As for advice on starting: a great thing to do is figure out a simple, small project to start with, and dive in. That will help give you concrete tasks to focus your learning of the hardware and dev tools around, and keeping the scope modest will prevent it from being overwhelming. There are a handful of tutorials if you want to try that route, and plenty of support (forums & discord).

Agreed too, Game Boy development has been exploding in the last couple years. GBStudio's arrival really brought making GB games within reach of a much larger pool of people. The ability to make them was no longer limited only those able to write software (or those working with them). This brought in a TON of graphics, music, storytelling and creative talent.

Re: Choosing tools for Game Boy development

#30

Post by bbbbbr »

hugo82 wrote: post #11

I wonder if we could have a web based GameBoy editor, like the Pebble had. Just write code on the site and have it compiled and pushed out at the click of a button? GB Studio seems to have some of that. Maybe just a little more magic to get it there?

RGBDS-live may be just what you had in mind. I can't remember exactly, but there may have been some experiments with a SDCC based C version of that as well. https://daid.github.io/rgbds-live/

Source: https://github.com/daid/rgbds-live

There was also a precursor to GB Studio which seemed headed in that direction. It was written by the same person who did GBStudio: https://www.chrismaltby.com/projects/gbdkjs

Post reply on HN