Back in 2006 I heard about the Atari 2600 homebrew scene and was fascinated to read about the mind-boggling tricks required to write a game for the system (like, coding to the TV raster beam... madness!). I went down the rabbit hole for a while and learned 6502 asm, and ended up with this "sort of a game" - https://github.com/mrspeaker/plops.
It was a great learning experience and certainly made me respect the devs of the day - who were performing miracles given the hardware constraints, and luck of modern debugging tools!
I've been into the 2600 homebrew scene since "Making Games for the Atari 2600" came out a few years ago. I haven't made anything useful yet, but the community is great and very active. There's an awesome twitch channel[1] dedicated to 2600 homebrew, ZeroPageHomebrew. They do 2 shows a week, ~2 hours each. The developers and various AtariAge people are usually active in the chat. They're doing an awards show in February for homebrews made last year.
I actually just finished reading "Making 8-Bit Arcade Games in C" in its entirety.
It definitely has a target audience:
Those who know how to program in a language resembling C, who don't know assembler, don't care to learn assembler, but can understand basic syntax of assembler. And most importantly it is for people who want to gain an understanding of the internal hardware of some vintage arcade machines.
I was surprised to learn that Robotron doesn't use sprites.
C? Pascal, maybe, Cobol, Fortran, and even some oddballs like Forth, but C didn't catch traction until the mid-80s. I remember Chuck Sommerville (author of the original Snake Byte) and his father describing this "new language" (C) which has all the speed of assembly but is much friendlier.
Applesoft Basic and 6502 ASM (thanks to the Lazer Systems Interactive Assembler -LISA) were tops in those days.
Maybe this will finally satisfy the people who balk when they see chip-8 pico-8 etc. described as 8-bit. This looks REALLY cool. I would love to see something similar for 16-bit/68000 console/arcade machines.
Sweet! I love that, 30-odd-years-later, I'm actually programming for the NES and can flash my own carts. What a piece of hardware that console was. To be able to pass on this knowledge in an easy-to-digest format is really cool. Kudos to the authors!
This reminded me of an interesting gent I met at last summer's San Mateo Maker Faire. He was showing off how he'd designed a Sinclair Z80 computer running on a FPGA.
Sadly I misplaced his info and can't find any info on the interweb.
8 bit games show what is possible when hard constraints are imposed on programmers. They did so much with so little. There's a great documentary about game audio, called "beep!" [1], where musician-programmers share stories about how they were given the absolute bare minimum memory to create sound effects and music. It's inspiring to hear what they managed to create.
This is a really neat project, I look forward to diving into it deeper.
Within the last week or two, I've (re)discovered the Game Boy homebrew scene, which seems to still be rather active. It's still quite Greek to me, but I've been attempting to learn how to make games in GBz80 assembly.
I sold my first program aged 15 back in 1981. It was a version of Space Invaders for the minimum-spec Acorn Atom squeezed into 512 bytes.
That kind of experience doesn't really go away, I still try and first find a clean minimal code before "expanding" the code to make it more easily maintainable.
By selling them to Computer Games companies who would mass produce them for sale via magazines or alongside computers in the early computer stores. In this case I remember the company was called "Bug-Byte".
The timing of this is superb - I literally just ordered an IceStick FPGA with the intention of recreating an 8-bit gaming platform, and I was wondering if I could somehow start playing in a virtual environment first! Can't wait to try this out...
It was a great learning experience and certainly made me respect the devs of the day - who were performing miracles given the hardware constraints, and luck of modern debugging tools!