baxter@milano.UUCP (10/23/86)
Those of you having CoCo IIIs and some understanding of the hardware can do a great service for those of us who don't. CoCo III promises compatibility of peripherals with CoCo II peripherals, presumably including floppy disk controllers and modem cards. It also promises 1.8 Mhz operation. Usually faster processors won't work with controllers designed for slower machines controllers (Motorola supplies different versions of it 6809 family for different clock rates); can someone explain why the CoCo III should be an exception? For BASIC, I suppose that the following strategem might work: run at 1.8Mhz until I/O is necessary, slow down to .8Mhz, do the I/O, speed back up again. If this was done consistently, I don't understand the CoCo III is delivered running at .8Mhz as the default (excuse my ignorance if that's not the case... data on the CoCo III is really hard to find right now). Under OS-9, the strategem wouldn't work as well, especially if several devices were busy at once. Reducing OS-9 to running at .8Mhz as the least common denominator would make a joke of the 1.8Mhz ability. Anybody sane would automatically WANT the 1.8Mhz as the default, so I presume that it is under OS-9... so there must be a different strategy. An aside: was the typeahead problem with OS-9 ever solved (i.e., I can't typeahead while the disks are spinning? Replies should be to the net. If I get personal replies, I will summarize. Sorry about the bungled message preceding. -- Ira Baxter arpanet: baxter@mcc.com MCC Corporation usenet: ut-sally!im4u!milano!baxter
rsanders@watdcsu.UUCP (Roger K. Sanderson P.Eng.) (10/24/86)
In article <2676@milano.UUCP> baxter@milano.UUCP writes: >Those of you having CoCo IIIs and some understanding of the hardware >can do a great service for those of us who don't. CoCo III promises >compatibility of peripherals with CoCo II peripherals, presumably >including floppy disk controllers and modem cards. It also promises >1.8 Mhz operation. Usually faster processors won't work with >controllers designed for slower machines controllers (Motorola >supplies different versions of it 6809 family for different clock >rates); can someone explain why the CoCo III should be an exception? The CPU chip in the CoCo 3 is a 68B09E, the B part means it will run at 2 mhz. Yes in theory the peripheral parts should also be B's to run at that speed. (ie 68B21 68B50 ). In practice however, most parts will run at the higher speed, but , they are not garanteed by the manufacturer to run at that speed under all temperature extremes. For critical aplications it would probably be best to slow down the I/O on the CoCo 3. >For BASIC, I suppose that the following strategem might work: run at >1.8Mhz until I/O is necessary, slow down to .8Mhz, do the I/O, speed >back up again. If this was done consistently, I don't understand the >CoCo III is delivered running at .8Mhz as the default (excuse my >ignorance if that's not the case... data on the CoCo III is really >hard to find right now). The CoCo 3 defaults to 0.8 mhz to be completely compatible with the CoCo 2. This is in case software was timing via instruction loops, etc. In a BASIC program you can POKE it into high speed mode. You should POKE it back for disk I/O though. Reports are that disk I/O will work at fast speed but it is not reliable. >Under OS-9, the strategem wouldn't work as well, especially if several >devices were busy at once. Reducing OS-9 to running at .8Mhz as the >least common denominator would make a joke of the 1.8Mhz ability. >Anybody sane would automatically WANT the 1.8Mhz as the default, so I >presume that it is under OS-9... so there must be a different >strategy. I understand that OS9 Level II does run in fast mode, but slows down for disk I/O ( the driver automatically does this ) >An aside: was the typeahead problem with OS-9 ever solved (i.e., >I can't typeahead while the disks are spinning? You always could type ahead while the disks were spinning, it was when the actual data was being transfered that the disk controller HALTS the CPU on a byte by byte basis, also the interupts are turned off here of necessity. Since you use the same disk controllers on a CoCo 3, this problem will still exist. It however, should be MUCH better (if they wrote the code right ) since the keyboard now will generate an interupt! Even if the machine is HALTed the interupt should get seviced eventually. We will have to wait for Level II OS9 to find out. >Ira Baxter arpanet: baxter@mcc.com >MCC Corporation usenet: ut-sally!im4u!milano!baxter -- Roger Sanderson Electrical Engineering Dept. University of Waterloo Waterloo Ontario Canada N2L 5E6 {decvax,allegra,ihnp4}!watmath!watdcsu!rsanders
knudsen@ihwpt.UUCP (mike knudsen) (10/24/86)
> Those of you having CoCo IIIs and some understanding of the hardware > can do a great service for those of us who don't. CoCo III promises > compatibility of peripherals with CoCo II peripherals, presumably > including floppy disk controllers and modem cards. It also promises > 1.8 Mhz operation. Usually faster processors won't work with > controllers designed for slower machines controllers (Motorola > supplies different versions of it 6809 family for different clock > rates); can someone explain why the CoCo III should be an exception? It isn't, except that all the PIA and other chips INSIDE the III are spec'ed for 1.8, so the speed-poke is OK as far as the box is concerned. Anything you plug into the side is another matter. In my case, the A-to-D converter chip in the CocoMax mouse pak won't hack the extra speed (it's spec'ed at 1.26 MHz max), so the cursor really jumps around. Symphony 12 will probably play music one octave higher (Walter -> Wendy mode) if it still works at all. Paks with their own crystals should be OK, if their bus interface can hack it. Most Coconuts already know which of their stuff will tolerate high speeds. > For BASIC, I suppose that the following strategem might work: run at > 1.8Mhz until I/O is necessary, slow down to .8Mhz, do the I/O, speed > back up again. If this was done consistently, I don't understand the > CoCo III is delivered running at .8Mhz as the default (excuse my > ignorance if that's not the case... data on the CoCo III is really > hard to find right now). Yes, I've done that for years; run the half-fast speed poke till you do some I/O, then speed back up. Disk I/O was always flakey under the speed poke, and of course cassette and RS232 were off. Yes, would be nice if BASIC automatically switched to slow clock during I/O, then back up. However, for compatibility with 6 years of peripherals, I can see why Tandy sets the old clock speed at powerup (yes you are right). No kidding data are hard to find ... keep those postings coming, folks! And check out CompuServe, etc. > Under OS-9, the strategem wouldn't work as well, especially if several > devices were busy at once. Reducing OS-9 to running at .8Mhz as the > least common denominator would make a joke of the 1.8Mhz ability. > Anybody sane would automatically WANT the 1.8Mhz as the default, so I > presume that it is under OS-9... so there must be a different > strategy. Right again. However, you don't really have I/O processes running as randomly as you might think (see below). You want default fast clock? Put this in your STARTUP: debug . ffd9 =0 q Conceivably, Level II, being specifically for the Coco-III, may have its device drivers switch to low speed on entry and restore on exit. Of course, we can add that mod ourselves. > An aside: was the typeahead problem with OS-9 ever solved (i.e., > I can't typeahead while the disks are spinning? Nope. Fixing this would require true DMA disk interface, which would be terrific. Because disk I/O locks out everything else, multitasking is still a joke even under Level II (when it comes). Thus your tasks can play the "slow to I/O" games as in BASIC. "Third one's the charm" -- 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."
ingoldsby@calgary.UUCP (10/26/86)
I'm a bit of a hardware hacker, and consider my self of reasonable competence (having designed and built computers from scratch). Nothwithstanding, I've never understood exactly why the disk controller can't run at 1.8Mhz. I can easily understand why things might not work out during an actual disk access, but why does a CoCo ( <> III ) hang when the high speed poke is given if a disk controller is plugged in (without disk I/O)?? I had always presumed that the ROMs inside it were just too slow, and since the BASIC interpreter loops through them quite frequently, the machine was just going into neverland. I saw a CoCo III with a disk controller plugged in that did NOT hang after the high speed poke. Was this just because the newer disk controllers (mine is an ancient model for the CoCo I) have better ROMs? Note that there is, in my opinion, a design defect in the Coco I (and I presume II). Although the 6809 and SAM guarantee drive TTL levels on the bus. My experimentation has shown that the drive current is barely marginal, and any additional capacitance, load, etc. is enough to foul things up. They should have put bus drivers on the external port. Is it possible that the CoCo III has such drivers, and that this is what allows it to use the disk controller at 1.8Mhz (or at least the ROMS)? Any help is appreciated, since this has baffled me for a long time. ...!ihnp4!alberta!calgary!ingoldsby Terry Ingoldsby
knudsen@ihwpt.UUCP (mike knudsen) (10/27/86)
> > > I'm a bit of a hardware hacker, and consider my self > of reasonable competence (having designed and > built computers from scratch). Nothwithstanding, I've > never understood exactly why the disk controller can't > run at 1.8Mhz. I can easily understand why things > might not work out during an actual disk access, but > why does a CoCo ( <> III ) hang when the high > speed poke is given if a disk controller is plugged > in (without disk I/O)?? I had always presumed that the ROMs inside it > were just too slow, and since the BASIC interpreter > loops through them quite frequently, the machine > was just going into neverland. I saw a CoCo III > with a disk controller plugged in that did NOT > hang after the high speed poke. Was this just > because the newer disk controllers (mine is an > ancient model for the CoCo I) have better ROMs? I'm a hardware pro with 4 years Coco experience, and I agree with you that the speed-poke problem is probably slow ROM reading from the controller. However, the culprit is most likely not the ROM itself, but rather the RC lowpass filter circuit in the CTS* line from the Coco to the external ROM cartridge. This series-R shunt-C made the square CTS* pulse look like the lower half of a sine wave before I ripped it out. Actually I think my old disk controller ran old my Coco at speed poke before I ripped out the above and a couple other "smog control" caps on the E and Q lines -- but I was just lucky I guess. Tandy's mask ROMs have always handle speed poke fine for me. > Note that there is, in my opinion, a design > defect in the Coco I (and I presume II). Although the > 6809 and SAM guarantee drive TTL levels on > the bus. My experimentation has shown that the > drive current is barely marginal, and any additional > capacitance, load, etc. is enough to foul things > up. They should have put bus drivers on the > external port. Is it possible that the CoCo III > has such drivers, and that this is what allows > it to use the disk controller at 1.8Mhz (or at > least the ROMS)? > > Terry Ingoldsby Again, my bus always looked good on a 'scope, but bus drivers would be nice, if only to provide some protection for your big $$ chips in case of static, inserting cart with juice on, etc. I have had problems when Y-cabling three carts (non-ROM) at once, tho. I think the Shack wants us to use MuliPak toaster for that sort of thing! Of course, if you ever used DMA (as some hard disks are said to do), even the address drivers would have to be reversable (ls245s instead of ls244s), and a control signal developed to reverse them. Given the rockbottom price of the III, I doubt it has any of this good stuff. In 80 days I'll pop the lid on my III and see for sure...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."
jimomura@lsuc.UUCP (10/28/86)
Actually, typeahead wouldn't necessarily require a DMA. A cheaper solution might simply be a keyboard processor with a bit of onboard RAM. Such dedicated processors can be done for little cost. I have a computer case with a smart keyboard which is controlled by a Z-80 and the whole thing costed about $100.00 (Cdn). -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880