HN Theater @HNTheaterMonth

https://youtube.com/watch?v=HyzD8pNlpwI&feature=share

“The ultimate gameboy talk” from 33c3

Beautiful and inspiring.

⬐ paoda

Agreed. It's a wonderful talk.

I'm elated that discoveries are still being made. Since this talk, the understanding has come to be that there are two independent pixel FIFOs. One responsible for sprites, and the other for background and window tiles.

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.

⬐ 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

Modern Vintage Gamer just released a video [0] discussing this leak in greater detail along with its expected implications.

Anyone who's curious can find the download links by backtracking through all the Pokemon Prototype General threads under the Pokemon board on 4chan.

One of the leaks that caught my attention was the source for Pokemon Blue, partially because of nostalgia and partially out of curiosity to see what an old game's codebase even looks like. The first thing that stood out to me was the project's flat folder structure, full of hundreds of files; I guess I was expecting things to be a bit more structured. The source is more readable and approachable than I expected, although I've only poked around in some of the more obvious places and definitions. I'd recommend watching The Ultimate Game Boy Talk [1] before trying to dive into any code.

[0] https://www.youtube.com/watch?v=n8G7eq0GlQs

[1] https://www.youtube.com/watch?v=HyzD8pNlpwI

⬐ dehrmann

I have zero experience in the video game industry, but I'd think that since video games get ~zero attention after they're shipped, writing maintainable code is less of a priority.

I'd be really curious to see how the Pokemon Red/Blue split was done. Is it a C precompiler flag? Build config? Actual config? Cloned repo?

⬐ ptmcc

In the old days that was probably more true than it is today, since so many games are "as a service" now with shared engines, online platforms, continual updates/patches, tons of expansions and DLC, supporting mods, etc.

The downside is that we'll never really be able to play today's games nostalgically like we can with old burned-to-ROM games.

Online multiplayer games have a shelf life of sorts that depends on the servers being available and having other people to play with. There's a few examples of community-driven projects to revive classic online multiplayer games with mixed success but it'll just never be the same thing.

⬐ creamynebula

After MSN Gaming Zone died in 2006, the Age of Empires II community developed a multitude of alternatives to play the game online (with a rating ladder). The one that was the most widely used up to the very recent release by MS of AoE2:DE on Steam was Voobly, which exists since 2008, although back then it was called IGZones.

⬐ Topgamer7

Well there is always the case of iterative releases of games of a genre. So Pokemon Silver vs Pokemon Blue. It is going to based off of the original source code. So writing maintainable code is desired (from the dev at least).

⬐ chongli

That’s not my experience of modern games. There are loads of games out right now that get patches constantly, sometimes even weekly. It’s not just multiplayer games; lots of roguelikes are in constant development as well.

⬐ saagarjha

They’re touched much less often than most software, but even older games would occasionally share engines and stuff. Games these days often have DLC.

⬐ inyorgroove

I might be wrong but it would make sense to me that the second gen games (Gold/Silver) would share a far bit of code from the first gen (Red/Blue/Yellow). In that sense in this case, the code did infant live longer than the release of the first game.

⬐ TheAceOfHearts

In the Pokemon Blue codebase they use 2 flag variables to distinguish between the different games, these are `pokemon_type` and `pokemon_type_blue`. The name of the second flag definitely hints that it was added later in development.

These are the values for each game:

    Green:  pokemon_type=0 pokemon_type_blue=0
    Red:    pokemon_type=1 pokemon_type_blue=0
    Blue:   pokemon_type=1 pokemon_type_blue=1

The general pattern for branching between game variations looks like this across the codebase:

    ifn pokemon_type
      ifn pokemon_type_blue
        ; blue
      else
        ; red
      endif
    else
      ; green
    endif

Conditional assembly directives like `ifn` are resolved statically during assembly, so only the code between matching conditions is included as part of the output. To anyone interested in exploring this a bit more, I'd recommend reading Chapter 8 Section 13 of the DOS version of The Art of Assembly Language Programming [0], which starts on page 43 of the linked PDF.

