íEíCfÃçü / Initialized by File Manager 4.0 for ADAMserve / File Manager (c) 1996 by AJM Software / ADAMserve (c) 1996 by Richard F. Drushel / n for the IDE card; so I have a limited supply of those chips preburned.It would be possible to manufacture more boards, but the propos- ition is expensive since all the layouts were destroyed and each card would have to be redrawn for manufacture, and at least 250 of each board produced.  Roughly you're talking about $1000, and I don't have the demand to get a return for that investment myself.I would be happy to supply anyone PREASSEMBLED cards for as long as I have inventory.  I have not made back thFIRST_DIR  Uªÿ BOOT       ˆDIRECTORY  ÈAdamHouseACleesA    €Clees#2A  	€CompClasA €DaleCOMPA €DaleZIPA  GeoffOA   €GeoffA    HarvPA    JoeAC09A  €Mitch#1A  ,		Mitch#2A  5PJ#1A     :€ReadME1A  <Rich#1A   >€Rich-1of4AW

Rich-2of4Aa.worldnet.att.net> To: coleco@flash.net <coleco@flash.net> Date: Tuesday, September 16, 1997 2:05 AM Subject: IDE controller cards>Terry, been meaning to get with you on a matter of importance.  At ADAMCON 09, the subject of HD IDE controller cards, MIB3 boards, double serial boards, and parallel interfaces was brought up.  MTAG user group in Toronto is in the market for about 10 this year they figure.  With that number from just one club, the idea prog- ressed into how many might be wanted AND, more to Ì1 ×68Bob,I have inventory of about 50 of each of the boards (unassembled) and components except for the Printer interface card which I will run out of very soon.  However, the MIB3 board can be used as a parallel card and eliminating some of the parts possibly just for that purpose.  With each order I assemble the card(s) and burn the GAL programmed chip with equipment and parts furnished by Mark when I purchased all his remaining stock.  However, there are some newer GAL chips he used that I cannot bure amount I paid Mark, so any business is more than welcome.  I have reduced the price of the MIB3 card to $49.95 assembled and tested with software and instruction.  I would be agreeable to quantity discounts on serial cards, too.  And, I have 64K and 256K cards of my own now that I can discount in quantity.Let me know what your interests are.Terry Fowler - ADAM'S HOUSE(Dale:  In his catalog, the HD cards are $49.95 US funds)-----Original Message----- From: Robert Slopsema <r.slopsema@postofficeRich-3of4AhRich-4of4Ap€Ron#1A    u€Ron#2A    |Ron#3A    €Ron#4A    SubscribA „TDOSmsgA  …€WillneriA ‰BLOCKS LEFT‹the point, how many are available (or can be produced). The idea was brought up that a possible appropriate use of A.N.N. be to buy enough boards or parts to make a new run worthwhile to produce.  Having no idea what your deal with Mark Gordon was and what the design rights are; we are a little in the dark as to the how, when and where of these hardware designs. Also discussed was the possibility of buying just the raw parts and having them assembled by the Toronto group for their members.I'd appreciate i the Atari adapter and other special con- trollers including new unopened roller controllers. I also carry the fiddly stuff - printer ribbons, printwheels, datapacks, etc. Likely of more interest to you, I can sometimes find used copies of books about the Adam. I also have the technical manual and the set of schematics, still blurry in places but the original size (about 18 x 24") so rather more readable than the 8 x 10s most often seen. I also have a vast collection of Adam newsletters from most major clubÌ1 ×61(response to a new ADAMite, Will Nerini)From the Clee'sWelcome back to the Adam world. It's a small one now to be sure, but just as a fig or pear develops its greatest sweet- ness as the water dries out so the Adam world seems to become ever more attractive as it shrinks. Talk to some of the folks about our Adamcons - and now is not too soon to start planning to be in Orlando next year (likely around Columbus Day) for Adamcon 10.  Ron Mitchell's posting alluded to a couple of Adam News Network pre almost any crashed tape or disc, assuming the fault is electronic and not mechanical. I generally charge a fee of $3.00 for my time and trouble, plus the cost of the medium (where applicable) and shipping. In short, whatever it takes to keep Adam users going, I try to provide. If I can't find it new I'll try to find it used, and if that doesn't work I'll try to find someone who can and refer you on. So - welcome back. If there's anything you happen to want or need, drop me an e-mail and (subject to the ssubmicroscopic hobby business (A.D.A.M. Services) offering hardware, software and supplies for the Adam. I still have a fairly large inventory of original software and licencing agreements with a number of the producers to keep on issuing their materials - I can even provide an original, factory-sealed copy of SmartLogo. I still have some remaining inventory of Micro Innovations interface cards of various types, and a huge mound of used Adams and their parts. Also have a lot of Colecovision cartridge games,t if you could let me know so I can pass on the info to MTAG, and A.N.N., especially concerning the HD cards.     Thanks.    [Bob]>PY   COMANSI    HEXARC     COMARC     COMBD      DOCBD04    COMBOOTBAS2IMGBOOTCALCIMGBOOTDAVIIMGBOOTFLASIMGBOOTLINKIMGBOOTLOGOIMGBOOTMAC IMGBOOTSPLAIMGBOOTTYPEIMGBOOTWRITIMGCD      DOCCD74    COMCDC11   COMCLONE21 COMs including the very early stuff. I refuse to loan them but will make them available for inspection any- time for those in my area, and anyone desperate enough to want to pay the cost of photocopying - the word extortion- ate comes to  mind, though the size of the job must be considered -  can have them for the asking. I also offer small services - I have most of the public domain collect- ions ever issued, plus the software later released as freeware. Provided I am given proof of legal purchase I can restoublications. As the body dumped with the responsibility for ANN's occasional publications, I am pleased to report that if you develop an uncontrollable lust to possess a copy of the Adam Survival Guide (now a bit dated in its directories, but otherwise still useful) ANN still has a couple left, and there is no shortage whatsoever of Guy Cousineau's EOS Programming Manual. If you need either, holler; the price is right as ANN charges little more than the cost of production plus postage.Separately, I run a ituation in my earlier general notice) I'll do my best to oblige as quickly as possible. Glad to have you aboard. MEOS     DOCEOSHD39AIMGERRCODESDOCEVE     HEXEXL     COMFC      DOCFC14    COMFF      DOCFF27    COMFM301C  IMGFM301C  IMGFORMAT  COMFORMAT  DOCFORMAT36COMHDFMT20 COMHEATH19 HEXIMAGE20 COMINITDIR DOCINITDR12COMIOBYTE  DOCIOBYTE12COMLT29    COMLT31    COMLT31    DYCLT31    DYCLT31    FORLT31    MYCLT31    MYCMIPART15COMMLOA the Atari adapter and other special con- trollers including new unopened roller controllers. I also carry the fiddly stuff - printer ribbons, printwheels, datapacks, etc. Likely of more interest to you, I can sometimes find used copies of books about the Adam. I also have the technical manual and the set of schematics, still blurry in places but the original size (about 18 x 24") so rather more readable than the 8 x 10s most often seen. I also have a vast collection of Adam newsletters from most major clubÌ1 ×61From: Frances &/or Richard Clee <cleechez@tamcotec.com> Subject: Big troublesTo all our correspondents - our computer has suddenly taken to crashing out totally - screen gone, keyboard ineffective, etc. - at about 90 minute intervals. We cannot tell right now if this is hardware, software, virus or what. Time constraints for many other obligations pr vent our spending the hours necessary to determine that fault and deal with it. Accordingly - if we do not respond to any communication, it is possib detail the problem you are encountering, and whether or not the problem is intermittent.  List any software or hardware that are associated with the problem.  Also list any modifications that have been done to your equpment.You may include a check or money order as a deposit for repair costs. You will be notified of the balance due.  Overages WILL BE REFUNDED!Carefully pack and ship your equipment to the address above via UPS or parcel post.  UPS is usually cheaper for larger packages.REPAIR CHARGES love you all. - Richard and Francesarge inventory of original software and licencing agreements with a number of the producers to keep on issuing their materials - I can even provide an original, factory-sealed copy of SmartLogo. I still have some remaining inventory of Micro Innovations interface cards of various types, and a huge mound of used Adams and their parts. Also have a lot of Colecovision cartridge games,D25 COMMLOAD25 DOCMMEX    COMMMEX    COMMOUNT11 COMNULU    COMPATH    DOCPATH13  COMPOWER   COMRAMTST15COMRDPARM10COMSERPORTSDOCSETBOOT COMSORTDIR DOCSORTDR10COMSPZ     COMSQ111   COMSQ111   DOCSTPARM11COMT458PAT LSTTDIR    DOCTDIR1-14COMTDIR2-14COMTDOS    DOCTDOS    DOC TDOS    DOC0TDOS    DOC@TDOS    DOCHTDOSINSTDOCTDOSINSTDOCTERM-TS1HEXTERM-TS2HEXTERMINALZ80TRANS10 COMTRANS10 DOCUCRLZH20COM
UNARC   COMUNARC   DOCUNARC   DOC UNCR    CÌ1 ×74                         COMPUTER CLASSICS                         Rt # 1, Box 117                         Cabool, MO 65689                                ********************************************************************** Phone (417) 469-4571 CST daily from 8AM - 8PM  If there is no answer, please try again.  I may not always here the phone.  VISA & MASTERCARD NOT accepted at this time.  Please send only money orders or checks. For repairs, please use a separate piece of paper to describe inle we did not get it, or the computer crashed before we could get out the answer, or simply we were unavailable at the particular time. We hope the worst will be over by Halloween. So if you send us a message and we do not respond - it may not have got here, or may have been lost afterwards in a crash, or a crash may have killed our response, or we may have been unavailable to deal with it. We sincerely apologize, and ask that you be patient until we and our computer can get its act together again. We still for ADAM computers Prices do NOT include shipping and handling.  Shipping depends on the distance, weight and shipper.  I will ship the cheapest way possible. Minimum handling charge is $2.00.  A surcharge will be made for repairing modified equipment-minimum $5.00  $10.00 each plus shipping & parts  64k expander, parallel interface, coleco power supply, autodialer, addresser card used with a parallel card, Eve SP-1, Eve-PS1 power supply, exp module #1, exp module #2, 300 baud modem, super action controlata soundfunc=201; style), that includes a sound sample player, as a proof of concept, I guess.  I'll probably be posting the source to it to the mailing list, or at least make it avail- able on my FTP archive.  Note to others who are interested in Version 0.77 of the TDOS version of my compiler, I've uploaded it to CompuServe, and  I'll get on my Web site soon.To make an integrated EOS development environment for develop- ing programs in my compiler, I could really use a RAM disk, which you've suggested OMMODORE, TI, SINCLAIR/TIMEX, OSBORNE, TRS 80, and IBM compatibles.(Editor's note:  this is the latest price guide I have.  At the present time, Dan does NOT fix any digital data drives because of the lack of part availability of the chip most often bad in the drive.)collect- ions ever issued, plus the software later released as freeware. Provided I am given proof of legal purchase I can resto, I'll make that available as soon as I get my GIF viewer to work with your (Rich Drushel's) prefered Adam palette. Currently version 1.0 of SHOWGIF doesn't display the image very well.  I have a RAWGIF command that ignores the palette and uses the default mapping and looks fine.  I've also developed a TDOS command line a program using MIC that loads sound samples in the Dynomite Sound Digitizer format and both graphs them and then plays them.  I wrote the overlay in assembly, which was assembled using Z80MÌ1 ×68From: dalew@truespectra.com (Dale Wick)Subject: Proposed EOS compilerRich Drushel,I'm continuing my work on a "visual" development environment for the proposed EOS version my compiler.  You asked me at AdamCon about how difficult it would be to incorporate your SB 1.x routines into my compiler.  Well, I haven't got a way of including external compiled library files in a compile yet, but I can add new (native) functions pretty easily.  I wrote an overlay (with out changing the compiler, as def dler, roler controller, keyboard$15.00 each plus shipping & parts logic board, game board$20.00 each plus shipping & parts expansion module #3 (without data drives)$25.00 plus shipping & parts ADAM console (without drives), disk drivesFor repairing add-on modules, monitors, printers or other computer- ized equipment, write for a price quote for the items you want rep- aired.  Customer can expect a 4-6 week turnaround time for most repairs.  Some problem cases may take longer.  I also service ATARI, Cto me that you have, and would be willing to let me use/resell as part of my compiler (I plan to sell the EOS version with documentation and give away the TDOS version with minimal documentation -- I probably have a market of 6 people for the EOS version ;-)  In exchange I would be willing to make available to you the latest version that contains anything I get from you.Since AdamCon I've developed a TDOS commandline utility using my new compiler that convertes PowerPaint cells into GIFs using my compilerre almost any crashed tape or disc, assuming the fault is electronic and not mechanical. I generally charge a fee of $3.00 for my time and trouble, plus the cost of the medium (where applicable) and shipping. In short, whatever it takes to keep Adam users going, I try to provide. If I can't find it new I'll try to find it used, and if that doesn't work I'll try to find someone who can and refer you on. So - welcome back. If there's anything you happen to want or need, drop me an e-mail and (subject to the sR and then converted using another new program "HEX2DATA" that creates a .MIC file containing a data statement with all of the machine code from a .HEX file produced by programs like Z80MR.  My compiler makes small effecient executables, and is pretty easy for me to work with, but to make EOS programs it is much easier to use a native EOS editor/compiler environment.  To do that I could easily require a harddisk instead of a RAM disk, but because temporary files mess up the directory (unless I include Krunces anyone know if the MIB-3 is bi-directional, or any of the other parallel ports?  Maybe the AdamNET one is bidirectional?  Dale 0.77 of the TDOS version of my compiler, I've uploaded it to CompuServe, and  I'll get on my Web site soon.To make an integrated EOS development environment for develop- ing programs in my compiler, I could really use a RAM disk, which you've suggested k   * File input/output -- both character based and block based that are all in pure assembly and written in 1994 and ready for insertion into an EOS version of MIC.  I feel that by making a visual development environment (expected completion AdamCon 15), I will be able to use the SmartKey routines easily for any program.Oh, BTW, I feel that what the world needs is a VT100 emulation added to AdamLink V.  Are you interested?  Would you allow me to write it and insert it if you're not interested?  I'm sure , I send out super-dittos to Zonker for the remarks regard- ing lack of/poor documentation for the ADAM. This is CLASS 'A', #1 reason that there is a lack of software to begin with. In contrast I'll compare the ADAM to the C-64...hands down the most popular 8 bit computer there was.The Commodore 8 bit computers had an OVERWHELMING supply of GOOD documentation for their computers! Why, just the other day I was reading through the 1541 users guide, and in the back it describes registers for the controller iÌ1 ×65From: dalew@truespectra.com (Dale Wick)Neil (neil@wick.net) said: >Someone at Adamcon was asking about the possibility of using an >Iomega Zip 100 dirve with the Adam.  I just happened to run across a Linux >driver for the Zip drive.  There seems to be enough source code that >something could probably be worked up.  See: > > http://www.torque.net/zip.html > >                                                NeilI took a quick peek at the Web page.  All we need is a bi-directional parallel port.  Doh in my application or something), it seems more useful to use a RAM disk.  Do you feel that this is a good approach?  I have now a set of routines: * Text editor -- very simple, but which I'm enhancing to allow more than a screen of text.   * Serial -- "universal", based upon Chris Braymen's QTERM patch. * SmartWRITER style SmartKey routines -- using a proportional font, dynamic display, etc. * Standard AdamNET media detection -- for a file request dialog * File Request dialog -- which still needs some worÌ1 ×69From: Geoff Oltmans <geoff@sprynet.com>Well, I just read a good batch of messages from Ron, Will, and Zonker regarding programming on the ADAM, and thought I would lend my own thoughts to this discussion.As a self-proclaimed video game/home computer historian, I wish to point out a few things which are great reasons why there is a lack of new software titles for the ADAM, and insight into my struggle with programming the ADAM, as well as the current state of personal computer software.Firstlythat I have all of the docs necessary.    DalePARM10COMSERPORTSDOCSETBOOT COMSORTDIR DOCSORTDR10COMSPZ     COMSQ111   COMSQ111   DOCSTPARM11COMT458PAT LSTTDIR    DOCTDIR1-14COMTDIR2-14COMTDOS    DOCTDOS    DOC TDOS    DOC0TDOS    DOC@TDOS    DOCHTDOSINSTDOCTDOSINSTDOCTERM-TS1HEXTERM-TS2HEXTERMINALZ80TRANS10 COMTRANS10 DOCUCRLZH20COM
UNARC   COMUNARC   DOCUNARC   DOC UNCR    Ctself, detailed programming informa- tion (low level information), as well as file organization. Commo- dore even published a book containing the SCHEMATICS for the C-64 for $20.00. Coleco didn't make any such information public.The other reason that I think that there is a lack of software available for the ADAM is that it never really had a lot of popu- larity to begin with (duh). This due, I think mostly to unfair treatment of the press regarding the first few SmartWriter printers that were defective (  24X Recordable CD-ROM (I explained that no such thing exists yet); 4.0GB hard drive or better 32 bit Sound Blaster (again, no such thing exists)...This kid was told by a counselor to get a machine like this! They get these machines that cost on average $3000-5000, when the average consumer can really only afford to spend $1000-2000. Who cares about backward compatibility? Come on. They then learn from the likes of Bill Gates and company that Quarterly upgrades to software is "okay", even if the user haszines. I think there's no doubt that Coleco got a raw deal with the ADAM.But that's water underneath the bridge...To expand on what Will said regarding, "It's the interface, stupid"  concerning the current condition of the personal computer. That certainly is an important issue, however, I think you missed the main problem.  Today, programmers in general are lazy. They are content to program in high level languages (Visual Basic, C, C++), and why shouldn't they? Why should they slave away to pro- duce roff the Windows95 bandwagon and I'm going to start using BeOS instead (since it will be ported to x86 architecture then). This should help curb the hardware inflation I mentioned.Now to answer Ron's question about why I don't program for the ADAM...hey...I'm having a hard enough time just reorganizing my disk collection and attempting to load a whole bunch of software onto my hard disk that won't boot from the hard drive, or don't have any support for the hard disk.Plus I got a new toy, the MIB3 card...es on a Pentium II 266 that run PERFECTLY WELL on their machine, and doesn't run well on someone's 586-133 or Pen- tium class 100 MHz machine, that the USER needs to upgrade!! Never before have I seen such hostility towards the user.I build and sell PC's for a living. Yesterday I was asked by a mother of a multimedia programming student for the following equipped system: Pentium II 266 MHz MMX processor (I am still convinced MMX is a pipe dream for the above reasons in the previous paragraph) ; 128MB RAM;never did I see an article stating that Coleco fixed them all, just that Coleco made junk). I remember asking people who had bought home computers at the time why they didn't buy an ADAM. Mind you that everyone I talked to had HEARD of the ADAM, and EVERYONE with the exception of two ADAM owners remarked that the reason they didn't buy an ADAM was because they had heard about all kinds of problems with the printers by salespeople (who presumably echoed and amplified the misconceptions of the press), or maga to pay for said up- grades...after all, that's how a lot of software companies make money today...they gouge the consumer with "upgrades" (what they mean to say is "bug fix")The problem compounds when the user has to upgrade every 6 months to a year (to keep up with current computing trends). It's an absolute travesty...A part of me wishes that computer prices would skyrocket, if anything to discourage the amount of hardware upgrade inflation that we are currently experiencing.Next Spring, I'm jumping ock-solid code that doesn't crash (ten years ago, crashy programs weren't a serious problem like they are today)? Why bother optimizing our program in order to make it run faster on older machines? I mean, for crying out loud, it's ridiculous that you should need a PENTIUM class machine with 16 MB of RAM just to do WORD PROCESSING!!!!  Programmers today have too many resources available to them; to the extent that they've lost touch with reality. Today's programmer EXPECTS that if a program he (or she) writwhich also lacked documen- tation when I got it. Talk later,*Geoff!*never did I see an article stating that Coleco fixed them all, just that Coleco made junk). I remember asking people who had bought home computers at the time why they didn't buy an ADAM. Mind you that everyone I talked to had HEARD of the ADAM, and EVERYONE with the exception of two ADAM owners remarked that the reason they didn't buy an ADAM was because they had heard about all kinds of problems with the printers by salespeople (who presumably echoed and amplified the misconceptions of the press), or magaÌ1 ×69Well, here's a thought.I was thinking it might be a cool project if we could add or replace the existing VDP with a memory mapped VDP of the same type or some other type. Immediately the problems that come to mind are having to rewrite all of the EOS and OS-7 routines that access video if you replace the VDP, and even still programs that don't use the OS routines wouldn't work. Since the VDP DOES have a composite video input, it might be possible to use the two together (for twice as many spritesrt. Does anyone know if the MIB-3 > is bi-directional, or  any of the other parallel ports?  Maybe,...the AdamNET one  is bidirectional?   > > Dale I recall Guy Cousineau once lamenting that nobody takes advant- age of the bi-directional printer port on the ADAM. I don't know if he was refering to the ADAMNET port or a third party port. Since Chris Braymen has done so much work with ADAMNET perhaps he could enlighten us. Regards, Harv> > DAM, Windows95, NT. UN*X,| "Yes" 7800/Lynx/Jag                           | "I'm GLAD you're happy." I'm a computer superfreak!              | - Dr. Who: "Hapiness Patrol"Enter command or <CR> for more !hink that there is a lack of software available for the ADAM is that it never really had a lot of popu- larity to begin with (duh). This due, I think mostly to unfair treatment of the press regarding the first few SmartWriter printers that were defective (Ì1 ×67From: Harvie Powis <bx705@freenet.toronto.on.ca> Subject: Re: Zip drive on the Adam> Neil (neil@wick.net) said:> >Someone at Adamcon was asking about the possibility of using an Iomega Zip 100 dirve with the Adam.  I just happened to run across a Linux driver for the Zip drive. There seems to be enough source code that something could probably be worked up. See:  http://www.torque.net/zip.html  > > Neil > > I took  a quick  peek  at the Web page.  All we need  is  a  bi-directional parallel po, etc.) The purpose of all this of course would be fast- er access to display memory, which is a limitation, at least for games. The disadvantage of this would be having to give of 16k of the system's available memory.  Maybe a second sound chip could be added as well, and these two devices could be put on a game card?Just some crazy ideas. :)*Geoff!*-- ------------------------------------ ------------------------------------ Geoff Oltmans                           | "Are you happy?" ColecoVision, AÌ1 ×73ADAMCON 09 By Joseph Alford     Thursday Reception.  There is no room 175 at the Midway Hotel.  The reception was in room 157.  We were in room 131, half a corridor away, because we were the next-to-last people to pre-register.  Procrastination wins again:  Many ADAMites were on the second floor.  The early bird gets the worm, but who wants to eat worms?  In fairness to the hotel, they were told to expect about 20 people and over 30 showed up.     The people in the two rooms directly across from tut I also look around at the vast majority who accomplish nothing at all.  My head is one of those that sticks up out of the swamp, and if that makes me egotistical, then so be it.  I got my vacation (two weeks back-to-back and only a month from hire date) from the new employer when I requested it.     ADAMcon is an interesting experience for me.  Almost everyone knows more about something than I do, and several people know more about everything than I do.  I feel like a nine year old at the circus and lov The convention began for me with Ron Mitchell's address on Friday morning.  At one time the ADAM community had the attitude that anything worth doing could (and should) be done on the ADAM.  (Dare I say we had a chip on our shoulder?)  Ron Mitchell and Richard Clee (Saturday's speaker) sang a different tune at this convention.  Many things can be done on the ADAM, an amazing number, in fact, but as other machines get bigger and faster there are more and more tasks for which the ADAM is no longer the best tlove watching other programmers work.  It never fails:  Within a few minutes I'm saying, "Hey, wait a minute.  What did you just do?  I didn't know you could do that.  Wow!"  There are many solutions to every programming problem and experts watch each other in hopes of learning a new one.     Frances gave a very basic presentation showing how to enter and sum a column of numbers.  That is exactly the approach one should take for a talk at ADAMcon.  Show new users something they can do.  Remove the mystery  to do anything for AC09 because I was not sure I would be able to go.     I stated in print several months ago that I would be ending a consulting job and that I am good enough at what I do that I would be able to dictate to my new employer when I would take my vacation.  My wife suggests gently that I am a bit (just a bit) egotistical.  As the old sage says drily:  "The boy values himself rather highly."     My own point of view is that I look at my accomplishments and don't value them highly at all.  Bhe hospitality suite (room 157) were not ADAMites and were not impressed with our 8-11 pm party.  As for the party itself, I have never understood the fascination some people have for alcohol.  I like who I am.  The idea of "loosening up" is frankly terrifying.  My wife, who doesn't drink either, thinks I could use a little (just a little) loosening up.  She is, of course, too polite to describe me as a Puritan, a person who suffers continuously from the suspicion that someone, somewhere is having fun.    e every minute.  Maybe that's why the reception bothers me so much.     Meanwhile, Frances Clee has been waiting patiently for me to quit talking about me and start talking about her ADAMCalc presentation.  Every time I have seen Frances speak she has expressed concern over the presence of the experts.  They make her nervous.  I tried at the reception to explain to her that she has no need to be nervous.  I am a professional programmer with fifteen years of experience.  I know a lot about what I do, but I ool.  There are still tasks for which it is the best tool, but it now shares the choir box with other voices and the harmony is good indeed.     By the way, in this era of shared desk tops I can now admit that I have always addressed envelopes with the best tool for the job:  a BIC pen.     Frances Clee talked about ADAMCalc.  I was very pleased until I realized that meant no one was going to talk about SmartLOGO which is one of my favorite topics.  Guess I should have volunteered myself.  I did not offerand get them started.     One of the newcomers this year was my wife, Helen.  She ran the computer and loved every minute of it.  Yes, I have tried to explain spreadsheets to her.  Yes, ADAMCalc was the spreadsheet I used.  Yes, I was a teacher for 12 years before I became a programmer.  The experience was hard on me, the wife, the computer and the couch.     Frances was not a threat.  Helen could ask questions - and did.  She felt free to make mistakes - and did.  Mistakes are how you learn.  Helen learnmazing is not that the bear dances poorly, but that it dances at all."     Herman Mason and Bob Slopsema were supposed to talk about Hard Drive Set Up and Repair.  Hardware problems delayed the start of this session for over an hour.  My family gave up.  Troy and Helen went to a local roller skating rink for three hours.  I hit two local book stores.     Saturday morning began with an address by Richard Clee with emphasis on chosing the right tool for the job.  For many jobs that is an ADAM, even in housekbook and keep running totals of several categories at the same time.  Sound familiar?  That is exactly what a spreadsheet does!     Gene Welch spoke next.  He talked about building an ADAMnet clock and about setting up a Hard-Drive cheaply.  At least I think that is what he talked about.  The last thing I remember is watching him take a pair of clippers and rip one of those multi-leg bugs off a circuit board.  I'm sure he knew what he was doing.  I'm sure the final result was more valuable than what he std, chiefly because of a long discussion of copyright problems.  ADAMites have always been ADAMant (lovely word, that) about protecting copyrights.  We've seen our software experts give up in disgust after selling 4 copies of a program and getting questions from 10 people.  Today, however, we have the opposite problem.  People want legitimate copies of programs that no one is currently selling.  ANN has formulated a policy to deal with this problem.  I am not going to state it here.  I think the subject is oard, but I was able to do some useful work, especially email.  Mitchell says ADAMLink V is not so good for Net-surfing.  He suggests using the TDOS program QTERM which allows access to PINE (email) Lynx, uploading/downloading thru FTP, Newsgroups, chat lines, Telnet and the search engines Archie and Veronica.  Sounds like a lot to me.  My ADAM, my IBM PC XT and my Pentium can all access the World Wide Web.  Of the three, the Pentium is the best tool for this particular job.  But, as Dr. D. says, "What is aed a lot from Frances Clee's ADAMCalc session.  Now she wants us to take a programming class together.     And yes, I did learn a few things myself.  I had never before blanked a block from a spreadsheet.  I had never noticed the printer bug that appears in large spreadsheets.  I don't use large spreadsheets.  Believe it or not, I do my taxes with a word-processor (SmartWriter), making lists and adding the columns with a hand calculator.  I even wrote a program one time that would let me go through my checs where a Pentium lords its grand GUI majesty.     P.J. Herrington spoke next on PowerPaint and related subjects and Gene Welch followed with a discussion of how to transfer PowerPaint Graphics to other formats for other computers.     After lunch came the ADAM News Network meeting.  To my surprise this meeting was open to anyone who cared to come.  This has been the practice, apparently, for some years.  I think that's a much better idea than a closed meeting.  The meeting ran an hour longer than expectearted with.  But when hardware experts go to work my mind shuts down and I have nightmares of Dr. Frankenstein.  Lunch was a relief.     Ron Mitchell talked about the ADAM and the Internet.  Graphics are out and a special text browser is needed, but such things do exist and it is indeed possible to do credible research on the Net.  There is even an advantage:  most of the advertising is graphics based.     When I was first on Compuserve it was with the ADAM using ADAMLink V.  I did not have an 80-column btouchy enough that it should be stated once by the ANN leadership and thereafter repeated verbatim by those interested.     Another item of great interest to me was a proposal that ANN use some of its money to pay for a hardware run of center-slot serial / parallel boards.  I think.  The discussion got a bit technical when defining the hardware to be produced.  What interested me was that only ANN could do this.  No single vendor could afford to tie up this much capital.  This particular issue was left verve.  The robots his students build have to be able to avoid obstacles while picking up plastic eggs and taking them to their home base.  Some eggs have higher values than others.  Some have negative values.  The robots must be able to distinguish the types of eggs.  The course teaches problem solving in a real-world situation:  limited resources and limited time.  Since the robots are too big and too fragile to transport, he brought a simpler model.  This robot would move foreward until it hit something anack problems so I missed most of that afternoon.     I did get back in time for the Yahoo Chat Internet Conference and the Compuserve Conference.  Several people all over the country were able to participate in ADAMCon 09 through these conferences.     Sunday, the final day.  A Continental Breakfast does not warrant getting out of bed.     Ron Mitchell's MIDI Music session was impressive as always.     The brunch was unbelievable.  The usual eggs, potatoes, bacon and sausage took care of the breakfast pe hands-on session both Helen and I took turns typing in the sample programs and we both enjoyed ourselves immensely.  This was probably our favorite session of them all.  I was so impressed that I bought the latest version so I can play with it more.    As an aside, one of the things that interested me was that the text editing was done in VDE.  For years people have been telling me that VDE is an excellent low-end word-processor that runs under TDOS.  It is described as very much like SpeedyWrite, my woris will undoubtedly be known as the kitten convention.  At one point the vicious attack kitten that had been roaming the presentation room was stalking Dr. Drushel as he paced during his Sunday presentation.  Luckily, his ever-alert fans noticed the dangerous beast and warned the good doctor, thus saving his bare legs from unsightly scars.     Dr. Drushel's robot was the second most popular small beast at the convention.  Dr. D. (as Zonker called him) teaches a course in robot building at Case Western Resery much to the discretion of Bob Slopsema who will make the initial contacts and determine the feasibility of the project.  The key, I think, is that ANN is taking the initiative for what I hope will be the first of a series of projects.  The future need not be one of constant retreats.     The ANN meeting went through the time for Bart Lynch's TDOS/EOS utilities lesson and into the time for Gene Welch's Multimedia Utilities.  I am sure those were excellent sessions, but by then I was having some serious bd then back up and move in another direction.  Drushel got this teaching job because he had practical hands-on experience with a small computer.  (Guess which one?)     Dale Wick did a demonstration of his micro-compiler for BASIC.  Actually, the language is not BASIC.  "For this version, the program is a mixture of MicroSoft QBASIC syntax, C, ADA, and some Coleco Adam specific ideas."  The key is that the resulting program can be compiled.  This makes the program run many times faster.  In a very intensivortion.  The lunch portion was a salad bar with an excellent assortment, including corned beef and cabbage.  There was a third area with three kinds of hot fish and two fish spreads.  A fourth area featured hot carved ham and roast beef.  to escape the room one had to run the gauntlet between two rows of desserts.  I have never seen such a spread.  We certainly got our money's worth on that meal.  I managed to mix Spanish peanuts with my scrambled eggs.  Crunchy, salty eggs.  Very interesting taste.     Thd processor of choice.  I finally got a chance to play around with VDE.  I found that it does indeed do insertions and deletions easily.  I did not get a chance to play with it a lot, but I had no trouble opening and closing files.  I have not yet had a chance to move text which is the other major word processing task.  I will keep you posted as I play with VDE further.     Came the Adam Store of which much good will be said.  Several vendors were very patient with me as I told them what I wanted, paid fordvance.  Further (an open invitation to any ADAMite) if you will let me know a day or so in advance I will put you up for the night of the meeting so you don't have hotel expenses.     Having said that, I should hasten to say that our meetings are generally Jerry and me talking for a couple of hours.  Neither of us is particularly inclined to try to teach the other and we don't get real formal.  Helen attends when she is not working.  Don Woolston comes when weather and health permit or when he has a harderfect on the XT.  I got used to that hard-drive.  Giving it up would be tough.     My final goal was to make my Pentium emulate a virtual ADAM.  Dr. Drushel was helpful in telling me what I needed to download from the internet to do that.  I'll keep you posted on these experiences also.     At the banquet Helen and I sat with Dale Wick.  I asked him what it is like to be a guru.  He launched into the story of how he was a teenageer and got his first computer (a TRS-80) and what he did with it.  The entir of those people and tell them if they really enjoy this game then they should also buy and play the original ADAMBOMB which I think is the finest game ever made for our computer. .     Having said that, I should hasten to say that our meetings are generally Jerry an iÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓmeet ADAM?     I was very surprised when Dale complained at the banquet that he often gets his 463-ADAM newsletter too late to attend the 463-ADAM meeting.  Dale lives in Ottawa, CANADA.  The meetings are held in Portage, IN, USA.  It never occurred to either Jerry Vrancks or me that anyone that far away would want to come to one of our meetings.  We generally schedule the next meeting one month in advance.  I talked to Jerry about this.  In the future we will schedule and announce meetings two months in a it, and then told them what I intended to do with it.  Herman Mason, George Koczwana and Howard Pine managed to straighten it all out and sell me what I needed rather than what I asked for.     My first goal was to re-attach my ADAM to my dot-matrix printer.  I broke my Eve serial / parallel box the last time I moved my ADAM.     The next goal was to make the ADAM access the hard-drive of the IBM XT that is its neighbor on my desk.  While the ADAM was cut off from the dot-matrix printer I was using WordPware or software problem.  We have actually had better attendance for some of our on-line meetings than for our regular monthly meetings.  We try to meet on-line every four or five months.  If there is some topic you want discussed either live or at an on-line meeting, please contact either Jerry or me.     ADAMBOMB 2 was the subject of much discussion at the convention.  Bob Bar convinced some people that they should open the disk and play this game that they have owned for a year.  I tried to get to eache table was fascinated.  This kind of story exists for every one of us.  How did you come to meet ADAM?  Let's tell those stories.     ADAM is a remarkable technological story, but most of us who are left are not all that interested in the technology.  Show me a TRS-80, a Timex, and an ADAM with their covers off and I doubt I could tell you which is which.  ADAMCon is a family reunion.  We are interested in people at least as much as in technology.  Let's tell the stories behind the people.  How did you Ì1 ×69Ron's Week'n'ADAM -September 2, 1997 by Ron Mitchell I have committed the ultimate transgression, for which there will be consequences no doubt.  I've taken the regal double blue back- ground from Marcel de Kogel's home page and applied it to my  486 DX4/120  as  wallpaper.  It serves to remind me which computer  I really like best.  Besides,  the result is quite impressive, if I do  say so myself.  Even with Windows 95 shortcuts plastered  all over it, it shows through well.Enough of that.  Therhe programmer control over pre-set fields on the screen,  a choice of fonts and spacing, and more.The  'escape codes' are usually made up of strings of characters, beginning with the 'escape' character,  27 ASCII or 1B Hex, foll- owed by one or more other letters,  numbers or symbols.  And  so, the  process  of  clearing the screen on my Thomson CSF  and  the Cybernex requires that my program send the characters,  1B 45 Hex or ESCAPE EThe moment the terminal sees the ESCAPE character,  it knows that theine got fired.This  bombshell  of  breaking news will generate  about  as  much interest as a penny in a bank vault,  but it gave me an opportun- ity to review a few things.  They seem worth sharing. TDOS termi- nal overlays quite frequently mess things up,  but if you have  a list  of  escape-codes for your terminal,  and a working copy  of SPZ,  or MLOAD,  you can do something about it. The CP/M and TDOS worlds are definately not 'plug and play',  but then what is?  In my  'snake pit' there are three 80he form of 'patches' or an accompanying           installation program.Without the proper terminal overlay,  your CP/M program might not interface  properly with your terminal,  and the results will  be visually unpretty.  Meanwhile, back in the snake pit, the Thomson CSF, which uses HEATH control codes, and the Cybernex were close, but not quite close enough.  How did I know that?  Well,  I tried running  MAINT.COM  that had been configured for  the  Hazeltine, that's  how.  The Hazeltine doesn't even u screen     homing the cursor     positioning the cursor     turning off and on the inverse video     turning off and on the half intensity video     turning off and on the flash function     deleting all characters from the cursor to the end of the line     deleting all characters from the cursor to the end of the page     cursor down, up, right, left     saving the cursor positon     recalling the cursor positionThese are only a few, but they are the basic ones. Some terminals give te's been some re-organizing going on  around here over the past few days. I've ditched the 80 column Hazeltine 1510  monitor  that has served my number one ADAM so well  for  7 years  and  replaced it with a Cybernex XL87D.  The Cybernex  was connected  to the PMC,  and the PMC was connected to CPM  3,  and since David Cobley (dcobley@island.net) gave me another PMC  that was connected to an HP150 terminal and also to CPM 3,  the Cyber nex  was  deemed more suitable for my 80 column TDOS ops and  the Hazelt sequence which follows is not meant to be put on the  screen, but rather to act as a control function.So  much for the theory.  In practice,  what it means is that al- though  the hundreds of CP/M programs available might run  on  an ADAM,  they  probably will not do so unless one of two things has occurred:  1)      The programmer wrote them on an ADAM using exactly the           same terminal as the user has.  2)      A choice of terminal overlays has been provided with the          program in t column terminals that  can  be used  with TDOS and either an Orphanware serial port or a  Micro- Innovations MIB2 or MIB3.  The Hazeltine is in a storage cupboard unplugged, so make that two. These terminals, having been made by different manufacturers,  operate in a different manner from each other,  in that the programming required to control their various functions is not uniform between them. The terminals have what is known as a set of 'escape codes' which control functions such as:     clearing these 1B Hex as an  ESCAPE character.  It  uses the ~ or tilde character plus a sequence  of hex characters. The resulting mess was not useful in the least.So  then I tried running on the Cybernex a version  of  MAINT.COM that  had  been overlaid for my HEATH-like Thomson CSF  terminal. This time MAINT at least looked like MAINT, although there was no inverse highlighting. Fortunately, since I have terminal documen- tation for both terminals,  I was able to discover why. The HEATH codes for inverse on and inrd method of changing the terminal overlay within a  prog- ram is to use a debug utility such as DDT, ZDDT, or Z8E to change the code. In this case, you would need to do a screen dump of all code  beginning at 0100H to locate the area to be patched.  In my experience,  this method is not as easy as using SuperZAP, but if you know what you are looking for, and approximately where it is, you can find it and change it,  byte by byte. You are looking for strings of code beginning with the hex characters 1B.  Unmally be; a) the file  to be patched,  and b) the appropriate overlay in Intel hex format.  So let's say,  for the sake of arguement, that you had a generic TDOS system file that you want to make compatible with my Cybernex terminal.  Let's further assume that my terminal overlay is called CYBERTRM.HEX,  and that the TDOS system file is  called 80TDOS45.COM. The syntax would be:        MLOAD 80TDOS45.COM=80TDOS45.COM,CYBERTRM.HEXThe  output  file produced would be called 80TDOS45.COM,  but  it would be ly on another         disk.2)      The overlay patch areas for terminal control is most often        located at the beginning of a program, usually within the         first two hundred bytes. It can be recognized as a area         where there are a lot of "1B" sequences, and there may also         be more '0s' than anything else. Patch  areas are seldom         full.  They will probably begin with  0's and end with 0's         and it will usually be quite easy to tell  where the         programmer wheel,  so they use non-standard methods of providing video cont- rol. In this case, you first have to know where the terminal code is.  And secondly, you need a means of changing it, byte by byte. This is where you need the services of a good disk editor such as SuperZAP  (SPZ36.COM).  You can use a program such as SuperZAP to locate  the  area within the target program  where  the  terminal escape  codes are located,  and then simply go in and change them pursuant to your terminal documentation.The thiverse off are:                1B 70 Hex and 1B 71 Hex respectively.whereas...The Cybernex codes for that function are:                1B 68 Hex and 1B 69 HexSo close, but not close enough.There are three ways of patching your TDOS or CP/M program. The first is to use a program by Night Owl Software,  available where good CP/M utilities are sold (or given away as the case may  be), called  MLOAD.COM.  MLOAD  takes  one or more  source  files  and creates an output file. The source files will norless  of course,  you're  a Hazeltine fan...  in which case you're looking for sequences beginning with 7E. Clear as mud, I know.None of this is new of course;  the knowledge has been around for years. What I'd really like to impart however, my experience over the past two or three days,  is that there are some pointers that will make your life easier as you try to do this overly 'thing'.1)      Never work on your original file. You may need to go back        to it. Work on a copy of the file, preferabwith the Cybernex terminal codes.Many  CP/M  programs are written in such a way as to  provide  an area for this overlay code in a standard position such that MLOAD knows  exactly where to put it.  All user needs to do is to  make sure  that  terminal overlay written in a  standard  format,  and assembled into an Intel HEX file is onhand.  In this manner, with MLOAD, the user can use the same terminal overlay for many diffe- rent programs.Unfortunately,  some  authors  think they can  invent  a  rounder's code resumes following a patch area.3)      It's all very well to say that you need your terminal        documentation. If you've picked up some old venerable         cyclops at a garage sale or used junk store, you might         not have the docs to go with it. Frequently, if you go         online and ask the hobbyist community out there (such as        the CP/M FIDO echo or the .alt.comp.os.cpm newsgroup)         somebody will have heard of your terminal and will have         the escape sequenhat I know nothing about. Once duly 'enhanced' the product was passable enough.  I suppose you readers are going to tell me that that there's nothing new in any of this. The concept of downloading personal photos to disk is a bit of a novelty in these parts. We've been able to get slides and prints put on CDROM for some time, and Mom even has a Kodak player. But they're expensive... about $1.99 Canadian per image. Seattle Filmworks has opened a branch plant in Richmond BC, just outside of Vancouver and isÌ1 ×71Ron's Week'n'ADAM September 9, 1997by Ron MitchellNice to see pictures of ADAMCON 09 distributed with the latest 463 ADAM (September '97). Jerry Vrancks (gvrancks@crown.net) is obvi- ously making use of his new technology.Speaking of which.... I have a set of ADAMCON photo's myself to put out for general offer. These photos' are available in digital format for a couple of days from the following Internet address:        http://www.filmworks.comGo to the "Photomail" download area, quote Would you buy a used car from this man?" (Just kidding Zonk.)All of which led to another project.Both Rich Drushel (drushel@apk.net) and Marcel deKogel  (m.dekogel @student.utwente.nl) have produced programs that will convert IBM bitmap files to Powerpaint format. Last week I downloaded Marcel's from his home page (http://www.komkon.org/~dekogel/adam em.html) along with another copy of the ADAM emuulator. It's been a while since my last visit to Marcel's site. He's been hard at work in the interim, havihe pictures and the Photoworks software you need to display them on your IBM. Needless to say, you need at least a 486/33 with 4 meg of RAM to do this. The results, in my humble estimation were just a little under exposed,  but that's not Seattle Filmworks' problem. It's more like my problem. One of these days I'll get the flash settings right on this old camera of mine. However, the Photoworks software allows you to play a little, adjusting the brightness and contrast, along with a range of photo values tces for it.In conclusion, it should be said that this is an area of TDOS and CP/M  knowledge  that  is not difficult to master,  and  where  a little perseverance and curiosity can go a long way.  Your payoff in  getting the terminal codes right for your programs  and  your system  is  that there are indeed hundreds of CP/M  programs  out there which are now pretty much free for the asking. building a rapidly expanding Canadian market.  Their service is reasonably priced - $17.70 Canadian for a roll of 20 and that includes the photos on disk option plus a replacement roll of  film. From here I mail the roll to be processed, and they notify me via  E-mail when it's ready for download from their Internet site. Neat stuff.Now I have my ADAMcon photos on disk, and I can play with them as I want... even to the point of putting nasty captions under Zonker's (lkl4511@mindspring.com) photo... ie, "customer order number 08706686 and roll number 22386053 You'll also need to download Photoworks v2.1 which is available for free. I'm not at all sure how long the file will be available for download from there. The initial notice said they would be retained until September 17, but now that I've downloaded them, the period of retention might be shortened.  Difficult to tell from the instructions on the Seattle Filmworks site.  If you find that you can't get them from there, let me know, and I'll E-mail you tng added a  host of new utilities for the emulator as well as the PowerPaint conversion programs. BMP2PP.EXE is an easy program to use. It will take a bitmap file on your IBM and convert it to PowerPaint format. It's menu driven and uses the Windows 'look and feel'. Unfortunately at this stage, I've not been able to get it to work. Maybe someone can check me up on my procedures which were as follows: 1) Conversion of my ADAMCON 9 photo's.  (or one of them as a test). The CD registered version of Photowork 6)  Your calc program is based on notched sticks.  7)  Your friends are incredulous when you tell them you are      going to a convention.Sb: #50926-Dinosaur Dig Fm: Sysop/*PJ (ADAM) 76537,1271 To: Sysop/Rob F. 'ADAM' 76702,417     OK, so how about this:  *  Your color bleeding problem has attracted the attention of     the local chapter of AMA.  *  You consider "multitasking" to be making coffee and folding     clothes while your tape drive loads. (or WINDOWS3.0, WIN95)  *  Your email addresure 4 times, using both color formats and both black and white formats, all of which showed up and were visible on the screen in Powerpaint format. The black and white versions weren't bad, but the color versions looked a little wierd. No matter - onwafrd 3) Saving to disk in the IBM environment. No problem.... routine stuff. So I now have 4 files which I should be able to transfer to the ADAM environment, right? Each one of these files is reported as being 80k in length. That sounds about right for a complhat I know nothing about. Once duly 'enhanced' the product was passable enough.  I suppose you readers are going to tell me that that there's nothing new in any of this. The concept of downloading personal photos to disk is a bit of a novelty in these parts. We've been able to get slides and prints put on CDROM for some time, and Mom even has a Kodak player. But they're expensive... about $1.99 Canadian per image. Seattle Filmworks has opened a branch plant in Richmond BC, just outside of Vancouver and isÌ1 ×66Fm: Sysop/*PJ (ADAM) 76537,1271 To: ALL  OK, gang, help me out here.  HOW TO KNOW IF YOUR COMPUTER IS A CLASSIC:  1)  Your power source consists of two sticks rubbed together.  2)  Your computer has no bugs, but is occasionally threatened        by low-flying pterodactyls.  3)  Your spell-checker keeps trying to change "YOU" to "Thee"      or "Thou".  4)  Your graphics program does not use a mouse, but a chisel      and mineral dyes.  5)  Your word processor prints out in heiroglyphics. s (available from Seattle Filmworks at a charge of $14.95 US) will save it's output in .BMP format (and just about every other format), so it's a relatively easy matter to save my photos as .BMP. 2) Loading the resulting .BMP file into BMP2PP.EXE. No problem. The picture shows up and looks just like the original. There are a couple of options for conversion to the PowerPaint format, including a couple of black and white options. Just for the heck of it, using the menu instructions, I converted the same picts ends in "ponyXprs.com".Fm: Sysop/*PJ (ADAM) 76537,1271 To: Sysop/Rob F. 'ADAM' 76702,417...and... Your original User Manual is written on papyrus. ...your internal modem delivers messages approximately 2 hours   after Snail Mail. ...The only virus which concerns you is the common cold (thanks to Loran Guyaz for this one)the Photoworks software allows you to play a little, adjusting the brightness and contrast, along with a range of photo values tete work- space in Powerpaint. 4) Converting each of the 4 files to its ADAM equivalent using Chris Braymen's (70057.2035@compuserve.com) ADAMDOS program resulted in 4 ADAM formatted disk Powerpaint files (80k binaries) which I then attempted to load into PowerPaint. It refused to read a single one. I have absolutely no idea what the result would have looked like, maybe good, maybe bad, but I mean to find out.  Stay tuned.-RonÌ1 ×65                   OCTOBER 1997 ADAM NEWS NETWORK****************************************************************DaleZIP       Dale Wick replies to a message to Neil concerning               the possiblity of a zip drive for the ADAM???HarvP         Harv Powis of MTAG comments on the zip drive issueMitch#1       Ron Mitchell's weekly happenings of Sep 2 1997PJ#1          A little humor from PJ and Rob, the CIS sysopsRich 1-4      Rich Drushel's writings published Sep 9 1997             n board, I hadn't done much with it; and various technical glitches have prevented us from getting B.A.S.I.C. members Pat Williams and Jean Davies on-line and participating.  Fortunately, as I am one of the sysops, I was able to intervene and save the Coleco ADAM Forum from destruction.  I updated some of the informational text files, redid the menu structure a little, and have at least planned how I want to revamp the newsgroup and bulletin board areas which we have.  If any of you have accounts on the Cle    trying to provoke some thoughts out there.Mitch#2       Ron's week sent out to the ADAM community Sep 9'97WillNeri      Introducing a new (?) or "renewed" ADAMite, Will              Nerini.......and he has some fresh ideas !ComClasCat    Computer Classics repair catalog with pricing for              all those repairs you need on your ADAM.  A.N.N.              recommended vendor!  Geoff2        Geoff comments on an on-going conversation about              the programming and the docs on it.xit the system Please enter 1, 2 or 3:You can enter "2" again, and you'll be able to look around the system. Once you get to a "Your Choice ==>" prompt, you should type "term" and set your terminal type (probably "vt100" would be best).  Then you can "go adam" and look at the information files and newsgroups.  Unfortunately, you won't be able to post any- thing if you are just a visitor.  You can, however, apply for an account, as indicated on the menu above; accounts on CFN are free.  I welcome any sugÌ1 ×67This Week With My Coleco ADAM by Richard F. Drushel I.  Rescuing the Coleco ADAM Forum on the Cleveland Freenet.     A couple weeks ago, a general notice was posted by the administrators of the Cleveland Freenet, to the effect that they were going to clean up (i.e., remove) any areas and SIGs which they deemed to be dead or abandoned. Unfortunately, the Coleco ADAM Forum was one of the SIGs that was slated for removal.  I must admit, other than reposting my TWWMCA articles to the general bulleti a four part offering to you.Subscrib      How to get your disk in the mail each monthTDOS-EOS      messages fro the Asylum BBS concerning the inner              workings of TDOS ..... AND its oddities...Clees         Message from Rich Clee to a newcomer-Will NeriniClees2        Apology from Rich only IF you called and did not              get that return call from him.DaleComp      Dale Wick on an EOS compiler he proposesGeoff-O       Geoff Oltmans wants to mess with the VDP.......          veland Freenet, all you have to do is type "go adam" at any "Your Choice ==>" prompt.  If you don't have an account on CFN, but have telnet access and want to check us out, then do the following:   telnet://freenet-in-a.cwru.edu You'll get a nice ASCII art picture of the Cleveland skyline, and then the following prompt:  Are you: 1. A registered user 2. A visitor Please enter 1 or 2:You can enter "2".  You will then get another prompt:Would you like to: 1. Apply for an account 2. Explore the system 3. EADAMhous      A message from ADAM'S House regarding the avail-              ability of HD cards, memory cards, etc.Rich#1        Rich Drushel's week with the ADAM Sep 16 1997Ron#1         Ron Mitchell's week of Sep 16, 1997Ron#2         Will Nerini comments on Ron's week of 9/16/97Ron#3         Ron's comments back to Will NeriniRon#4         Will's reply back to Ron againJoeAC09       Joe Alford's views and reviews of ADAMCON 09Readme1       This file         gestions about improving the look of the Coleco ADAM Forum.  Let me know what you think!  You can reach me and the other sysops (Herman Mason and George Koczwara) by sending mail to xx001@po.cwru.edu. II.  Interrupts and Shared System Resources.In last week's TWWMCA (9709.07), I promised to talk about the problem of the non-reentrancy of EOS VRAM routines, and a solution that I implemented as part of the EOS-8 project.     What do I mean by "non-reentrancy"?  Basically it means that VDP (video display on the video screen) when this VDP interrupt occurred, and the VDP ISR also tried to write to the screen?  The result would be garbage on the screen and a confused VDP, because it hadn't finished the first write before starting the second.  The issue is not academic for the VDP, because of a quirk in the way the VDP responds to interrupts.  Any VDP ISR must have, as its last action before returning from the interrupt, a read of VDP register 7 in order to acknowledge the interrupt and enable it for another a time.  The Z80 microprocessor allows external conditions (such as a keyboard or button being pressed, a character arriving at a modem) to generated a signal called an interrupt.  When an interrupt is received, the Z80 finishes the last machine code instruction it was executing, and then jumps to some special locations in memory and starts executing whatever program is there.  (The programmer has to plan for this and provide the appropriate program at the appropriate location.)  This program is called an ifree).  SmartBASIC 1.0 uses both methods in different places.  (1) In TEXT mode, the main program can PRINT to the screen, while the VDP interrupt routine manages blinking on and off if the FLASH command is active.  Blinking can't safely occur, however, if a PRINT is in progress.  SmartBASIC uses a status flag to indicate that PRINT is active, and the FLASH interrupt routine leaves the VDP alone; however, the FLASH interrupt routine also maintains a status flag for PRINT to tell it that an interrupt has occ, which means sitting in a loop asking "Are you ready yet?  Are you ready yet?" over and over until the answer is "Yes".  With interrupts, when it's ready, it will come grab *you*, so you can do other things until you get grabbed.     How might the VDP get interrupted?  It turns out that the VDP itself generates an interrupt 60 times per second (50 for European ADAMs running on 50 Hz line current instead of 60 Hz).  What if the main program was in the middle of a write to the VDP (say to display a character processor) is hardware which can only be acc- essed by one user (or subroutine or process) at a time, and while that user is accessing it, nobody else dare interrupt him, or the VDP will get messed up or confused.  Think how hard it is to concentrate if you're talking to someone on the telephone and then your kids pick up the extension phones and all start talking at once.  Unless you have remarkable powers of concent- ration, the phone is a non-reentrant resource--only one person can talk intelligibly at cycle 1/60th (1/50th) of a second later.  If *any* VDP read or write is already in progress, this acknowledgment read will disrupt it and leave the VDP in an unstable state.  There are two possible solutions to the problem:  (1) keep the VDP interrupt disabled, so the main program can never get interrupted; or (2) somehow keep track of when the VDP is being used by a user program, so that an interrupt routine won't try to access the VDP if it's busy, but will instead wait until another time when the VDP is nterrupt service routine (ISR), because it is supposed to deal in some special way with whatever condition caused the interrupt.  For example, in the case of a keyboard interrupt, the ISR might read the key that was pressed and save an ASCII code for it in a buffer somewhere.  The ISR ends with a special form of the RET (return) instruction, which tells the Z80 to go back to the program that it had been working with and keep going, right where it left off.  Interrupts are an efficient alternative to pollingurred and that PRINT needs to do the acknowledgment read of VDP regist- er 8, to restart the VDP interrupt for the next cycle.  The result of this handshaking is that access to the VDP is regulated to one routine at a time.  The FLASH rate during a PRINT is visibly slower, however, than if you are just sitting at the ] prompt.  (Try this:  TEXT, FLASH, then CATALOG some disk/tape that will cause the directory listing to scroll off the screen.  Observe the difference in blinking rate.)  (2) In the graphics mn a previous article, Chris Braymen (6) says: >Hi Folks:  A discussion took place at ACIV that I want to make sure I understand..  The PROBLEM: You will end up with scramb- led graphics if you  read VDP register 8 (to restart the video interrupt) while you are in the process of accessing the VDP. According to "The TMS 9118/28/29 Data Manual" (Texas Instruments, 1984),  "In an interrupt-driven environment (CPUs accepting interrupts), it is possible for an interrupt to occur before any one of the [multi-byte  hatched, one of the topics of discussion was this very problem of non-re- entrancy of the EOS VDP I/O routines.  Based upon study of disassembled EOS code, Bruce Walters had suggested a particular code fix which he thought might solve the problem. In brief, the current EOS-5 code reads/writes the VDP one byte at a time, using IN/OUT instructions in a software loop.  The Z80 also provides instructions which can read/write multiple bytes to/ from a memory buffer without a software loop, namely  INIR/OUTIR (irite register, read register 8) will be corrupted if an interrupting routine also tries to access VRAM.>Most Coleco software solves this problem by maintaining a couple of flags that effectively delay the video interrupt restart until after the application is done using the VDP.  ColecoVision games employ an OS-7 routine which defers the writing of graphical ob- jects (as defined with certain data structures) until desired by the programmer.  Usually, VDP writes are deferred *until* an NMI occurs. At thatMark Gordon's Micro Innovations BBS, dated 31 July 1992 (about 2 weeks after ADAMcon IV), in which Chris Braymen and I discuss the issue. It was in writing this post that I thought of a mechanism for VDP interrupt deferral for the EOS VRAM routines.** VDP INTERRUPT HANDLING DISCUSSION**[Note:  I am using Internet E-mail format to respond to the tech- nical discussion, so I can quote relevant parts of previous posts in my response.  The T-BBS message editor does not allow this. -- Rich Drushel (75) ]Iodes (GR, HGR, and HGR2), the VDP interrupt is turned off com- pletely.  Thus, the main program can read/write the VDP with impunity.  Returning to TEXT mode restarts the VDP interrupt. (In SmartBASIC 1.x, a software clock is installed as part of the VDP interrupt routine, ticking at 60 (50) times per second; the clock stops whenever you are in a graphics mode, because the VDP interrupt is disabled.) III.  Interrupt Deferral in EOS-8 VRAM Routines:  Genesis.     At ADAMcon IV, whence the EOS-8 project wasVDP access] sequences is finished.  For example, an interrupt may occur immediately after loading address byte 1 or 2 during a write to VRAM operation.  In this case, the interrupt service routine does not know where the interrupt occ- urred within the sequence.  Therefore, it is necessary to disable and enable interrupts before and after every setup sequence.  This action sequence prevents loss of continuity between the CPU and the VDP" (p. 2-9).  This means that *ANY* VRAM access (read data, write data, wn/out-increment-repeat).  These commands use the HL register as a pointer to the buffer, the C register as the port to read/ write, and the B register as a counter.  Data is transferred via port C; HL is incremented and B is decremented; transfer stops when B is zero.  Bruce had hoped that INIR/OUTIR, being single commands, were not interruptable (i.e., they would not respond to an interrupt until B=0); but unfortunately, they *are* interruptable.      I reproduce below a post to the Programmer's Forum on  point, the VDP is uninterruptable, so all the deferred writes are done until the deferral queue (or stack) is empty.  This routine works only with the special graphical ob- jects, not low-level VDP reads/writes or register access.  In SmartBASIC, NMIs are simply disabled in GR, HGR and HGR2, ducking the problem.  In TEXT mode, NMIs are enabled, and the NMI routine changes the pointer between normal and inverse pattern name tables (if FLASH is enabled) after a defined number of cycles.  This is fine except space between which is vulnerable to interrupts.  [note added 9709.14:  OTIR and INIR *are* interrupt- able, so the point is moot]>So my questions are: >     1)  Am I correct in assuming the VDP hardware will get messed up if >register 8 is read during Command sending OR during data read and write?  You are correct. >     2) If so, will the EOS rewrite use OTIR and INIR in place of OUTI and INI in the Read_VRAM and write_VRAM routines? It can't, because of 3) below. >     3) If so, how will you incorprograms leave the NMI disabled throughout. >A proposal was made that this problem could be solved in the EOS system software by using OTIR instructions in place of the cur- rent OUT and OUTI instructions.  Having reexamined my disassembly of EOS-5, I believe that this is no longer a viable solution.  See below.  >QUESTIONS:  My understanding of this problem holds that: > >      A) The problem occurs as a direct result of reading VDP register 8 and has absolutely nothing to do with the amount of time spent aNIR :)  >RECOMMENDATIONS:  I recommend leaving the system VDP access completely interruptable and making it the application program- mers responsibility to handle the Video interrupt restart at a time when he/she is not doing anything else with the VDP. I agree 100% here.  However, I would like to propose a mechanism whereby interrupt routines *WHICH ACCESS VRAM* could do so with- out fear of corrupting a main program VRAM access in progress. [description omitted; see IV below]>I can live with 2 byte intead between reading or writing consecutive data using the auto incrementing VRAM address.   This is correct.>Some people at the table indicated the problem only exists dur- ing VDP command access because the EOS already uses OTIR and INIR for data reads and writes.  This is not true!  The EOS functions Read_VRAM and  Write_VRAM use OUTI and INI enclosed in loops, they do NOT use the non-interruptable commands OTIR and INIR.  You are correct.  What's more, the register writes use separate OUT commands, the that PRINT accesses the VRAM, as well as the actual TEXT command. The solutions are:  The NMI routine checks to see if PRINT is executing, and if so, just does RETN (with no register 8 read to  restart the NMI).  The PRINT routine itself maintains the FLASH counter and will switch the name table pointers, and then issue a register 8 read.  (Check the FLASH frequency when sitting waiting at the prompt versus when text is PRINTing and scrolling on the screen; it is noticeably slower while PRINTing.)  Other porate the 2 NOP delay for the "Slow" >VDP between each read/write?  You can't.  So unless Bruce's code with OTIR and INIR actually does work, meaning the "slow" VDP on the design board wasn't really so "slow" in pract- ice, I don't think you can use OTIR and INIR to make the write/ read uninterruptable. >And most importantly <grin>, if the OTIR and INIR opcodes are un-interruptable (except by DMA), how can I make sure I'm not losing MIDI bytes during large transfers to the VDP?  Only by not using OTIR and Iway from the VDP operation at hand during interrupt processing. *Any* VRAM register read/write, or VDP data read/write, is vul- nerable if interrupted by a routine which also attempts to access VRAM.  It is not restricted to the register 8 read to restart the NMI for another cycle. Remember that the register 8 read is *OBLIGATORY* to restart the NMI; RETN is not sufficient.>      B)  The problem will occur if register 8 is read between sending the 2 bytes that make up a VDP command, OR if register 8 is rerrupt disabling transfers, but I'll have trouble >with any interrupt disabling transfer that's bigger than about 80 bytes.  If there isn't a bug in what I just proposed, you should be safe.  INTs are enabled throughout all EOS VRAM function calls, and as long as your INT routine does not access VRAM, you could ignore the above. >CLOSING: Please take this into consideration when designing the new EOS.   I am trying :)>Spinner applications may also be adversely affected by an OTIR in write_VDP.  Absolutely.ich access VRAM *cannot* be deferred if the NMI is active.  The logic of the implement- ation follows: INT:      DI                           ;disable further INTs          IF vram_access=1             ;if VRAM I/O is in progress...             THEN int_request=1        ;...then request a deferred INT                  RET                  ;and return to VRAM I/O                                       ;*NOTE* INTs *DISABLED*             ELSE int_request=0        ;else wipe the INT request flag    x) can be found via anonymous ftp at:  ftp://junior.apk.net/pub/users/drushel/vram_def.asm    **************************************************************** EOS-8 VRAM INTERRUPT DEFERRAL ROUTINES. designed by Richard F. Drushel  6 October 1992Here is a mechanism whereby interrupt routines *WHICH ACCESS VRAM* could do so without fear of corrupting a main program VRAM access in progress.  (If your interrupt routine does not access VRAM, there is no problem).  It would work best with the NMI (because of it* NMIs *DISABLED*             ELSE nmi_request=0        ;else wipe the NMI request flag                  CALL do_nmi          ;do the user NMI routine                  read VDP register 8    ;restart the NMIs                  RETN                 ;return from non-maskable interrupt          ENDIF do_nmi:   {user NMI routine goes here}          RETEOSVRAM:  IF vram_access=1             ;if VRAM I/O is already in progress...                                       ;i.e. this is a VRAM call made f not.         bit 1  ==>  nmi_request         1 if an NMI routine needs                                         to be executed, 0 if not.        bit 2  ==>  int_request               1 if an INT routine needs        to be executed, 0 if not.The handshaking of interrupt deferral is such that it is impossible to defer *BOTH* NMIs and INTs simultaneously.  Indeed, since a READ_REGISTER (read VDP register 8) is required to restart NMIs after each NMI cycle, this effective- ly means that INT routines wh   >Thanks, Chris Braymen (6)Regards, Rich Drushel (75)******************************IV.  Interrupt Deferral in EOS-8 VRAM Routines:  Algorithms.      I reproduce here the design summary of the VRAM interrupt deferral routines for EOS-8, as posted to the Programmer's Forum on Mark Gordon's Micro innovations BBS on 6 October 1992.  The algorithms are presented as pseudocode and as skeleton assembler. The complete assembler version as used in EOS-8 (and in a proof- of-concept version of SmartBASIC 1.              CALL do_int          ;do the user INT routine                  EI                   ;reenable INTs                  RETI                 ;return from maskable interrupt          ENDIF do_int:   {user INT routine goes here}          RETNMI:      IF vram_access=1             ;if VRAM I/O is in progress...             THEN nmi_request=1        ;...then request a deferred NMI                  RET                  ;and return to VRAM I/O                                       ;*NOTEs relatively low frequency; an INT can occur at any frequency) but might be useful for INTs as well.  It would not improve existing interrupt routines, but could be used as a paradigm for future ones or rewrites.  Anyway, code would be required both in the interrupt routine and in each EOS routine which accesses VRAM.  EOS would define an interrupt status byte with 3 flag bits: bit 0  ==>  vram_access         1 if an EOS function call accessing                                    VRAM is in progress, 0 ifrom                                        ;inside another VRAM call, already                                       ;flagged             THEN JR do_vram_routine   ;...then just do it                                       ;this allows the interrupt routine to   ;use EOS VRAM functions, where it is                                       ;safe from interruption             ELSE vram_access=1        ;else mark that we're doing VRAM I/O                                       ;*NOTE* now we can't b               ;return with INTs *DISABLED*A71:      RES 2,A                 ;clear request flag for safety      LD (INTERRUPT_FLAGS),A   ;save it      CALL A83                 ;do the user INT routine (doesn't need                               ;to PUSH AF)      POP AF                  ;restore AF      EI                      ;reenable INTs      RETI                    ;return from maskable interrupt A83:      JP user_int_routine      ;jump to the actual user code                               ;                       EI           ;*FINALLY* reenable INTs                          RETI         ;and return from the interrupt                                       ;We have done our main VRAM I/O *and*                                      ;our INT VRAM I/O.                     ELSE                  ENDIF                  IF nmi_request=1     ;now if a deferred NMI occurred                                       ;while we were doing the VRAM I/O...                     THEN nmi_request=0 ;... with NMIs *DISABLED* A117:      RES 1,A                 ;clear request flag for safety      LD (INTERRUPT_FLAGS),A   ;and save it back      CALL A133                ;do the user NMI routine (doesn't need                               ;to PUSH AF)      IN A,(191)              ;restart the NMI by reading VDP register 8      LD (VDP_STATUS_BYTE),A   ;save it for EOS usage      POP AF                  ;restore AF      RETN                    ;return from non-maskable interrupt A133:      JP user_nmi_r       ;all done using VRAM                   RET                 ;we're done!The actual implementations are:INT: A56:      PUSH AF                  ;save register      LD A,(INTERRUPT_FLAGS)  ;point to interrupt flags      BIT 0,A                  ;is a VRAM I/O in progress?      JR Z,A71                 ;NO, so just do the routine      SET 2,A                  ;YES, so request a deferred INT      LD (INTERRUPT_FLAGS),A   ;save it back      POP AF                  ;restore AF      RET      e interrupted;                                       ;INTs and NMIs will be deferred                  CALL do_vram_routine      ;do the VRAM routine without fear                  IF int_request=1     ;now if a deferred INT occurred                                   ;while we were doing the VRAM I/O...                     THEN int_request=0 ;...then clear the request                          CALL do_int   ;do the user INT routine                         vram_access=0 ;clear the VRAM usage flag   it must save AF, HL and any other used                              ;registers, and end in RETNMI: A102:      PUSH AF                  ;save register      LD A,(INTERRUPT_FLAGS)   ;get interrupt flags      BIT 0,A                  ;is a VRAM I/O in progress?      JR Z,A117                ;NO, so just do the routine      SET 1,A                  ;YES, so request a deferred NMI      LD (INTERRUPT_FLAGS),A   ;saveit back      POP AF                  ;restore AF      RET                     ;returnthen clear the request                          CALL do_nmi   ;do the user NMI routine                         vram_access=0 ;clear the VRAM usage flag                          read VDPreg8 ;*FINALLY* reenable NMIs                          RETN         ;and return from the interrupt                                       ;We have done our main VRAM I/O *and*                                       ;our NMI VRAM I/O.                      ELSE                   ENDIF                   vram_access=0outine      ;jump to the actual user code                               ;it must save AF, HL and any other used                              ;registers, and end in RET;end code which must be installed by the user application;begin code which is in EOS RAMVRAM:      PUSH HL                  ;save register      LD HL,INTERRUPT_FLAGS   ;point to interrupt flags      BIT 0,(HL)               ;is a VRAM I/O in progress?      JR NZ,DO_VRAM2           ;YES, so just do it                              ;tion of ADAMserve (which I have been meaning to do for quite some time).      See you next week!     *Rich*.  The PROBLEM: You will end up with scramb- led graphics if you  read VDP register 8 (to restart the video interrupt) while you are in the process of accessing the VDP. According to "The TMS 9118/28/29 Data Manual" (Texas Instruments, 1984),  "In an interrupt-driven environment (CPUs accepting interrupts), it is possible for an interrupt to occur before any one of the [multi-byte       RES 0,(HL)               ;NO, so no deferred interrupts; all done      POP HL                  ;restore HL      RET                      ;bye! DO_DEF_INT:      RES 2,(HL)              ;clear request flag      CALL A83                 ;do user INT routine      RES 0,(HL)               ;all done with VRAM routine      POP HL                  ;restore HL      EI                      ;finally reenable INTs      RETI                    ;return from maskable interrupt DO_DEF_NMI:      RES 1,(HL)  ive use in ADAMserve (and also SmartBASIC 1.x, whence they were derived). This makes a rather easy TWWMCA article for me,  since I did  the actual writing in 1992 :-) But *you've* never seen it before,  so I'm not blushing too badly about dredging it up.II. A Detailed Description of EOS-8.Here  is a helpfile I wrote for the benefit of the other program- mers  who  were nominally helping with the  EOS-8  project.  This accompanied a complete source listing and bootable SmartBASIC 2.0 binary  which had beVRAM2:     POP HL DO_VRAM:     {routine here}      RET*********************************************************V.  For Next Time.     If I get any questions or other expressions of interest from the readers, I can talk about a few more details of the interrupt deferral code, which have been omitted above.  For instance, there are some EOS VRAM routines which *cannot* be deferred; the technical reasons for this are perhaps of some interest.      Otherwise, I will start to write a technical descrip(interrupts are already deferred)      SET 0,(HL)               ;NO, so mark it now in progress      POP HL                  ;restore HL      CALL DO_VRAM             ;do the VRAM routine VRAM_COMMON_EXIT:      PUSH HL                  ;save HL      LD HL,INTERRUPT_FLAGS   ;point to interrupt flags      BIT 2,(HL)               ;is there a deferred INT?      JR NZ,DO_DEF_INT         ;YES, so do it      BIT 1,(HL)               ;is there a deferred NMI?      JR NZ,DO_DEF_NMI         ;YES, so do itÌ1 ×70This Week With My Coleco ADAM  9709.07by Richard F. Drushel  (drushel@apk.net)I.  More About the EOS-8 Project.I've  had  a few inquiries about the internals of EOS-8,  my  in- progress/abandoned  upgrade to the EOS operating  system.  I  was digging  through some old correspondence and found some  informa- tional  descriptions which might be of interest.  I also  decided that  I  would post some commented code for the universal  serial and parallel drivers that I wrote,  since these are in act            ;clear request flag      CALL A133                ;do user NMI routine      RES 0,(HL)              ;clear VRAM flag      POP HL                  ;restore HL      PUSH AF                  ;save AF      IN A,(191)              ;restart NMIs by reading VDP register 8      LD (VDP_STATUS_BYTE),A   ;save it for EOS                              ;VDP_STATUS_BYTE is in EOS global RAM      POP AF                  ;restore AF      RETN                    ;return from non-maskable interrupt DO_en uploaded to Mark Gordon's BBS.  I  haven't found my disk with this binary yet,  but when I do, I will put an .IMG of the disk up for anonymous ftp.Two errors of faulty recollection I made in TWWMCA  9708.31:  the prototype  ADAMnet  parallel  device is accessed as  PR  #2  from SmartBASIC 2.0,  and the serial device as PR #4 and IN #4. I will correct the archived version of this article;  newsletter editors and other archivers, please make this fix or grab my fixed vers- ion from the ftp site (see end cular EOS partition.  This overlay is positioned so that the  current  HD volume remains at absolute  address  58343,  for compatibility  with existing programs.  The overlay must be  less than 400 bytes long.  The overlay interface accommodates up to 16 EOS  volumes,  and has provisions for 2 hard drives per  physical interface:        HD_MW1_CODE    EQU   1        HD_MW2_CODE    EQU   2        HD_SASI1_CODE  EQU   3        HD_SASI2_CODE  EQU   4        HD_IDE1_CODE   EQU   5        HD_IDE2_CODE   Evice numbers can be reassigned to non-ADAMnet physical devices, to allow existing programs to function with non-ADAMnet hardware (i.e. use a parallel printer 2-63        are reserved for up to 32 non-ADAMnet devices; the following         are defined:        32   USERPAR_ID       parallel port (64)        33   USERSER_ID       serial port (any Eve/Orphanware/MIB2)        34   USERAMDISK_ID    RAMdisk using standard XRAM        35   USERHD_ID        Hard disk (any Mini Wini/SASI/IDE)This  includes                           wrapping back to 0 when MAX_VOLUMES                              is exceeded  o     User-defined hotkey.  This was implemented as part of EOS7. The user specifies a key to trap, and a vector to a handler routine. When this key is pressed, the handler routine is called; control returns to the main program.  o     User-defined number of FCBs and DTAs.  Instead of being hard-coded at 3,  the user can change the contents of NUM_FCBS to have  as  many  files open at once  as  desid with a _START_...  call is performed to completion before exiting the  call,  including  updating the dummy DCB.  This  means  that _END_...  calls  for  non-ADAMnet I/O don't  do  anything  except return the status from the dummy DCB.  o     Defined overlay area for hard drives.  The overlay has a defined  code  and data interface so that any type of hard  drive (or  other block device) can be used.  The overlay  includes  the volume  offset table which is used to specify the volume sizes of the partiof article).******************************************************************** EOS87.HLP *** help file for EOS8 rev.7 (9209.20) by Richard F. DrushelThis  file provides a brief overview of the design philosophy and implementation of EOS8,  specifically rev.7. This should serve as a  guide for outside reviewers and programmers as EOS8 is  final- ized. *****************************************************************WHAT'S NEW IN EOS8 rev.7.  o     Logical-to-physical device mapping.  ADAMnet deQU   6        Note:  the current version was assembled with Mini Wini HD drivers in place,  assuming 10 EOS volumes 1024 blocks each.  You will  have  to reassemble it for your own HD  characteristics  to access any volume other than 0; 0 will always work :)  o     Hotkey functions for hard drives.  The following keys are trapped:        Shift-Undo           reboots HD from volume 0/block 0        Shift-WildCard       parks HD heads        Shift-Tab            toggles ahead the current HD volume,    complete  emulation of ADAMnet  devices  by  non- ADAMnet  equivalents.  Physical devices use dummy DCBs which  are set up as if they were controlling an actual ADAMnet device. This includes  the  status byte at (DCB+0)  and  the  device-dependent status at (DCB+20).  For serial devices, the (DCB+20) status bits for  #  characters pending and ok to send are maintained  exactly like  the  prototype ADAMnet serial board.  I/O  for  non-ADAMnet devices is *NOT* concurrent/background.  Thus,  all I/O initiatered.  Make  sure  you _FMGR_INIT after changing NUM_FCBS :) This was also part of EOS7.  o     NMI clock driver routine.  Each CALL to this routine updates the clock by one tick,  complete with weekday,  day,  month,  and year rollover. Additional locations in EOS_GLOBAL_RAM are defined to hold 60th of second, second, minute, hour, and weekday.  o     Auxiliary jump table for direct access to non-ADAMnet devices and extra EOS functions.*****************************************************************nowledge, only SmartBASIC act-        ually allows  the user to open 2 files at once.  Moreover, because the  file I/O routines in SmartBASIC are defective, there is no practical use for 2 open files.  EOS8 allows the applica- tion programmer to both set the number of DTAs and to relocate the DTAs/FCBs, so future programs can have more than 1 user file open at once if proper  setup is done.  At least one  existing  program,  however (ADAMlink  V) uses the 2nd DTA at its absolute address under EOS5 (not  ren, for the non-ADAMnet serial boards. If initializa- tion  compatibility is not maintained,  then (1)  dedicated  init routines will be required for non-ADAMnet serial boards,  and (2) it  will not be possible for non-ADAMnet serial boards to emulate the  initialization code for device 14.  SmartBASIC 2.0 does  not attempt to initialize device 14,  but it is unknown if any  other Coleco EOS software attempts to do so.  o     Trapping of serial port overrun, parity, and framing errors.  The  source  code htunately does *NOT* write BLOCKS LEFT as the name of the "not a file" directory entry.  Many exis- ting programs look specifically for BLOCKS LEFT,  and hence  will crash under EOS7-8. I have not yet looked into fixing this.  o     Bidirectional parallel printer emulation for SmartWriter. I have not included  the routine which intercepts  the  printhead direction changes sent by SmartWriter to the ADAM  printer.  This means  that  text printed from SmartWriter will have every  other line spelled backwardsto what under EOS5 is the 2nd  user  DTA.  The existing prototype RAMdisk  routine  (demon- strated at ADAMcon IV) appropriates this area for its own  inter- bank  transfers.  While it is possible to rewrite the RAMdisk I/O to  page through a smaller buffer,  I have decided to wait  until both  the  hardware  clock I/O routines and  the  VRAM  interrupt deferral routines are implemented,  so I know how large a RAMdisk buffer I will have available (either 256 or 512 byte).  o     The 2nd user DTA.  To my kWHAT'S MISSING FROM EOS8 rev.7.  o     Hardware initialization routines for both Eve/Orphanware and MIB2 serial ports.  A management decision is needed regarding the parameter  passing mechanism--namely,  will we remain  compatible with the prototype ADAMnet serial board (device 14)? The difficu- lty with this approach is that the values 0-5 will have to become reserved  data  values which flag initialization  parameters--you would lose the ability to send them as serial data independent of initializatiolative  to the pointer to start of DTAs)  as  a  transfer buffer;  these  unfortunate  programs overwrite the larger  EOS8.  SmartBASIC  hackers  also have been known to store  machine  code routines here.  o     Hardware clock I/O routines.  I can extract them from SmartBASIC 1.x,  but have decided to wait for comments about what I have done already.  o     VRAM I/O deferral during interrupts.  The logic of this deferral has been described previously (in VRAMDISC.TXT).  o     BLOCKS LEFT.  EOS7 unforas conditional assembly of traps  for these errors.  The enclosed binary has these left out,  to  avoid problems with SmartBASIC 2.0.  (The way the code is in SmartBASIC 2.0,  if you type too fast and overrun the port, the routine will loop  forever;  unlike  SmartBASIC  1.x,  it  will  not  force  a PR#0/IN#0 if an error occurs.) You can reassemble the source with the traps put back in if you like :)  o     Software RAMdisk routines.  Since EOS8 ver.7 is currently larger than 8K,  EOS code has spilled in. (This does not happen from the Electronic Typewriter  mode.)  An  80-byte line buffer  and  line  inversion software must be added to __PR_CH and __PR_BUFF.*****************************************************************-Richuence.  Therefore, it is necessary to disable and enable interrupts before and after every setup sequence.  This action sequence prevents loss of continuity between the CPU and the VDP" (p. 2-9).  This means that *ANY* VRAM access (read data, write data, w***************NEW GLOBAL ENTRY POINTS IN EOS8 rev.758343   HD_OVERLAY:             HD_CURRENT_VOLUME:                DS 1 58344   HD_VOL_OFFSET_TABLE:                DS 16;note:  the following 4 JPs are for *INTERNAL EOS USE ONLY*, but are; fixed entry points which the overlay programmer must provide.58360   HD_STATUS:                       ;get dummy DCB status                JP __HD_STATUS 58363   HD_RESET:                        ;park heads                JP __HD_RESET 58366   HD_WRITE:    Ì1 ×67(part 2 of 4)HOW TO LOAD EOS8 rev.7.EOS8  rev.7 is currently part of a modified SmartBASIC 2.0  which lacks all the EXTMEM features. (I did it this way as a quick-and- dirty loader,  also to test the logical-to-physical remapping  of PR#2/PR#4/IN#4.)  Put  the disk in any drive and pull the  reset. Once SmartBASIC 2.0 comes up, you can put any other bootable disk in  the  drive  and CALL 64560 (_EOS_START).  The  disk  will  be booted, but the EOS8 will still be in effect.Since  there aren't ble entries!JUMP2_COUNT     EQU     964484   _GET_HW_CLOCK      EQU  $    ;read hardware clock time to system clock        JP     __GET_HW_CLOCK64487   _SET_HW_CLOCK      EQU  $    ;write system clock time to hardware clock        JP     __SET_HW_CLOCK 64490   _UPDATE_NMI_CLOCK  EQU  $    ;system clock tick (every NMI)        JP     __UPDATE_NMI_CLOCK 64493   _WRITE_PAR         EQU  $    ;write character to parallel port        JP     __WRITE_PAR 64496   _READ_SER          EQU  $    ;read characte       EQU    68        SER76_PORT       EQU    76        SER84_PORT       EQU    84        SER92_PORT       EQU    92        SER_MIB21_PORT   EQU    24        SER_MIB22_PORT   EQU    16The current logical-to-physical mapping is:        device 2 (ADAM printer)        --->  USERPAR_ID        device 13 (Coleco Centronics)  --->  USERPAR_ID        device 14 (Coleco RS-232)      --->  USERSER_ID        device 24 (tape 2)             --->  USERHD_ID**************************************************rite register, read register 8) will be corrupted if an interrupting routine also tries to access VRAM.>Most Coleco software solves this problem by maintaining a couple of flags that effectively delay the video interrupt restart until after the application is done using the VDP.  ColecoVision games employ an OS-7 routine which defers the writing of graphical ob- jects (as defined with certain data structures) until desired by the programmer.  Usually, VDP writes are deferred *until* an NMI occurs. At that                    ;write 1 block                JP __HD_WRITE 58369   HD_READ:                         ;read 1 block                JP __HD_READ58372   USER_HD:                         ;code for HD type                DS 1 [...];SECONDARY EOS JUMP TABLE.;  This is for the additional EOS function calls.  The bottom of the; table is fixed, so new entries must be added to the *BEGINNING*.  Do *NOT*; delete any entries!  Also, make sure that the JUMP2_COUNT variable is ;updated whenever you add jump tayet any serial port init routines,  you  must use  some other program to init them *BEFORE* you load  EOS8,  or else boot SB1.x under EOS8 and use the SERIAL command. My primary testing tool has been SB1.x,  because it lets me do EOS  function calls  directly  via register variable setups and  CALL  EOS(nn). Also,  the  default value at USER_BASEPORT is 0 (no serial port). You will have to POKE 65206,baseport in order to use device 14 as a non_ADAMnet serial port, where baseport maps as:        SER68_PORTr from serial port        JP     __READ_SER 64499   _WRITE_SER         EQU  $    ;write character to serial port        JP     __WRITE_SER 64502   _INIT_SER          EQU  $    ;initialize serial port        JP     __INIT_SER using a                                     ;logical devic        JP     __GET_PHYS 4508   _SET_PHYS          EQU  $    ;specify the physical device to be used                                     ;by a logical device        JP     __SET_PHYS; *** _SET_PHYS IS THE LAST ENTRY!! *e A regis- ter;  the Z flag reflects the status; if an error occurred, A has the error code.The  other great advantage of this code is that it  implements  a 10-second  timeout.  If  the  I/O is not  successfully  completed within 10 seconds (software loop timing assuming 4 mHz  Z80),  it times  out  and  returns an error code.  This  prevents  infinite polling  loops which require a hard reboot to get out of  if  you specify  the wrong port,  or if a printer or modem isn't on-line. Feel  free  to use thi   DS 1            ;RFD65206   USER_BASEPORT:ns 65207   USER_SER_STATS:               ;in case we emulate ADAMnet serial board        DS 6            ;RFD          ;initializations (hold                                       parameters)        DS 3            ;added by RFD to reserve space65216   PCB:        DS P_SIZE 65220   DCBS:            ;only 12 real ADAMnet devices permitted        DS 12*D_SIZE;****************************************************************DUMMY_DCBS:; Note:  these willand the other  serial port parameters (bitrate,  parity,  number of  stop bits) passed in other registers.  I can post this code at a later time.;****************************************************************-Richke  SmartBASIC  1.x,  it  will  not  force  a PR#0/IN#0 if an error occurs.) You can reassemble the source with the traps put back in if you like :)  o     Software RAMdisk routines.  Since EOS8 ver.7 is currently larger than 8K,  EOS code has spilled in*****************************************************************III.  Universal Non-ADAMnet Serial and Parallel Drivers.Here is commented source code for drivers for the Orphanware  and MIB2 serial ports and the Orphanware parallel printer port. These were  written to be a "universal" module--just include it in your program,  and  it can support all 6 serial ports as well  as  the printer port. For the serial ports, the serial baseport to use is passed  in the C register;  characters are passed in th** ; *** DO NOT ADD TO THE END OF THIS TABLE!! ***[...]65196   TRIGGER_CHAR:        DS 65197   USR_DFND_RTN:        DS 2 65199   NUM_FCBS:        DS ;begin EOS8 global RAM65200   EOS_60TH:        DS 1            ;RFD 65201   EOS_SECOND:        DS 1            ;RFD 65202   EOS_MINUTE:        DS 1            ;RFD 65203   EOS_HOUR:        DS 1            ;RFD 65204   EOS_WEEKDAY:        DS 1            ;RFD65205   INTERRUPT_FLAGS:              ;store INT/NMI flags for VRAM routines     s code.  Note the conditional  assembly  of tests  for  overrun,  framing,  or parity errors for  the  serial drivers.  I left them conditional in EOS-8 to save some space  in EOS  RAM;  they are active in the SmartBASIC 1.x code.  If  these errors  occur,  the only way to clear them is to reinitialize the serial port.I  haven't  included universal serial  port  initialization  code here. It's present in the boot for the ADAMserve boot disk, again requiring  the serial baseport passed in the C register,   *NOT* be relocated if the PCB is ;relocated!  So if you application is switching to XRAM or ;ROM up here, you will *LOSE* these devices!!!;     Note 2:  these are *NOT* user entry points!  This is for reference  ;*ONLY*!!  Always  access  the  DCBs  indirectly,  via _FIND_DCB.  The  parallel ;DCB is currently stored at  DCB_IMAGE, but this is subject to change.65472   SERIAL_DCB:        DS 21 65493   RAMDISK_DCB:        DS 21 65514   HARDDISK12_DCB:        DS 21 65535   RESERVED_BYTE:        DS 1Ì1 ×73(part 3 of 4);Non-ADAMnet Serial Read Character With Timeout Check. ;     On entry, C=base port.  On exit, if the read was ok, ZF=1and ;A=character, else ZF=0 and A=error code.  Routine retries approximately 10 ;seconds before timing out.  C is preserved.;errors;CHAR_DEV_TIMEOUT_ERR   EQU  25       ;parallel or serial timed out ;CHAR_DEV_NO_PORT_ERR   EQU  26       ;no port found for parallel or serial ;CHAR_DEV_OR_F_P_ERR    EQU  27       ;serial had overrun/framing/parity error ;PRINTER_OFF,(C)                ;get character RDY2:        DEC C        DEC C        DEC C                   ;restore C to entry state (baseport)        JR SET_ZF2              ;ZF=1 for ok exit, leaving A=character ;******** EVE_OWARE_READ: OUTR_LP_EO_RD:        LD HL,65535            ;inner loop counter INNR_LP_EO_RD:        IN A,(C)               ;read status port        LD E,A                 ;save it in E        CP 255                 ;does the port exist?        JR Z,NO_PORT           ;NOIF OFP_CHK  ot needed per se, but makes exits compatible                                ;with SER_SEND_TCHK        INC C                   ;point to status port        LD D,8                  ;outer loop counter        LD A,C                  ;get baseport        CP SER68_PORT           ;is it Eve-Orphanware?        JR NC,EVE_OWARE_READ    ;YESMIB2_READ: OUTR_LP_MI_RD:        LD HL,65535             ;inner loop counter INNR_LP_MI_RD:        IN A,(C)                ;check the status port        LD E,A        C D                  ;YES, so one less outer loop        JR NZ,OUTR_LP_EO_RD    ;not done yet, so reset inner loop and try again        JR TIME_OUT            ;we have timed out! ;******** READ_RDY_EO:        POP AF                 ;restore character        POP DE                 ;all done with big loop counter        DEC C                  ;back up to data port        IN A,(C)               ;read the character        INC C                  ;restore C=status port        JR SET_ZF2             ;ZF=1 L                    ;down to zero yet?        JR NZ,INNR_LP_MI_RD     ;NO, so keep going on inner loop        DEC D                   ;YES, so one less outer loop        JR NZ,OUTR_LP_MI_RD     ;reset the inner loop and keep trying        JR TIME_OUT             ;sorry, we've timed out! ;******** READ_RDY_MI:        POP AF                  ;restore character        POP DE                  ;all done with outer loop counter        INC C        INC C                   ;point to data port        IN ALINE_ERR    EQU  28       ;parallel printer is off-line;serial baseports;       SER68_PORT        EQU     68 ;       SER76_PORT        EQU     76 ;       SER84_PORT        EQU     84 ;       SER92_PORT        EQU     92 ;       SER_MIB21_PORT    EQU     24 ;       SER_MIB22_PORT    EQU     16;********__READ_SER:        PUSH HL                 ;save so we can use it for inner loop counter        PUSH DE                 ;save so we can use it for outer loop counter        PUSH AF                 ;n      AND 56                 ;YES, 00111000 any framing/parity/overrun errors?        JR NZ,OR_FR_P_ERR      ;YES, so exit        LD A,E                 ;NO, so check status again ELSE ENDIF        AND 2                  ;is there a character ready?        JR NZ,READ_RDY_EO      ;YES, so get it        DEC HL                 ;NO, not yet, so one less inner loop        LD A,H        OR L                   ;are we down to zero?        JR NZ,INNR_LP_EO_RD    ;NO, so keep trying on inner loop        DE          ;save it in E        CP 255                  ;does this port even exist?       JR Z,NO_PORT            ;NOIF OFP_CHK        AND 240                 ;YES, so 11110000 check upper 4 bits        JR NZ,OR_FR_P_ERR       ;sorry, errors        LD A,E                  ;check the status again ELSE ENDIF        BIT 0,A                 ;is there a character to read?        JR NZ,READ_RDY_MI       ;YES (bit set)        DEC HL                  ;NO, so one less inner loop        LD A,H        OR for ok exit, leaving character in A ;******** SET_ZF:        PUSH HL SET_ZF2:        LD L,A             ;save A        XOR A              ;ZF=1        LD A,L             ;restore A        POP HL        RET;****************************************************************];Non-ADAMnet Serial Send Character With Timeout Check. ;Modified PR #3 routine from SmartBASIC 1.x version 20Y by Richard F. Drushel ;Removed error jumps to force PR #0 and print error messages, and cleaned up ;some spaghetti left     ;restore C to entry state (baseport)        OR A                    ;ZF=0 for error        RET ;******** NO_PORT:        LD A,CHAR_DEV_NO_PORT_ERR ;missing port        JR SER_SEND_BYE           ;error exit ;******** OR_FR_P_ERR:        LD A,CHAR_DEV_OR_F_P_ERR ;mark overrun/framing error        JR SER_SEND_BYE          ;error exit ;******** SEND_RDY_MI:        POP AF                  ;restore character        POP DE                  ;all done with outer loop counter        INC C        INC C   ;save so we can use it for inner loop counter        PUSH DE                 ;save so we can use it for outer loop counter        PUSH AF                 ;save character        INC C                   ;make status port        LD D,8                  ;outer loop counter        LD A,C                  ;get baseport        CP SER68_PORT           ;is it Eve-Orphanware?        JR NC,EVE_OWARE_SEND    ;YES MIB2_SEND: OUTR_LP_MI_SND:        LD HL,65535             ;inner loop counter INNR_LP_MI_SND:   nowledge, only SmartBASIC act-        ually allows  the user to open 2 files at once.  Moreover, because the  file I/O routines in SmartBASIC are defective, there is no practical use for 2 open files.  EOS8 allows the applica- tion programmer to both set the number of DTAs and to relocate the DTAs/FCBs, so future programs can have more than 1 user file open at once if proper  setup is done.  At least one  existing  program,  however (ADAMlink  V) uses the 2nd DTA at its absolute address under EOS5 (not  re        OR L                    ;down to zero yet?        JR NZ,INNR_LP_MI_SND    ;NO, so keep going on inner loop        DEC D                   ;YES, so one less outer loop        JR NZ,OUTR_LP_MI_SND    ;reset the inner loop and keep tryingTIME_OUT:        LD A,CHAR_DEV_TIMEOUT_ERR  ;say we're timed out SER_SEND_BYE: SER_READ_BYE:        POP DE                  ;clear AF off stack        POP DE                  ;the real DE        POP HL                  ;restore HL        DEC C               over from binary patching.;     On entry, C=base port and A=character.  On exit, if the send was ok, ;ZF=1 and A=character, else ZF=0 and A=error code.  Routine retries ;approximately 10 seconds before timing out.  C is preserved.;errors:;CHAR_DEV_TIMEOUT_ERR   EQU  25       ;parallel or serial timed out ;CHAR_DEV_NO_PORT_ERR   EQU  26       ;no port found for parallel or serial ;CHAR_DEV_OR_F_P_ERR    EQU  27       ;serial had overrun/framing/parity error__WRITE_SER:        PUSH HL                                 ;point to data port        OUT (C),A               ;send it        JR RDY2                 ;restore C, set ZF=1 and exit with A=character ;******** EVE_OWARE_SEND:-Richr,  I have decided to wait  until both  the  hardware  clock I/O routines and  the  VRAM  interrupt deferral routines are implemented,  so I know how large a RAMdisk buffer I will have available (either 256 or 512 byte).  o     The 2nd user DTA.  To my k     IN A,(C)                ;check the status port        LD E,A                  ;save it in E        CP 255                  ;does this port even exist?        JR Z,NO_PORT            ;NOIF OFP_CHK        AND 240                 ;YES, so 11110000 check upper 4 bits        JR NZ,OR_FR_P_ERR       ;sorry, errors ELSE ENDIF        BIT 3,E                 ;can we send a character?        JR NZ,SEND_RDY_MI       ;YES (bit set)        DEC HL                  ;NO, so one less inner loop        LD A,HÌ1 ×73(part 4 of 4)OUTR_LP_EO_SND:        LD HL,65535            ;inner loop counter INNR_LP_EO_SND:        IN A,(C)               ;read status port        LD E,A                 ;save it in E        CP 255                 ;does the port exist?        JR Z,NO_PORT           ;NOIF OFP_CHK        AND 56                 ;YES, so 00111000 any framing/parity/overrun errors?        JR NZ,OR_FR_P_ERR      ;YES, so exit        LD A,E                 ;NO, so check status again ELSE ENDIF        AND 1        LD A,H        OR L                  ;are we down to zero?        JR NZ,ONLINE_CHECK    ;NO, so keep trying        DEC B                 ;YES, so decrement big loop counter        JR NZ,LITTLE_LOOP     ;not done yet, so restart little loop PAR_TIMEOUT:        IN A,(PAR_PORT)       ;we've timed out!  so let's find out why        BIT 1,A               ;so was it off-line?        LD A,PRINTER_OFFLINE_ERR  ;let's assume not on-line        JR NZ,PAR_ERR_EXIT    ;YES        LD A,CHAR_DEV_TIMEOUT_EY_EO:        POP AF                 ;restore character        POP DE                 ;all done with outer loop counter        DEC C                  ;back up to data port        OUT (C),A              ;send the character        INC C                  ;restore C=status port        JR SET_ZF2             ;ZF=1 for ok exit, leaving character in A;****************************************************************;Parallel printer send with timeout check. ;Modified PR #2 routine from SmartBASIC 1.x vers   ;ZF=1 for ok exit while preserving A PAR_BYE_BYE:        POP BC        POP HL        RET ;********** NO_PAR_PORT:        LD A,CHAR_DEV_NO_PORT_ERR  ;no parallel port found        JR PAR_ERR_EXIT            ;so error exitIV.  For Next Time.In my next article, I will discuss interrupt deferral techniques to prevent reentrancy in the EOS video RAM routines.  This will include a transcript of some discussions that Chris Braymen and I had  on the subject,  as well a complete pseudocode for the algloop counters        PUSH AF               ;save character        LD B,9                ;big loop counter LITTLE_LOOP:        LD HL,65535           ;little loop counter ONLINE_CHECK:        IN A,(PAR_PORT)       ;read the parallel port        CP 255                ;does it exist?        JR Z,NO_PAR_PORT      ;NO, so no parallel port error        AND 1                 ;is it on-line?        JR NZ,PAR_READY_CHECK ;YES PAR_NOT_READY:        DEC HL                ;NO, so decrement little loop counter                  ;is it ready to receive a character?        JR NZ,SEND_RDY_EO      ;YES, so send it        DEC HL                 ;NO, not yet, so one less inner loop        LD A,H        OR L                   ;are we down to zero?        JR NZ,INNR_LP_EO_SND   ;NO, so keep trying on inner loop        DEC D                  ;YES, so one less outer loop        JR NZ,OUTR_LP_EO_SND   ;not done yet, so reset inner loop and try again        JR TIME_OUT            ;we have timed out! ;******** SEND_RDRR  ;NO, anything else is busy PAR_ERR_EXIT:        OR A                  ;ZF=0 for error        POP BC                ;get rid of AF on stack        JR PAR_BYE_BYE        ;and exit ;******** PAR_READY_CHECK:        IN A,(PAR_PORT)       ;read the parallel port        AND 2                 ;is it ready to receive another character?        JR NZ,PAR_NOT_READY   ;NO, so keep trying        POP AF                ;YES, so restore character        OUT (PAR_PORT),A      ;send it        CALL SET_ZF        ion 20Y by Richard F. Drushel;On entry, A=character to send.  On exit, if the send was successful, ZF=1 and ;A=entry character.  If the printer timed out (either not on-line or non- ;existent), ZF=0 and A=error code.;errors:;CHAR_DEV_TIMEOUT_ERR   EQU  25       ;parallel or serial timed out ;CHAR_DEV_NO_PORT_ERR   EQU  26       ;no port found for parallel or serial ;PRINTER_OFFLINE_ERR    EQU  28       ;parallel printer is off-line__WRITE_PAR:        PUSH HL        PUSH BC               ;save for o rithms,  which  I  successfully implemented in EOS-8,  and  in  a modified version of SmartBASIC 1.x (as proof of concept).V.  Administrivia.I finally unpacked my 486 system after ADAMcon 09,  so now I  can start  working  on all the leftovers in my  buffer,  including  a master set of distribution disks for ADAMserve (including ADAMse rve PowerPaint,  and user-configurability of server hardware).  I will get lynched soon if I don't clean it up!        See you next week!        *Rich***********trouble to understand it, and neither did many other people.  That I don't understand either.  At any rate, through trial and error, Gene and I got the state of our knowledge about the Digitizer to the point where we had figured out a few very basic things, and on that basis the demo proceeded. To make a long story even longer, Gene sent me an E-mail fol- lowing my return from Grand Rapids asking about a program that was supposed to have been included with the Dynomite distribu- tion disk, a program called Ì1 ×65Ron'sWeek'n'ADAMSeptember 16, 1997Why are there not more people writing programs for ADAM in Z80 assembly language? Why are there not more people writing prog- rams for ADAM in C or SmartBasic 1.x?  For that matter, why are there not more people writing programs for ADAM in Forth, Pascal, Fortran, or whatever their heart pleases? Why don't you write programs for the ADAM?  Have you ever wondered about this deep and painful question? Sometimes people I know put up emot- ional fences when the subjined Z80 source code for a machine language overlay, along with a brief description of how it could by used with another program call- ed Dynoplyr10 to allow play of digitized sound files under SmartBASIC. Z80MR was recommended by the author for assembly of the file. I wrote Gene with this information, and he wrote back a couple of days later saying that he'd tried the assembly but had been unable to open the input file.  Now this partic- ular file contains a few paragraphs of introductory text, asking userDynomite Sound Digitizer (Trisyd Video Games, Toronto - Syd Carter, developer). I wanted to in- clude the Digitizer in my  MIDI presentation the following morn- ing and I was really scrambling.  It was one of those products that I just had to have at ADAMCON 02, and having  acquired it I left it to gather dust sitting in the least used ADAM in my collection. Apart from a couple of demos at ADAM User Friendly Group meetings  in Ottawa, little use was made of this unique and original device. I never took the *******************************************************Note:  TWWMCA is archived.  Back issues are available via anonymous ftp.        ftp://junior.apk.net/pub/users/drushel/twwmca/Files have the form wkyymmdd.txt, where yy=year, mm=month, dd=day.*****************************************************************rial ;CHAR_DEV_OR_F_P_ERR    EQU  27       ;serial had overrun/framing/parity error__WRITE_SER:        PUSH HL               'basplyr'. Gene wanted to use his Digitizer to produce sound files for use in his programs - a capability that Syd had provided through a pair of programs accessible from SmartBASIC. Gene advised that he'd been unable to find 'basplyr' and would I please send a copy. Being eager to oblige, I located my original Dynomite Sound  Digitizer distribution disk and had about as much luck as Gene in locat- ing the file. In looking through the files one by one, I finally came upon one called "Copyright", which contaect of programming comes up. They don't even want to talk about it. I've never understood that. Under those circumstances I often get the impression people feel that the  conversation has shifted from whatever was legitimate to that which is not, to something that is almost a mystical and cauldron bubbling art. It's not  really rocket science you know.  But it can sometimes seem that way; case in point follows: Late one night at ADAMCON 09, Gene Welch (dpwgene@msn.com) and I were trying to figure out the s not to distribute the code and imposing other limitations on its use. Following this text, the commented Z80 source code begins. The trick is to delete the text from this file so that it contains only Z80 code or comment lines beginn- ing with a semi-colon. The place to begin is easy enough to spot. You then re-save the file and load Z80MR (available as PD these days, I think) to assemble the file. This is where Gene got stopped. Lesson 1When you load Z80MR and a source code file to be assembled, the  TDOS to EOS using the FC.COM file conversion utility,  where it will perform as advertised.Dynoplyr10 works with the assembled overlay basplyr. It will play a sound file produced with the Dynomite Sound Digitizer whether or not the Digitizer cartridge is present. In other words, you can use this program to load  short sound files into your SmartBASIC programs.I shall have to write Gene Welch and tell him all this.I suppose it might serve to explain why there aren't more people writing programs for ADe of  the 3 letter file extension.Moving right along.....Z80MR went to work and informed me that it had assembled the input file with no errors. Great stuff - except that this pro- cess has been completed under TDOS. Sure enough, the directory where the assembly had taken place now contained new files in addition to the original source:                 basplyr.prn                basplyr.hexUsing FC.COM I transferred basplyr.hex to EOS and put it in the same directory as the Dynoplyr10 file, renaming     ;restore C to entry state (baseport)        OR A                    ;ZF=0 for error        RET ;******** NO_PORT:        LD A,CHAR_DEV_NO_PORT_ERR ;missing port        JR SER_SEND_BYE           ;error exit ;******** OR_FR_P_ERR:        LD A,CHAR_DEV_OR_F_P_ERR ;mark overrun/framing error        JR SER_SEND_BYE          ;error exit ;******** SEND_RDY_MI:        POP AF                  ;restore character        POP DE                  ;all done with outer loop counter        INC C        INC C e basplyr as a binary (CNTL-B) file instead of an H file. I even tried making it an A file. That shows you how much I know about SmartBASIC. Lesson 2Before conversion from TDOS to EOS, the assembled object file - basplyr.hex - has to be *LOADED*. To accomplish this, you use a CP/M 2.2 program called                  LOAD.COM which reads the file basplyr.hex and loads it starting at 0100H, which is where all CP/M or TDOS .COM files begin. The resulting file,           basplyr.com can be transferred fromZ80 source file should appear on the command line *without* the file extension. So let's suppose for the sake of arguement, the Z80 code retrieved from the file "Copyright" was renamed as                 basplyr.Z80 The assembler command line would then read:                Z80MR basplyrI've found this to be the case with most Z80 assemblers that I've used. As a rule, they do not like file extensions, because following the input file name, they usually expect to find other parameters or switches in placAM. -RonC D                   ;YES, so one less outer loop        JR NZ,OUTR_LP_MI_SND    ;reset the inner loop and keep tryingTIME_OUT:        LD A,CHAR_DEV_TIMEOUT_ERR  ;say we're timed out SER_SEND_BYE: SER_READ_BYE:        POP DE                  ;clear AF off stack        POP DE                  ;the real DE        POP HL                  ;restore HL        DEC C               it as basplyrH. The author claims that although  his basplyr overlay is assem- bled to load at 0100H,  there is an offset included in the file to ensure that it loads at the required address under SmartBasic This fact sailed straight over my head. Looking at the Smart- BASIC file Dynoplyr10, I saw that one of its first actions was to BLOAD the file basplyr. So I ran it. When ADAM regained consciousness...... There was the error message:                filetype mismatchI tried using Filemanager to renamÌ1 ×65From: wnerini@ww-web.com (Will Nerini)Re: RonsWeek'n'ADAm  Sept 16, 1997>Why are there not more people writing programs for ADAM in Z80 assembly language? Why are there not more people writing programs for ADAM in C or SmartBasic 1.x? (Will reply:) I'll wager because the mainstream computer industry has moved farther and farther away from the idea DIY computing. With the advent of personal computers we were doing it all ourselves.  BASIC was supplied with everything, and most people knew the wg that is almost a mystical and cauldron bubbling art. It's not really rocket science you know.  I agree wholly. See Above. I find people beginning to defer to me on _ANY_ computer related issue. I sometimes think people see me as "The Village Wizard" which spooks me.  But it can sometimes seem that way; case in point follows: ....Explanation of FUBARed software distribution troubles deleted.> I shall have to write Gene Welch and tell him all this.See, this brings up one of my pet peeves, to (mis)quoept that "programming is impossible", and that it's best left to "professionals" like myself.  > For that matter, why are there not more people writing pro- grams for ADAM in Forth, Pascal, Fortran, or whatever their heart pleases? Why don't you write programs for the ADAM? OK Ron, gimme some time to pick it all up again. While I'm mostly talking though my hat at this point, It seems from my rather shallow(so far) view of the current Adam scene, what we need most is a high-level, compilable language. EitZ80 source file should appear on the command line *without* the file extension. So let's suppose for the sake of arguement, the Z80 code retrieved from the file "Copyright" was renamed as                 basplyr.Z80 The assembler command line would then read:                Z80MR basplyrI've found this to be the case with most Z80 assemblers that I've used. As a rule, they do not like file extensions, because following the input file name, they usually expect to find other parameters or switches in plachan one drive at a time, implement all sorts of copy, rename, etc functions. definitely make use of the SmartKey metaphor, etc. > Have you ever wondered about this deep and painful question? Sometimes people I know put up emotional fences when the subject of programming comes up. They don't even want to talk about it. I've never understood that.  Under those circumstances I often get the impression people feel that the conversation has shifted from whatever was legitimate to that which is not, to somethinay to get the best S/W was to write it themselves. Our PD industry flourished, and a near-infinite variety of programs was developed. That has changed. Although Visual Basic for Windoze is as easy(easier) to use than the old BASICs of the past, it is priced beyond the reach of most everyone, say $500 for a useful version(the "pro" edition). Who would have even _thought_ that computers wouldn't come packaged with SOME way of controlling them, other than on a merely cosmetic level. So, people have come to accte Trash can butt, "It's the User Interface stupid." While things have gotten a little better in the industry, for the most part programmers like myself take little or no time to learn the astetics(sp) of how to make something useable to people. This need runs from Setup to Docs, to removal.  Well, I try, but am no shinning example myself. > I suppose it might serve to explain why there aren't more people writing programs for ADAM.  AGREED!her some sort of "SmartBasic blitzer"(compiler), a pascal system, a 'C' compiler, or maybe best of all, a customized language for the Adam, like Promal for the C64, Action! for the Atari 8 bits, or even "e" for the Amiga. But for now, I'm gonna start in SB1x with Z-80 asm routines.   On a temporarily lighter note, I've settled on my first task, a _great_ filemanager program. filemanager is a decent product, does it's job, but it's hardly up to snuff. i'm going to try and make it multi-drive(display move tÌ1 ×64FROM Ron MitchellRe: RonsWeek'n'ADAM reply from Will Nerini (Ron#2.txt)1)   you have my undivided attention. And I'm a genuine Fileman freak, complete with autographed copy from the author. 2)   Well.... suppose as long as they pay you, what the heck, let them call you what they will.3)    Love it!  Actually, I'd settle for a meaningful and use- ful 'help' file that takes some account of the quagmire some of us users can get ourselves into. Most of 'em say something like, "well son, if you'veugh to have both of these guys as members of my user group in Ottawa up to about 1990. So I learned despite myself. Other ADAMites freeze at the mention of TDOS, and strongly prefer to remain with ADAM's native operating system, EOS., and with the  small amount of software Coleco produced as well as so pretty darned good after market stuff. If you go to an ADAM meeting and so much as mention TDOS, eyes will start to glaze over. So the programmer really needs to make use of ADAM's user interface (ie the SmarÌ1 ×61Also from Ron Mithell to Will NeriniRe: RonsWeek'n'ADAM reply from Will NeriniI'd look forward to whatever contribution you'd care to make Will.  I do have the following here if they are of any use to you: Manx C compiler and attendant files.   Implements Aztec C under CP/M 2.2 or TDOS  Turbo Pascal 3.3 which will run under TDOS  There is also Microsoft MBASIC 5.?  (something or other)  You also ought to have a look at Dale Wick's  'MIC' compiler. It'll blow your mind. It was distributed to all og that is almost a mystical and cauldron bubbling art. It's not really rocket science you know.  I agree wholly. See Above. I find people beginning to defer to me on _ANY_ computer related issue. I sometimes think people see me as "The Village Wizard" which spooks me.  But it can sometimes seem that way; case in point follows: ....Explanation of FUBARed software distribution troubles deleted.> I shall have to write Gene Welch and tell him all this.See, this brings up one of my pet peeves, to (mis)quoional version of Visual BASIC, V2.0 (what the hell, the price was right),  Visual Basic 5. (learning edition), Borland C++, Visual C++, Borland Turbo Pascal 6, etc, etc etc,  Got 'em all installed, one of these days I might even start studying them. I should add that there is quite a dichotomy in our small ADAM world. Those who got curious a few years back when Tony Morehen and Guy Cousineau (TDOS authors) were still active, learned enough about TDOS to be able to use most CP/M 2.2 software. I was lucky eno screwed things up this badly, you better go check with your IBM reseller for assistance."Let's hear it for 'look and feel".  Substance is not required.  -Ron Mitchell----------(snip....snip...snip)d beyond the reach of most everyone, say $500 for a useful version(the "pro" edition). Who would have even _thought_ that computers wouldn't come packaged with SOME way of controlling them, other than on a merely cosmetic level. So, people have come to acctkeys such as display- ed by Smartwriter), and  produce  product that will be reasonably easy to operate from first boot-up. We're not much on command lines, input arguements, and command line switches and that sort of thing.  Once had a network administrator at work who told me that one day soon all us old DOS 'far*s' would eventually die off and then he would be free to do his job. He'd never heard of CP/M. Imagine. Ron Mitchellf us at ADAMCON 09, and is presently a 'work in progress'. Dale has produced a very small, compact, working compiler that uses syntax like nothing else I've ever seen. It made up of BASIC, C, PASCAL, DBASE II, you name it. There are bits and pieces from everywhere. But it works, and will produce a .COM file that ADAM can run under TDOS.As for me, I'm a language junkie. Jack of all trades master of none and know enough to be dangerous. Have just been on a spree in the Windows world, picking up the ProfessÌ1 ×64                        ANN SUBSCRIPTIONS***************************************************************This is another in a long line of monthly offerings from the ADAM NEWS NETWORK, A.N.N. for short.   Subcription rates are $25.00 US per year and insure you that a disk will be delivered to your door each and every month all year long.  The monthly disk is also available on CompuServe in the CLUB section (GO CLUB) at Library 9 and Library 10, but you will incur down- load charges from CompuServems.  I'd have to know exactly what he  was trying  to run,  and what the configuration is of each machine he was trying to run it on. Just a guess... I may be way off, but that has happened to me too.  -Ron Mitchell " End QuoteFrom:  BART LYNCH Subject:  differing tdos Folder:  General You Said:   "hmmmm....forsooth,  yon mitchell speak true.  hadn't thought  of  that myself.  while MY own two  systems  are  almost exactly  the  same as to periphreals,  that's not always true  of other  folks.  i havÌ1 ×68Editor's note: Here is a sampling of the ASYLUM BBS messages from September.  They illustrate some chit chat; but more importantly, it gives us some information about the use of TDOS and maybe some frustrations also.   From:  RON MITCHELL Subject:  Exit Comment Folder:  General You Said:   "Was replying to a bunch of old messages  Bart,  from way  back  in May.  Then the mailpacket I downloaded  last  night ended up incomplete somehow.  Didn't get it all.  No matter.  Got the first part, and repl could well be right.   Think even Guy Cousineau was getting somewhat  concerned toward the end of his presence with us about the number of diff- erent kinds of TDOS that had to be proliferated out there..... 80 col for IDE, 80 col for Minnie Winnie, 40 col with hard drive, 40 col without hard drive, 80 col with Orphanware Serial Port for PBBS use... 40 col for IDE for PBBS Use..... and on and on. Not sure if that's really what they intended.... oh and then of course you have to add disk drives, or no diskhe main for the TDOS system to  react  properly.  What  he really needs to do is  to  have  a separate  TDOS boot disk for each of the spares,  as well as  the main..(assuming  that they don't have the same drives and  memory expanders). Otherwise, TDOS expects to see whatever it was orig- inally  set up with.  It'll boot on another system with different peripherals (memory expanders,  disk drives,  etc...) but it  may not  recognize  them.  That might have an adverse effect  on  the running  of some progra and you will need to know how to use some basic TDOS or EOS programs in order to make readable versions of the disk each month.  The choice is yours.To subscribe and have it delivered to you, sent $25.00 US and of course your complete mailing address to our treasurer:Bob Bair 6552 N 400th E Kendallville, IN 46755   The monthly disk is available in any format you need; 160k, 320k, 720k or digital data pack.  All available upon request.Bob Slopsema Editor-in-chief e at had an absolute rock bottom  last  ditch bail  out tdos disk.  this is configured for just one disk drive. this is when i've made a royal mess of soemthing and need to  get SOME  sort of tdos up.  i noticed when i was getting thing  ready for  my ac session that this "basic" tdos sometimes wouldn't  run what  i  wanted  it  to run.  you could well  be  right,  all  in all....." End QuoteFrom:  RON MITCHELL Subject:  differing tdos Folder:  General You Said:   "And that's the scary part.....  that Iied to a couple. If anybody has sent me a message over the past month or so that I haven't acknowledged, or that we didn't talk about at ADAMCON, perhaps they'll repeat it, and I'll reply again. One thing I did read about in the heat of the battle somewhere... was I think Dave Ruff talking about TDOS programs working on his main but not on his spare. Now I don't know the precise answer to why that should be, but here's something to keep in mind. The spares would have to be configured EXACTLY the same as t drives to that, and if so how many, and what type ....  and what density.... and  eeeeechhhh! LIke you, i have a stripped down, no-memory expander, semi-brain- dead,  'stairs-go-all-the-way-to-the-top'  version  of TDOS  that sits in my "dont-touch-unless-you're-in-a-state-of-absolute- panic" case.  -Ron Mitchell " End QuoteFrom:  BART LYNCH Subject:  differing tdos Folder:  General You Said:   "yeah,in my personal opinion, i think this is part of what caused guy to throw in the towel.   His eyes RE those!).   Oh, and for those who haven't found it yet, try http://www.ebay.com/aw Auction Web. They often have old coleco and Adam stuff for sale(that's where I got my CPM). Thanks, Will ect:  differing tdos Folder:  General You Said:   "hmmmm....forsooth,  yon mitchell speak true.  hadn't thought  of  that myself.  while MY own two  systems  are  almost exactly  the  same as to periphreals,  that's not always true  of other  folks.  i havÌ1 ×72From: Will Nerini134@nerini.drf.comWell, after a nearly 12 year span of non adam ownership, I have gotten myself a new adam, Smartbasic, and cpm2.2.  I'm remarkably interested in making the adam my programming hobby. I'm a professional programmer(on pcs), and want to (re)learn all I can about the Adam. So my question to you all is this: What's the best materials to start with. Pointers to programming info? what hardware add ons are a _must_? Etc.About me: I'm 31, the programmer for the Daily Raöööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööönd developed commercial apps for it till about 92-93, started drifting into PC land. Now I write Visual Basic, Java and Perl code for a living(a good one, I'll bring the much joked about cash infusion into the Adam community). I'm actually a little better rounded than that, I play guitar, have a degree in the Russian language and enjoy hiking and raquetball. I also colect all manner of old computers. Especially old handhelds(Mattell) and Orphan systems like the Adam and Aquarius(thank god I never had one ofALLY  started bugging out at how many possible combinations of tdos there would have to be to cover PBBS!! " End QuoteZ80 code retrieved from the file "Copyright" was renamed as                 basplyr.Z80 The assembler command line would then read:                Z80MR basplyrI've found this to be the case with most Z80 assemblers that I've used. As a rule, they do not like file extensions, because following the input file name, they usually expect to find other parameters or switches in placööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööcing Form online, I've been into computers since late 81 when I sat down in a Radio Shack every day at lunch and after school and taught myself to program. I have had, in succession: A TRS-80(loaner), and apple][(loaner), then TADA: my first computer was an Adam. I learned quite a bit about it, especially ML from SmartBasic, but alas, that's mostly gone now. After my original Adam busted and I couldn't get another one(easily), I drifted to the Ataris, then in 86, I got an Amiga. I found a new coding home, aöööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööö