6502.org

Hello!

I'm sorry if I missed the post that already contains an answer to my question.
I'm wondering what are the hard limits of cycle stealing for 6502, Sally (Atari version of 6502), 6510 and CMOS 6502(that I assume is available as of today)? Such behavior would of course pose a problem for a programmer (leaving him/her almost without cpu cycles), but if we assume that the dma is so powerful/sophisticated that it's worth doing, how far could we go?

Welcome!

By 'cycle-stealing' it sounds like you mean stalling the CPU while something else has use of memory. I don't see any hardware reason why you couldn't do that indefinitely. What would probably limit you in a realistic system is any realtime nature of the software environment. For example, interrupt latency would be increased, user interfaces might stutter or be perceived as unreliable, audio and video outputs would not be updated. For human interaction, a few tens of milliseconds stutter might be about as much as would be tolerable. For audio output, latency is very important, although I don't have a number for it. (It seems MIDI clocks at around the millisecond level.)

Welcome, pokey

You need to consider whether the CPU is stopped via the RDY input or via clock stretching.

NMOS members of the 6500 family have a limit to how far the clock can be stretched; this is listed in the data sheet as the maximum pulse width for the clock input -- ie, how slow the CPU clock can be. Exceeding the limit can result in data loss -- the CPU will become unreliable. Anecdotal reports indicate the spec is very conservative, and can be exceeded by a large margin. Nevertheless you can't stretch the clock indefinitely (with NMOS).

Modern WDC 65C02 processors can tolerate indefinite clock stretching. Rockwell and other vintage CMOS chips can also be stopped indefinitely but only with the clock input in the high state. All of this info (except the anecdotal reports ) can be found in the pertinent datasheets. For some related background you may find my Visual Guide to 65xx CPU Timing helpful.


For all 6500 CPU's the RDY input can be used to stop operations indefinitely. (Slight exception: with NMOS CPU's RDY won't suspend a write cycle; the CPU will halt on the next read instead.) Of course you'll still need to consider the limitations Ed mentioned.

Do you have a project in mind? We'd be glad to hear about it!

cheers
Jeff

(Very good point about clocking!)

Thank you very much for you responses!
I'm pondering on a design of something like the essentials of 6502-based home computer that could have been made in a400/a800 era. Given that I'm totally clueless when it comes to electronics I'm almost certain that I'll never get it done but still can't stop - it's too much fun. No hardware to speak of at the moment unfortunately - I'm still validating the higher level aspects of the design (bolting the 'chipset emulation' on 6502 emulator and playing with it, e.t.c.)
If I remember correctly Atari (before Sally) had to go for clock stretching and I don't remember why (my guess is that RDY is leaving the bus in a state they where not happy with, but I really need to look it up)
I intend to place that burden on the programmer (damage control for lost cycles), but I'm planning a really simple system where I beleive it's not very hard to do.

Cool. So a retro vision, but implemented in FPGA?
Hmm. Reading that, I'm reminded of an entertaining remark from one of the other forum members: I'm also unsure, but it could well be because of the "slight exception" I mentioned -- ie, that, with NMOS CPU's, the RDY input won't halt a write cycle. That could be a show-stopper if -- as with video -- timing irregularities can't be tolerated. So, not exactly slight, in those circumstances.

-- Jeff

If I recall correctly, the most that the CPU will do is three write cycles in a row (for IRQ response). Throwing a small FIFO into the design that will stall the CPU if possible whenever the FIFO is less than full could cover for that scenario (the FIFO will basically always have at least one byte of data ready, so the output timing becomes predictable). That said, this is an off-the-cuff thought, and maybe clock stretching is or was either easier or cheaper.

Honestly, as software (rather than hardware) guy I'd be perfectly happy with just an emulator. However it's no fun unless I keep it within Atari's gate/money limits, and the closest I can get to substantiating that claim is to implement it in FPGA (not just in one chip but rather implementing each chip separately pretending they're in DIP-40 or lesser package) and paying attention to the older chip limits.

Interesting challenge - do post updates!