Re: 6502, 6510 tri-state

From: silverdr_at_wfmh.org.pl
Date: Fri, 30 Nov 2018 15:11:51 +0100
Message-Id: <D2C82DF6-F867-4870-BA64-9DF8E2EEC0E5@wfmh.org.pl>
-- 
Sent from mobile device. Please have understanding. 

>> On 30 Nov 2018, at 01:17, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> 
>> On Fri, Nov 30, 2018 at 12:48:17AM +0100, silverdr@wfmh.org.pl wrote:
>> I've got a question I can't answer out of my head and can't currently set any test bench for - how does the 6502 and 6510 behave when it comes to getting off the bus. I know we can make 6510 off the address bus with the additional line that is not available in 6502 but the question is: does any of the two (especially 6510, which surely has the ability) get off the bus by itself like during other phase of the clock cycle?
> 
> The 6502 always drives all address pins.  The 6510 whenever AEC is high.

Roger. AEC is the additional line I was referring to above.

> 
>> IOW - if put into a tight loop like:
>> 
>> 1000 - JMP $1000
>> 
>> will all the address lines (except the two lowest ones, obviously) remain unchanged and continuously driven by the CPU? Or will those only be driven during active clock phase?
> 
> On a 6502: yes.  On a 6510: AEC is an *input*.  For example on the C64
> it is driven by the VIC-II, and that pulls AEC low every first half clock,
> and those second half clocks it steals, too.

Does this happen all the time, regardless of whether the VIC is "blanked" (bit 4 of SCROLY if memory serves)?

If yes, then is there a (software) way to make it stop doing that?

> 
> AEC also control R/#W and the data bus (which of course the 6510 only
> drives whenever it is writing to memory).

The role of AEC is clear. The question came when the address lines of a 6510 were said not to remain constant even if VIC was supposedly blanked and therefore the expectation was that it would not need to touch AEC. I thought in such configuration the 6510 would behave the same as 6502, namely drive the address bus all the time. 
Received on 2018-11-30 16:00:08

Archive generated by hypermail 2.2.0.