Bonus fun-fact: In the Pokemon Yellow codebase it says `pokemon_type=1` is yellow, while `pokemon_type=0` is pink! This suggests to me that the idea of Pokemon Pink with Jigglypuff as your starter was probably being floated around but it was eventually scrapped. (The only remaining options for a pink starter pokemon with a pink evolution in the original 151 would be Clefairy and Slowpoke, neither of which are very cute.) The idea of Jigglypuff as a starter is further supported by her appearance alongside Pikachu on the roster of the original Super Smash Bros. which seems rather unexpected unless they had bigger plans for her.

[0] http://www.plantation-productions.com/Webster/www.artofasm.c...

⬐ abaga129

I seem to recall watching a video somewhere, perhaps on Didyouknowgaming, that Clefairy was intended to be the Pokémon mascot before Pikachu. I could be completely wrong here, but if so that is really cool to think it may have had its own game!

⬐ advance512

Very cool, uncovering game development history via the source code.

Thanks for this!

⬐ abaga129

I found some supporting evidence from bulbapedia "Clefairy was originally going to be the official mascot of Pokémon, but Pikachu was used instead due to the popularity of the anime and Pikachu's familiarity with fans".

Source: https://m.bulbapedia.bulbagarden.net/wiki/Clefairy_(Pok%C3%A...

Very cool find about the pink version!

⬐ sb057

Incidentally, Pokemon Red and Blue were disassembled years ago:

https://github.com/pret/pokered

⬐ klmadfejno

Maybe relevant, but Pokemon Blue is part of the American release, which came quite a while after the original Japanese release of Green (both had a red). They had to rework some things to handle English. It wouldn't surprise me if that contributed somewhat to a less ordered structure in that it's an alteration of the original.

⬐ lprubin

Is the reason for the flat structure saving space? I know on older games, space is at a premium and referencing files from the root might save some bytes so maybe that's the reason due to shorter file reference names.

⬐ wtetzner

I don't think the filenames of the source files would end up in the final ROM.

⬐ mywittyname

This was probably development environment limitations. You have to remember that this game was released in 96, which means it was probably developed on a command-line machine with an IDE like Turbo C.

⬐ klmadfejno

I wouldn't be surprised. As I understood it, just translating the game into English was a problem because there's more characters to cram in the cartridge.

⬐ numpad0

Or maybe it’s in part cultural. Deep nested hierarchy is not very Japanese concept.

⬐ kimikimi

It was way more common to simply not attempt to organize projects in this way "BITD" - it complicates your build system because now it has to manage paths, which entangles it with the OS file system. Not every file system even has subdirectories and not every tool acknowledges or agrees upon how to use them, so depending on how antiquated their dev environment was, it may have been totally impractical.

⬐ BenoitEssiambre

The most shocking part of this story is still that Nintendo keeps all its code in CVS. CVS!!!

⬐ grawprog

It wasn't Nintendo's CVS it was BroadOn's CVS. It was a third party Chinese company Nintendo allowed to produce Nintendo compatible hardware in China. They had access to a bunch of sdks and the source codes for the system to develop their hardware.

⬐ fl0wenol

It was probably iGware's or Acer's CVS when it was hacked, if I'd have to guess.

RouteFree->BroadOn->iGWare->Acer Cloud Technology (as of 2011, now just a business unit)

⬐ ginko

For game code written in the mid 90s I'm actually pleasantly surprized. I would have expected just a bunch of copied folders with weekly snapshots.

⬐ Blackthorn

I'm really excited by the Pokemon leak. The game was so large and detailed yet the resulting output so incredibly tiny. The developers implemented so many tricks to keep the size down. Now you can see what they did and how it worked. This could be really historically important.

Anyone interested in how the Game Boy works should watch "The Ultimate Game Boy Talk" by Michael Steil.

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

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

[0]: https://www.youtube.com/watch?v=HyzD8pNlpwI

I really like the Gameboy hardware; it's limited, but the design feels very elegant in it's simplicity.

