Donkey Kong Country 2 and Open Bus

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). Often it's like this case too where things might accidentally work some of the time.

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)

Was there ever an architecture that used dynamic memory with a 6502 CPU? In my (limited?) experience, that platform always had static RAM.

I think you'll find more systems used DRAM than SRAM.

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

Most of them. Static RAM was (and still is) more expensive since it needs more transistors and chip area per bit stored. It it, however, also much easier to interface since it doesn't need refresh circuitry. This is why you see it in the earliest designs, and also why you see it in so many hobbyist designs. It's also why you tend to see it in the video systems even if the rest of the machine uses DRAM. Dealing with DRAM refresh while reading out the whole memory chip sequentially (while also having a second port to read/write from the CPU!) starts making things very complicated.

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.

Well, the SNES - if that counts, it's a 65816 - uses DRAM. This is especially noteworthy because the DRAM refresh is actually visible on-screen on some units:

https://www.retrorgb.com/snesverticalline.html

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.

There must have been computers with 6502 and DRAM.

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.

6502 was my first assembly language, and 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).

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.

The last time I tried an LLM on assembly, it made up instructions that didn't exist.

Are you thinking of SDRAM (a type of DRAM)?

cool; nowadays LLMs are better

I appreciate all of the responses. I did development on a KIM-1 and I owned a SYM-1. Both of these used static RAM. I expanded the RAM in my SYM-1 from 4K to 8K (with eight 2114 static RAM chips). I never owned any other 6502 based computers.

Today I used chatgpt for winapi stuff - it made up structs and enums regarding display config. So not too convinced it'll be any good with 6502 asm.

cool; but not better enough

The mid-1980s Acorn 8-bit range all used dynamic RAM for the onboard memory.

The BBC Micro range all had 250 ns DRAM, with the CPU getting 2e6 accesses and the video getting the other 2e6 (taking advantage of the 6502's predictable RAM access rate). The display memory fetches served to refresh the RAM.

I don't know much about the Acorn Electron, which was very different internally, but it had dynamic RAM as well. I expect the video refresh was used to refresh the DRAM in this case too - as the display memory layout was the same, and so over every 640 microsec it would touch every possible address LSB.

The 6502 second processor had DRAM as well, refreshed by a circuit that ran on a timer and stole the occasional cycle from the CPU at some rate.

Though static RAM was quite common for RAM upgrade boards (of one kind or another), presumably cheaper for this case than the alternative.

Yeah I've been using Claude to review a bunch of m68k asm that I've been working on and it's been helpful at catching silly mistakes like using a direct address instead of an immediate value, clobbering registers, incorrect branches etc.

Of course if you just blindly ask it to write asm it will occasionally invent new instructions or address modes but it's very good at reviewing and making adjustments

The clever thing about the Apple II is that there are no refresh cycles. Woz laid out the screen buffer in memory in such a way that simply scanning out the screen will touch every single row of DRAM.

This is more about saving chips than saving cycles, since the Apple II was implemented entirely with 74 series logic. A more traditional approach that used spare cycles during horizontal blanking would have required several more chips.

It does mean that the layout of the Apple II's screen memory is somewhat insane. Those DRAM chips needed to be refreshed every 2ms, and it takes 16ms to scan out a whole screen. Every 8th of the screen needs to be spread out across all 128 rows.

It's funny because some time ago (months? years?) people would say that you just didn't prompt the LLM well enough. But now LLMs are better and prompting isn't as arcane as before, so the next frontier is giving them the proper context. See this HN thread currently in the front page

https://news.ycombinator.com/item?id=44427757

You also have to be using the exact right model to get reasonable results, which is always the one you have to pay for, not the free one, and also not the one you were using

The Sinclair ZX80 and ZX81 have static RAM internally, which you wouldn't expect for a) a computer that's designed to be as cheap as possible and b) uses a Zilog Z80 which has built-in refresh circuitry.

The reason is that the designers saved a few chips by repurposing the Z80's refresh circuit as a counter/address generator, when generating the video signal. Specifically, it uses the instruction fetch cycle to read the character code from RAM, then it uses the refresh cycle to read the actual line of character data from the ROM. The ZX80 nominally clocks the Z80 at 3.25MHz, but a machine cycle is four clocks (two for fetch, two for refresh), so it's effectively the same speed as a 0.8125 MHz 6502.

I wrote a long section here about how the ZX80 uses the CPU to generate the screen and the extra logic that involves, but it was getting too long :) The ZX81 is basically just a cost-reduced ZX80 where all the discrete logic chips are moved into one semi-custom chip.

Doing this makes external RAM packs more expensive too. You couldn't use the real refresh address coming from the Z80 because the video generator would be hopping around a small range of addresses in the ROM, rather than covering the whole of RAM (or at least each row of the DRAM). The designer has two options:

1. Use static RAM in the external RAM pack, making it substantially more expensive for the RAM itself; 2. Use DRAM in the external RAM pack, and add extra refresh circuitry to refresh the DRAM when the main computer is using the refresh cycle doing its video madness.

I think most RAM packs did the second option.

No, SDRAM means Synchronous DRAM, where the data is clocked out of the DRAM chips instead of just appearing on the bus some time after the Column Address Strobe is asserted. Clocking it means that the data doesn't appear before the CPU (or other bus master) is ready to receive it, and that it doesn't disappear before the CPU has read it.

Static RAM (SRAM) is a circuit that retains its data as long as the power is supplied to it. Dynamic RAM (DRAM) must be refreshed frequently. It's basically a large array of tiny capacitors which leak their stored charge through imperfect transistor switches, so a charged capacitor must be regularly recharged. You would think that you would need to read the bit and rewrite its value in a second cycle, but it turns out that reading the value is itself a destructive operation and requires the chip to internally recharge the capacitors.

Further, the chip is organised in rows and columns - generally there are the same number of Sense Amplifiers as columns, with a whole row of cells discharging into their corresponding Sense Amplifiers on each read cycle, the Sense Amplifiers then being used to recharge that row of cells. The column signals select which Sense Amplifier is connected to the output. So you don't need to read every row and column of a chip, just some column on every row. The Sense Amplifier is a circuit that takes the very tiny charge from the cell transistor and brings it up to a stable signal voltage for the output.

So why use DRAM at all if it has this need to be constantly refreshed? Because the Static RAM circuit requires 4-6 transistors per cell, while DRAM only requires 1. You get close to 4-6 times as much storage from the same number of transistors.

Of course there were. Commodore 64 has dynamic memory, for example.