as-q USERS gboup Giffiix, CoCo. Atari, Mac 6809 - 68K OS-9 Level 1. 2, 3 COCO-3 BOOT LIST ORDER BUG (BLOB) Facts, fixes and theories by Kevin Darling & friends THE BLOB. Some owners have it, some have never seen it. Ordering of modules in a bootlist for os9gen seems to affect it. Adding new devices may cause it to show up. What causes it? It's past time to lay out both what has been conjectured and what is truly known so far. At first, the OS-9 kernel itself was blamed. VeVe been pretty sure nowfor a long time iiat it is NOT at fault. All the modules are position-independent, and have been gone over very closely by several of us , looking for anything that could cause a problem. We have found no software cause at all (with the exception of the disk driver - see below). Instead, hardware and timing discrepan- cies in the CoCo-3 and peripherals have been found almost always to be at fault. In fact, it's often possible to pinpoint the exact cause of a particular problem, with enough information. Enougli preliminaries. Here are most of the confirmed and imconfirmed symptoms and possible reasons, including things that act like BLOBs... FLOPPY FORMATTING HALTS IN FIRST FEW TRACKS; READMrRITES ARE OFF BY A BYTE: "en Schunk, myself, and others long ago ound that the halt method used by CC3Disk (and some RSDOS drivers in programs) has a problem with some disk controllers (apparently mostly pre-19S5 1773's). The usual method is to wait for the FDC (floppy disk controller) to indicate it is ready to exchange a byte of data, and then have the CoCo go into the halt mode. What will happen is that the first byte transfer gets lost, and this is returned as a "Read Error" by the driver. For reasons as yet unknown, this **data lost" sequence sometimes "seems" to be driver position dependent. I would guess that most boot failures are caused by this one^ especially with older controllers (altho I've seen it happen on newer ones, too). The drivers can be fixed, and we should be able to post patches later. READSAVRITES GO TO WRONG LSN: Actually, they go to the wrong TP^CK, which is also always the wrong LSN. Usually caused by using disk drives that are set to turn on their motors only with drive select, instead of the required method of all motors on with the motor-on signal. All drivers assume that if one motor is on, ALL are on. Because of this assumption, and especially because the drive READY line isn't usually available on the CoCo setup, the FDC will send stepping commands to a drive that is still spinning up again when selected (it takes about 1/2 second to be actually "ready"),... and those stepping pulses are totally ignored by drives not spun up. So while the FDC _thinks_ it's stepped the head to a new track, in fact either some or all of the step pulses have been lost. Worse, the 1773 FDC seems to ignore the imbedded track information on the disk itself (contrary to docs) and so as long as the sector nunxber matches up, the data is read/written. . . to whatever track the head happens to be over! So make sure your drive motors all come on at the same time. SPEED AND BAD CHIPS Testing and experiences by several people has shown that the American semiconduc- tor industry has gotten pretty bad over the last few years as far as quality goes. Or per- haps retailers are selling more reject chips that they buy on the grey market. In any case, some failures of chips used in add-on devices have been found to be brand de- pendent. For example, some of the LS245 data buff- ers inside CoCo-3*s seem to fail to pass true data at times. Replacing this chip with a Japanese brand will usually cure this par- ticular problem. Motorola chips seem to be the worst bet. Symptom is that an instruc- tion loop reading from the MPI sometimes sees bits set that it shouldn't. Solution is to replace the chip or slow down the loop* Speedwise, many people use hardware designed and built for IMhz operation from the CoCol/2 days. A conunon prob- lem is with RS232 paks... they may need the 6551 replaced with a higher speed ver- sion. INTERRUPTS Boot problems also sometimes appear when a device's interrupt line isn'tcorrectly reset. I've had several 6551 ACIAs (used in PS232 paks, etc) thatdecided not to clear their interrupt line just by resetting the CoCo. This leaves an interrupt hanging and can mess up a machine trj^ing to boot It's also been found that some RS232 paks were built with the E clock tied to the IRQ line... this can abort a boot also. Stuck interrupts are covered in J;he various "IRQ HACK" files available on most net works, as are files on the RS232 pak. MULTIPAK UPGRADE A non-upgraded MPI definitely causes problems. At the least, it can cause wrong information to be read from the crucial GIME interrupt status port. The most common rumor we see on BBS's is that the MPI upgrade "isn't needed", because **my machine runs fine without it". DO NOT LISTEN TO THESE PEOPLE. PLEASE EXPLAIN TO THEM THAT THEY ARE STUPID. While we can't swear that you WILL hurt your GIME if you don't upgrade, we can certainly say that it does make electronic sense to DO the upgrade (plus Tandy sold the upgrades at first cheaper than their cost, which alone would make one think there's a good reason for having it, eh?). The electronic reason for the upgrade i: this: a READ from $FF80-9F will txim on BOTH the GIME data bus AND the MPI data bus. (In addition, really old MPIs ghost their slot select at $FF7Fand $FF9F, which causes problems.) It's never a good idea to have tvt'o devices trying to put data on a bus at the same time... one of them could get hurt (usually the GIME, in reported expe- riences). Especially under OS-9, where the interrupt register at $FF92 is re-ad at least 60 times a second, it makes sense to not have that data be corrupted by bogus MPI data coming on at the same time. So UPGRADE YOUR MULTIPAK NOW! E-CLOCK SYNCHRONIZATION: All accesses to peripherals need to use the 6809 E clock to validate the transfer of data (especially at 2Mh2^). A few early versions^ of third-party devices accidentally were made with registers that didn't do this. All have been fixed for a year now, as far as I know. Also, sometimes a module (especially os9pl) will get hit by an errant program, and then you os9gen a new disk... which gets perpetuated with the bad os9pl from then on through newos9gens. We also find that people often reverify a bad module quite by accident using disk editors on their bootfile, thus hiding future trouble. Keep a log of all changes you make, and CRCs! MISC THEORIES Most other problems fall into the mystery section (meaning we don't have a firm handle on the caizse yet). I have two pet ideas that may or may not make sense, but which are bolstered in part by experiences by myself and others. One is that since interrupts cause the inter- nal BASIC ROM to turn on (to get the interrupt vectors), the ROM stays on a bit too long and corrupts the data bxis at times. Probably a dumb theory <grin>. The other is that the dead cycles within many instructions have an effect. During the dead cycle the address bus contains $FFFF (which turns on the ROM!) and again, perhaps this data sticks around, or the address lines change too fast enough once in a while from true address to FFFF. This ties in with partial evidence that some 6809s at 2Mhz will start changing their address lines immediately after the end of an E cycle, perhaps even before E-gated devices finish up . We do know that oddball reads/writes occur at times to strange ad- dresses, and this might explain them. A third theory gaining some acceptance (but we just don't know how the GIME works internally) is that the GIME, like the S ANI chip , powers up using either the up or down side of the main oscillator clock (remember hitting reset on SAM machines to get the right red/blue fake color phase? likis that). Perhaps one side is better than the other. Certainly powering down some- times cures a boot or other problem . So who knows? We also know that changing cpu brands, and sometimes switching GIMEs, will of- ten cure timing problems and tJiesparklies. Not always, though. CONCLUSIONS We're still gathering data, and occasionally do run across something unexplained. For the most part though , BLOBs have become fairly rare. This may be because people have more L-II experience, or newer hard- ware, or a combination. OS-9 itself is not at fault , and note that even RSDOS applications can and do suffer from the same symptoms. The basic answer is that we moved up to a faster machine, while still using older peripheral eqtiip- ment. Tlie order of the bootlist CAN affect the symptoms (as we Ve seen), but this is simply software showing up hardware bugs, and is NOT the fault of OS-9 itself. So the final word is this: our best evidence is that there really _isn't_ a boot list order bug. Look to your hardware instead. -kevin- P.S. The above information has been gleaned over the past two years from per- sonal experience, many phone calls and network messages, and the work of Bruce Isted, Tony DiStefano, Chris Burke, Roger Krupski, DP Johnson, Dave Wiens, Ken Schunk, and many others. FS: Ifyou have anything to add, please send information to me at: 76703,4227 - CompuServe OS9UGPRES -delphi uunet!76703, 4227@compuserve.com and More. Downloadacopyof DIRM. This utility will display a directory of the memory modules and which memory block each' module resides. NOTE: The following information is con- tained on the inside back cover of the DISTO Super Controller II manual. The author is Kevin Darling and is offered here in a plagiarized form. —Rodger Alexander— OS-9 LEVEL II FORMAT/BOOT PROBLEMS When a new bootdisk is made, a boot file is used. This is a text file that contains the names of all the drivers and descriptors that make up your specific bootdisk. The order in which these drivers and descriptors appear in this list CAN catise problems. The symptom is, bootdisks that have trouble booting up or formatting disks. The formatting problems are more com- mon but the cause is not always identified as a bad boot disk. Changing the order in which the drivers and descriptors appear will cure the boot/ format problem . It seems that the RBF and CC3Disk drivers MUSTre^de in the same 8K block. If you have modified your boot, installed or patched drivers you may have caused CC3Disk to drop down to the nexi; memory block. Usually nxoving the INIT module from it's present position to the bottom of the list, works. Remember though, the OS9p2 driver niust always be the first on the list. You can change the order by using EDIT or retyping the whole file using BUILD then Tise-OS9GEN*td makeanew bootdisk. Another method is to actually delete and re-install modules los- ing EZGEN. Bellingham 0S9 Fouth Comer 68xxx Mug Sehome 0S9 "What should we call ourselves? Or does it mailer? Iffhat does mailer is -whal is our purpose. "Whal is il Ihal >»e can provide as a group Ihal -we canrol achieve on an individual basis? Of course Ihe grealesl advanlage in combining forces and meeting as a group is the sharing of our common interest in 0S9. Sharing our knowledge, experience, and resources to help one another. 0S9 is a powerful system that is growing world wide and with the advent of the 05-9000 for the 80486/66030-40. we have a lot to look forward to. PH^EFITS: Qub Public Domain Library Access to the Gimix multi- tasking 0S9 system Group purchases at discounted prices Monthly Users Meeting at Sehome High School N^3 Letter Barbequed RBBS 0S9 Conference. Bulletins and 350 Downloads Demonstrations and Guest Speakers Stale-wide 039 User Groups CoCo/OS-9 Software - Hardware CoCo Hardware/Software PERSONAL COLOR RADAR (Vidlex package for down loading radar weather fax) MATH TUTOR (Rom Pak) .. ^.DDIO SPECTRUM ANALYZER (Rom Pak) fflCRO wms DS-es digitizer 8S9TRSCOR^ fifW TKSFDIT PraaSION TIME MODULE (Real Time Oock Rom Pak) ZOKO RAN Rom Pack GHANA BWANA (039 Disk Game) SUPER SCREEN MACHINE (Disk) eOLORCOM/E (Disk) S.ANDS OF EGYPT (Disk) ONE ON ONE (Basketball Game-Disk) BIOSPHERE Game (Disk) FLJPSIDE Game (Tape) DALLAS QUEST (Disk) POOY.AN (tape) FUL-O-PAJi (0S9 level-1 screen utilities) RS-232Pak TELEWRlTER-64 lordprocessor (CoCo 1-2) DATAPEN yght Pen (tape) MAGI-GRAPH (Disk) gflPER PITFALL (Rom Pak) MICRO ILLUSTRATOR (039 Disk) PlTFALL-11 (0S9 Disk) JfEGA-BUG (Rom Pak) MUSIC (Rom Pak) PEANUT BUTTER PANIC Game (tape) CASTLE OF THAROGGAO (Rom Pak) PEGASUS (0S9 Disk) DESKMATE (0S9 level-1) HIGH RESOLUTION JOY SHCK RADIO BALL Game (tape) DIAGNOSTICS (Rom Pak) DUNGEONS OF DAGGORATH (Rom Pak) GOMOKU/RENJU (Rom Pak) CANYON CUMBER (Rom Pak) bask: 09 (Level-; Disk) TETKS (iftHB f^i Osy Levei-I FLIGHT SlMULATOR-1 PERSONEL FINANCE II (Rom Pak) X-PAD Januan Meeting Sehome H.S. Jan, 11 7;30p.m. (room 109) Agenda: Wes Payne has been working on an E-mail type of security message base for 0S9 using Basic09. Wes will demonstrate and explain the process involved. Wes has also set up special "USER GROUP" access directories on the Gimix. Documentation and manuals will be available to help us answer the remaining questions regarding RMS and the INTROL C Compiler. A demonstration of some recent utilities that have become a must in solving the Boot Order Problem referred to by Kevin Darling at the beginning of this Newsletter. Group Goals need to be addressed at this meeting- And hopefully even more CoCo / 0S9 Stuff for sale should be available for viewing and pur- chase. z o — ,y 2 f. 1-1 ? >- K to G) CM »— 00 OJ J » «W M M liJ > U J • (0 fr OJ LJ ,- $ °, 1 r 0) 1 < - GO 1 < 1 < 1 < o UJ I CQ 1 < n < OJ 1 < 1 < CD Z a. i t- z ID Q D h UJ J, U < h a o Q. o h 3 I 111 h