HN Distilled

Essential insights from Hacker News discussions

Donkey Kong Country 2 and Open Bus

Original Article

Hacker News Discussion

Here's a summary of the themes present in the Hacker News discussion:

The Value of Detailed Explanations and Historical Context

Many users expressed appreciation for explanations that go beyond just the code, particularly when dealing with complex or arcane systems like the 6502. The narrative aspect of uncovering long-forgotten bugs in classic software was also a significant draw.

  • "Love stuff like this, I feel like I’m only ever 60% following the assembly code, so the prose explanation alongside really helps – and it’s fun to hear these ‘bugs that nobody understood or possibly even noticed until now in a classic piece of software’ stories!" – mock-possum
  • "HELf: I love this sort of content! My favorite things I find on HN :D"

Low-Level Hardware and the "Wild West" of Early Computing

A recurring theme is the stark contrast between the early days of computing, particularly with systems like the NES, and modern practices. The lack of built-in safeguards and the direct manipulation of voltages and timing signals were highlighted as both challenging and fascinating aspects of this era.

  • "One of the things I love about this era of systems is that there were none of the modern checks that we consider table-stakes in nearly everything, including most embedded systems..." – shadowgovt
  • "Lots of reads and writes in the original NES just toggled voltages on a line somewhere, and then what happened, happened. You got the effect you wanted by toggling those voltages in a very controlled manner lock-stepped with the signal indicating the behavior of the CRT blanking intervals." – shadowgovt
  • "It was a wild time." – shadowgovt

Common 6502 Assembly Pitfalls and Nuances

