Re: 6502 trashing memory cycles...

["bieling@terra.es" <bieling@terra.es>]

On 5 mar, 05:18, Mark McDougall <m...@vl.com.au> wrote:
>
> It's called 'pipeling'. For example memory cycle 2 is not "wasted" - at
> this point the opcode has not been decoded and the cpu _has no way_ of
> knowing whether or not the next byte in memory is required as an
> operand, for example. So the system pipelines the operation by fetching
> the next byte in case it is required. If you 'stole' that memory cycle
> then you'd slow down every instruction that required more than a single
> byte.

I'm not saying that the 6502 doesn't internally do something useful
during that cycles.
I'm saying however that whatever it is, during these cycles, accessing
the memory is not neccesary.
During these cycles it does un-needed memory accesses.

> How do you propose that an external circuit can 'know' which cycles it
> can steal??? Even if you could use the cycles, how could it possibly
> 'know' that the CPU was fetching, say, RTS rather than data that
> corresponded to an RTS opcode? Your logic would require a state machine
> similar to the instruction decoding logic within the CPU itself. And
> even with all that, it would have to disconnect the CPU from the bus
> before the next cycle started.
>
> Regards,

The circuit would have to monitor SYNC marked cycles in order to check
the fetched opcode, then start an n-cycles state machine (a function
of the fetched opcode) that flags the free/available cycles that can
be stealed. The CPU would have to be isolated from the address/data
bus during that cycles, in a DMA-style but without stopping the cpu's
phase 0 clock.

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.

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

I found this an interesting AppleII-logy matter to think about...
isn't it ?
Would you, dear AppleII-logist colleagues, mind to comment about
this ?

Regards,
Jorge.