Re: Blurry picture

Hi!,


On 2011-11-18 20:52, Segher Boessenkool wrote:
>... 
> You mean it generates its own #CS from the address pins?  That will almost
> certainly cause #CS to be active earlier than the data showing up on the
> data pins, sure.

Hmmm, I think I don't really understand something. Or two things, actually.

First, in my notes, I can see that on a write cycle, address is set up
first (which is probably translated to an internal CS' signal in the
TED), then data gets stable, then R/W' is pulled low. So, that's true,
CS' may be generated prior to the data to be written was known. "But"...
The TED only ever needs to sample its data inputs when data is to be
written to some of its registers. In turn, register write is triggered
by accessing the appropriate address, _and_ pulling R/W' low. At that
particular minute, data is already stable, without doubts.

Second, even if data was to be sampled before R/W' actually goes low, I
can't see that this structure could behave like the chip actually does.
In practice, the dots are always of color code $7f. On the affected
VIC-I and VIC-II chips, similarly, color code is always the possible
"highest" one ie. all bits = 1. Contrary to that, the data bus doesn't
go back to $ff  each time the chips leave it floating (for some time).
There are test programs that take advantage of that behaviour, ie. read
from unconnected address space in order to catch data read by the VIC or
TED in previous cycles. I can remember Marko's $dadb test routine that
ran entirely in unconnected address space. Now if data was picked up
from the data bus, the color code (and so the color) of the appearing
dots would just need to change with the actual content of the data bus.
...But they actually never do, consequently, the invalid data should not
come from the data bus.

However, the hint that delaying CS' practically fixes the problem in the
C64 is valuable, because it might point to the right direction. If
someone said that some "internal" data bus of the VIC or TED is too
slow, or possibly gets confused by the interrupted read operation (CS'
with R/W' high first, then R/W' going down), I'd be less skeptical.


Best regards,


Levente

       Message was sent through the cbm-hackers mailing list