Worse than the floating-bus in this example is when it depends on uninitialized RAM which is often consistent based on DRAM so the code will always work on your machine/emulator but won't on someone else's machine with different DRAM chips (invariably you catch this at a demoparty when it won't run on the party machine and you only have 15 minutes to fix it before your demo is about to be presented)
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
But still DRAM is what you would use for a "real" system. 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.
For higher memory capacities, e.g. 32 kB, 48 kB or 64 kB, static RAM would have been too expensive and too big, even if 6502 did not have an integrated DRAM controller, like Zilog Z80.
Using SRAM instead of DRAM meant using 4 times more IC packages, e.g, 32 packages instead of 8. The additional DRAM controller required by DRAM would have needed only 1 to 4 additional IC packages. Frequently the display controller could be used to also ensure DRAM refresh.
Not quite related, but i get a similar feeling if the game seems really tough: "is this due to emulation latency". I went down a rabbit hole on this one and built myself a mister FPGA!
Sometimes it does feel that way...
After reading, I realized that he just meant that the bus was "open" as in not connected to anything, because the address line decoders had no memory devices enabled at the specified address ($2000).
It's pretty funny that the omission of the immediate mode (#) went unnoticed until the obsolete emulator didn't behave in the same way as the real hardware when reading <nothing> from memory.
His solution of changing the instruction to use immediate addressing mode (instead of absolute) would have the consequence of faster execution time, because the code is no longer executing a read from memory. It's probably now faster by about 2us through that blob of code, but maybe this only matters on bare metal and not the emulator, which is probably not time-perfect anyway.
(Some) SNES emulators really are basically time-perfect, at this point [0]. But 2us isn't going to make an appreciable difference in anything but exceptional cases.
[0] https://arstechnica.com/gaming/2021/06/how-snes-emulators-go...
That means the 2 clock cycles could theoretically make an observable difference if they cause the CPU to miss a frame deadline and cause the game to take a lag frame. But this is rather unlikely.
When byuu/near tried to find a middle-ground for the APU clock, the average turned out to be about 1025296 (32040.5 * 32). Some people have tested units recently and gotten an even higher average. They speculate that aging is causing the frequency to increase, but I don't really know if this is the case or if there really was that much of a discrepancy originally.
It does cause some significant compatibility issues, too, like with attraction mode desyncs and random freezes.
IIRC ZSNES actually had basically no timing; all instructions ran for effectively one cycle. ZSNES wasn't an accurate emulator, but it mostly worked for most games most of the time.
Donkey Kong 64 has a memory leak that will kill the game after a (for that era) unlikely amount of contiguous time playing it (8-9 hours, if I understand correctly). That was not caught in development but is a trivial amount of time to rack up if someone is playing the game and saving progress via emulator save-state instead of the in-game save feature.
(Note: there is some ambiguous history here. Some sources claim the game shipping with the Memory Pak was a last-ditch effort to hide the bug by pushing the crash window out to 13-20 hours instead of 8-9. I think recent research on the issue suggests that was coincidence and the game didn't ship with either Rare or Nintendo being aware of the bug).
In order to understand what actually happens, we need to look a little closer at the physical structure of a data bus -- you have long conductors carrying the signals around the motherboard and to the cartridge, separated from the ground plane by a thin layer of insulating substrate. 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.
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).
There's also speedrun strategies that rely on open-bus behavior as part of memory-corruption or arbitrary-code-execution exploits, such as the Super Mario World credits warp, which sends the program counter on a trip through unmapped memory before eventually landing in RAM and executing a payload crafted by carefully manipulating enemy positions [1].
But there's some exceptions to the usual predictable open bus behavior. Nonstandard cartridges could return a default value for unmapped memory, or include pull-up or pull-down resistors that impact the behavior of open bus. There's also an interesting interactions with DMA; the SNES supports a feature called HDMA which allows applications to schedule DMA transfers to transfer data from the CPU to the graphics hardware with precise timing in order to upload data or change settings mid-frame [2]. This DMA transfer temporarily pauses the CPU in order to use the bus to perform the transfer, which can change the behavior of an open-bus read if a DMA transfer happens to occur in the middle of an instruction (between reading the target address & performing the actual open-bus read).
This very niche edge case has a significant impact on a Super Metroid speedrun exploit [3] 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. This has created a mild controversy in the community, where some routes and strategies are only reliable on emulators and nonstandard firmwares; a player using original hardware or a very accurate emulator has a high chance of experiencing a crash, whereas most emulators (including all of Nintendo's official re-releases of the game) do not emulate this niche edge case of a mid-instruction HDMA transfer changing the value of an open-bus read.
Also, the current fastest TAS completion of Super Metroid [4] relies on this HDMA interaction. We found a crash that attempted to execute open bus, but wasn't normally controllable in a useful way; by manipulating enemies in the room to influence CPU timing, we were able to use HDMA to put useful instructions on the bus at the right timing, eventually getting the console to execute controller inputs as code and achieve full arbitrary code execution.
[1]: https://youtu.be/vAHXK2wut_I
[2]: https://youtu.be/K7gWmdgXPgk
mock-possum•4h ago
shadowgovt•2h ago
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. Some animations in Super Mario Bros 3 involved toggling a RAM mux to select from multiple banks of sprite data so that when the graphics hardware went to pull sprites, it'd pull them from an entirely different chip with slight variations in their look. And since the TV timing mattered, they had to release different software for regions with NTSC and PAL TVs since those TVs operate with different refresh rates and refresh rate was the clock that drove the render logic.
It was a wild time.