It's well known that in order to do asynchronous DMA on the 6502 you need to wait 3 cycles between deasserting RDY and accessing the bus. I am intrigued by the fact that a DMA operation is allowed to interrupt the CPU in the middle of an instruction, but not when a write is about to happen.

Does anyone know the reasons behind this? Is it an intentional feature, what practical applications might it have, is it a side-effect of some optimization or shortcut, or is it just an anomaly? Of all the places I've found mention of this, I have not seen any reason mentioned.

OK, actually I've seen it mentioned with respect to the 6510 processor, used in the C64, I'm not sure if it applies to all (NMOS) 6502s.

I was also rather surprised to find that the document archive on this site has datasheets for just about every 6502 variant or peripheral, but NOT for the NMOS 6502 itself... or am I just blind again?

Thanks

Welcome!

I don't know exactly why RDY doesn't stall for writes. It's an interesting question. It might be that it would have cost more transistors to stall writes as well as reads. I suspect it might have been that RDY was only originally needed for reads - specifically, for ROM reads, as RAM at the time of introduction was fast enough but ROM likely to be the limiting factor on system clock rate.

Yeah, realized that after I posted... fixed with an edit. Thanks!

[I would delete this one as well, but can't find a Delete button... ?)

For the datasheets, there are several which cover the NMOS 6502:
http://archive.6502.org/datasheets/mos_ ... g_1975.pdf
http://archive.6502.org/datasheets/rock ... _r651x.pdf
http://archive.6502.org/datasheets/syne ... manual.pdf

Cheers
Ed

(I noted your RDY fix and already removed my note!)

You're correct. At the time of its introduction, the 6502 was slower than the available RAM, but much faster than ROM. Hence only read wait-states were necessary to make the system work. Of course, that soon changed and one of the features introduced with the 65C02 was the ability to respond to RDY while writing.

Incidentally, zero page addressing was developed precisely because RAM was faster than the MPU in those days. The MC6800 had ZP addressing, so it was no surprise that it magically showed up in the 6502.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's because there is no delete button. Everyone knows that once it's on the Internet it never goes away.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ahhhhh.... that makes sense.

Datasheet is helpful... mentions both DMA and clock-stretching for slow ROMs, so it does recognize DMA as a valid application of it... but I suspect you are right about the original intent being for wait states. I've read that the Apple 2 does DMA by actually halting the clock signal, which is one reason I was thinking that DMA might not be an intended use.

Now that I think about it, I recall someone (somewhere online) mentioned the possibility of it being to enhance the integrity of RMW operations, so that when applied to peripheral devices the new value is written shortly after the value it was based on... inserting large amounts of time between the read and write might have odd consequences. Of course, since it happens 2 cycles later, it seems this would never be a perfect fix, as anything that could change over 50 cycles might also change after 2.

Might it also provide atomicity (atomicness? LOL) for locks in a multi-processor bus? At least on the NMOS version I think this would be a benefit, since a (dummy) write cycle begins immediately after the read. But on later versions this benefit probably disappears.

But I doubt those were anything the designers considered...

Oh yeah... BigEd just deleted a line of text... not a whole message.



And.... that is why I have a no-rant policy

Stopping the clock is only practical with the WDC version of the 65C02, and 65C816, both of which have fully static cores. Stopping the clock with any of the NMOS MPU's will cause loss of register content—there's a minimum clock frequency at which the NMOS parts must be run to assure reliability.

If you design something new it should be with the WDC 'C02 or '816, not the NMOS parts. Aside from the clock matter, the CMOS parts fixed errata in the 6502, and added new instructions and new addressing modes for existing instructions. Last but not least, the 'C02 and '816 can run at much higher clock rates.


R-M-W operations on I/O hardware are in that category of things that are frowned upon in the world of professional software development. In executing a R-M-W instruction, the 6502 will do a "dummy" write on the target register before writing the final value, which could result in some strange device behavior. The 65C02 is more benign in that regard, doing a dummy read before the final write. The 65C816 has additional outputs to tell glue logic when access should be allowed.


At the time of its development, the 6502, being a low cost alternative to the then-current Intel, Motorola and Zilog offerings, was not a candidate for a multi-processor system. When the Commodore VIC-20 was introduced in 1980, it effectively had a multi-processor design, as the VIC (Video Interface Controller) used the same buses as did the 6502 to fetch data from video RAM. As the 6502 has no specific control inputs that would allow another device to claim the buses (no BE input, as is present on the 'C02 and '816), Commodore had to use external silicon to get the two devices to cooperate. The C-64 and C-128 also had this issue.

The WDC 65C02 and the 65C816 have an output—MLB—specifically intended to address bus contention issues during R-M-W instructions. MLB is normally high, but goes low during the cycle in which the MPU writes out the final value to the location being modified. That tells other potential bus masters that they must not attempt to claim the bus.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I don't think the Z80 was early enough to influence the 6502 design. I would think that first generation of microprocessor designers would be learning what they could from minicomputers.

Note that a stalled clock is not a stopped clock - it's certainly possible to have irregular clocks to allow things to happen. It looks like the Apple II just has a mildly irregular clock - doesn't miss a beat, and RDY is not used in an unexpanded system:
"most 6502 cycles are 978 nS long, but every 65th cycle is 1117 nS long."
- http://mirrors.apple2.org.za/Apple%20II ... df#page=29

Without violating the NMOS minimum spec you mentioned, cycle-stretching to accommodate a slow device is readily possible, as are short-to-moderate DMA bursts. The first sentence of the quote above seems like an overly broad generalization.

Another generalization? This view of R-M-W operations on I/O isn't unanimous. In the 'C02/'816 context, the Eyes & Lichty manual says, "The test-and-set instructions are highly specialized instructions intended primarily for control of memory-mapped I/O devices." And, in context of the NMOS 6502, MOS Technology's MCS6500 Microcomputer Family Programming Manual deems R-M-W with I/O hardware worthy of mention and explanation, even to the point of including an illustrative code snippet (Example 11.7, which demonstrates the use of the ROL instruction on a PIA).

IMO caution with R-M-W is warranted when using a 65xx CPU with I/O devices from other families, but this is not the typical case.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That technique was used in the C-128 during I/O block accesses due to the I/O hardware (excepting the 8563/8568 VDC) being rated for 1 MHz operation.


No. I was specifically addressing the use of R-M-W instructions on the 6502, which can cause grief with I/O devices due to the spurious write as the instruction is processed.


The test-and-set instructions do not exist in the NMOS parts, therefore the manual's statement would explicitly reference the 'C02 and '816.


Yes, I am aware of that, but stand by what I said regarding use of them vis a vis the NMOS MPUs. Also, use of R-M-W with the 65C02 could potentially cause issues with some hardware due to the spurious read before the final write. As always, caveat emptor.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ed, any idea how long the NMOS 6502 can be stopped before the leakage messes up the state ?

I think I've guessed before that a few milliseconds might be possible - based on the necessary refresh rate of DRAM. It will vary by temperature and supply voltage, and vary between batches of parts. DRAMs are of course made as small as they can be without losing reliability, so the big solid transistors in a 6502 should behave better.

I've a feeling Garth might have offered some answer to this in the past.

But the bottom line is that I don't know!

Ah, I see 50kHz minimum is mentioned on a datasheet. That gives a max cycle time.
http://archive.6502.org/datasheets/mos_ ... v_1985.pdf
via viewtopic.php?f=4&t=3371