2

Looking over the Apple II expansion card pinout, it seems it's largely just the pins of the 6502 plus some +12V supplies and such.

Generally speaking, though, is there any reason any other 6502 machine, like the PET or Atari, couldn't have supported them?

I suspect the memory mapped I/o would present a problem if it overlapped with other items in the machine's own libraries, but that seems like something that could be corrected in the driver ROM, which one would expect would be different anyway.

Am I missing anything special about the hardware that might make Apple II cards difficult to use on other platforms? For instance, did the motherboard have specific interfacing hardware like latching or such that would have to be implemented to make it work? Or it is, as it appears, just a bunch of pins and a driver?

1
  • 1
    The Apple II definitely forwards some relevant select lines, in order to provide slot addressing, but I suspect you've already factored that in.
    – Tommy
    Feb 13, 2020 at 15:14

2 Answers 2

5

Looking over the Apple II expansion card pinout, it seems it's largely just the pins of the 6502 plus some +12V supplies and such.

Yes, and no. The unique point about the Apple II bus is that basic address decoding is done externally to the card. This saves quite some circuitry.

Generally speaking, though, is there any reason any other 6502 machine, like the PET or Atari, couldn't have supported them?

No. it would need some glue logic for address decoding.

I suspect the memory mapped I/o would present a problem if it overlapped with other items in the machine's own libraries,

In fact, Woz' strategy to put decoding external removes the hardware side of that issue, as the needed external decoder logic would have to be made to cover this.

but that seems like something that could be corrected in the driver ROM, which one would expect would be different anyway.

Sure, driver/ROM code has to be replaced. Not just because of the address issues, but also for integration in the new environment. Each machine's BIOS and OS has it's own ways of integration for drivers, so usually it might best to drop ROM support and go with loadable drivers.

Am I missing anything special about the hardware that might make Apple II cards difficult to use on other platforms?

It may only go tricky when a card going for real deep integrated function like taking over the bus like with a CPU card. Or for example cards snooping the bus to capture things like screen data or certain system setup (softswitches). But then again, adapting such special cards between systems are always tricky.

For instance, did the motherboard have specific interfacing hardware like latching or such that would have to be implemented to make it work? Or it is, as it appears, just a bunch of pins and a driver?

It's a bunch of pins and drivers - plus address decoding. Apple II cards expect

  • A 16 byte address window accessed with /DEVICE-SELECT and A0..A3, used for I/O registers.
  • A 256 byte address window accessed with /IO-SELECT and A0..A7, usually holding the promary driver and all entry points. Some cards use it as well for RAM or registers. This is usually called 'PROM' space.
  • A 2048 byte address window accessed with /IO-STROBE and A0..A10, usually this holds the main driver ROM. But it has as well be used for RAM windows.

While the first two are reserved for each card at fixed addresses, the last one is shared between cards. The protocol is rather simple and all hardware needed is on the card and handled by drivers (*1).

So after adding address decoding, according to whatever system you have, a good number of Apple cards should work right away - sans driver that is.

The next level would be to check if RDY handling for DMA is possible. On the Apple II pulling RDY from the card during PHI1 will put the CPU on hold (like with any 6502 system) but as well decouple it from the bus, allowing the Card to put out a memory address of it's own. Ofc, this will be hard to archive on machines that are unable free up the bus.

Everything after that will be rather extreme Apple II specific and more about the inner workings of the II series, not really worth to be supported.


*1 - All cards have to disable their ROM as soon as an access to the top address in ROM space is detected. That's /IO-STROBE plus A0..A10 all high ($CFFF when decoded like in an Apple II). Some cards only decode that partitialy, ignoring the lower value addresses. That's fine, as long as the top most address is included.

Hardware wise ROM enable/disable is usually done (on card) by a simple flipflop. /IO-SELECT is simple wired up to set it, while /IO-STROBE + A3..A10 will reset it. As a result, every time code is executed within PROM space the ROM is paged in. Now a single BIT (or alike) instruction is all that's needed to disable all, as the next instruction will again enable the own ROM. I always liked the elegance. No lengthy loading of values and port handling to swap between ROMS. Instant and automatic.

3
  • 1
    So the takeaway is that yes, they could, but they would have to emulate the motherboard logic for card selection and such. This is precisely what I was asking in the end. If I'm reading your post correctly, it seems they ended up sort of emulating an 8080-style IO bus addressing scheme. Feb 14, 2020 at 18:17
  • @MauryMarkowitz Not really. It was more like Woz needed to do the internal decoding anyway. Adding slot support needed (IIRC) just two additional TTL. No need to 'emulate' the Apple II decoding, instead only supplying decoding for these 2 (3) signals in the address space of the new host is needed. It could be made by using 4 KiB of address space, like on the Apple, or by providing a single instance of 16 + 256 bytes (+2 KiB) for a single card, or plus some banking for many cards. Unlike with S100 or ISA, the whole decoding is done external to the cards, thus making it rather portable.
    – Raffzahn
    Feb 14, 2020 at 18:33
  • "The unique point about the Apple II bus is that basic address decoding is done externally to the card." This is far from unique to the Apple II. The C64 also provided some select lines based on address decoding on its cartridge slot (IO1, IO2, ROML and ROMH), and the Fujitsu FM-7 also provided selects for accesses to the I/O page and in fact provided only the necessary eight address lines for use in that page. The Apple II differed from these in providing different enables to each slot for different address ranges, but I'm not even sure that was unique to it.
    – cjs
    Mar 24, 2020 at 1:29
1

I believe the major factors, besides just the electrical characteristics of the bus, are:

  1. Standardization of access to each slot, such that each is guaranteed certain resources that cannot conflict with other slots/cards. This is something the Apple ][ provided, and 6502 systems without slots didn't.
  2. Built-in and aftermarket software support that is platform specific.

Obviously, any expansion system is a combination of hardware and software. And there is a lot of specific work for device drivers for each card that is highly platform dependent. Just doing the relatively simple adaption for the electrical characteristics of the card is not going to be sufficient for it to work in a new platform, like the C64.

You must log in to answer this question.

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