If an MPI is present, you will be able to send a value to $FF7F and read it back. If there is no MPI present, the value at $FF7F will not change.
On my Coco3 without the MPI plugged in, $FF7F=126. I don’t know what you will see with a Coco1 or 2.
Getting the value 126 without an MPI present is a side effect from using Basic’s PEEK function. If you were to execute a LDA $FF7F you would get a different value (probably 27).
Thanks guys. Shall I assume that insignificant bits of FF7F would be garbage? And garbade in general without an MPI? DarrenA makes it sould like there’s pull-ups on the data lines in the CoCo?
No, the insignificant bits will be what was written to them, at least on the 36-3024. I don’t know about the 26-3124, but on the 26-3024 there is a full 8-bit readback latch at $FF7F, so all bits are stored and read back.
gimechip is correct. I did a test with both a 26-3024 and 26-3124 MPI and verified that in both cases, all 8 bits will read back whatever you write to them.
In theory this means you don’t have to mask interrupts or save the original value when testing for the presence of an MPI. You could just toggle the insignificant bits as in:
lda $FF7F
eora #$CC
sta $FF7F
cmpa $FF7F
bne NoMPI
On the other hand, to support the possibility that a souped-up MPI design with more than 4 slots may be present, you would need to be more careful.
Yes, you should treat the undefined bits of FF7F as garbage.
Some CoCo 2 boards (including my 26-3127B) apparently have pull-ups on the data lines. If you PEEK an un-mapped hardware address on one of those you get 255. The CoCo 1 boards and the CoCo 3 definitely do NOT have pull-ups. On those, if you PEEK an un-mapped hardware address without an MPI attached, you get 126. This is actually stale data from the previous CPU cycle. I posted a message on the maltedmedia list that describes how you can predict the data seen in this case:
If your application is a Disk BASED application, you could use assembly to write a routine to: disable interrupts, store the value at $FF7F somewhwere, point CTS* to slot four (the default for the disk drive anyway), look for 68 ($44) at $C000 (the first byte of all Disk BASIC’s) and if it’s there, then set CTS* to another slot and check again – if it’s still 68, then obviously there’s no MPI so set a flag accordingly and then restore $FF7F, re-enable the interrupts and return. Of course this assumes the application requires a Disk Controller…
If an MPI is present, you will be able to send a value to $FF7F and read it back. If there is no MPI present, the value at $FF7F will not change.
On my Coco3 without the MPI plugged in, $FF7F=126. I don’t know what you will see with a Coco1 or 2.
Getting the value 126 without an MPI present is a side effect from using Basic’s PEEK function. If you were to execute a LDA $FF7F you would get a different value (probably 27).
Thanks guys. Shall I assume that insignificant bits of FF7F would be garbage? And garbade in general without an MPI? DarrenA makes it sould like there’s pull-ups on the data lines in the CoCo?
No, the insignificant bits will be what was written to them, at least on the 36-3024. I don’t know about the 26-3124, but on the 26-3024 there is a full 8-bit readback latch at $FF7F, so all bits are stored and read back.
gimechip is correct. I did a test with both a 26-3024 and 26-3124 MPI and verified that in both cases, all 8 bits will read back whatever you write to them.
In theory this means you don’t have to mask interrupts or save the original value when testing for the presence of an MPI. You could just toggle the insignificant bits as in:
lda $FF7F
eora #$CC
sta $FF7F
cmpa $FF7F
bne NoMPI
On the other hand, to support the possibility that a souped-up MPI design with more than 4 slots may be present, you would need to be more careful.
The results of attempting to read “unreadable” bits seems to vary from Coco to Coco. Pull-ups seems right.
Yes, you should treat the undefined bits of FF7F as garbage.
Some CoCo 2 boards (including my 26-3127B) apparently have pull-ups on the data lines. If you PEEK an un-mapped hardware address on one of those you get 255. The CoCo 1 boards and the CoCo 3 definitely do NOT have pull-ups. On those, if you PEEK an un-mapped hardware address without an MPI attached, you get 126. This is actually stale data from the previous CPU cycle. I posted a message on the maltedmedia list that describes how you can predict the data seen in this case:
http://five.pairlist.net/pipermail/coco/2010-January/047210.html
Attaching an MPI to any system appears to have the effect of pulling up undefined bits.
If your application is a Disk BASED application, you could use assembly to write a routine to: disable interrupts, store the value at $FF7F somewhwere, point CTS* to slot four (the default for the disk drive anyway), look for 68 ($44) at $C000 (the first byte of all Disk BASIC’s) and if it’s there, then set CTS* to another slot and check again – if it’s still 68, then obviously there’s no MPI so set a flag accordingly and then restore $FF7F, re-enable the interrupts and return. Of course this assumes the application requires a Disk Controller…
gimechip:
Yeah, I thought of that method too. But figured some people wouldn’t have a normal ROM, with the “DK” signature.