Re: 6502 trashing memory cycles...

[dempson@actrix.gen.nz (David Empson)]

bieling@terra.es <bieling@terra.es> wrote:

> Given that most of the instructions have memory cycles to "offer", I'm
> wondering if a faster-clocked CPU would very likely have provided
> enough memory cycles so as to have done the both the video memory scan
> and refresh "for free", i.e., without sacrificing half of the memory
> bandwith as have been done in the Apple II.

I'd dispute that "most" instructions have spare memory cycles. It may be
that somewhat more than half have a wasted memory access cycle, but the
more commonly used ones don't waste cycles.

For example, all immediate, zero page and absolute instructions don't
waste any memory cycles, but indexing does, as do all single byte
instructions, which have a minimum of two cycle execution time.

Typical code patterns would result in "spare" cycles only appearing
intermittently. You certainly can't guarantee a minimum number of spare
cycles within any particular period of time for arbitrary code
execution, which limits the usefulness of stealing these cycles for
something else.

I'm not sure why the 6502 needs to waste a cycle for things like NOP or
INX. The 6801 derivative I used at work (Hitachi 6303) managed to
execute these in one cycle.

> Another clever idea would have been to steal cycles to fecth data for
> sound generation, in a similar way to what was years later done in the
> original Mac.
> 
> The problem is that certain sequences of instructions may not provide
> enough free cycles for that purposes, but I think that the probablity
> for such a sequence to happen is very likely very small...

Lots of code does thinks like LDA immediate, STA somewhere, repeating
for further locations. This could easily go on for ten or twenty
instructions with no spare cycles.

-- 
David Empson
dempson@actrix.gen.nz