An Amiga 1200 exposes the entire CPU bus on the expansion port, so that an accelerator only needs to assert BR which causes the onboard CPU to stop all computation and electrically disconnect from the bus entirely, and then wait for BG which should mean that the CPU on the accelerator is ready to consider itself the Master Of The Bus.

Or something.

And in the case of the Commodore 64, the VIC-II asserts the BA so that it can completely take over the bus.

The thing is, I don't see anything like BA, BR or BG on the Apple II slot. So what's unclear to me is, when a CPU is added to the Apple II, how it takes over the control. I suppose it would be problematic if the 6502 was still running. Take the Z-80 Softcard. It's got a CPU obviously, and a handful of TTL for glue logic. But it does not have any RAM. It just uses the same RAM which is already installed in the computer. This means that if some application is running on the Z80, its state might get clobbered by whatever the 6502 is doing.

TL;DR how do CPU cards work on the Apple II if there's no way to take the bus over?

  • I can see that PHI1 and PHI2 are available on the slot, but these are presumably outputs, not inputs. Commented Oct 29, 2018 at 10:24
  • 1
    Isn't that exact what the DMA signals are for, as in retrocomputing.stackexchange.com/questions/5633/… ? Asserting DMA is supposed to halt and isolate the CPU such that the card now gets ownership of RAM.
    – Tommy
    Commented Oct 29, 2018 at 11:53

1 Answer 1


how do CPU cards work on the Apple II if there's no way to take the bus over?

That's what /DMA (pin 22) is good for. It halts the CPU and tristates the bus. Now any card can take over.

Unlike its daddy, the 6800 (and many other CPUs as well), the 6502 can be halted in at any clock state by pulling /RDY. It will extend the actual cycle (*1). This doesn't tristate the bus or anything else, and is primarily meant to allow singlestepping and support slow memory, but can do DMA as well. Not very sophisticated, but it does the job.

On the Apple II Woz added a bunch of buffers to tristate the address bus when needed. When DMA gets pulled, the CPU will get its /RDY pulled and the buffers will tristate the address/data lines.`

Video update and RAM refresh will continue as before - The Card May Only Access the Bus During Phi0, even with DMA pulled continuous, as video and refresh logic will access the RAM during Phi1 (*2)

But there are Apples fited with a NMOS 6502 (*3). Due its dynamic nature (*4) it needs to do some workout to keep the register content intact. In general, one successful cycle every 10 cycles will do it (*5, 6). Each card needs a appropriate solution.

This can be some counter halting the card every 4th, 8th or 16th cycle and hand one cycle to the 6502, or maybe there are times where the card's CPU doesn't need the bus, which may be always handed over to the 6502 (*7)

The Z80 card is doing the later, as the CPU needs an internal cycle after each opcode fetch (signaled by M1), where no bus activity happens. relinquishing that to the 6502 makes it happen often enough (*8) without throttling the Z80 at all.

Apple has published a detailed information about DMA handling in their Technical Note Nr.2 for the Apple IIe. While there are some differences with the Apple II, and even more with the IIgs, it does give a good base to understand the workings without traceing schematics.

*1 - Well, it shouldn't be pulled within a write cycle, as the CPU will not repeat such. Then again, when pulled during Phi1, it will always stop.

*2 - So no, there is no chance to access the RAM at 2 MHz from an I/O card. Would have been nice, wouldn't it?

*3 - so if the card needs only to work with a CMOS like in an enhanced IIe, it will be possible to use all cycles.

*4 - The registers are basically dynamic memory and need refresh.

*5 - It's said that a MOS/Rockwell chip can do 10-17 cycles without, while a Synertec is guaranteed to do 40.

*6 - yes, this means the 6502 is active running at maybe 5-10% speed. So here's your chance for real dual CPU action.

*7 - If these holes are common, the 6502 may get even more usable CPU time.

*8 - Well, going by the books there are some instructions (most notably all modifying with index register + displacement addressing like INC or RES) which need 23 cycles. Since the Z80 runs at double the 6502 clock (*9), this ends up being 12 cycles, thus still on the good side.

*9 - Well, it's way more complicated than that, but also a great example of clever hardware design. The Z80 runs from the Apples 7 MHz clock, divided by two but only during Phi1 which will result in a full and a half cycle in the first 6/7th of Phi1 plus the other half of the second stretching over the rest of Phi1and all of Phi0. Effective clock speed is 2.04 MHz, with a non symetric clock (*10). Some instructions are extended by one of the 'short' cycles to synchronize for memory access, making it a little less than 2 MHz in average. Not much.

*10 - Needing a 3.5 MHz Z80 to do so.

  • 1
    Ah, DMA is maybe a misnomer then. Does the CPU card need to implement some DRAM refresh while DMA is asserted? Commented Oct 29, 2018 at 11:57
  • 3
    It's not technically a misnomer; you want direct access to memory, you get direct access to memory. Though I guess that the fact of the 6502 being disabled is only an implication?
    – Tommy
    Commented Oct 29, 2018 at 12:13
  • 1
    Access has always to be synchronized with the rest of the system - nothing different on the Apple. And yes, such cards where available. Just way more expensive than basic cards. While in the early 80s a Z80 clone card could be bought at less than 50 USD, one with it's own RAM was rarely available as clone and called at 400+ USD. Similar 6809 cards. The great part about the Apple was that you could geet next to any CPU on a rather cheap card, so much variety - and one who realy needed speed would rather by a native Z80 (etc.) computer.
    – Raffzahn
    Commented Oct 29, 2018 at 13:13
  • 1
    The 6502 cannot be halted in all clock states. If /RDY is received coincident after the data-read portion of a read-modify-write instruction or the low-address read of a JSR, it will not take effect until the third following cycle (the next instruction fetch, or high-address read). If received during the second cycle of a BRK or interrupt-handling event, it will not take effect until the fourth following cycle (the low-address read).
    – supercat
    Commented Oct 29, 2018 at 16:08
  • 1
    @Raffzahn: The 6502 has a relatively small number of situations where it performs write cycles. If interrupts are disabled, the worst-case delay on responding to RDY will depend upon what kind of instructions might be performed; a device that will need the bus at a certain time may assert RDY 1, 2, or 3 cycles before that. Looking at the data sheet, it appears RDY is sampled on the rising edge of phi2. I suppose it's not clear whether a transition on RDY that occurs in response to the rising edge of phi2 would simply be delayed a cycle versus...
    – supercat
    Commented Oct 29, 2018 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .