BryanParkoff@yahoo.com (Bryan Parkoff) writes: >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. This is all a consequence of the fact that the 6502 has an 8-bit ALU. It cannot add the 8 bit index to the 16 bit address and propagate the carry in one cycle. It needs a 2nd cycle. If the instruction is a read (LDA etc) add the addition does not need a carry the processor does the instruction in one less cycle. If the addition does need a carry (or the instruction is a write (STA etc)) then the instruction takes the extra cycle and generates a false read. >> > 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. > Can you please comment why WDC did not fix 65816's invalid address >bus? I am very curious. I seem to recall that the 65816/65802 was made more compatible with the 6502 than the 65C02 was. See "Programming the 65816: Including the 6502, 65C02, and 65802" by David Eyes, Ron Lichty (or even the 65816 data sheet) for more info. -- David Wilson School of IT & CS, Uni of Wollongong, Australia Bryan Parkoff replied: >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. That's a great way to find out what it actually does. > 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. If I understand what you are saying, yes, the extra cycle is needed because the high byte must be incremented to get the real target address. The processor will always latch _something_ when it issues a read cycle, whether it is meaningful or not. The value in this case is discarded inside the processor, so it is irrelevant. The only effect, as you have surmised, is the side effect on any associated softswitch. Reading many softswitch addresses does not cause anything to drive the data bus, resulting in the processor latching the data on the bus during the previous video cycle. This unintended behavior permits some surprising and wondrous effects. (See "Vapor Lock" by Don Lancaster.) > 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. Correct. But this is a different kind of "vigilance" than watching for possibly misplaced phantom reads of the kind you describe above. In the Apple II, most "active" I/O addresses are in the $C0 page, so indexed references to page $C1 are the ones that can have unintended effects. Of course, nothing stops a peripheral designer from putting I/O addresses with potential side effects in the $Csxx space, in which case page $C1 up to $C8 can all result in troublesome phantom references. Note that it's only reads with side effects that are a concern--for example, a read that sets or resets a softswitch, or a read of an ACIA register that clears status. > Can you please comment why WDC did not fix 65816's invalid address >bus? I am very curious. _Invalid_ is a little strong, since it is simply reproducing exactly the same behavior exhibited by the 6502, and presumably already allowed for by software and hardware designs based on that architecture. You could say that this is taking compatibility a bit far, but a case could be made for either leaving it, as WDM did, or "fixing" it, as 65C02 designers did. When a bug has a long history, some consider it a "feature". ;-) Remember that the 65C02 wouldn't run a few 6502 programs that were written to depend on the "jump indirect to end of page" bug. -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/