A correction. We didn’t use graph paper for the art work. Maybe be very first artists did, but not any I know.
The tools were pretty good. Deluxe Animator II and Deluxe Paint - both for MS DOS - is what I used for all my console games - Game Gear, Game Boy, SNES etc.
> We didn’t use graph paper for the art work. Maybe be very first artists did, but not any I know.
I mean, whether or not pixel-paint software exists, graph paper, even today, is still great for sketching and ideating pixel art [and/or level designs, but I'll just say "pixel art" from here on.] If you try to come up with a design for a 8x8 or 16x16 sprite or icon by freehand sketching it, you'll probably come up with something that won't look legible at that size. Better if you have the constraints of the grid even in your sketchbook; and so, better if your sketchbook is graph paper. (In fact, I believe they've make special-purpose graph-paper sketchbooks for forever now, specifically for ideating cross-stitch and latch-hook art.)
We're really only just barely out of the era of ideating pixel art using physical media, with the advent in the last ten years of cheap tablets that can run pixel-painting software, that are light and convenient enough that an artist would prefer to lug them around in place of their sketchbook.
Of course, after the ideation process—once you've got a draft you like—you'd likely be using some kind of software (visual or not) to input it. Scanner tech, and downsampling algorithms, were both far too crap back then to rely on faithful digitization of "discrete" information like pixel-art pixels. (Unless you were using a special scanner, special software, and special constraints on your inking process. Remember Scantron sheets? A 1980s pixel-art scanner would require basically the same fraught workflow.)
But also, on the other side of the urban-legend scale (that the article thankfully doesn't repeat), no artist was ever having to do bit math to get packed words to type into a resource file. Programmers may have done that for first tests with crappy programmer-art, but even back then, comparative advantage was a thing, and any artists on a project weren't hired to be good at calculating on long strings of numbers.
Instead, from the very beginning of computers being hooked up to displays and having character/tile display modes with configurable character/tile memory, there were already "textual graphics" formats like NetPBM, where you could use a visual editor like DOS edit or Unix vi as your "pixel art editor." These files can then be compiled, resulting in the a C or ASM source file defining some constant as a uint8-array literal. (They weren't necessarily standardized; but it was very easy to reinvent these formats and their tooling, and many companies did in the process of producing early game software.)
There was pixel-paint software too, even in the early 80s... but it wasn't on every platform. And, since you were often stuck on the platform you were targeting, that was a problem. (You were fine when targeting closed platforms like the gameboy, because the SDK would usually be built for a workstation-class system; but when targeting your average 8-bit micro, this was often the case, and 8-bit micros had no niceties like "standardized floppy disk formats" or "networking standards" to transfer in data from your nice graphics workstation. If you want to write e.g. ZX Spectrum software, you write it on a ZX Spectrum—or one of its younger brothers, once those came out.)
But, no matter the platform, if it was display-oriented, you could pretty reliably get a visual text editor. (Even on the ZX Spectrum!) So writing textual "1"s and "0"s into text files was indeed a thing—for a while, at least.
Small world- I just finished watching this again today. I've been trying palette-cycling techniques with 32blit to see if I can learn the ropes and put together a half-decent tutorial. I've had these - http://www.effectgames.com/demos/canvascycle/ - up on my screen for the last few days. I managed to get - terrible - palette-cycled fire sprites working with smooting (which Joe calls "Blend Shift Cycling") and I think there are still some interesting interactions to be found between these classic techniques and modern hard/software.
It's really exciting to see renewed interest in these techniques and "8-bitish" games in general since it probably means we've chosen the right time to make our handheld.
The Gameboy has the advantage of a smaller display with fewer pixels (with less colordepth) to update. 16 bit pointers are also (relatively) easier to push around than 32 or 64 bit pointers.
I would wager that doesn't make up for how much slower the hardware is, though.
The 4MHz value is the clock speed, but all instructions take a multiple of 4 clock cycles to accomplish, so you often talk about it as a 1MHz "instruction cycle" machine.
The fastest memcpy implementation I've seen for it (not including in-hardware DMA features, which are only available for copying to OAM (sprite) RAM on the original gameboy) takes 4.5 cycles per byte (one 16-bit word every 9 cycles).
That means that if you were trying to update every pixel on the screen (which doesn't actually work - the GB's screen pixels aren't memory mapped directly but generally specified via a combination of up to 384 unique 8x8 tiles, which are then arranged on a 20x18 tile grid), which would be 160 * 144 * 2 bits/pixel = 5760 bytes, it would take 25920 instruction cycles ~= 24.72ms, which comes out to approx 40.45 FPS.
Of course, as I mentioned, the actual GB doesn't work like that, and has a Pixel Processing Unit that handles writing to screen every frame. While the PPU is writing to the screen, the CPU cannot access VRAM, which means that the CPU actually only gets what's called the v-blank period, which is only 1140 instruction cycles, which is only enough time to copy up to 254 bytes or so (I'm skipping over some detail here, like how you could squeeze a few extra bytes out by loading the first 4 or so bytes into registers before vblank begins, or how you can also (with very careful timing) write to VRAM during a ~60 cycle window on each line knowing as the h-blank and OAM search periods).
In practice, games work despite these limitations because they generally only have to modify a small amount of the screen in any one frame. Scrolling is implemented in hardware, and you can write new data off screen then scroll into it so you can take multiple frames to write it if needed.
This plus other tricks (for example, animating 50 copies of a common tile by editing the tile's pixel data, which affects every copy at once) let these games accomplish so much with so little.
It's impossible to compare to a modern sytsem with a polygon-based GPU, they're entirely different things.
The thing I love most about older computing technology is that it wasn't ridiculously over complicated yet. In order processors with fixed instruction sets, no MMUs, no caches, no 500 layers of abstraction between you and what you're actually trying to accomplish. You know, stuff you could form a solid mental model of and reason about. Part of me really wants to go back to that world, even if it does mean a huge loss of performance.
There are still some developers who work on microcontrollers and the like.
Also a lot of the embedded world still has MMUs and caches but there's not a whole lot of software between you and hardware.
I have a few problems with that, though. For one, I don't really care about the vast majority of projects that kind of stuff is used for, and for another they often have closed proprietary toolchains.
Yeah, see, that's a hold up for me. If I'm going to go through the effort of building something completely non-commercially viable than I want it to at least be completely open. And before you say anything, no, I'm not at all interested in making anything commercially viable.
Retro platforms were current technology. If I'm going to use technology with several orders of magnitude less power, then I'd at least like it to be open, is all I'm saying.
I agree, and is much of what I try to design by computer design (although there is ways to improve the performance (in different ways than what is common now; some of it is strange and may have some unusual (but still simple) features), and there is other improvements from the old designs too, while still having a lot of the features of the older designs). It doesn't use superscalar, out of order execution, automatic caching (there is a cache but it must be programmed explicitly, and otherwise it does nothing), and all of that mess.
Just the other day I was looking for a good NES IDE for my son who's interested in learning assembly and who has maxed out his PICO-8 skills. I think this would be a good way for kids to learn some niche skills like assembly that are still going to be needed in some careers but aren't as widespread as JavaScript or Python.
I feel like there's a lot of value in the whole "knowing how the sausage is actually made" thing. You'll still take collections and the garbage collector for granted 95% of the time, like everyone else, but at least you will have some sense what's going on under the hood if you've had to implement pieces of it manually somewhere along the line— and an actual working implementation, not just a toy one for some undergrad class.
Having done no CS in school and jumping right into python and JS, learning how the sausage was made was immensely satisfying. I wrote a CHIP-8 emulator in Python and then a Game Boy emulator in Rust. None of those skills have been practically useful but were very educational.
>None of those skills have been practically useful
Honestly you never know when something you are familiar with becomes important later.
Something that was important to get it done may not be as important in later tasks. (My Operating Systems Class at university was greatly useful in my first job, not as much after) My dabbling in JS got me job programming timecard apps for blackberries and changed my work trajectory.
This field changes so fast and you can't learn everything, so learning things you enjoy and help you get what you are working on now.
That and data-structures and databases, you can never know enough about both.
Unrelated question: what resources did you use to write your CHIP-8 emulator? I've also been wanting to write one in Python for educational purposes, but haven't found any great resources yet in Python. Granted there are a few in C that I could try to translate over, but I'm curious to know what you used.
I looked at the Wikipedia page and a couple PDFs from Google front page.
I stole a collection of games from someone else's project to use for testing.
My goal was to get in the door so I picked a language I knew well and set some constraints:
1. Doesn't have to be fast. Just has to run.
2. Write opcodes as pure functions, passing in an array of memory and returning a new array of memory. This made it easy to test and debug. But also made it super slow.
3. DO NOT look at someone else's code. This forced me down a way slower path where I learned a whole lot more than I would have if I just reimplemented others' work.
Fully agreed. Currently doing web dev as a daily job, and even most of my personal projects are all fairly high-level. However, I cannot under-appreciate how useful and eye-opening building my own CPU pipeline and learning assembly was back in college. Just the fact of understanding how it ALL works under the hood (even if it is just a simplified version of it) made me feel amazing and gave me a lot of insights I wouldn't have gotten otherwise.
I found https://8bitworkshop.com which seems to be just what we're looking for, but since it's a web app and we don't have internet at home, it's going to take some effort to get it working for him.
It's a huge time sink. We've gotten more done at home in the past 6 months since getting rid of TV and internet than we have in the past 6 years. And our family life is significantly more connected and alive than when we had TV and internet.
I heartily recommend everyone try it for a couple months. No TV, no mobile data plan, no home internet, no radio. It's amazingly refreshing.
Edit: another reason is that almost all social media is geared towards making you addicted to it and encourages hopelessness, and when you get rid of social media, not just deleting accounts but even to stop consuming it regularly, your attitude will just change for the better on a daily basis. Waking up will feel refreshing, not burdensome, like today is a new opportunity, not a new day of drudgery. Well, at least it will play a big part in this shift.
I'm a software consultant, but I can do most of my work offline. When I need internet for my work, I go to the local library during ordinary work hours (9-5pm) and use their free wifi. Most documentation that I need is available offline in Dash (or Zeal for Windows) and I can download that and whatever else I need while at the library. It's a lot easier than I thought it would be.
What I am interested in, though, are the public library board meetings that they hold monthly, open to the public. I can't imagine what kind of things they discuss, and I'm thinking of attending one just to find out.
What kind of consulting do you do, if I may ask? I assume something unrelated to web applications? Working on a web app with a thousand dependencies, even if working on the backend, would be terribly frustrating and almost impossible, I believe.
Mostly React.js and Node.js, and I use NPM to install dependencies while I'm at the internet, and they still work when I go offline since they're downloaded.
The hard part is dealing with live APIs, but fortunately these can be recorded while online and replayed when offline, which seems like a good practice anyway during development.
> The hard part is dealing with live APIs, but fortunately these can be recorded while online and replayed when offline, which seems like a good practice anyway during development.
Just record the important parts of an HTTP request using your server software, such as Node.js, save them to disk, and replay them on matching subsequent requests when offline mode is enabled. Or use a high level library that already does this; I'm looking into yakbak[0x00].
After reading the post a few days ago about the Playdate console and reading this post, it makes me wish there was a popular retro-style handheld console that I could develop for.
The difficulty in making retro style (programming) hardware is that any technique you use to use to make it nowadays could be trivially be boosted to be much more powerful, sufficiently powerful in fact you could probably just run a software emulator for the thing.
I'm going the route of others with making a fantasy console, and will be content to run it on mobile platforms in an emulator, which is what happens with the pico8.
That said, I do have a half baked idea in my head to make something from a AtMega and an ESP32. If the higher clockspeed of the esp32 is enough to make it pretend to be a valid xram interface for the AtMega. Then output s-video out the DACs.
Honestly, I can't recommend the GBASP enough. It's small, it has a lot of power for a handheld of that era (enough to pull off texture-mapped polygonal graphics at an acceptable frame rate) and the addressable ROM size is practically limitless, going all the way to 64 MB.
> I am considering teaching a university course where the students implement a NES or GB emulator though. Should be a blast!
I was considering doing the same for my Machine Language class, but it seems that many games rely on the precise timing of the emulation to work. And, because the output was an anolog TV, there are a lot of tricks that need to be figured out. I thought that was a no-go for a course.
yea, I posted with another suggestion on this thread, but the GBA itself is just such a dream machine. It's the sweet spot for retro programming in my mind. All the cool console features, streamlined hardware, simple interface. So good.
not popular I guess; it's not even out yet, but the Pimoroni people are doing a GBA-like handheld kickstarter geared towards developing, called 32blit. Doesn't have all the cool bitmap, sprite, etc hardware I'm sure, but they try and give a pretty integrated environment. Also maybe geared a bit more towards beginners, but I really like the idea. And because it's modern hardware, you can just use all your standard tools. It's also got hardware debugging, looks like.
I'm wondering if selling physical copies of the game doesn't come with legal issues...
The "Nintendo" logo you see when booting a Game Boy comes from the cartridge and is checked against one stored in the console.
If they don't match the whole thing stops, which means that you have to add (and distribute) a Nintendo logo to your game in order for it to work on real hardware.
I have not tested this particular game on real hardware, but multiple games found ways around the console's logo checksum. It has a buggy implementation that can be circumvented, allowing you to never have the logo on your cartridge.
For those interested in classic game dev, the guys at the Computerphile YT channel did a series with a guy that wrote a Genesis game a few years back using an original dev kit on a mid-90s PC.
Great read! I was active in the gb dev scene in the late 90s (hmu if you remember gbdev99 or the bunghk contests), and it's amazing to see so many of the names and libraries built so long ago still come up today. The Game Boy is still one of my favourite platforms today; such a great example of what you can accomplish with very limited resources if you have enough creativity. We've seen some of the best games of our generation come out on a battery-powered device with a CPU that can't even multiply.
My Nephews stole my Gameboys by borrowing them and never returning them. I still got a DS my son owns. But I had the Classic Game Boy, Game Boy translucent case, Color Game Boy yellow shell, Game Boy Advance SP. All gone now. They are collector's items now worth a lot.
I had an Atari Lynx but had to sell it because I needed the money. It was like the Game Boy but Atari and it had color graphics and slim cartridges.
I think Free Pascal or some other language can make console games by cross compiling.
Right now I have a Raspberry PI with RetroPI to play Gameboy games.
For anyone interest, I recommend watching "The Ultimate Game Boy Talk" [0] from 33c3, lots of interesting details about how a Game Boy works, including the PPU
That is what learning to compute all about. Since day one. What is the driver of internet. Or pdp machine. To play game developed and maintained by us and fellow hackers.
The tools were pretty good. Deluxe Animator II and Deluxe Paint - both for MS DOS - is what I used for all my console games - Game Gear, Game Boy, SNES etc.