Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
mg_notes:general:hardware_probing [2018/09/28 14:29] M.G. [How to Probe for Hardware] |
mg_notes:general:hardware_probing [2018/10/30 15:36] M.G. [Recommendations for Slot Card Designers] |
||
|---|---|---|---|
| Line 21: | Line 21: | ||
| So how do you safely probe for something like that? | So how do you safely probe for something like that? | ||
| - | Well, here's how I recommend doing it. | + | Well, here's how I recommend doing it: |
| - Do not probe slot 0 as the user shouldn't put anything but a language card or ROM card there. | - Do not probe slot 0 as the user shouldn't put anything but a language card or ROM card there. | ||
| - | - Identify all slots cards as either block device cards or firmware cards via Apple-recommended [[ProDOS device ID bytes|http://www.1000bit.it/support/manuali/apple/technotes/pdos/tn.pdos.21.html]] or [[http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html|Pascal firmware ID bytes]]. | + | - Identify all slots cards as either block device cards or firmware cards via Apple-recommended [[http://www.1000bit.it/support/manuali/apple/technotes/pdos/tn.pdos.21.html|ProDOS device ID bytes]] or [[http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html|Pascal firmware ID bytes]]. |
| - | * Eliminate any cards that are block devices unless in a IIgs and the slot selection is not "your card." | + | * 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: | * Eliminate any cards that are Pascal devices unless: | ||
| - The machine is an Apple IIe, the slot is 3, and INTC3ROM is enabled; or | - The machine is an Apple IIe, the slot is 3, and INTC3ROM is enabled; or | ||
| Line 41: | Line 41: | ||
| 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. | 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. | ||
| - | 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 $C400 and $C480 and have 16 registers each. Cards exist with more VIAs present on further $10-byte divisions. | + | To probe for the Z80, set up a routine at $0FFD (Z80 FFFDH) with the following code: |
| - | 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%% same as the Softcard. So probe for it under the same conditions of the Softcard. | + | 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. | ||
| ===== Recommendations for Slot Card Designers ===== | ===== Recommendations for Slot Card Designers ===== | ||
| Line 49: | Line 61: | ||
| 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 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. | + | I highly recommend including a firmware option, even if you don't plan on shipping the card with any 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. |