>> ... >> 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 listReceived on 2011-11-19 03:00:13
Archive generated by hypermail 2.2.0.