Re: 6502 / 65C02's Invalid Address Bus

[BryanParkoff@yahoo.com (Bryan Parkoff)]

mjmahon@aol.com (Michael J. Mahon) wrote in message news:<20040911034154.17374.00000492@mb-m27.aol.com>...
> Bryan Parkoff wrote:
> 
> >I find an interesting issue that invalid address always occur when
> >page boundary is crossed.  Low Byte of Address Bus is always correct,
> >but High Byte of Address Bus is always invalid until extra cycle to
> >correct High Byte of Address Bus.
> >    Understanding Apple //e manual claims that 65C02 has fixed invalid
> >address on fourth cycle, but 65816 is not fixed.  I have not tested
> >Apple //e and Apple //c yet.
> >
> >For example.
> >
> >0FFE: LDX #$FF
> >1000: LDA $C051,X
> >1003: RTS
> >
> >6502
> >X = FF
> >Cycle 1
> >Address Bus: 1000
> >Data Bus: BD
> >Cycle 2
> >Address Bus: 1001
> >Data Bus: 51
> >Cycle 3
> >Address Bus: 1002
> >Data Bus: C0
> >Cycle 4
> >Address Bus: C050
> >Data Bus: IGNORE
> >Cycle 5
> >Address Bus: C150
> >Data Bus: DATA
> >
> >    65C02 should always place 1002 instead of C050 on fourth cycle
> >before it places C150 on fifth cycle.  I give three example
> >instructions from $0FFE through $1003 for you to test on Apple II+,
> >Apple //e, and Apple IIgs, but I have not tested Apple //e yet.
> >    You run at *FFEG.  See what happen...GR (Low Graphic Resolution)
> >is turned on at $C050 on fourth cycle since it is always in TEXT
> >screen.  Please let me know what you find this out.  What do you
> >think?
> 
> I think that the 6502 designers accomplished a great deal
> with very little logic, and spent relatively little time on the
> details of states they considered "don't care".
> 
> It is true that placing "unreferenced" addresses on the bus
> for a processor that must always either read or write (since
> there are not separate "read" and "write" request lines) can
> create some issues for memory-mapped I/O.  It is necessary
> to consider what "phantom" addresses might be generated
> while code is running to avoid problems.  This is not, in
> general, very difficult, though it would be nice not to have
> to consder it at all.
> 
> In the specific case of the Apple II, people who write
> $Csxx slot ROM code must consider these effects.
> 
> (BTW, your sugestion to re-fetch $1002 above is probably
> inconsistent with the implementation.  I would expect that
> the program counter has already been incremented to $1003,
> but that should generally work, too.)

    I have tested 65C02 today.  It shows address bus at $1002 instead
of $C050 at fourth cycle.  I don't think that it is really $1003, but
it should be $1002.  If I prove to be correct, I will put 16 LEDs to
65C02's 16 address bus' pin to test.  I will trace at one cycle at
this time using Ready line.  Then I can be able to determine address
bus and data bus by observing 16 LEDs.
    I suspect that data bus is never ignored, but it might contain
data at fourth cycle.  It is possible to get data from data bus at
$C050 on 6502 and $1002 on 65C02 on fourth cycle.  It is possible that
fourth cycle needs data from data bus while it can increase or
decrease data before it can be stored in Address Absolute High Byte.
    I agree that assembly programmer must be very careful to
manipulate I/O device.  If they work Disk II Drive, and they desire to
replace from LDA $C08F,X to LDA $C0EF, write routine of RWTS will fail
because it has only one strobe.  It needs to be two strobes, but LDA
$C0EF,X is acceptable if X = 0.  I think that strobe means cycle.  It
receives one cycle for data bus at this time.  Then, another
instruction receives two cycles for two data bus at different time.
    Can you please comment why WDC did not fix 65816's invalid address
bus?  I am very curious.

--
Bryan Parkoff

> 
> -michael
> 
> Check out parallel computing for 8-bit Apples on my
> Home page:  http://members.aol.com/MJMahon/