10

The 6502 series of CPUs has an interesting quirk: indexed loads and stores may perform a "false read", reading from the target address or a different address on a previous page. There are situations, such as code for the Disk ][, where this can be advantageous.

I have two closely-related questions about this...

  1. What are some examples of how this was used deliberately?

A well-known example is discussed on page 9-22 of Jim Sather's Understanding the Apple II. A write to $C08F,X is used to keep the address on the bus for two consecutive CPU cycles. Was the feature used for other devices? Why?

  1. How did CPU behavior change with later CPUs? Put another way, what are the best practices for taking advantage of the feature across all members of the Apple II product line?

Apple used the 6502, 65C02, and 65C816 in its product line, and the false-read behavior changed a bit in the later CPUs. I read that initial versions of the 65816 removed the behavior, but it was restored to prevent older Apple II software from breaking. Apparently the final behavior of the 65816 is actually closer to that of the original 6502 than the 65C02.

I would also be curious to know if the behavior was removed from production chips used in non-Apple products, e.g. if you managed to fit a Rockwell 65C02 (with BBR/BBS etc.) into an Apple //e would disk writes fail.

Improve this question
5
  • 1
    Hmm. Nice question. Say, so you have any citation for "I read that initial versions of the 65816 removed the behavior"? After all, each and every cycle is a memory cycle on a 6502, so the false ready can not be removed - well, unless the internals are changed entirely and the cycle is dropped in whole.
    – Raffzahn
    May 16 '20 at 21:23
  • 1
    @Raffzahn: there's a reference to Cortland (Apple IIgs) docs here. The false read was apparently removed from (DP),y on the 65C02 (based on Nick Westgate's experiments on an Apple II later in that same thread), but restored in the 65816, so some changes were being made.
    – fadden
    May 16 '20 at 21:40
  • Cool. Then again, I'm using an 65SC02 with my II since that CPU came out. I never ever had issues with the drives, so either the SC02 doesnt have it (don't think so, as it really saves a few cycles on certain instructions), or it doesn't matter as much as you assume. Oh, and ona sice note, some NMOS versions also do double writes.
    – Raffzahn
    May 16 '20 at 22:03
  • I don't think the false read behavior was really "advantageous" for the Apple Disk II, but the controller state machine had to be designed for it to either always occur or never occur. I suspect that if the controller were designed for "never" figure that code to write a sector would use be patched in RAM to use non-indexed absolute addressing], it may have been possible to allow a GCR byte indexed by X to be written via BIT $C0_D / CMP table,X / BIT $C0_C without disturbing A or X, facilitating on-the-fly encoding. Figure that with DB6 on, the state machine would always trigger...
    – supercat
    Jun 12 '20 at 21:27
  • ...a flux transition on the eighth succeeding transition, simultaneous with fetching a byte, which would then stall the state machine until DB6 was turned off, at which point it would perform a flux reversal or not based upon the MSB of the shifter and then start shifting out data every 8 ticks after that. The data to be written would need to be pre-shifted left by a bit (no need to specify the MSB, since it would always be set), but for table-driven code that shouldn't matter.
    – supercat
    Jun 12 '20 at 21:33
4

The 65802 and 65816 were specifically designed to retain certain bus-timing quirks of the NMOS 6502, because some Apple ][ hardware had been designed to exploit it, and Apple was the primary customer for the 65816 (ie. the ][gs). The 65802 was intended to be a 65816 software-compatible drop-in upgrade for NMOS 6502s, and internally was mostly a 65816.

The 65C02, by contrast, was designed to eliminate some of these quirks, by converting dummy writes to dummy reads, and directing dummy reads during index addressing modes to benign addresses. Hence, some cycles that on the NMOS 6502 could cause a spurious write to an I/O device register would instead perform a harmless dummy read to zero page or the current PC address. Most system designers prefer that to the NMOS behaviour.

The 65816 does, however, have explicit signals (VDA & VPA) to indicate whether any given bus cycle is a "dummy read", which makes it much easier to design an I/O device to ignore them.

Improve this answer
4
  • That reasoning doesn't really make much sense, as Apple already used the 65C02 in all their Apple II lines before the IIgs development started - IIc delivered(!) with 65C02 since 1984 and IIe Enhanced since 1985. Heck, they even pushed existing IIe users to use a 65C02 with their enhancment kit
    – Raffzahn
    May 17 '20 at 14:38
  • @Raffzahn Nevertheless, that is the rationale given by Bill Mensch as to why the 65816 bus timing is so much more similar to the NMOS 6502.
    – Chromatix
    May 17 '20 at 22:03
  • I know, I did read it as well, still, it doesn't make sense. So either there's more to it, or the story contains some hindsight added when told.
    – Raffzahn
    May 17 '20 at 22:45
  • 1
    65816 development started in 1982 and it was due in 1983, and Apple IIgs (originally IIx) development started in 1983, only to be cancelled and then resurrected in the same year: 1984.
    – Nick Westgate
    May 18 '20 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.