Several users shared their personal experiences with common errors made when programming in 6502 assembly. The distinction between immediate values (prefixed with #) and memory addresses, and the ease with which these could be confused, was a particularly strong point of shared experience.

  • "I have to say as a 6502 assembly programmer I have wasted many hours of my life tracking down the same issue in my code (forgetting to put an # in front of an immediate value and thus accidentally doing a memory access instead)." – deater
  • "I don't always make 6502(ish) errors, but when i do, it's usually the memory address instead of the immediate! It's a very common and easy mistake to make, and i believe Chuck Peddle himself deeply regretted the (number symbol, pound sign, hashtag) #$1234 syntax for immediate values." – nicetryguy
  • "I know it's OT, but I have to say, for a 30-year-old video game, it's remarkable how well DK Country 2 holds up today." – jihadjihad
  • "I always thought of instructions like "LDA #2" as "load A with the number 2" versus LDA 2 (load A with what's in memory location 2)." – RiverCrochet

DRAM Refresh and System Design Cleverness

The use of Dynamic Random-Access Memory (DRAM) and the necessity of refreshing it were discussed in detail. Users highlighted the clever engineering solutions employed in systems like the Apple II and Commodore 64, where the video hardware or other bus masters were leveraged to perform DRAM refreshes as a side effect of their operations, thus saving dedicated logic.

  • "The Apple II was one of the first 6502 systems to use DRAM (in 1977) and Woz was incredibly clever in getting the refresh for free as a side effect of the video generation" – deater
  • "Wozniak's design for the Apple II used a clever hack where the system actually runs at 2 MHz with an effective CPU rate of 1 MHz. Any read from a DRAM row will refresh the entire row. Approximately every other cycle the video system steps incrementally through memory, refreshing as it goes." – retrac
  • "Same with the VIC-II and the 6510 in the Commodore 64. The video chip is given the main character role for the bus, stopping the CPU from moving forward if it needs cycles for video generation or DRAM refresh." – rzzzt
  • "This is especially noteworthy because the DRAM refresh is actually visible on-screen on some units:" – wk_end

Emulation Accuracy and Discovering Bugs

The discussion touched upon the role of emulators in uncovering or even introducing bugs. The idea that a bug might only manifest in an emulator, or that an emulator might not perfectly replicate hardware behavior, leading to incorrect assumptions about game design, was a significant point. The idea of emulators becoming so accurate that previously invisible hardware quirks start to surface was also mentioned.

  • "Whenever I'm playing a game via emulation and I get stuck, I do end up wondering if it's a bug in the emulator. This particular issue, I would have assumed the game was designed this way it and is just difficult." – pipes
  • "I only ever played DKC on ZSNES, and I had no idea that this was an emulator bug until reading the article. Like you said, I just assumed that it was the intended game design to time your launch from the barrel so that it was the correct angle. It blew my mind to learn that it was a bug!" – bigstrat2003
  • "I once encountered SNES Puyo Puyo doing PPU open bus. This was when I was working on the RunAhead feature for RetroArch, and was checking when savestates failed to match. CPU execution trace logs didn't match because a value read out of PPU Open Bus didn't match after loading state." – Dwedit

The Nature and Implications of "Open Bus" Behavior

A considerable portion of the conversation focused on the concept of "open bus," with users explaining its technical underpinnings and how it can lead to unexpected game behavior or be exploited. The physical nature of the data bus as a capacitor, and how un-driven lines tend to retain their last state, was a key technical explanation.

  • "Open bus quite literally means that the data bus lines are an open circuit – the CPU has placed an unmapped or write-only address on the address bus, and no hardware on the bus has responded, so the bus lines aren't being driven and are just floating. Thus, nominally, this is a case of undefined behavior at the hardware level." – NobodyNada
  • "This looks a lot like a capacitor, and in fact this is described and modeled as 'parasitic capacitance' by engineers who try to minimize it, since this effect limits the maximum speed of data transmission over the bus. But this effect means that, whenever the bus is not being driven, it tends to stay at whatever voltage it was last driving to – just like a little DRAM cell, producing the 'open-bus reads return the last value transferred across the bus' effect described in the article." – NobodyNada
  • "It's not uncommon for games to accidentally rely on open-bus effects, like DKC2. On the NES, the serial port registers for connecting to a controller only drive the low-order bits and the high bits are open-bus; there are a few games that read the controller input with the instruction LDA $4016 and expect to see the value $40 or $41 (with the 4 sticking around because of open-bus)." – NobodyNada
  • "This very niche edge case has a significant impact on a Super Metroid speedrun exploit which causes an out-of-bounds memcpy, which attempts to transfer a large block of data from open-bus to RAM. The open-bus read almost always returns zero (because the last byte of the relevant load instruction is zero), but when performed in certain rooms with HDMA-heavy graphical effects, there's a good chance that a DMA transfer will affect one of the reads, causing a non-zero byte to sneaks in somewhere important and causing the exploit to crash instead of working normally." – NobodyNada

The Utility and Limitations of LLMs for Code Analysis

The topic of using Large Language Models (LLMs) for code analysis, particularly for lower-level languages like assembly, was brought up. While some see potential, others expressed skepticism based on recent negative experiences.

  • "This is the kind of situation where feeding your code through an LLM can actually be helpful: they're really good at spotting the kind of errors/typos like this that have a profound impact but which our eyes tend to all to easily scan over/past." – bartread
  • "The last time I tried an LLM on assembly, it made up instructions that didn't exist." – nancyminusone
  • "I know it's OT, but I have to say, for a 30-year-old video game, it's remarkable how well DK Country 2 holds up today. I've been playing it with an emulator and the graphics, sound, level design, and controls are all masterful. The kids can keep Fortnite, I'll take DKC and Chrono Trigger any day!" – jihadjihad
  • "cool; nowadays LLMs are better" – cdelsolar
  • "I once encountered SNES Puyo Puyo doing PPU open bus. This was when I was working on the RunAhead feature for RetroArch, and was checking when savestates failed to match. CPU execution trace logs didn't match because a value read out of PPU Open Bus didn't match after loading state." – Dwedit

Nostalgia for Classic Games and Design

Several comments shifted towards appreciating older games like Donkey Kong Country 2 and Chrono Trigger, highlighting their enduring quality and how they still hold up today. This nostalgia often intertwined with the discussion of emulator accuracy and bugs.

  • "I know it's OT, but I have to say, for a 30-year-old video game, it's remarkable how well DK Country 2 holds up today. I've been playing it with an emulator and the graphics, sound, level design, and controls are all masterful. The kids can keep Fortnite, I'll take DKC and Chrono Trigger any day!" – jihadjihad
  • "Chrono Trigger holds up. That game is a masterpiece." – christophilus
  • "DKC 1 with the SGI prerendered 3d graphics was cutting edge stuff. Vector Man on the Genesis did something similar to less acclaim." – jgalt212

The Physics and Engineering of Data Buses (Shoutout to Ben Eater)

A specific mention of Ben Eater's work on building a breadboard computer was made, emphasizing the value of his educational content in making complex hardware concepts, such as those related to data buses, understandable to a wider audience.

  • "Once again, I have to give a shout out to Ben Eater, whose video series on making a breadboard computer with the 6502 is why I actually understand what the article is about and what you're referring to when describing the hardware issues. (Obviously, extrapolating from his basic bus example to a commercial machine.) I'd be pretty clueless otherwise." – russellbeattie