Too bad Amiga was mismanaged from the word go, and that the less than upgradeable 500 was the face of the platform, as it was really ahead of its time in terms of internal design.
But over time the more upgradeable, and cloned to hell and back, IBM PC won out. In particular once the chipsets gained DMA and new expansion buses.
I agree that Amiga was mismanaged from the word go, that was the main issue IMO (they waited far too long before pushing for an upgraded chipset, and they should never have forced the Amiga team to relocate, causing most/all of the original team to leave).
As for expandability, whilst the A500 wasn't as expandable as the A2000, I'd say it was expandable in the ways most users would care about. For example, this expansion allowed users to add a faster CPU (and an FPU), add more RAM and add a hard drive:
As long as we're linking personal GB emulators... :-)
Here's mine, written as one file of less than 5000 lines of C: https://github.com/binji/binjgb. It's very accurate, based on few of the most commonly used GB emulator test suites (Blargg's and Gekkio's).
Interestingly, there are still many questions about the specific timings of the Gameboy PPU and APU. An interesting case pointed about by LIJI128 is that no accurate emulator can run Pinball Deluxe; they all crash in some way: https://www.reddit.com/r/EmuDev/comments/4n71ea/gb_pinball_d....
More or less relevant: For an university project where we made a Game Boy emulator, I wrote a presentation framework on the Game Boy itself, in which we recorded the design video:
Great talk, tempted to try some Game Boy development now! Apart from the development tools/resources mentioned at the end of the video, any others to recommend?
I was at this talk in Hamburg and it inspired me to tidy up a gameboy dev project I started in Feb. I wish I'd seen this before I started.
BGB (mentioned at the end) really is the best emulator for development, and it works pretty flawlessly in wine (on both OSX and linux). http://bgb.bircd.org/
Aside from that, there is a gameboy cpu manual / cheat sheet (handily printable as an A5 booklet) [1] and by some incredible stroke of luck, there was a university course in Wichita that taught assembly programming via programming gameboy roms [2].
shameless plug: the project I started is available on github here [3] - i'm working on figuring out how to build native ruby extensions so I can have the assembler be built on install, rather than dirtily bundling pre built binaries for OSX use.
Thanks for the links, looks like they're great resources to kick start GB dev.
With your project, I'm not sure I understand it yet, is it a tool for creating and running makefiles that work with a GB assembler? If that's right, I can see it being useful.
That's pretty much it, yeah - as well as collating common tools + providing some basic templates for creating projects (getting to hello world requires a lot of boilerplate initialization).
One of the most interesting parts of the talk was the fact that the boot code checks that the game contains the Nintendo logo @19.15. Very smart way of keeping control of the game releases. They have always been very good at keeping their games and copyrights.
Thanks, I had skipped to random parts and missed this one.
Here is a transcript:
"The game has to have a copy of that Nintendo logo inside. If it doesn't match, the game does not boot. This was meant so that Nintendo could control which games are released for the platform, because all games had to contain the logo, which is not just a copyright violation but also a trademark violation if you include that and don't have Nintendo's permission".
It's brilliant. Though this seems like a very "greedy corporation" move nowadays, this was the secret to Nintendo's success eay on. By keeping a tight control over the platform, it guaranteed high quality games and avoided the shoveware of Atari 2600. One could argue Apple emulated this same model 20 years later with the initial tight control over the App Store, to great effect.
I think it was easier to get away with it, when it was simply a entertainment device. But with smartphones etc being about so much more (like say basic communication with an autistic child) it becomes a much harder sell.
It is an interesting overview of Game Boy development: it includes hardware description (CPU, memory map, etc.), per-line interrupt ("raster effects"), palette, priorities, layers, sprites, sound, etc.
How was the game boy able to do the OAM scan in 20 cycles? You need to do 2 memory reads per sprite(status and y location), times 40 is 80 reads, means 4 reads per CPU cycle.
I don't know anything about GB programming other than watching the video, but my understanding is that it's not doing memory reads but rather transistor logic to determine which sprites have priority on that line. This is also why you have that 10 sprite limit, as the 10 active sprites end up getting pushed into hardware comparitors for that line.
Explanation starts around 46 minutes into the video.
Right, so these 10 sprites are definitely not in RAM, but in transistor logic, but at the start it has to scan 40 sprites in OAM, which means checking 80 bytes, and copying 10*4 bytes to the comparators.
OAM is separate from VRAM and is located inside the SOC.
The PPU is clocked at 4mhz and I suspect OAM is also clocked at 4mhz (though it could also be implemented as two banks clocked at 2mhz with status in one bank and y location in the other bank). So 4 reads per CPU cycle sounds correct.
[1] https://www.youtube.com/watch?v=fe1-VVXIEh4
[2] https://www.youtube.com/watch?v=aNyebnxV9R8
[3] https://www.youtube.com/watch?v=DIwC9vdqfqw