Re: Blurry picture

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

The address output from the CPU is tristated when not AEC; and the data
output is tristated when not DBE.  DBE is generated internally by the
6510, it is the CPU Phi2 (which is the external Phi0, delayed -- the
VIC Phi2, delayed, later than AEC?).  Address and R/#W are stable before
AEC is active (but tristated, so not stable on the bus yet).

I think this is the same with TED?

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

The way it works on VIC, and probably also on TED, nothing is triggered,
that is, it is not edge-sensitive but level-sensitive; i.e., as long as
#CS and #WR, the selected register reflects what is on the bus.

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

Right, I see your point there.  Loading the VIC images, this will take
a while...

... okay done.

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

The colour registers cannot change until WR is active (that's the  
internal
signal, active when both #CS low and R/#W low).  The output colour  
bus is
precharged, but it's negated so that cannot explain the observed  
behaviour.
So, what is happening must be that when a grey dot is produced, WR is  
active
and the internal data bus is high.

There are two thing that can drive the data bus relevant to this: it can
be driven from the data pins, when a signal I call enDin is active;  
or it
can be precharged, when preD is active.  So let's look how those are
generated :-)

We have

	enDin = (phi1 or (phi2 and enA) or wr) and not 2phi1
	preD = 2phi1 and 4phi2

[2phi1 is the first phase of the 2MHz clock, etc.]
[Why 4phi2 there and not 4phi1?  I have no idea, it could be wrong even]

So that is pretty much it: the data pins do not drive the internal VIC
data bus during the first half of the CPU write to a register (or any
other VIC 2MHz cycle); the internal data bus is precharged during that
time.

So then why doesn't it happen on non-C C64...  Okay, opening another
huge chip image (65xx VIC-II) and fetching tea...

(...time passes...)

...it's still not done.  Will report later.  I also should look at when
exactly AEC is generated (I think that is different between 65xx and  
85xx
actually).


Segher


       Message was sent through the cbm-hackers mailing list