knudsen@ihwpt.UUCP (mike knudsen) (10/24/86)
Last nite at the Chicago OS9 User's Group meeting, someone brought a Coco-III and we decided to do the scheduled software talks & demos on the III as far as we could, till something wouldn't work. A TDP-100 (Coco 1.5) was standing by to finish the demos. Incredibly, everything was made to work in the III! From this evening and some home diddling, I can tell you these tidbits, some of which CONTRADICT other things I've heard. Bear in mind that different people on CompuServe report different experiences too; seems some Coco IIIs are more equal than others, depending on your peripherals, temperature, religion, who's watching ... (0) Disk controllers: Non-RS DOSes like ADOS and CDOS throw graphics snow all over the screen at power-up, or at least fail to be recognized (the copyright notice says "Extend Color BASIC 2.0", no mention of "disk". Someone on CompuServe says to try EXEC &HE010 in the latter case, as this forces BASIC to copy and patch the DOS as it does for RSDOS 1.0 and 1.1. Didn't do a thing for us except get us hung. We could not get ADOS or CDOS to boot. Incredibly, JDOS, the black sheep of compatibility, worked (mostly). Someday we will understand all this. Really. (1) Multi-Pack (MPI): Some MPIs get software-switched to Slot 1 by the new BASIC's initialization, probably thru their ghost address at FF9F. You can tell by ?PEEK(&HFF7F). If this gives 255, your MPI is safe. If 0, then you'll have to put your disk controller (or whatever) in Slot 1, and you can't select the other slots (tho self-decoding paks in them work fine). Don't bother POKEing FF7F to some other slot; something in new BASIC just keeps hammering it back to 0. (Well, try it!) (2) OS9 versions 1.0 or 1.1 can be booted up ONLY by first booting Version 2, then inserting your 1.1 or 1.0 boot disk and hitting RESET. Yes this is weird! (3) The CocoMax mouse pak CAN be read properly, even tho its FF90 address is the new GIME's interrupt control register (or something like that). Granted, I did this under OS9 1.1 booted behind 2.0 as above. Or maybe the mouse pak was just driving the data bus harder than the GIME chip (no writes involved here), and someone's GIME chip ain't feeling too good this morning. Speculation: the new GIME (VDG+SAM) chip may have modes where it is less vulnerable to reads/writes in its new areas (like the FExx page). Version 2 may set this mode to "harden" it against whatever wrong things the earlier versions do. This would explain (2) and (3). Why doesn't new BASIC set these hard-shell modes at power-up??? You guys with OS9 disassemblers: check the boot code for new writes into the I/O pages -- if there's a way to get more Coco-II compatibility by setting up the GIME, we should know about it. (4) The double-speed poke (FFD9) works great, even under OS9. However, disk reads may fail, and writes are definitely not recommended if you're fond of that diskette. It was fun to watch my music score editor graphics go twice as fast. Games can be run at double speed UNLESS they auto-load; the double-speed messes up the remaining disk reads. "Cracked" copies are best, since if you can LOADM and then EXEC, do the POKE before EXEC. "Marble Maze" gets smoother and more natural, not just harder. (5) You know that any Coco can get messed up enough that RESET won't work; you have to cycle power. Seems that on the III, the "three stooges" reset (hold CTRL and ALT while RESETting) usually guarantees that the next RESET push will get you a COLD (not warm) restart. Nice. Oh yes, our club decided that this picture is at $C000, the area covered by cartridge ROM (including disk), so useful ROM space was not wasted (tho some fancier initializations could have been put there). (6) The pokes to get real lower case on late Coco-IIs (poke 359,0 and poke 65???,80) still work on the III, allowing lowercase on WIDTH 32. (7) CocoMax doesn't finish booting. P51 hangs right after the runway select option comes up. Probably these programs use FExx, as does my old music synthesizer. Even the Rainbow's pompom boys took Tandy to task for not warning us away from there. Please share your experiences, especially where they differ from the above. More news as it happens ... mike k -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs (AT&T) (312)-979-4132 (work) Nobody pays for my opinions, which are mine alone. "A mind is a terrible thing to waste, but the pay is good."