My parents never let me have video games growing up because they thought it would be a waste of time. They let me get a gameboy for some reason though, I guess cause they couldn't imagine someone wanting to stare at a 2x2 black and white screen for any length of time. Even when my friends got n64s, we spent most time playing Pokémon or Zelda on game boy, because the games were just so good
I recently downloaded roller coaster tycoon for my gf, as we both used to play it when we were younger. She doesn't really play games, but during our 4th date at an amusement park we found out we both played it as children. That game was written in assembly by one person
Not really a point here, other than that nostalgia and craftsmanship can be far more powerful than the latest hardware or software
>craftsmanship can be far more powerful than the latest hardware or software
I was just listening to the original Warcraft soundtrack for nostalgia's sake and the Youtube video had scrolled through some of the old artwork. It brought back memories of playing at my friend's house when we were kids. The game also had such nice craftsmanship--the artwork, character and themes. It reminded me of what those old games on small budgets were able to do. Something about that seems missing in today's big gaming titles.
While reading the articles over at Filfre, i ran into a quote from an early Lucasarts adventure games guy lamenting that the computer games industry had a bad habit of rebooting itself each time some new hardware was released.
Meaning that if you went from say grayscale only graphics to color graphics, for years afterwards the industry would produce glossy but shallow games. This because the game devs were more focused on showing off how far they could push their new toys than making engaging games.
And with Nvidia pushing out a new GPU seemingly every quarter, i wonder if this has lead us into a kind of "eternal september" type scenario regarding games development.
That said, there are a number of good indie games bouncing around Steam these days. Many of them taking design cues from the NES era of gaming.
> Not really a point here, other than that nostalgia and craftsmanship can be far more powerful than the latest hardware or software
A friend just bought me an xbox controller (to use with my PC) as an early christmas present. I've been replaying Final Fantasy 7 which I briefly tried with mouse/kb but was miserable.
I'm literally blown away by how much there is in this game. I've been playing for 30 hours, am nominally on disc 2. The storyline is cool, the characters are a bit one dimensional in places but I still care about them. The cleverness in what they achieved with what they had (interspersed FMV and game, clever environments, all backed by pretty drawings and really good music) is just kinda magical.
I'm loving it as much this time as I vaguely remember loving it the first time - UI warts and all.
The hardware may seem very limiting but in fact you can often exploit the limitations to achieve even better effects --- for example, the LCD's relatively slow refresh rate means you can do temporal dithering to go beyond 2 bits of grayscale, and I believe modifying the GPU registers multiple times per frame, while it's drawing, is another relatively common trick.
You can look at some of the GameBoy demos from the demoscene to get an idea of what others have been able to get from the hardware:
One very common effect is to change the x offset of the background mid-frame to create parallax effects. The introduction to Link's Awakening does that for instance: https://youtu.be/qoj8F0ymwpI?t=23s
It looks like you have multiple layers in the background moving at different speeds but of course on the GB you only have one background layer so it's just the game modifying the offset when it reaches certain lines.
To help with that the console lets you configure an interruption when the GPU reaches a certain line so you don't have to poll the line register or use an external timer.
Showing that the design of the GB dates back to the time of the NES and C64. The tight coupling between the CPU and the CRT beam meant that you had similar interrupts there.
And as those systems supported color displays (in a limited fashion), it was used for things like swapping palettes mid draw.
While it takes whole different level of effort to do so, it is quite impressive what can be done on limited hardware when one do not have multiple layers of abstractions on top.
Just about every architecture works like this because ultimately to drive a screen you need to send display data down the wire in order.
Modern systems are so capable that using raster interrupts wouldn’t add anything but if you change the display without Vsync you can see that it still works by scanning lines.
All the (uncompressed) video protocols still work like in the good old time of CRTs, you have the notion of horizontal and vertical blanking. Image is sent top to bottom, left to right (well, progressive video is, but let's not get into interlacing).
Actually in many protocols you have to keep the blanking periods because people crammed tons of things in them over the years (audio, subtitles, timecode, remote control protocols, various metadata...).
Having random access to the pixels would be beneficial if you only wanted to only update specific portions of the screen but you have to know which parts of the screen have to be updated (either by diffing each frame with the previous or by being tightly coupled with the drawing code and know which parts have been updated). However in very dynamic content like movies or video games you'll often end up having the entire screen changing at once so you'll have to be able to support that anyway and the additional complexity of optimizing for the simpler cases is probably not worth it.
What features would that add? The only one I can think of is saving energy for static content, but you can mostly achieve that by varying the refresh rate and most of the energy used by the display goes to the backlight anyway.
I really like Game Boy development - one nice thing is that its graphics hardware is more regular in comparison to e.g. the NES, and its sound hw is legendary. Also fun is the DS, which although being far newer still retains the tile-and-sprite graphics hardware. Flash cartridges are also plentiful.
It seems to be the season of homebrew - Tobu Tobu Girl is another Game Boy game on a physical cartridge to come out this month, with full source code (also using GBDK) http://tangramgames.dk/tobutobugirl/
We get new games for old computers often, and in my particular case I'm a huge fan of the Oric-1/Atmos sytems from the 80's. These are similar in many ways to the Gameboy architecture, but were far more user-dependent in that there was never any good software for them. (Well, not enough, anyway.)
But the machines live on and many elite developers are quite fond of them, so lately, every few months or so, we get new stuff for the Oric-1/Atmos systems. The latest game that blows everyones minds (because who knew you could do it on Oric), is Blakes7:
Its quite an achievement as a point 'n click adventure and there is much to the 8-bit aesthetic in this game that would appeal to those who came here for the Gameboy look.
Remember kids, old machines never die - their users do!
Wow, thanks for Blakes7. I love the series and old computers (I have an Oric somewhere) but did not know this game. Orac on Oric...
Wish someone with a brain would redo the series though; even though the effects are dated, the series drips misery more than what goes for dystopian these days imho.
I strongly urge you to dig out your old Oric and get Blakes7 running on it, you won't believe how great it is .. these machines still get a lot of love, so I hope I'll see you out there on oric.org and/or forums.defence-force.org if you get the druthers .. Cheers and happy hacking!
I had an Oric Atmos at one point. I got it in the late 80's as I always loved the look of the Oric computers and (ahead of my time) collected retro computers at that point. I sold it sometime in the Noughties, but I keep thinking to get another one.
They're delightfully interesting machines, in that they really didn't get the chance to shine back in the day .. but now we have emulators and disk drives, and all kinds of weird and wonderful stuff.
The guys at Defence Force are making a dual-Oric: two Orics' chained together to combine graphics and audio capabilities .. if you get the druthers, follow the progress here:
i have been writing a gameboy emulator for the last year (with short bursts of work where i implement some module), and it's been very challanging and fun, i recommend everyone to try it.
it has a very simple 8-bit (risc) architecture, but obviously tailored for games (for example, it has a dedicated sprite memory sector). i recommend people to try it out because it is has fun quirks compared with "regular" architectures, like arm and x86, for example in the way it handles cartridges, or in that some cartridges actually had non-trivial logic inside them and weren't just a rom.
it always amazes me how active gameboy research and development is still today, for example there's a very recent gameboy emulator / research project done in rust https://github.com/Gekkio/mooneye-gb
there are even test roms with which you can test your emulator to see if it implements all opcodes, interrupts and whatnot correctly (where correctly not only means "with respect to the effects" but also with respect to how many cycles everything should take). example of these test roms: http://gbdev.gg8.se/files/roms/blargg-gb-tests/
The 8080/Z80 variant that is used in the Game Boy is not a RISC architecture - it is a processor architecture from a time long before the term "RISC" was even used the first time.
While the terms RISC/CISC are defined somewhat vaguely, there are still some common properties of architectures that are considered RISC:
- Load-store architecture:
Counterexample: ADD A,(HL)
- Lots of general purpose registers:
The 8080 has rather few:
B,C,D,E,H,L,A as 8 bit registers and BC,DE,HL,SP as 16 bit registers
- Very orthogonal instruction set:
Counterexample: AND has always destination A
- Often pipelined architecture (though this is not very specific to RISC)
- Instructions typically aim to be run in one cycle (when pipelined)
Counterexample: Look at the instruction timing tables
The instruction encoding is quite regular -- it follows the 2-3-3 pattern that came from the 8008 (if not earlier), and thus looks much better in octal than hex:
> The instruction encoding is quite regular -- it follows the 2-3-3 pattern that came from the 8008 (if not earlier)
While it is true (and I am aware of it) that the Z80 instructions follow the 2-3-3 pattern, it is nevertheless not that regular. Best look at the "purest example" for this that is referred in the literature all the time and acted as a model for the criterion that in RISC the instruction format is very regular: the instruction format(s) used by MIPS. Here there only exist 3 different types of instruction (R-type, I-type and J-type) and all have a very regular pattern. One can find very suggestive pictures at
I did something similar with NES; built an emulator, and come back to it every couple of years. It's had 2 CPU cores (2nd added recognition of idle loops, and runs instructions in chunks instead of 1 at a time), 3 PPU implementations (each iteration emulated at a higher level, adding caching and hardware compositing), and 2 implementations of the ROM subsystem (adding caching and multiple memory mappers the second time around).
There are similar testing ROMs for NES emulators, too. My emulator tends to pass the CPU tests and fail some of the PPU ones; guess I need to write a 4th implementation of that chip!
Cartiridges being more than just ROM has been a staple of Nintendo designs all the way back to the NES.
A common trick was to have a logic chip sit between the ROM and the console, doing bank switching. This allowed a game to consist of much more data than could be fitting directly on the data lines provided.
Some games, particularly those sold in Japan, had improved sound chips for example.
And by the time we reach the SNES, Nintendo used this to even introduce rudimentary 3D acceleration in the form of the SuperFX chip.
For NES, another cool approach takes advantage of the fact that the cartridge is natively split between CPU memory and PPU memory. This means that it's possible to make a cartridge with RAM instead of ROM for the tile pattern data ("CHR" in NES jargon), thus enabling things like pseudo-framebuffer operation, compressed/generated graphics, and animations that work by modifying the tile data or depend on its organization in memory [1]. Strictly speaking, there's no reason that RAM and ROM couldn't be combined in this address space with a mapper, but I haven't heard of any cartridges that do so.
There were programmable cartridges in the 90's but IIRC Nintendo sued them all out of business, even the ones from Hong Kong. Did Nintendo lose interest in them after they stopped releasing new cartridges on those platforms? I didn't keep up after we cancelled the cartridge project I was working on at the time.
That's nuts. I'm sure if the DMCA covered it, there'd be cases on record of it happening (too lazy to search). I have no doubt there's a cases for selling counterfeit games but to outlaw the possession of the cart itself is ridiculous. A 1 year sentence is even more ridiculous.
> the judge argued that "the mere fact that the device can be used for a non-infringing purpose is not a defence."
It's always interesting when retro game dev is delivered on actual hardware (disks, cassettes, modules). The recently featured RTS by the "8 bit guy" even comes in a box.
On the other hand, while I appreciate this voluntary hardship (a bit like esoteric languages), I guess you get about 90% of the "engendering art with constraints" with a lot less pain by using something like PICO-8.
im currently doing something similar but with the ps2. it really amazes me that there are so few people interested in picking apart the ps2 and its games, and so few people interested in writing demos and games for the ps2. this lack of interest means that finding good documentation has been a little hard, but recently i hit a goldmine with official sony documentation on many of the important processors and coprocessors of the ps2 and it has been fascinating to read them. messing around with old game consoles is definitely a lot of fun.
I think there's a sweet spot for these things. Very old consoles are very limited but also pretty simple. You could get an overview of all the basic capabilities of a GameBoy in half an hour. As such they're easier to get started, playing a sound on a GB from scratch would take you a dozen CPU instructions at most, pushing a sprite into the GPU only slightly more.
Doing that on a PlayStation 1 would be already significantly more complicated. Even if you don't bother with 3D you need to figure out how to upload the texture to the (significantly more complex) GPU, configure a bunch of stuff and then you might be lucky enough to draw something on the screen. Take for instance this code for a "virtual terminal" on the PS1 GPU, this is what the GPU init code looks like: https://github.com/simias/psx-hardware-tests/blob/a72e0ba0c8...
And keep in mind that it's a super simplistic case, for anything more serious you'll want to configure double buffering, DMA, the GTE coprocessor for the 3D transforms and probably a few other things. Even just reading data from the CD-ROM is significantly more complex than accessing the memory mapped ROM of the GB.
I expect the PS2 to be even more complicated, although I don't have a significant experience coding on it. So you end up coding on a machine that's very limited by modern standards but at the same time might be more complicated to develop for than if you used Unity or the Unreal Engine.
PS2 is already at the level where hardware only knows about 3D.
Also its programming model is closer to something like Vulkan, thanks to the Emotion Engine.
Meaning having to create command buffers and command lists, and then dispatch them via DMA to the GPU.
Or by doing GPU shaders, which on the PS2 means Vector Unit Assembly (similar to MIPS).
So even for 2D games there is quite a bit of boiler plate to write up, until something gets properly displayed on the screen.
Those lucky enough to get a Linux Kit for the PS2, could use a kind of mini-GL implementation, PS2GL, that would make it a bit easier, given that PS2 Linux did not have access to the APIs for professional game developers.
There is a copy of the web site still available, with the programming guides.
I feel like this hits the nail. In addition to the complexity, there is also the thing that ps2 is comparatively similar to basic PC development, whereas 8/16 bitters have a very distinct different feeling.
2D pixel graphics arguably have aged better than early 3d graphics, and simple pixel graphics is also far more doable for a solo dev (or a very small team) than complex 3d scenes.
> 2D pixel graphics arguably have aged better than early 3d graphics, and simple pixel graphics is also far more doable for a solo dev (or a very small team) than complex 3d scenes.
I often ask whether part of the reason for this is also that the (graphics) tooling for 2D pixel graphics is better than for 3D graphics.
Nintendo has had some recent success releasing new versions of old hardware. It would be pretty interesting to see what they could do with a a re-release of the GameBoy.
Does anyone know where one might find modern made buy-able Game Boy games? I have an old working Game Boy Color knocking around and would love to purchase some modern games for it!
This is why my one of my hobby coding is using the NDK on Android, although we are carry a supercomputer in our pockets, I get some of that nostalgia feeling back.
I guess a better experience would be to plug an ESP32 to a LCD screen. :)
you can even do console on android with aide. was doing recently. paused while I switched to porting some console stuff to jailbroken iPad. running those over ssh. great nostalgia running nurses Dr Mario in a terminal. pointless, but enjoyable.
well, this is amazing. I was especially impressed with reusing tiles for the main screen image.
I'm a graphic designer and definitely not a coder for anything fun like this --- but I love seeing how people design low res sprites more than almost any other type of image. I think it speaks to my desire for minimalism, in a sense.
It is interesting to see which systems get thriving home-brew communities. Anecdotally I see a lot of posts about Game Boy hacking, but nothing about Sega Game Gear hacking.
The 16-bit generation is the inverse. The Sega Genesis has an AMAZING homebrew community thanks to a C-language dev kit that makes writing games remarkably easy. The SNES has almost nothing, save for a wiki and secondary board on Nesdev.
Could this be that the SNES hackers are modifying existing games instead? There's all sorts of fan hacks and remakes of Super Mario World, Super Metroid, Zelda, Final Fantasy, Mario Kart, Castlevania, and more. But the Genesis doesn't have quite so many memorable franchises beyond Sonic so that's where the homebrewers are making new stuff.
I recently downloaded roller coaster tycoon for my gf, as we both used to play it when we were younger. She doesn't really play games, but during our 4th date at an amusement park we found out we both played it as children. That game was written in assembly by one person
Not really a point here, other than that nostalgia and craftsmanship can be far more powerful than the latest hardware or software