Inside my coco3, is there a simple place where I could safely grab 12V with alligator clips/etc, so that I could mount an internal muffin fan on my case?
If memory serves, the CoCo3 doesn’t have a 12 volt supply. The schematics I have are unreadable. Others can verify but I’m 82.6% sure that the coco3 is only 5 volt.
I haven’t tested the CoCo 3 yet, but I know on the CoCo 2, the highest DC voltage you can get off the circuit board is 9v. This voltage comes directly after the rectifier circuit and before the 5v regulator. The CoCo 3 should have the same power supply. This is why the early floppy controllers require modification to work on the CoCo 2 and CoCo 3.
Agreed… You can pull off the cathode of D1/D2 which should drive the fan. It’s unregulated and will have some ripple. The fan may not run full speed but it should work just fine. Again, verify this. My schematics are virtually useless. Bad copy. Anyone have a clean copy they would like to post???
Thanks as always for all the good info. This is all related to a problem I posted before–after about 20 minutes of my coco3 and justus vga converter running, my video goes blank. So it’s either converter or coco, no one has ever heard of a justus converter overheating. I’ve just rigged up a muffin fan that I’ll try on my coco, and if it still blanks out, I’ll lay it on converter, see if either one keeps it from happening.
I suspect coco just because no one is complaining about converter, and I’m running high speed poke (drivewire), so I could see coco getting hot. Also have the cloud9 512k kit in there, maybe that little board is interfering with ventilation a bit…
It may help to know why you need to detect an MPI. Checking for the presence of the software switch at $FF7F seems like the logical way to go. The following subroutine should return with B=0 when no MPI is present:
pshs x,a,cc
orcc #$50
ldx #$FF7F ; point X to MPI software switch
lda ,x ; get current switch setting
ldb #$33
clr ,x
bitb ,x
bne NoMPI
stb ,x
andb ,x
cmpb #$33
bne NoMPI
*MPI Present. Restore switch setting and return.
sta ,x
bra Exit
It may help to know why you need to detect an MPI. Checking for the presence of the software switch at $FF7F seems like the logical way to go. The following subroutine should return with B=0 when no MPI is present:
So it looks like the software switch register is readable then? I’m assuming the non important bits are garbage.
This will make life easier, as I was assuming the MPI switch was not readable, and I’d have to change the switch setting to see if the cart rom/devices change… I was not looking forward to that.
I’m working on some more device drivers (SD and DriveWire) support for my Ans Forth. In particular, I’m working on a rommed version that will search for different devices (FDC, IDE, UARTS) in the cartridge slots. So Forth can find a device with a Forth boot partition data.
If memory serves, the CoCo3 doesn’t have a 12 volt supply. The schematics I have are unreadable. Others can verify but I’m 82.6% sure that the coco3 is only 5 volt.
Update: I did find a document that states the CoCo3 (NTSC) is only 5 volt. The PAL version does have a 12 volt supply. Are you using a PAL version?
I haven’t tested the CoCo 3 yet, but I know on the CoCo 2, the highest DC voltage you can get off the circuit board is 9v. This voltage comes directly after the rectifier circuit and before the 5v regulator. The CoCo 3 should have the same power supply. This is why the early floppy controllers require modification to work on the CoCo 2 and CoCo 3.
Agreed… You can pull off the cathode of D1/D2 which should drive the fan. It’s unregulated and will have some ripple. The fan may not run full speed but it should work just fine. Again, verify this. My schematics are virtually useless. Bad copy. Anyone have a clean copy they would like to post???
Try this one:
ftp://maltedmedia.com//coco/NEWLY-RECEIVED/CoCo3%20-%20Revised%20Schematic.zip
Nice, thanks much!!!
Thanks as always for all the good info. This is all related to a problem I posted before–after about 20 minutes of my coco3 and justus vga converter running, my video goes blank. So it’s either converter or coco, no one has ever heard of a justus converter overheating. I’ve just rigged up a muffin fan that I’ll try on my coco, and if it still blanks out, I’ll lay it on converter, see if either one keeps it from happening.
I suspect coco just because no one is complaining about converter, and I’m running high speed poke (drivewire), so I could see coco getting hot. Also have the cloud9 512k kit in there, maybe that little board is interfering with ventilation a bit…
It may help to know why you need to detect an MPI. Checking for the presence of the software switch at $FF7F seems like the logical way to go. The following subroutine should return with B=0 when no MPI is present:
pshs x,a,cc
orcc #$50
ldx #$FF7F ; point X to MPI software switch
lda ,x ; get current switch setting
ldb #$33
clr ,x
bitb ,x
bne NoMPI
stb ,x
andb ,x
cmpb #$33
bne NoMPI
*MPI Present. Restore switch setting and return.
sta ,x
bra Exit
*MPI Not Present. Return 0 in B.
NoMPI clrb
Exit puls cc,a,x,pc
This was supposed to be posted to the “How to Detect an MPI” thread. I don’t know why it showed up here or how to move it.
From DarrenA:
It may help to know why you need to detect an MPI. Checking for the presence of the software switch at $FF7F seems like the logical way to go. The following subroutine should return with B=0 when no MPI is present:
So it looks like the software switch register is readable then? I’m assuming the non important bits are garbage.
This will make life easier, as I was assuming the MPI switch was not readable, and I’d have to change the switch setting to see if the cart rom/devices change… I was not looking forward to that.
I’m working on some more device drivers (SD and DriveWire) support for my Ans Forth. In particular, I’m working on a rommed version that will search for different devices (FDC, IDE, UARTS) in the cartridge slots. So Forth can find a device with a Forth boot partition data.
Thanks DarrenA