I've written a couple of toy Gameboy emulators at this point. It's a bit challenging to get anything working, and honestly I have no idea how to approach audio at all. Nevertheless, it's still quite fun. The LCD timings are a point of curiosity for me. It seems there's still a slight bit of mystery around it, still today.

I was inspired to play with emulating Gameboy specifically after an excellent 33c3 talk, The Ultimate Game Boy Talk, which I highly recommend.

https://youtu.be/HyzD8pNlpwI

(Some day I would like to approach emulation for more platforms, both newer and older, but I feel I still have so much time learn about designing emulators that I haven't bothered with that yet. It's so open ended, and handling things like cycle counting has a lot of different approaches of varying desirability.)

⬐ anyfoo

You might really enjoy this talk as well, then: https://youtu.be/GBYwjch6oEE

⬐ jchw

Oh thank you, I've never seen this talk nor heard of this conference but on it's face it sounds like it's right up my alley.

I've been working on a GB emulator for awhile.

Step one is to understand the architecture of the system. What are the different hardware components? How do they interact?

A simple emulator boils down to:

While(true) Emulate_one_cpu_cycle()

For each cycle you have to produce any side effects from the various peripherals (serial comms, update the display, generate audio, etc.), process any external changes (button presses, serial data), and emulate the next CPU instruction (basically a big switch).

I recommend "The Ultimate Gameboy Talk (33c3)" [0], for an overview of the Gameboy and it's internal peripherals.

There are various test ROMs available that you can use to verify the basic functionality. [1][2]

0. https://m.youtube.com/watch?v=HyzD8pNlpwI 1. http://gbdev.gg8.se/wiki/articles/Test_ROMs 2. https://github.com/Gekkio/mooneye-gb

Game Boy emulators are always great for educational or experimental projects, because the Game Boy platform is surprisingly simple, which leads to a very quick payoff, and yet very "real" in that the Game Boy was a great commercial success with thousands of software titles available, so you have plenty of software available to try in your project and actually make use of that payoff.

One example to illustrate how simple the Game Boy is: There is no operating system at all, only a 256 byte boot ROM whose sole purpose is to display the Nintendo logo from the cartridge and halt if it does not checksum correctly (for both cartridge integrity and legal reasons).

This entertaining 33c3 talk manages to describe the Game Boy hardware practically in its entirety (and with some previously unknown details, actually): https://www.youtube.com/watch?v=HyzD8pNlpwI

⬐ bandwitch

