Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
mg_notes:general:hardware_probing [2018/10/30 15:35] M.G. [How to Probe for Hardware] |
mg_notes:general:hardware_probing [2021/10/30 23:38] (current) M.G. [How to Probe for Hardware] |
||
|---|---|---|---|
| Line 43: | Line 43: | ||
| To probe for the Z80, set up a routine at $0FFD (Z80 FFFDH) with the following code: | 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 | + | FFFD: ld ($Es00),a ; s=slot being probed turn off Z80, next PC is $0000 |
| - | 0000: ld a,$01 | + | 0000: ld a,$01 |
| - | ld (flag),a | + | ld (flag),a |
| - | jp FFFD | + | jp FFFD |
| - | flag: .byte $00 | + | 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. | + | For the 6502 part of the equation: |
| + | |||
| + | lda #$C7 ; start at slot 7 | ||
| + | sta startz+1 | ||
| + | lda #$E7 ; same, from Z80 view | ||
| + | sta $FFFE | ||
| + | loop: lda #$00 | ||
| + | sta flag | ||
| + | startz: sta $Cs00 | ||
| + | lda flag | ||
| + | bne foundz | ||
| + | dec startz+1 | ||
| + | dec $FFFE | ||
| + | lda startz+1 | ||
| + | cmp #$C0 | ||
| + | bcs loop | ||
| + | noz: ; Z80 not found | ||
| + | ... | ||
| + | foundz: ; Z80 found | ||
| + | |||
| + | The reason for placing the ld ($Es00),a 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) without a reset, 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. | 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. | ||
| Line 61: | Line 81: | ||
| 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. |