[deater]

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)

[anonymousiam]

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

[retrac]

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.

[tom_]

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.

[wk_end]

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

[adrian_b]

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.

[deater]

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

[jackettm]

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

[Braxton1980]

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

[RiverCrochet]

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

[bartread]

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.

[nancyminusone]

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

[bogantech]

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