Coincidentally, the "Practice of object-oriented programming" course in EPFL has as a project this semester to build a Game Boy emulator in Java. You can have a look here (https://cs108.epfl.ch/). Although it's in French, google translate does a decent job.

⬐ sjrd

OMG, I had no idea. I TA'ed this course 3 years ago. I wish the project had been the GB emulator at the time ... I would have had so much fun :-p

⬐ anyfoo

Heh, should have read the article before writing my comment, the author mentions the same and even links to the Ultimate Game Boy talk as well. I hope I was able to add some detail.

⬐ None

None

⬐ near

The Game Boy is only simple in the early stages of emulator development.

You find quickly that it is full of excruciatingly complex edge cases that aren't documented, and aren't well understood by anyone.

We're still making significant progress to this day on it.

And even in the early stages, the Z80-like Sharp LR35902 is quite a hassle. If you want an educational project, consider an NES emulator instead. Still has lots of edge cases, but the documentation and reverse engineering work is far ahead of the Game Boy.

Some reading if you like:

https://mgba.io/2017/05/29/holy-grail-bugs/#pinball-fantasie...

https://mgba.io/2018/03/09/holy-grail-bugs-revisited/#the-ph...

⬐ brailsafe

For an educational project however, wouldn't an opaque platform with broken-ass documentation and edge cases that make you hate yourself be more representative of real software dev in general? ;)

⬐ skate22

It depends how many meetings you have first

⬐ userbinator

Still has lots of edge cases, but the documentation and reverse engineering work is far ahead of the Game Boy.

...to the point where there are transistor-level simulations of the CPU and PPU:

http://www.visual6502.org/JSSim/

https://wiki.nesdev.com/w/index.php/Visual_2C02

The only other game console I'm aware of a public transistor-level simulation for is the much more limited Atari 2600:

https://github.com/gregjames/Sim2600

⬐ monocasa

Eh, the NES is more complicated IMO. To start off there's the weird clock scheme that there's like 3 CPU cycles for every 5 PPU cycles (and there are games that depend on partial results). There's the greater combinatorial complexity of everyone and their mother making custom ROM boards. The PPU is just more complex, IMO. Etc. Etc.

⬐ zorked

Isn't the NES graphics chip considerably more complicated than whatever the Game Boy users?

⬐ zeta0134

As far as capabilities go, both chips are remarkably similar, with the Gameboy supporting an extra background. They both do a handful of sprites and tiled backgrounds with attributes for things like palette selection. However, the NES has one difference that throws a wrench in things. Unlike the Gameboy, which has VRAM in the console, the NES reads all of its graphics data from the cartridge directly.

The NES's PPU is simple in operation, but many cartridge types (MMC3 and MMC5 in particular) relied on the precise behavior of the PPU's reads and writes to time some of their extra features, often something like a scanline counter. This makes the complete system much more difficult to emulate, even though the base features of the console are straightforward to grasp.

What makes the NES such an attractive target for a first emulator is that, due to this quirk and the system's popularity, its hardware is just about perfectly understood. Take a look at the Nesdev Wiki's article on rendering, which has an extremely thorough breakdown of the timing, including the bugs in the sprite rendering subsystem and how to correctly emulate them:

https://wiki.nesdev.com/w/index.php/PPU_rendering

⬐ stormbrew

I would think the thing that would make the NES unsuitable would actually be the very large number of mapper chips for the platform. The NES seems less like one platform and more like tens of them at that point. AFAIK the Gameboy didn't really have this proliferation of chips that manipulated the system so directly.

At the very least, you might be able to badly emulate most gameboy games, but a mapperless NES emulator is only going to even be able to try to run the first generation of games from the console.

⬐ zeta0134

This is definitely true. The gameboy does have memory mapped cartridges to deal with, but they don't hook quite so deeply into the system; they're much more straightforward to implement, and for simpler games you can ignore the mapper entirely.

The NES is a different beast; nametables _alone_ will give an early NES author headaches, and they're incredibly important to get right, otherwise games won't be able to scroll properly. Even simpler games like Mario and Metroid rely on basic nametable support being there. In this case I think it's the limitations of the NES itself that led to the mappers doing so much more externally; game authors had no other choice if they wanted to pull off advanced tricks. This trend continued with the Super Nintendo; remember the SuperFX chip? It almost turns the Super Nintendo into a dumb terminal at that point, generating entire screens worth of graphics in the gamepak directly.

⬐ khedoros1

> In this case I think it's the limitations of the NES itself that led to the mappers doing so much more externally

Agreed. The Game Boy's ability to generate interrupts at various times in the scanline, and access to the current scanline number, make timing things with vanilla hardware much easier on the Game Boy than the NES.

⬐ byuu

So you can cover about 95% of the library (and 99% of the games people want to play) with about 20 or so mappers. From there it can be a slog to support them all, but conceptually mappers are really very simple. Almost all of them are just registers that let you page in chunks of memory.

The most advanced mapper is the MMC5, that one can take some doing. And the VRC7's OPL audio is also a nightmare (yet used only for one game.) But beyond that, it's all really simple. Usually around 10-30 lines of code per mapper. Mostly very well documented, with the exception of how mappers detect scanlines (important for accurate emulation, not so much for full compatibility. You can just cheat and give them the PPU scanline counter.)

But, maybe I'm biased. I've emulated thirteen systems so far, and the NES was one of my favorites to work on due to the documentation and general simplicity. I know the rabbit hole goes on forever even with the NES, though.

⬐ rychco

Emulation sounds like a cool project. Mind sharing some tips on where to start or any helpful links?

⬐ khedoros1

This one walks you through writing an emulator for the classic Space Invaders game: http://emulator101.com/

But really, if you've had a computer architectures class (or do equivalent research on your own), it's doable to just start looking up info about a specific system, and digging down as necessary.

⬐ wiz21c

From the first link : "But then why does this game work well in inaccurate emulators? That’s also a bit of a mystery, but it’s possibly because their timings are just wrong enough that things do not end up cascading the same way."

If it's that then my hat goes off to the devs who find it, timing issues are second to none in difficulty.

⬐ yodsanklai

Any idea of how hard would be a C64 emulator? it's the computer of my childhood and I've always contemplated writing an emulator for it.

⬐ keithnz

you could check out http://www.c64js.com/ its github is https://github.com/mborgbrant/c64js

⬐ anyfoo

Sorry, I should have clarified: The Game Boy is very simple in concept and on a sufficiently high level. But this is exactly what allows you to get payoff quickly, and why I like it for educational and experimental projects. Especially earlier games like Tetris don't significantly rely on many edge cases and implementation details, so even a quick and dirty implementation runs them reasonably well.

Once you want to do "serious" emulation that runs a wide variety of games and accurately reproduces them in every spect, things become much less simple and might also lead you to completely abandon initial approaches, e.g. because your straightforward but non-cycle accurate CPU main loop doesn't cut it anymore.

Compare this however with a more modern system that has an MMU, where you have a long, long road of busywork ahead before you can even get past any reasonable definition of "booting", whereas for the Game Boy even a shoddy first draft implementation might at least get you into a game's initial menu screen, completely with working buttons and all.

And strictly spoken, a conceptually more complex system will have more edge cases and implementation details to deal with, albeit I think that it often also means that those implementation details are less exploited, as developers stay on a higher level and are less trying to squeeze out every last bit of the "simplistic" hardware.

⬐ anyfoo

And the simple front with the fractal complexity below it also make this more fun and educational: You can start off easy while still getting good results, and go arbitrarily deep in perfecting your emulator, choosing from an apparently still unexhausted variety of interesting problems to solve.

Your links are a good example, I love reading about the complex implementation details in emulators of superficially simple hardware.

The Ultimate Game Boy Talk (33c3)

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

⬐ npgatech

Thank you, absolutely fascinating talk. It was hard to develop video games back in the day and just as it was hard to beat those games. What a wonderful era of ingenuity, creativity and passion.

The Ultimate Game Boy Talk[0] (listed in the page) is one of my favorite talks of all time.

If you were to send this talk to someone, with basically just the videe they could likely build a faithful Gameboy clone. It's so dense, easy to understand, and comprehensive.

I'll listen to it form time to time and think about all the cool tricks it reveals. Super impressive to have that much knowledge for a system that only had a couple thousand programs ever written for it.

[0]: https://www.youtube.com/watch?v=HyzD8pNlpwI

⬐ jerrre

>Super impressive to have that much knowledge for a system that only had a couple thousand programs ever written for it.

Released for it. Officially.

⬐ djhworld

I wrote a gameboy color emulator a few years ago https://github.com/djhworld/gomeboycolor

Probably would require some effort to get it to build again, but it was a fun, if a little intense programming project.

The architecture is very approachable, although I never got the sound working.

There's no greater feeling of toiling away for months on the CPU/GPU/MMU code where you eventually reach the point where you can successfully boot the emulator into rendering the "Nintendo" logo that scrolls down the screen.

⬐ lathiat

Can confirm

⬐ t0mek

This talk inspired me to create a Game Boy emulator [1] and indeed it's enough to create a general design of each hardware subsystem (CPU, IRQ, Pixel Processor Unit, etc.) Also, the part about the pixel transfer is great, only few emulators implement it with FIFO queue, as presented, and this seems to be very accurate way.

During the further work I needed more details (list of CPU opcodes, timing of the IRQs, a list of audio and timer bugs, etc.), but the list links to all required resources - as far as I know this is everything we know about the Game Boy at the moment. It doesn't mean the console is fully reverse-engineered - especially the STAT IRQ timings is still very hard to get right.

Particularly interesting link is the "Pan Docs", moved and updated in the gbdev wiki [2]. Maybe it's not the best place to get the general information about the hardware, but it provides a lot of specifics.

[1] https://github.com/trekawek/coffee-gb [2] http://gbdev.gg8.se/wiki/articles/Pan_Docs

⬐ binji

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....

⬐ tbrock

Nice C code! Took a look and seems very solid.

I was unaware of the GB test suites. Thanks for sharing that tidbit.

⬐ pepijndevos

Amazing!

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:

https://drive.google.com/file/d/0BzPtU6SpBQZzVVdZZ0kxNGhqVjg...

Source: https://github.com/pepijndevos/gbpaint/blob/presentation/mai...

⬐ pryelluw

That code is very clear. Nice. Did you ever go back and write for the GB?

⬐ pepijndevos

That's my most recent project, but I wrote a paint program and some Pokemon hacks before that.

⬐ gravypod

I wish someone made something about "The Ultimate x86/x64" talk that covered all of the features of modern (x86/x64) processors.

⬐ striking

It'd be a couple days long, though...

⬐ gravypod

That's fine. It's worth it. Hell, make it + set of lectures + a book + homework exercises and sell it as a college architecture corse.

⬐ apetresc

Sooo why not just watch a college architecture course?

⬐ gravypod

They are usually very poor in quality. They are also usually stuck in the 70s of architecture development.

⬐ Yan_Coutinho

LOL this made me remember of a stream about a guy developing a game boy emulator in Python.

By the way, this is the link: https://www.livecoding.tv/michielha/videos/ZeNNa-a-python-ga...

⬐ None

None

⬐ ZenoArrow

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?

⬐ rkachowski

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].

