Hardware probing on the Apple II is somewhat hard because there is no guarantee that expansion card designers have put ROM in the space where ROM normally exists ($CsXX). In fact, some cards (Microsoft Softcard & compatibles, Mockingboard & compatibles) put I/O or I/O-like behavior into the $CsXX space.

As an example of a card that you might want to probe for is the Uthernet II. Its documentation (retr. 9/28/2018) provides a recommendation for probing for the card.

The document rightly points out that the card has no firmware, and therefore that is problematic for identification. However, the document and its example code are critically flawed: they recommend blindly scanning all slots for the Uthernet II, with the only guard being to do it in a “likely” order by probability that the card is installed in a particular slot.

Ultimately this led to disruption of other hardware by ADTPro, which is capable of using the Uthernet II for disk transfers.

This was solved by disqualifying cards by some (non-standard) ID bytes. I believe this is an incomplete solution.

Because the Uthernet II lacks firmware, there are several scenarios in which it might be installed:

• In an Apple II or II+ in any slot, even slot 0.
• In an Apple IIe in any slot, even slot 3.
• In an Apple IIgs in any slot regardless of control panel setting, except slot 6 which has an IWM at $C0E0 when the built-in disk controller is enabled there.

So how do you safely probe for something like that?

Well, here's how I recommend doing it:

1. Do not probe slot 0 as the user shouldn't put anything but a language card or ROM card there.
2. Identify all slots cards as either block device cards or firmware cards via Apple-recommended ProDOS device ID bytes or Pascal firmware ID bytes.
   • Eliminate any cards that are block devices unless in a IIgs, not slot 6, and the slot selection is not “your card.”
   • Eliminate any cards that are Pascal devices unless:
     1. The machine is an Apple IIe, the slot is 3, and INTC3ROM is enabled; or
     2. The machine is an Apple IIgs, and the slot selection is not “your card.”
3. From the remaining slots, probe for the Uthernet as described in its documentation.

What about some other cards?

First, the PCPI Appli-Card. It doesn't have slot firmware, per se, but it is designed in such a way that the slot ROM space contains repeated $7A (ASCII 'z'). However, it can be installed in the slots that are used for built-in firmware in a //e or IIgs in the same manner as the Uthernet II.

So again, the same steps as the Uthernet, though you might be able to short-circuit detection by looking for the 'z' in the firmware space.

Next, the Microsoft Softcard. It doesn't have slot firmware at all and, on top of that, it is toggled on and off by writing to what would normally be its slot firmware space (a bad design decision, if you ask me). Similar steps to the Uthernet II can be performed, but in this case we eliminate all slots with identifiable firmware from the probe since it cannot be in an occupied slot, nor can it work “under” the built-in firmware of the IIgs or //e.

There's a big exception to the above paragraph: The Apple //c. Several companies produced Microsoft-compatible Z80 cards for the //c, including the popular AE Z-RAM series. These respond to appropriate writes, but also contain the machines built-in firmware in the “slot.” So if the machine is a //c, it is safe to probe all slots for the Z80.

To probe for the Z80, set up a routine at $0FFD (Z80 FFFDH) with the following code:

FFFD:  ld ($Es00),a   ; s=slot being probed turn off Z80, next PC is $0000
0000:  ld a,$01
       ld (flag),a
       jp FFFD
flag:  .byte $00

The reason for the instruction at $FFFD is to overcome the Softcard's inability to reset the Z80 any other way than through the RESET signal on the bus. This probe will leave the Z80 in a state resembling the reset state while it is off, ready to execute the instruction at $0000. Note that for the same reason, if the Z80 has already been accessed via another method (such as booting CP/M first), this probe will fail and the machine will probably crash.

Finally, the Mockingboard and clones don't have slot firmware, instead having two or more 6522 VIAs present in the space normally used for slot firmware. For a two-VIA card, the VIAs are at $Cs00 and $Cs80 and have 16 registers each. Cards exist with more VIAs present on further $10-byte divisions.

In this case, the Mockingboard is probably not going to look like a standard slot card when ID bytes are checked. Since it's I/O is in the firmware space, it won't work in a IIgs slot that isn't set to “your card,” nor in slot 3 of a //e, basically the same constraints as the Softcard. So you'd probe for it under the same conditions of the Softcard, generally.

Where you might run into trouble is if you believe you have a Mockingboard, attempt to write to one of the VIAs, and instead have a Softcard in the slot. The Softcard turns on, and you have likely crashed. You can take advantage of the fact that the Softcard has floating bus, but the VIA's DDRB and DDRA registers do not float.

I strongly recommend not placing I/O in the CsXX space, as it leaves the potential to disrupt the system when identifying installed cards. Place the I/O at C0nX or in $C8-space to avoid such problems.

I highly recommend including a firmware option, even if you don't plan on shipping the card with and firmware. One of the reasons I've been reluctant to acquire an Uthernet II is because the things I'd want to do with it kind of need firmware. Imagine a UDP disk image server that the machine could boot from. Any small CPLD can perform the necessary I/O decoding needed to support the $Cs00- and $C8-space for a particular card, and small flash chips are relatively inexpensive. It adds a few bucks to the design and implementation costs, but you might be surprised what people might do with your card.