From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!blade.stack.urc.tue.nl!lennart Thu Jun 23 18:00:15 CDT 1994 Article: 70047 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!blade.stack.urc.tue.nl!lennart From: lennart@blade.stack.urc.tue.nl (Lennart Benschop) Newsgroups: alt.folklore.computers Subject: Re: 4004 processor info Date: 22 Jun 1994 08:20:41 GMT Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands. Lines: 70 Message-ID: <2u8s8p$djt@tuegate.tue.nl> References: <2u5hd9$onj@sundog.tiac.net> <1994Jun21.062324.15060@iglou.com> <2u8c5d$rkh@illuminati.io.com> NNTP-Posting-Host: blade.stack.urc.tue.nl Status: RO In article <2u8c5d$rkh@illuminati.io.com>, John wrote: >In article <1994Jun21.062324.15060@iglou.com>, >Bill Marcum wrote: >>>Can today's Intel machines run 4004 executables? >> >>VERY unlikely. The 8080 could not run 8008 binary code, nor can the >>80x86 run 8080 code. Source code written for the 8008 or 8080 could be >>re-assembled to run on later CPUs. > >Actually, what I've heard is that the 8080 *binaries* can be >automatically converted to run on the 8086. This influenced some of >QDOS's system calls: ever wonder why there's an interrupt to print out >a string terminated by '$'? Answer: because CP/M had such a function, >and one of the original design goals of DOS was to be a CP/M clone. >There was a program that would take 8080 binaries for CP/M and convert >them to 8088 binaries for QDOS. I don't think binaries can be converted very well from 8080 to 8088 format. First there is the problem that you cannot easily see which is code and which is data. Further the 8080 instructions and the corresponding 8088 insstructions are not all of the same size. Therfore the addresses will be different. Unless you can get a clean disassembly of the CPM COM file, you cannot convert. Assembler *source* files for the 8080 can be translated automatically to 8088 assembler source. For one thing the 88 has register pairs, e.g. BH and BL which form the 16-bit BX register. This is just like the good old 8080. I think the BC pair is mapped to CX, DE to DX and HL to BX. A is mapped to AL. One of the pointer regs (BP,SI or DI) is used for temporary address. Another feature of the 8088 is that the bits in the status register are compatible to that of the 8080 and that all instructions with 8080 equivalents set the same flags. THe whole raison d'etre for the LAHF and SAHF instructions is to convert the instructions PUSH PSW and POP PSW PUSH PSW can be converted to the sequence LAHF XCHG AH,AL PUSH AX At this point, most 8080 instructions can be converted to a single 8088 instruction, except - LDAX STAX XTHL (need a temporary address register, e.g. SI) LDAX B converts to MOV SI,CX MOV AL,[SI] - PUSH PSW and POP PSW (see above) - Conditional CALL and RET (convert to conditional jump with call/ret) - RST (Is this ever used in CP/M?) Can be converted to call. - Conditional jumps with large displacement (convert to conditiona jump and normal jump). This process expands the original COM file. Something could be gained by a simple optimizing pass. Note that MSDOS defines an entry point at address 5 of the PSP. Therefore the familiar CALL 5 to execute a CP/M BDOS call works!!!!! Most of the MSDOS functions below a certain number are compatible to their BDOS counterparts. As long as the CP/M program did not modify or generate machine code, and as long as it would fit into 64K after conversion, it would run painlessly. On today's machines one can run a software emulation of CP/M faster than the original Z80/8085 machines would run it. Further note that the similarities between 8088 and 8080/Z80 still contribute significantly to the efficiency of a properly written software CP/M emulator for the PC. -- Lennart Benschop --- lennart@stack.urc.tue.nl "Real programmers do it in hacks." 52 65 61 6C 20 70 72 6F 67 72 61 6D 6D 65 72 73 20 64 6F 20 69 74 20 69 6E 20 68 61 63 6B 73 2E Forth/C/6809/Linux/ZX-Spectrum/Z80/80x86 From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!usenet.ins.cwru.edu!po.CWRU.Edu!rfd Mon Apr 4 23:39:10 CDT 1994 Article: 64312 of alt.folklore.computers Xref: uchinews news.groups:78815 comp.os.misc:2975 alt.folklore.computers:64312 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!usenet.ins.cwru.edu!po.CWRU.Edu!rfd From: rfd@po.CWRU.Edu (Richard F. Drushel) Newsgroups: news.groups,comp.os.misc,alt.folklore.computers Subject: RFD: comp.os.t Followup-To: news.groups Date: 1 Apr 1994 06:05:59 GMT Organization: Case Western Reserve University, Cleveland, OH (USA) Lines: 88 Message-ID: <2ngdk7$pfl@usenet.INS.CWRU.Edu> Reply-To: rfd@po.CWRU.Edu (Richard F. Drushel) NNTP-Posting-Host: slc10.ins.cwru.edu Status: RO REQUEST FOR DISCUSSION (1st POSTING) PROPOSAL FOR NEW NEWSGROUP proposed by: Richard F. Drushel (rfd@po.cwru.edu) ====================================================================== Group name: comp.os.t Status: unmoderated Distrib: world Summary: a newsgroup for the discussion of T, a multiTasking operating system for the Coleco ADAM microcomputer RATIONALE: Despite being abandoned by Coleco Industries in 1985 in favor of Cabbage Patch Kids, the Z80-based ADAM microcomputer has continued to enjoy a loyal following, both among original ADAMites (who paid $700 for their computers) and newcomers (who found them at garage sales for $20). Recently, an international design team consisting of Richard F. Drushel (rfd@po.cwru.edu) and Guy Cousineau (ab773@freenet.carleton.com) has developed a preemptive multiTasking operating system for the ADAM, T, which allows multiple programs (including ColecoVision video games) to run concurrently (either full-screen or in separate windows on the 256x192 display). T, which will be formally introduced at ADAMcon 06 in October, has already created a flurry of interest and activity in ADAM forums on CompuServe, the Cleveland Freenet, and Fidonet. Opening up a USENET newsgroup for some of this traffic would be a public service to those many thousands of people who have ADAMs sitting in the attic somewhere, unaware that (1) support still exists for their "orphan", (2) the ADAM has not been left behind by modern operating system design, and (3) you can now play e.g. "Gorf" and "Spy Hunter" at the same time. In addition, professional programmers and operating system designers may benefit from the practical examples of multitasking in a minimized- hardware configuration. Lastly, we like the serendipitous look of this proposed addition to newsgroup namespace. CHARTER: The proposed group will provide an unmoderated forum for discussion of any issues related to the preemptive multiTasking operating system T for the Coleco ADAM microcomputer. These include, but are not limited to: * porting cartridge-based ROM software to RAM operation * compatibility with existing ADAM operating systems (e.g. EOS-5/7/8, OS-7, CP/M 2.2, TDOS 4.58) * bug reports and kernel updates * optimizing new ADAM applications to run under T * new ADAM peripheral design considerations (e.g. ADAMnet vs. port I/O devices) * installation hints, tips, and kinks * comparisons with other single- and multitasking operating systems on other computers (e.g. MS-DOS, MS-Windows, OS/2, Unix, MacOS, Linux) * general ADAM advocacy ("keeping the flame alive") SUPPORT: The proposed group will be directly supported by the ADAM Forum on the Cleveland Freenet (xx001@po.cwru.edu). Our Internet and non-Internet contacts with the worldwide ADAM community will be utilized to prepare appropriate FAQs and serve as an initial repository of T expertise. Arrangements for a permanent ftp site for FAQs, etc. are incomplete at this time, but it is expected that an ftp server will be available soon. ====================================================================== Please send comments and criticism to rfd@po.cwru.edu, and post information for discussion to news.groups. ====================================================================== NOTE: The RFD is being issued as per the advice of "How to Create a New Usenet Newsgroup", which is regularly posted in news.announce.newgroups. Please refer to this article for any questions about the mechanics of newsgroup creation. This RFD has been crossposted to news.groups, comp.os.misc, and alt.folklore.computers. Followups are set to news.groups. --- Richard F. Drushel, Ph.D. Department of Biology Case Western Reserve University Cleveland, Ohio 44106-7080 U.S.A. From urb@onramp.net Wed Jun 28 09:49:43 CDT 1995 Article: 106199 of alt.folklore.computers Xref: uchinews alt.folklore.computers:106199 comp.sys.ti:5436 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!news.onramp.net!usenet From: urb@onramp.net Newsgroups: comp.sys.ti,alt.folklore.computers Subject: Re: the 4A (was Re: TI human factors prize) Date: Tue, 27 Jun 95 21:28:28 PDT Organization: On-Ramp; Individual Internet Connections; Dallas/Ft Worth/Houston, TX USA Lines: 99 Message-ID: References: NNTP-Posting-Host: dal05.onramp.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage Status: RO In article , writes: > Newsgroups: alt.folklore.computers,comp.sys.ti > Path: news.onramp.net!news.sprintlink.net!simtel!uwvax!uchinews!ellis!enf1 > From: enf1@ellis.uchicago.edu (Eric Fischer) > Subject: Re: the 4A (was Re: TI human factors prize) > X-Nntp-Posting-Host: midway.uchicago.edu > Message-ID: > Sender: news@midway.uchicago.edu (News Administrator) > Reply-To: enf1@midway.uchicago.edu > Organization: The University of Chicago > References: <3sc18q$7q2@dns.netvision.net.il> <3sfk5r$1mr@sashimi.wwa.com> <950624.132540.9u3.rnr.w164w@alpha3.ersys.edmonton.ab.ca> > Date: Mon, 26 Jun 1995 16:29:46 GMT > Lines: 16 > Xref: news.onramp.net alt.folklore.computers:109731 comp.sys.ti:5733 > > Russell "Russell_Schulz@alpha3.ersys.edmonton.ab.ca" Schulz writes, > [TI-99/4a] > >yes, but the console BASIC was pitiful -- programs would take forever > >to start up, checking for unnested FOR/NEXT, and then not run all > >that quickly (which would have made up for it) > > You can't blame it all on the BASIC. The main reason for the > slowness was that the CPU actually didn't have direct access to > the built-in 16k of memory, but had to do every memory access to > RAM through a request to the 9918A video chip, which actually > owned the RAM. The ROM and the optional 32k memory expansion > were actually attached to the CPU and could therefore run much > faster. > > Eric > enf1@ellis.uchicago.edu > More specifically, the execution speed of BASIC and improvements provided by EXTENDED BASIC can be explained as follows: BASIC speed limits (from most limiting to least limiting) IMHO -------------------------------------------------------------- * The BASIC interpreter, including the parser, prescan, and most of the general interpreter routines (excluding the floating point math routines) were written in a intermediate language called GPL (Graphics Programming Language). There was a GPL interpreter contained in the console 16-bit CPU ROM which was written in 9900 assembly language. THUS, EACH BASIC STATEMENT WAS SUBJECT TO A DOUBLE-LEVEL INTERPRETATION. First, the GPL instruction had to be interpreted by the GPL interpreter. Then, the sequence of GPL instructions in turn interpreted the tokenized BASIC program. This was the primary speed limiter for BASIC. * The BASIC interpreter, except for the floating point routines, was stored in GROMs (Graphics Read-Only Memories), which could only be accessed in a relatively slow, indirect fashion (same as the 16K VDP RAM in the console). * All BASIC program and data was stored in the 16K VDP RAM in the console and was accessed in an indirect fashion, which was considerably slower than direct memory access. * All numeric calculations were performed to full 13 (15?) digit resolution, even for the simple loop variables such as 'i' in: for i=1 to 100.... Although this was a slowdown for programs which required only simple integer math, for scientific applications, the 99/4A was actually quite fast. There were some comparisons between the 99/4A and some of the other home computers of that period (Commodore, Atari, etc.) which showed that the 99/4A actually outperformed the competition in scientific, number-crunching applications. The reason: all the floating point routines in the 99/4A were implemented in assembly language in the console ROMs, which resided directly on the 9900 processors 16-bit bus with no wait states inserted, and the other units were 8-bit based vs. the 16-bit 9900. EXTENDED BASIC speed improvements --------------------------------- * Much (but not all) of the BASIC parser and interpreter was contained in a ROM in the EXTENDED BASIC cartridge. The portions of the BASIC interpreter contained in the ROM were substantially faster because: 1) They were written in 9900 assembly language, so there was only a single level of interpretation for this ROM code, instead of two levels as in the GROM-based interpreter code. This was the most significant speed gain in XBASIC. 2) This ROM was mapped directly into the 9900 address space, so access to this ROM-based portion of the interpreter was faster. * Much of the BASIC program and data was stored in the 32K expansion RAM, if present. As in the cartridge ROM, the 32K expansion RAM was directly mapped into the 9900 address space, and thus was much faster to access than the indirectly mapped 16K console VDP RAM. Hopefully, this gives some technical insight into the performance determinants of 99/4A BASIC and EXTENDED BASIC. Paul Urbanus *** - WARNING - *** urb@onramp.net *** "Urbite ships attacking" *** *** (Parsec, 1982) *** From rfd@po.CWRU.Edu Thu Jul 27 09:42:32 CDT 1995 Article: 109353 of alt.folklore.computers Xref: uchinews alt.folklore.computers:109353 comp.os.cpm:9930 comp.os.misc:4639 comp.sys.misc:4235 Path: uchinews!ncar!gatech!usenet.ins.cwru.edu!po.CWRU.Edu!rfd From: rfd@po.CWRU.Edu (Richard F. Drushel) Newsgroups: alt.folklore.computers,comp.os.cpm,comp.sys.misc,comp.os.misc Subject: The Future of the Coleco ADAM: keynote speech from ADAMcon 07 Date: 27 Jul 1995 00:22:28 GMT Organization: Case Western Reserve University, Cleveland, OH (USA) Lines: 755 Message-ID: <3v6m84$i2q@usenet.INS.CWRU.Edu> Reply-To: rfd@po.CWRU.Edu (Richard F. Drushel) NNTP-Posting-Host: slc10.ins.cwru.edu Status: RO The Future of the Coleco ADAM: 1995 perspectives by Richard F. Drushel at ADAMcon 07 July 20-24, 1995 Waterloo, Ontario, Canada First, I'd like to thank Dale Wick for asking me to give this year's "Future of the ADAM" speech. Second, I promise to you that, although I have a Ph.D. and my job is biological research, I will keep the technical jargon to a minimum. Third, I'd like to apologize in advance if some of what I have to say makes you angry or upset. Fourth, I want to warn you that it's very likely you *will* be angry or upset at some point in the next half hour. As you will see, this is both necessary and good. Fifth, I want to reassure you that I am *not* here to make personal attacks, and I want to reassure you that I will *not* take any of your anger or distress as a personal attack against me. And last of all, I need to include all the standard disclaimers: the views expressed are my own, and do not necessarily reflect the views of the convention organizers or anybody else in the ADAM community, etc., etc. In this lecture, I will begin with a little ADAM history. Next, I'll talk about the future of ADAM hardware and software. Finally, I'll discuss some of what might best be called community issues, and try to bring everything together into a few takehome messages. I. History. Many of you here today have been part of the international Coleco ADAM community from its very beginnings. You got a ColecoVision video game system in 1982. You watched ADAM computer commercials on television, paid $600 US your R59 ADAM at Christmas 1983, maybe had it sent back for repairs when it was dead out of the box. You subscribed to Family Computing and Computer Shopper because they published listings of SmartBASIC programs. When Coleco went bankrupt, you joined NIAD (the Northern Illiana ADAM users group) or some other users group, or you started your own users group. You subscribed to newsletters, wrote articles for newsletters, or published your own. You bought an ADAMlink modem, joined CompuServe, and started calling BBSes, or maybe you started your own BBS. You started to talk electronically to the people you were reading about in the newsletters. You saw Eve Computer Systems come and go, you saw the start of Orphanware Business Systems and Micro Innovations. You saw the rise and fall Solomon Swift. You went to the first ADAMcon in 1989. You have seen all the important "firsts". I, however, came late to the ADAM, and even later to the ADAM community. Let me tell you a little about my history with the ADAM. My first ADAM was my Dad's, an R59 bought that first Christmas in 1984, with a 160K disk drive no less, rescued from the trash in 1988 when he got sick of software bugs and bought a Tandy 1000 PC clone. Dad had joined NIAD in its second year, but had given up on both them and the ADAM a year later because NIAD's SmartBASIC programs kept locking up his system. I renewed the NIAD subscription (mostly for the product line, I didn't get too involved in the articles). I bought a new version of SmartBASIC 1.0, an R80 console, an extra tape drive, a Panasonic printer, and the two "Hacker's Guide to ADAM" books. My original intention for the ADAM was as a home word processor: I was starting graduate school and had to generate lots of paperwork, and our lab had only 2 computers, which were always busy. When I found out that I could read blocks off a 160K ADAM disk in a PC 360K drive using Norton Utilities, I got motivated to write a PC program to copy ADAM files. This led to lots of PC and Z80 assembly language hacking, and eventually disassembling ADAM's EOS operating system and SmartBASIC. Eventually, I got too busy with school to play with my ADAM, and it was clear that I could never do enough bug fixing quickly enough to use my ADAM to do useful lab work (which had been my original intention). I dropped NIAD in early 1989, before ADAMcon 01 got off the ground, and that was my last contact with the ADAM public at large until the fall of 1990. At that time, I was starting to write up my Ph.D. thesis, and I bought a laptop with an internal 2400 baud modem. I got an account on the Cleveland Freenet, and found an ADAM sig, with sysops none other than our own Herman Mason, Jr. and George Koczwara. When they found out how much I had figured out about EOS and SmartBASIC, with only slight help from the "Hacker's Guide" books, and when they saw the preliminary version of SmartBASIC 1.x, they realized I had done something nobody else had done, and which lots of ADAM users could benefit from. Through their BBSes and their contacts, they got me plugged back into the ADAM community. They are responsible for my being here today. The reason I am telling you the history of my personal involvement with the ADAM is to emphasize that, compared to many of you pioneers out there, I am a latecomer and even an outsider. I believe that this gives me a certain unique objectivity, but my lack of seniority in the ADAM fraternity, if you will, may make it difficult for some of you to consider the comments I will make shortly. II. Hardware. I know that I surprised and alarmed several of you at ADAMcon 06, when I stated the fact that the read-only memory chips in game cartridges, disk drives, and on the ADAM system board have a finite lifetime. ROMs and EPROMS have a mean time before failure of 10 years. This failure is a single-bit error: a 1 becomes a 0 or a 0 becomes a 1 somewhere. Since the ADAM is now 12 years old, and the ColecoVision 13 years old, we should expect to start seeing flaky game cartridges, or ADAMs with obscure errors in SmartWriter (since SmartWriter is in EPROMs), or even ADAMs which crash all the time (since both the OS7 and EOS operating systems are in ROMs). There is no way to predict where or when one of these single-bit errors will occur, and it's possible for one to occur and do no overt damage. For instance, if the error occurs in an internal message string (like a hidden programmer's name or "Hi Cathy" message), you won't see any effect. If, however, the error occurs in a menu string, or in a screen data area, it might show up as a corrupted SmartKey menu, or some stray bits of garbage in one part of the screen display; but normal operations wouldn't be otherwise affected. The worst case is, of course, an error in a code segment--the actual machine code gets mutated to a different instruction, with totally unpredictable results, and then the program malfunctions. Imagine the effect of such an error in the EOS ROM routine _WRITE_BLOCK under SmartBASIC: you could load and run existing programs on tape or disk, but you couldn't save anything, because the _WRITE_BLOCK routine itself had become damaged. There is also ROM code stored inside the 6801 microcontrollers which control the operation of the tape drives, keyboard, printer, and the ADAMnet itself. This ROM too is subject to single-bit errors over time, and any failures here will have devastating consequences: a dead tape drive, a dead printer, a dead ADAM. ADAMs beginning to lose their minds...a terrifying thought. Fortunately, there are steps we can take now to guard against the day when one of these insidious single-bit errors happens to your ADAM. Devices exist which can read and write standard ROMs and EPROMs; they are common and relatively inexpensive (about $150 US), as are blank EPROMS ($2 to $5 US apiece). The strategy is, read all your ROMs now, while they are still good, and save the data; when one goes bad, program a new one with the saved data, and you're set for another 10 years or so. In the case of the EPROM (E for Erasable programmable read-only memory), you don't even have to buy a new one--just uncover its little quartz window (it's usually covered with a label), erase it with bright ultraviolet light and reprogram it. For the 6801 microcontrollers, however, the task of replacement is a bit more complicated. The 6801s have their programming built-in when they are manufactured; there is no way to change it or replace it. An EPROM version of the 6801, the 68701, is available, but (a) it's expensive, about $25 US, and (b) the 68701 reader/writer is far more expensive than a standard EPROM burner, about $500 US, and (c) it's not exactly pin- compatible with the 6801, so you can't just plug a 68701 into a 6801 socket without some extra jumper wiring. A final replacement headache is that your defective chip may not be socketed; it may be soldered directly into the circuit board. In this case, you have to desolder the old chip in order to install the new chip (preferably in a socket to make it easy to replace next time). Desoldering a 40-pin chip can be a difficult skill to master, so the average ADAMite will probably have to pay a professional repairman to do it. I have never seen a game cartridge with socketed ROMs. The EOS and SmartWriter ROMs and EPROMs are always socketed. The 6801 microcontrollers are sometimes socketed, sometimes not. There are copyright issues involved, but it certainly would be nice if we could form a centralized library of EPROM and 6801 binaries, so that when *your* SmartWriter ROM or *your* Cabbage Patch Kids Adventure In The Park game cartridge goes bad, there is a known good copy somewhere to restore it from. Someone with the proper hardware could burn new EPROMs and supervise replacement of defective 6801 microcontrollers with 68701s. This might be a good job for A.N.N. to coordinate, in cooperation with the existing ADAM repair services, or interested hardware hackers like me who already have some of the necessary equipment. Or A.N.N. might buy the necessary equipment as a public good, and designate someone to operate it, providing services at cost (that is, non-profit) to any ADAMite. Just to warn you, I shall have more to say about profit later in this talk. If your ADAM doesn't begin to lose its mind in the next few years, it's likely that some of its peripheral devices will start to break down. Some of this is simply due to age, but age effects are exacerbated by some of Coleco's bad designs for the hardware. Nothing is fan-cooled and everything runs hot. Try touching the big aluminum heatsink at the back of the ADAM printer sometime after it's been on for an hour, or a data pack that's been shut up in a tape drive. The worst is the original 160K disk drive--through cheap design, the power supply circuitry is badly overloaded, and you can boil water off some of the components. Chemistry tells us that for every 10 degrees Celsius (that's 18 degrees Fahrenheit) increase in temperature, the rate at which chemical reactions take place doubles. This means that some parts of the poor disk drive are going bad about 128 times faster than they would if they were kept cool to a more reasonable 30 degrees Celsius (that's 86 degrees Fahrenheit). The takehome lesson from this bit of CHEM 101 is that, if you want to make your ADAM last as long as possible, you should keep it cool. Fans and air-conditioned rooms work best, but cold basements are okay, too. What do you do when one of your peripheral devices dies? Howard Pines and a few others can make some repairs. Since complete ADAM systems can still be had for less than $50 US, you might consider picking up a spare ADAM (or two) at the local Good Will or flea market. I'm pretty sure there are spare ADAMs for sale somewhere around here :-) This will give you an extra keyboard, tape drive, printer, and system unit; you can use the backups while your original is sent off to be repaired. Coleco disk drives are very hard to come by, so if you have a chance to get one, grab it while you can. As for third-party hardware, you'll probably have to find someone to fix it for you. George Koczwara and I are prepared to deal with Orphanware stuff, and I believe that Mark Gordon will still do repairs on Micro Innovations stuff. Since everything third-party except the Orphanware serial board is now out of production, you'll have a harder time acquiring duplicates of this hardware, at any price. Since the ADAM hardware is old and some of it is scarce or unobtainable, you should be worried about what you will do if any of it dies. For those of you who have stuck with your base ADAM system and are contemplating upgrading to disk drives, parallel printers, serial modems, or even hard drives, scarcity and age are big impediments--you can't find it to buy; if you do find it, scarcity makes it expensive; and if you sink big bucks into it, it may turn around and repay your investment by dying of old age. This is enough to make even the most devout ADAMite heave his ADAM into the dustbin and buy a PowerPC or a Pentium. Technology can help solve the problem of scarce, aging ADAM hardware, but the cost may be high. Let's consider a few possible hardware futures for the ADAM. We could build new hardware that's just like the old. We could design and build new, better hardware--how about a SCSI interface, or 24-bit color graphics, or 16-bit stereo sound? We could redesign the ADAM system board to use a 25 mHz Z380 CPU and 16 megabytes of RAM. We could have some kind of "ADAM-on-a-card" to plug into an expansion slot in a PC clone. Do any of these excite you? Mark Gordon has said that he would be only too glad to do any of these, if somebody will pay him enough to design it, and as long as *somebody else* makes the investment to actually build, sell, and support it. This won't be cheap. How excited are you now? Mark Gordon is a businessman, and a businessman wants to make a profit. Given the high startup costs involved in designing and debugging a new piece of hardware, or even making more of an existing design under license, I believe that there will *not* be any more new ADAM hardware in significant quantities, because there's no way to make a profit from ADAM hardware anymore. If there aren't at least 20 people ready to prepay in full, you won't even break even. Few if any of us here are sufficiently well-off that we can absorb those kinds of monetary losses, simply for the "greater good" of the ADAM community. This is not to say that there won't continue to be new hardware developments for the ADAM. People like Chris Braymen or Dale Wick or me will have have some new things from time to time; but these will be strictly build-it-yourself projects. If you want one, the responsibility is yours to buy the components from JDR, wire wrap it, and test it yourself. If you're not technically adept, you may be able to convince somebody to assemble one for you at cost or at a nominal fee; but nobody will be making 50 of them for sale pre-assembled and ready to go. This is 1995, not 1986 (when, I'm told, Orphanware Business Systems could make more than a few tens of thousands of dollars US in hardware sales). The unpleasant fact is, in the ADAM community of 1995, there's not enough market to justify the investment for a businessman who wants to make a profit. To some of you, another unpleasant fact is that many ADAMites have moved on to other computers, most frequently IBM-PC clones. I actually view this as an unexpected benefit, which can be exploited to the benefit of ADAM users. Modern PCs have large-capacity hard drives and disk drives, high-resolution video displays, serial ports, parallel ports, the ability to access mice, CD-ROM drives, magneto-optical disk drives, scanners, you name it. A typical 80286 PC, which is considered junk nowadays, often has more peripheral hardware on it than the most advanced ADAM with every available third-party bell and whistle. Even the lowly IBM-PC/XT has a 20 megabyte hard drive, a 360K disk drive, a parallel port, and a serial port. And PCs are cheap, some almost as cheap as a complete bare ADAM system. The ADAM-only versions of this hardware, if they exist at all, are scarce and expensive. A Micro Innovations 1.44 megabyte disk drive cost nearly $300 US when you could still get them; for the same money, I can get a used '286 with both 1.44 megabyte and 1.2 megabyte disk drives, plus a 40 megabyte hard drive. Given these economic incentives involved in increasing one's computing power, at first glance, the hands-down winner is the PC over the ADAM. But if I had some way to allow my ADAM to use the advanced hardware of my PC, then maybe I would have some incentive to keep using my ADAM. This is why I view the introduction of PC clones into the ADAM community as a benefit, because (shameless promotion mode on) I have developed a way to let ADAMs use IBM hardware. I call it ADAMserve. As many of you saw at my demonstration, the basic idea behind ADAMserve is, you let an ADAM communicate with a PC via a serial connection. Whenever ADAM wants to access a disk or tape or printer, instead of looking for a genuine ADAMnet disk or tape or printer, it instead asks the PC to look for one of *its* disks or printers. The PC hardware does all the work; it "serves" the ADAM (hence the name), and passes the results back to the ADAM over the serial connection. The ADAM operating system software is rewritten so that your application programs never know that they aren't using "real" ADAM hardware; the switch is totally transparent to the user. By extension, *any device* that you can attach to a PC which transfers either blocks or characters can effectively be used by the ADAM, as if it were ADAM's own. Of course, you need a genuine ADAM serial board in order to establish the communications link; but serial boards are common (in fact, the Orphanware type is still in production by HLM-GMK), and the serial board is the *only* additional piece of non-Coleco hardware you need. A 1-tape-drive ADAM, bare out of the box, when equipped with a serial port and ADAMserve software, can use the PC hard drive, disk drives, parallel and serial ports, and real-time clock. Collecting the ADAM-only equivalents of this hardware nowadays is a difficult and expensive task. ADAMserve is intended to be free except for distribution media costs--you provide the PC and a serial board. Since there isn't enough of a market to allow production of most ADAM-only hardware to continue, and since many people already own PCs with advanced hardware capabilities, I believe that something like ADAMserve will be the average ADAMite's only hope for upgrades, and for replacing original ADAM peripherals which die of old age. III. Software. Just as for hardware, the twin issues of innovation and maintenance are important as we consider the future of ADAM software. Fortunately, this means that my remarks about software can be briefer than those about hardware :-) Innovation means writing new software that meets some need in the ADAM community. Maintenance means keeping existing application programs running despite any hardware or operating system innovations, as well as bug fixes for existing problems. Since economic incentives apply equally to software and hardware, my prediction is that, from now on, there will be little or no new application software produced for the ADAM, and that code maintenance and minor bug fixing will be a necessary but neglected job, relegated to the few programmers left among us. I think it's a pity, but aside from perhaps games, there isn't really any software class in the ADAM software library which is crying out for a new program; there are already adequate choices for all. On the EOS side, for word processing you have SmartWriter and SpeedyWrite; for graphics, PowerPaint; for databases, SmartFiler; for spreadsheets, ADAMcalc; for telecommunications, ADAMlink V; for programming, SmartLOGO and several flavors of SmartBASIC; for music, VideoTunes and any of Chris Braymen's software for the MIDI interface. On the CP/M and TDOS sides, there are many fine choices in all categories except graphics and music, since CP/M and TDOS are text-based operating systems. Even if none of the available choices in some category exactly suit you, it's unlikely that someone is going to spend a year writing the perfect version for you--unless you get highly motivated, highly educated about the guts of the ADAM, and write it yourself--because other than attaboys and the feeling of well- being which accompanies heroic acts of selfless altruism, there are no rewards to be had. Consider also the plight of the remaining ADAM software vendors. They have stocks of software acquired when there was reasonable hope of sales, at full prices. As the ADAM community has grown smaller and smaller, the remaining active ADAMites tend to have more and more software, picked up when ADAM systems are liquidated. Those who remain probably already have copies of what the vendors would like to sell. This inventory is virtually unmovable, and the vendors can never recoup their losses. Thus, vendors have little incentive to add yet more unsalable software to their stagnant inventories, further limiting the market for new programs. At this point, new ADAM software can only arise out of the goodness of someone's heart, or as a necessary part of some new bit of ADAM hardware which needs driver code. Anybody who thinks he can recoup more than perhaps media and mailing costs will be quite disappointed. You can't sell software for what it's worth, either intrinsic worth to the ADAM community because it's such an improvement, or worth to you because you slaved over it for a year to get it working. If you want as many people as possible to use it, your only real option is to give it away. Given the shrinking ADAM community, the number of people willing to vote with dollars for new software is also shrinking. Those of us who are programmers wish from time to time that this were not so. In my own case, the $10 US per copy of my SmartBASIC 1.x that I profited over my media and printing expenses was used to buy ADAM hardware so that I could better support it through my software. Of the 40-odd copies of SmartBASIC 1.x that I have sold since its introduction in 1991, probably 25 were sold in the first two years, another 10 the third year, and an odd copy here and there thereafter. More have been given away as door prizes for ADAMcons lately than have been sold :-) If SmartBASIC 1.x were new for ADAMcon 07, I would be lucky to sell 5 copies at the convention itself, a few over the next year, and subsequent "new" copies would only move as ADAMcon door prizes. I wouldn't even recoup the photocopy costs for a minimum run of 10 manuals. In 1995, if you are an active ADAM programmer, like me, there is no way that you can be doing it for hope of financial gain--by now, there's none to be had. I'm an ADAM programmer because I'm intrinsically interested in the ADAM. I write software for *me*, and if other people find it useful, that's great, but I'll program whether anybody else cares about what I'm doing or not. For me, it's been *fun* (though often challenging and frustrating) to learn about how the ADAM works, and how to make it do interesting things. Unfortunately, I have not found many other people like me in the ADAM community. There aren't many of us programmers left, for a variety of personal and professional reasons. *I* don't believe you need a Ph.D. in order to learn how to write your own software in SmartBASIC or even assembler, but most of *you* out there believe otherwise; and I can't overcome the strength of your belief. There are many practical benefits to doing your own programming, not the least of which is that you can make your program do exactly what *you* want it to do. More important nowadays, however, is that ADAM programming skills can be part of your maintenance toolkit. If all the ADAM newsletters disappear, all the ADAM BBSes go off-line, no more ADAMcons are held, and you can't find anybody else who has an ADAM, then you, like Robinson Crusoe, can be self-sufficient on your own desert island. For me, that is an important motivation--because I'm really worried that the ADAM is about to become a desert island. IV. Community. The annual ADAMcons have been public celebrations of the community of Coleco ADAM users since 1989. Attendance peaked at over 100 for ADAMcon 04, but geography severely hurt ADAMcon 05, and both geography and international economics prevented many otherwise enthusiastic Canadians from attending ADAMcon 06. The extra 3-month interval between 05 and 06 made it harder to sustain interest, and the subsequent hurry-up to hold ADAMcon 07 in July again has, I'm certain, created logistical problems for Dale, Jill, and the other convention organizers. And the prospects for an ADAMcon 08 are far from clear. The ADAMcons are a public service to the ADAM community. They aren't supposed to turn a profit, but they have to break even. In order to break even, there has to be a certain critical mass of attendees. In order to make it worth someone's while, or some users group's while, to put effort into planning and running an ADAMcon, you'd like to see a little more than the bare minimum attendance. But I'm not sure that it's reasonable to expect much attendance at all. Already, the evidence is clear that there are not enough dollar votes to support new ADAM hardware and software development. What's the attraction of yet another ADAMcon? There won't be much new to see, the sessions will be pretty much the same as they've always been, most of the big-name personalities from the first 5 years of ADAM have moved on to other things, so those of you who like to hobnob with royalty will find only Johnny-come-latelies like me. Unless this is your first or second ADAMcon, everything is as familiar as an old shoe, only the city and hotel are different. Is it really worth $250 US for the same hamburger in a different bun? Well, it must be, since all of you are here now :-) Unless you are a first-timer just discovering that there is a wider ADAM world, like me at ADAMcon 04, you must admit that the ADAM per se is only a flimsy excuse for your attendance this year. The real reason you're here is social. At past ADAMcons, or via now- defunct newsletters, or through now-disconnected BBSes, you met people who have become your friends. The ADAM brought you together, originally for some concrete and practical purpose (such as, you wrote some software that I want to buy), but now the ADAM connection is a historical artifact. Some of you would keep in touch whether there were still ADAMcons or not, whether you ever used your ADAMs again or not. There is nothing wrong with this; I merely state it as an important fact to consider in the planning of future ADAMcons, if there are to be any. At some point in the near future, maybe in a year or two, maybe even now, there will not be enough dollar votes from the ADAM community to justify holding another ADAMcon. This is inevitable; the ADAM community is not growing any more. Just look at the ages of the people sitting around you. Growth comes from youth, and nowadays, the ADAM has little to offer the 12- year-old video game wizard or embryonic computer geek. Compared to other computer and video game options currently available, the ADAM and ColecoVision have been completely surpassed. This was not true as recently as the early 1990s, when sound cards and high-resolution color graphics were still relatively uncommon on IBM-PC clones, and Sega and Nintendo versions of video games still weren't very different from the ColecoVision versions. But today, if you're a kid, unless somebody gives you an ADAM, or your parents or grandparents have one already, you won't even know ADAMs exist; and once you've played DOOM on your neighbor's Pentium, the likes of Burger Time and even Spy Hunter (my all- time favorite game cartridge) look pretty lame. In his Future of the ADAM speech at ADAMcon 04, Rich Clee talked about the need to match people with ADAMs. Don't let people be tricked into buying expensive PCs if all they really need is an ADAM with SmartWriter. It would be nice to do this, but marketing hype conquers all. Something is wrong when you need a Pentium and a laser printer to write a simple letter, and when the word processing program takes 20 megabytes of hard disk space and 8 megabytes of memory. But like it or not, those are the standards of today. If it doesn't have scalable, proportional fonts and the ability to include fancy graphics, nobody wants it, even if they don't really *need* those features. Worse, however, once all the nifty features are available, people will use them, become dependent upon them, and never again conceive of doing their jobs without them. At that point, the game is over. For contrast, Wordstar 3.3 for CP/M is a 23K .COM file on a floppy disk, and runs in 64K of memory, but unless you have a daisy-wheel printer, it won't "look" as good as the laser- printed version, and it will take 10 times longer to print out. The floor has risen beyond what the ADAM can provide, I think needlessly so, but I can't win this argument with Bill Gates, the president of Microsoft Corporation, who's laughing all the way to the bank. Consequently, I now believe that the ADAM has ceased to be a computer that people would use to perform real work, as their system of choice, if they had access to more modern machines. All the EOS software for doing real work, like SmartWriter, SmartFiler and ADAMcalc, is more a "toy" than a productive tool. "Gee, I'd never have thought you could do that on an ADAM, but my Mac does it better and faster." The CP/M software has a wider usage, because there have been many other computers besides the ADAM which run CP/M, but it too isn't going to be found in today's offices and businesses. If the ADAM is no longer a viable tool for today's computing needs, why do you bother with it any more? Part of the answer is interia--you've invested so much time and money into it, you're in too deep to give it up. Another component, as mentioned above, is social--you've met some dear friends with the ADAM as a catalyst, and thus you have an emotional attachment to the ADAM. In my own case, have found the ADAM to be an ideal environment for learning about digital electronics and computer programming. But I am a rare minority in this. Inertia and socializing are not sufficient, in the long run, to insure the growth of any organization, let alone maintain its status quo. The best evidence I can give of this is my own users group, B.A.S.I.C. (Best ADAM Support In Cleveland). Our monthly meetings, held in my basement, begin happy and sociable, but when it's time to talk about the ADAM, it gets quiet. With few exceptions, nobody has done anything with his ADAM since the last meeting, nobody knows what he wants to do with it today, nobody says except in vague terms what he wants the group to do next time. If someone creates a structured agenda, there is little interest. Nobody seems interested in learning anything new. Soon, talk turns to what people are doing on their PCs at home, we break up and most go home. Those who stay usually are having hardware problems, which are diagnosed and repaired if possible. Those who are left after that eat pizza, and I'm usually left wondering why we're bothering to have these meetings, except to collect dues for the annual Christmas dinner and to eat pizza once a month. In the case of B.A.S.I.C., there is blame on all sides for our current state of affairs. But I would argue that the lack of a desire to learn new things is the primary difficulty we face. Since ADAM software in general often isn't as user-friendly as more modern software, and since the ADAM has its own hardware quirks, it *will* be harder to learn to use than the average Mac or PC running Windows. Given the economic realities I've talked about previously, this will never improve. Thus, the average ADAMite will not be able to wait passively for someone else to work out all the bugs and kinks--he has to learn enough to do that himself. Since this will require effort, if he isn't internally motivated enough to do this, he might as well be honest with himself, put his ADAM in the attic, and have done with it. V. Synthesis. I came into the ADAM community as a public person at ADAMcon 04. While this represents the peak of ADAMcon attendance, probably this was on the downside of the peak of the ADAM community in general. The Solomon Swift debacle, which was before my time, seems to have been the first breach of trust. Since then, everything has been downhill. The catfight over FidoNet versus ADAM BBSes broke up the telecommunications links which had previously kept ADAMites in contact, and created hostilities which still persist. Important resource people like Tony Morehen and Guy Cousineau found better things to do with their lives and moved on, leaving a void of programming experience. One by one, the hardware vendors went out of business. People stopped writing new ADAM software because there was no money in it. PCs and Macs got less expensive and became more powerful than ADAMs, inducing ADAMites to gravitate to where the action was, so to speak. And soon, CompuServe will move to an all-new graphical user interface, like Prodigy and America OnLine, which can never be accessed from an ADAM, so ADAM and all the other 8-bit microcomputers will be swept aside as insignificant--as nowadays they are, in dollar terms. When this happens, the last great connecting link for the ADAM community will be broken, and ADAM will be without a large-scale electronic voice. For those of us who choose to remain with the ADAM in some capacity, it may be painful to confront these realities. That's why I warned you at the outset that I might say things which would make you angry or upset. But confront them we must, if we wish to maintain some semblance of an ADAM community. Rich Clee's ADAMcon 04 dream of an ADAMcon 0E (that's 14 in hexadecimal) seems quite improbable to me now, but it will certainly be *impossible* if the status quo is allowed to continue. Our best shot at changing the status quo is to consciously change our group philosophy from advocacy to maintenance. It doesn't matter how many good reasons we can think of for why people should be using ADAMs instead of PC clones--the uninitiated are not interested, and telling us over and over is just preaching to the choir. We've lost, get over it, and move on. Circle the wagons and concentrate on taking care of the people who are already here. If we can't win globally, we should at least win locally. If a lost ADAMite stumbles across us, fine--welcome to the fraternity, we'll take good care of you. But we can't afford to launch expeditions into the wilderness to find all the lost ADAMites. I realize that, with the loss of ADAM advocacy, vendors are effectively being told to eat their inventories--new, lost ADAM users are more likely to buy hardware and software than veterans of 4 or 5 ADAMcons, and no new users means no sales. I can't, however, change this fact: in 1995, there is no way to make a living solely from the ADAM community. Terry Fowler is trying it, and he claims he's doing it, but I have my doubts. Ask Rich Clee how fast his inventory is moving; ask Herman Mason and George Koczwara how brisk their sales are. At this point, these gentlemen can't be in it for the money (unless they are deluded); they are basically providing a public service out of the goodness of their hearts, which they will continue to do as long as they can (mostly) break even. Maintenance philosophy means anticipating problems before they occur. Picking up a spare ADAM system is good preventive maintenance. Getting an account on your local Freenet, if you live near one, is another: when CompuServe becomes unusable by the ADAM, you can still send and receive Internet E-mail, and keep in contact with other ADAMites who are on the net. Learning how to program the ADAM, first in SmartBASIC, then in assembler, is a vital maintenance skill: if you get cut off from the rest of the world, you can do your own troubleshooting, and you'll always be able to write your own software, and thus, your ADAM will always be able to do what *you* want it to do. Remaining active users groups and A.N.N. can coordinate repair services, software libraries, and technical support, and can make necessary technical information available. Think about your ADAM as if it were a 1957 Chevy convertible. It runs, and on sunny summer days you drive it around to show it off. It's a great car, and you could probably drive it back and forth to work every day, but if anything broke, it would be murder finding parts, or a garage with the experience to fix it. So, you don't take too many chances; it stays covered in the garage most of the time. You join a car club, learn how to do tuneups, how to change points and plugs, get reprints of the shop manual, and learn as much about the car as you can. You become your own expert, and teach others what you know, just like others taught you. This requires energy and activity; if you aren't interested in maintaining it yourself, and if you aren't rich enough to pay somebody to do it for you, you'd better stick with a more modern automobile. There is no shame in that, but you have to be willing to admit to yourself and to everybody else that you don't want all the trouble. For me, the prime intellectual attraction of the ADAM is that it's a closed universe with definite limits: since it's a commercially dead architecture, it isn't changing very much, and it stays put long enough so that you can, in principle, learn everything there is to know about it. It has interesting complexities, yet it is simple enough that you can carry almost the entire machine and operating system around in your head. You can teach it to yourself without trying too hard. Compare this to a modern IBM-PC clone running MS-DOS and Windows. Both the hardware architecture and DOS have stayed remarkably constant since 1981, so what you learned about the original PC/XT way back then is still mostly valid for a Pentium, and you've had 14 years to assimilate it all. The Windows operating system, however, is so huge and complicated that it takes 10 tedious, highly technical reference books from Microsoft to *begin* to explain it; and after late August, you can throw them all away, because the new Windows '95 introduces a host of changes and incompatibilities. Unless you are a professional programmer and paid to look at those manuals all day, you have no hope of ever mastering their contents. As amazing as it may sound to you avowed non-programmers out there, ADAM programming can be fun, even though Windows programming is always terribly hard work. I warned you at the outset of this speech that I would probably make you angry or upset, but that this was both necessary and good. It was necessary because these strong emotions are about the last motivating force we have left to get ADAMites off their duffs. Here is your wakeup call: the end of ADAM may be inevitable, but how soon that end comes is directly under the control of every person sitting here tonight. Each of you is free to junk his ADAM and move on, no hard feelings. But those of you who choose to stay can't stay through intertia. You don't have the luxury of passively waiting for other people to do things for you--you need to boost your own activity level. Why do you think that ADAMcon 07 is "The Year To Bond"? If we want to continue to have some semblance of an ADAM community, we'd better start bonding, banding together to save our community, or it *will* disappear. The good which I want to come out of your feelings of depression about the current state of the ADAM community is that you'll get inspired to become more active in your users group, inspired to start learning how to be self- sufficient with your ADAM, and inspired to share what you know with the people in this room. Whether an ADAM community persists or not, *I* will still have fun with my ADAM, if only to please me myself. Despite all the gloom and doom I've been spouting up here, I want you to remember that the ADAM is *fun*. It's fun for *me*. ADAM isn't a tool any more, it's a hobby; so we can all lower our expectations. It doesn't have to be efficient, it doesn't have to be fast, because we're not basing our livelihoods upon it--it just has to be interesting. Since I find it interesting, and I find all of you interesting and friendly, I have a personal stake in seeing the ADAM community last for a long time. You've heard about World War I army platoons which bought cases of champagne in 1918 and agreed to meet every year to drink a bottle to the health of the survivors and to the memory of the fallen. Every year the attendance gets smaller, and finally the year comes when there is just one old soldier and one last bottle. "Here's to ya, lads," he says, raising his glass to a room full of ghosts. I don't want to be that last man. I don't want this to be my last glass. I don't want this to be the last year for the ADAM. But even if it is, I will still say, "Here's to ya, lads." Richard F. Drushel, Ph.D. ADAMcon 07, 23 July 1995 -- Richard F. Drushel, Ph.D. | "Aplysia californica" is your taxonomic Department of Biology, Slug Division | nomenclature. / A slug, by any other Case Western Reserve University | name, is still a slug by nature. Cleveland, Ohio 44106-7080 U.S.A. | -- apologies to Data, "Ode to Spot" From drushel@junior.wariat.org Tue Aug 1 11:30:03 CDT 1995 Article: 109899 of alt.folklore.computers Xref: uchinews alt.folklore.computers:109899 comp.os.misc:4663 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!bug.rahul.net!a2i!news.erinet.com!en.com!wariat.org!junior.wariat.org!drushel From: drushel@junior.wariat.org (Richard F. Drushel) Newsgroups: alt.folklore.computers,comp.os.misc Subject: Some ADAM history, post-Coleco (was Re: History of dead PCs) Followup-To: alt.folklore.computers,comp.os.misc Date: 1 Aug 1995 02:44:58 GMT Organization: Akademia Pana Kleksa, Public Access Uni* Site Lines: 174 Message-ID: <3vk4fa$o56@wariat.wariat.org> References: <3viub5$lvc@lastactionhero.rs.itd.umich.edu> NNTP-Posting-Host: junior.wariat.org X-Newsreader: TIN [version 1.2 PL2] Status: RO Andrew Philip Fabbro (afabbro@umich.edu) wrote: : For example, the Coleco ADAMcon post mentioned "The Solomon Swift debacle, : which was before my time, seems to have been the first breach of trust. : Since then, everything has been downhill. The catfight over FidoNet : versus ADAM BBSes broke up the telecommunications links which had : previously kept ADAMites in contact, and created hostilities which still : persist." This is one sort of history that would be interesting, as well : as simple business history. To amplify a little on my remarks at ADAMcon... Solomon Swift and the ADAM. The "Solomon Swift debacle" was the story of a swindle which didn't start out as a swindle. Around 1986, a man calling himself Dr. Solomon Swift (not his real name, not really a Dr. either) began publishing a good, highly technical and assembler- oriented newsletter called "Nibbles and Bits". It was full of neat assembler routines you could POKE into memory from SmartBASIC, to access OS routines, manipulate sprite graphics, format and edit disks, etc. Some came from disassembly of Coleco programs like SmartBASIC and SmartLOGO, others came from hardware manufacturers who gave him their latest add-ons to play with. From time to time, Sol, through his company, Digital Express, would release integrated, commercial versions of the hack utility programs he published in his newsletter. Some of these, especially the graphics program PowerPaint, stand among the best ADAM software ever written (for the end user; on the inside, Sol's programs were all cruft and spaghetti--he was totally self-taught and dyslexic as well; nothing had a true source code, it was all block edits in hex or POKEd in from SmartBASIC). In about 1988, Sol announced that he was developing a new operating system for the ADAM, called GoDOS. GoDOS would be a graphical interface, mouse/joystick driven, with icons, pull-down menus, dialogue boxes, MacOS for the ADAM, as it were. He also planned to develop new applications to work under GoDOS, replacing the original Coleco software--GoBASIC (an enhanced BASIC interpreter), GoFiler (a database program), GoWriter (a word processor), GoLink (a telecom program), and I believe GoPaint (a graphics program). Soon after this announcement in all the leading ADAM newsletters, publication of "Nibbles and Bits" began to get erratic. Sol finally said that he was in a temporary financial squeeze, but that work was proceeding on GoDOS; GoBASIC was almost completed. He asked for, and received, substantial prepayments from many ADAMites for the entire Go software series, as seed money to keep the project afloat. In 1990, he did release a password-protected, time- bomb version of GoDOS with GoBASIC to everyone who had prepaid (after a certain number of boots, even with the correct password, it self-destructed); but then he disappeared, and there were no more issues of "Nibbles and Bits". He took with him (I believe) over $5000 in prepayments. The ADAM community was completely shocked, because Sol had been an important source of good software and useful technical information. After much legal wrangling on the part of some who had been left holding the bad, Sol was finally tracked down, tried, convicted, and sent off to prison. He's still there today. In an attempt to make restitution, he left the rights to his other commercial software in trusted hands, with the direction that all profits go towards paying back his creditors. GoDOS with GoBASIC were released into the public domain. Out of curiosity, I've disassembled some of GoBASIC, and it's a prime example of creeping featurism run amok. You can do *everything*--music, graphics, menus, dialogue boxes, you name it--but there are so many features, there is no workspace left to do *anything*. It fills an entire 64K memory expander and all but 8K of standard RAM; the most you can do is show that individual commands work, but you run out of memory before you can build anything other than a toy program. And all the new command names are 15 characters long (Sol had evidently been reading some MacOS documentation), wasting even more memory. The other projected Go software evidently never existed--Sol's hope had been to write them in the GoBASIC... The scam soured lots of ADAMites; they left, betrayed, and have never come back. Those who remained became very skeptical of new software or hardware claims--something I ran into when I appeared on the scene in 1992 claiming to have disassembled and commented the EOS operating system and to have written a new, improved SmartBASIC interpreter. I actually had to get "name" people in the ADAM community to vouch that I was not Sol Swift in another guise; there is good evidence that before "Solomon Swift" appeared, the same man was "The Data Doctor", another early source of ADAM software and technical information, whose telephone stopped being answered one day... The Fight Over FidoNet Around 1992, a lawyer out of Kansas City, Missouri named Barry Wilson (who ran his law practice on 4 ADAMs) promoted an idea which eventually came into being as the ADAM News Network (A.N.N.). The concept was to issue (on disk) a sort of Reader's Digest of all the ADAM newsletters, every month, at a subscription cost a little over the materials cost (so A.N.N. could make a little money, to be used for other projects to benefit the ADAM communnity as a whole). This way, an ADAMite could keep up with current happenings without having to subscribe to 10 different newsletters. Barry had other visions for A.N.N., including having it act as a centralized administrative body, coordinating the dissemination of information, helping to organize the yearly ADAMcons, providing a dispute mediation service (a vestige of the Sol Swift scandal), etc. There was little objection to these ideas in principle. In practice, however, most of the long-distance communication between ADAMites was via the several newsletters and about 10 ADAM BBSes located throughout the US and Canada. As Barry began to spread his ideas around, he naturally began to run up a large long-distance telephone bill as he made the rounds of the BBSes. As a way to reduce his own costs, he seized on some local FidoNet nodes, whom he convinced to start carrying an ADAM Echo; and he belligerently began to encourage ADAMites to move to FidoNet. Some followed; the BBS crowd resisted, partly because of turf, and partly because Barry was being really insolent and intolerant about the entire issue. A fullscale flamewar erupted over the ADAM Echo. Naturally, the local node operators began to tire of the whole business (since they were just passing along the ADAM Echo to be nice guys). ADAM BBS traffic dropped to almost zero (because everybody wanted a freebie from the ADAM Echo instead of paying for their own long-distance BBSing), and, since there was no fun in it any more, many of the sysops took down their BBSes. The ADAM Echo stopped getting propagated because of Barry's badgering of various nodes and because the other traffic was all flames and whining. The result was that now there was no regular long-distance electronic communication among the ADAM community. Some of the diehard ADAM BBS operators tried to resurrect traffic by carrying their own ADAMnet Echo. Each participating BBS would have its own Echo area; local callers could post there. Periodically (maybe once a week), each sysop would call all the other BBSes, grab *their* Echos, and repost them locally. This worked at first, but then the originator of the ADAMnet Echo idea, a young vendor from New York named Steve Major, began another turf war: he wanted to collect all the local Echos, then have all the other sysops call just him to get a master copy. As I recall, he wasn't being timely about getting the local Echos, so the other sysops ignored him. Steve then began to assert his rights to the Echo software, in loud and nasty enough terms to (again) scare off all the traffic. The ADAMnet Echos are still there today, but nobody uses them; Steve Major sold all his ADAM inventory and went to the Amiga. Since the FidoNet flamewar, there are only about 4 ADAM BBSes still in operation, 3 running the ADAMnet software, 1 (maybe 2) running PBBS under CP/M. None of these has any traffic to speak of. Since A.N.N. started sending out monthly news disks, almost all the local newsletters have gone under--why subscribe to several newsletters when you can get the best of all of them from A.N.N.? Barry Wilson, leaving devastation all around him, has retired from what's left of the ADAM community, in very poor health, aggravated by all the flamewars. Sigh. These histories are to the best of my recollection, from some things I've observed personally, but mostly from things I've been told by others. Any of you others out there, please feel free to jump in and correct me :-) *Rich* -- Richard F. Drushel, Ph.D. Department of Biology, Slug Division :) Case Western Reserve University Cleveland, Ohio 44106-7080 U.S.A. From konigsba@thegroup.net Sun Aug 13 12:37:51 CDT 1995 Article: 111183 of alt.folklore.computers Xref: uchinews alt.folklore.computers:111183 Path: uchinews!vixen.cso.uiuc.edu!uwm.edu!lll-winken.llnl.gov!simtel!news.sprintlink.net!noc.thegroup.net!localhost From: konigsba@thegroup.net (Dan Konigsbach) Newsgroups: alt.folklore.computers Subject: Minor folklore: What Radio Shack and Coleco have (had?) in common Date: Sun, 13 Aug 95 06:55:14 GMT Organization: Data Transfer Group Lines: 14 Message-ID: <40k7md$od6@noc.thegroup.net> NNTP-Posting-Host: 199.2.50.67 X-Newsreader: News Xpress Version 1.0 Beta #3 Status: RO There's another thread here in alt.folklore.computers about the Coleco ADAM, (one of the more interesting might-have-been's in recent history) and it reminded me of a tidbit I thought was interesting. Back when the ADAM was around, two of the most widely known names in home computing were Coleco and Tandy/Radio Shack. These two companies had something unusual in common: If I'm not mistaken, they previously sold leather arts-and-crafts kits. Radio Shack is Tandy, which started out selling Tandycraft kits. Coleco originally stood for "Connecticut Leather Company". It's not a big point, but I thought it was an interesting coincidence. From noelle@cs.buffalo.edu Sat Apr 13 11:28:25 CDT 1996 Article: 138968 of alt.folklore.computers Xref: uchinews alt.folklore.computers:138968 Path: uchinews!news.luc.edu!chi-news.cic.net!news.math.psu.edu!psuvax1!news.cc.swarthmore.edu!netnews.upenn.edu!dsinc!ub!acsu.buffalo.edu!noelle From: noelle@cs.buffalo.edu (David M Noelle) Newsgroups: alt.sysadmin.recovery,alt.folklore.computers Subject: Re: Movie Depiction of Computers Date: 9 Apr 1996 02:56:38 GMT Organization: State University of New York at Buffalo/Computer Science Lines: 44 Message-ID: <4kcjl6$k51@azure.acsu.buffalo.edu> References: <312c47f4.1487149@news.dircon.co.uk> <4igb68$727@styx.uwa.edu.au> <4ijqbn$eil@narses.hrz.tu-chemnitz.de> <4j68d9$3ku@work.smurf.noris.de> NNTP-Posting-Host: gagarin.cs.buffalo.edu NNTP-Posting-User: noelle Status: RO Thusly quoth Matthias Urlichs : >In alt.sysadmin.recovery, article <4ijqbn$eil@narses.hrz.tu-chemnitz.de>, [...] >The fun part is that when Commodore built the 1541, they just replaced the >parallel IEEE bus with that wimpy serial thing (COME ON people, couldn't >you at _least_ do a proper three-wire handshake? Not too difficult on a >5-wire cable, no? Noooo....), patched the few locations which referred to >the second disk drive, and hacked the old code to run on one CPU instead of >two. This is _very_ obvious if you ever saw a commented assembler listing >(or commented it yourself ;-) for the beast. And all this time I thought the fun part was when they manufactured the damned things and pulled a few randomly off the assembly line for random trial-and-error research and development projects. That's a poilte way of saying that they had some bozo sitting around and randomly cutting out bits here and adding in wires there and testing to see if the drive still worked. If it did, it went back into the pile with the rest for distribution. If not, it got recycled. Occasionally, it worked better (or so it seemed) and they would make note of it. At least, that's what I heard from someone who repaired Commodore hardware professionally. He told me this story (I don't remember whether he told me the source) when he saw that the drive I had a problem with was, in fact, one of the randomly altered drives. It sounded like a rather bizarre and far-fetched tale, but I couldn't think of any reason not to believe this guy (I had known him for several years, and he didn't appear to be joking when he told me this) and I couldn't think of any better explanation for the scratched out connections on the drive's motherboard and the mismatching wires haphazardly soldered onto various components, particularly when the drive had never been serviced before. If anyone can confirm or refute this story, I'd be interested to hear about it. -Dave Noelle, noelle@cs.buffalo.edu the Villa Straylight Fuck the CDA Disclaimer:#include Quote of the day: Sign on bank: We can loan you enough money to get you completely out of debt.