[1] http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

[2] http://cratel.wichita.edu/cratel/ECE238Spr08

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.

[3] https://github.com/rkachowski/rubygb

⬐ ZenoArrow

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.

⬐ rkachowski

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).

⬐ jfktrey

From what I understand, not only does it work in Wine, but it's a first-class supported platform. Never seen that before in software.

⬐ FlorianRappl

Cool project! Thanks for the resources. Hopefully I'll find the time to play around with it ...

⬐ jupp0r

Having attended the talk in person, it was probably one of the best uses of animations and diagrams in a presentation I've ever seen.

⬐ mattlevan

Agreed. If you discover how he achieved it, let us know please!

⬐ Darthy

Another well designed recommended video about the same topic: "The Game Boy, a hardware autopsy", https://www.youtube.com/watch?v=RZUDEaLa5Nw .

⬐ duiker101

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.

⬐ russellbeattie

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.

⬐ digi_owl

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.

⬐ None

None

⬐ gumoro

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".

Neat :)

⬐ koorogi

It's a legal trick that doesn't actually work. Sega tried the same trick and lost when they took it to court in 1992.

https://en.wikipedia.org/wiki/Sega_v._Accolade

⬐ faragon

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.

⬐ dom96

This is a really great talk. I have worked on a gameboy emulator in the past in Nim,[1] sadly I didn't get enough time to finish it.

The amount of features offered by the Gameboy does seem rather overwhelming after watching this video.

1 - https://github.com/dom96/gbemulator

⬐ planteen

Very cool. When I was in high school, I tried my hand at developing Game Boy games using a C compiler. Lots of good memories.

Really hoping they do that Super Nintendo talk next year.

⬐ pepijndevos

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.

⬐ phire

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.

⬐ q3k

Perhaps the OAM is in a different memory..? The NES PPU's OAM is in a DRAM, while rest of the PPU RAM is an external SRAM.

⬐ mmastrac

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.

⬐ pepijndevos

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.

⬐ deutronium

I'm very interested in the Kong Feng GB Boy Colour he mentioned, I'd love to know how they copied the GameBoy CPU etc. through decapping.

⬐ t0mek

Similar talks for C64 [1], Atari 2600 [2] and even exotic "Galaksija" [3] computer (ZX 80 clone) are available as well.

[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

⬐ ZenoArrow

There's also one for the Amiga 500:

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

⬐ digi_owl

A real eyeopener.

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.

⬐ ZenoArrow

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:

http://amiga.resource.cx/exp/gvp530