| AdamCon.org : ann |
| AdamCon 13 | AdamCon 12 | AdamCon 11 | AdamCon 10 | Adam News Network Archive
|
Return to adamcon.org | Adam News Index | Volume 97
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 burn 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 the 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@postoffice.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 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 it 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]
>
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 possible 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 love you all. - Richard and Frances
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 publications. 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 submicroscopic 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, 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 clubs 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 restore 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 situation in my earlier general notice) I'll do my best to oblige as quickly as possible. Glad to have you aboard.
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 in 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 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 controller, 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, COMMODORE, 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.)
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 data 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 to 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 compiler, 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 Z80MR 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 Krunch 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 work * 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 that I have all of the docs necessary. Dale
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. Does anyone know if the MIB-3 is bi-directional, or any of the other parallel ports? Maybe the AdamNET one is bidirectional?
Dale
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.
Firstly, 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 itself, 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 (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 magazines. 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 rock-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) writes 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; 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 has 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 off 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...which also lacked documen- tation when I got it.
Talk later,
*Geoff!*
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 sprites, 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, ADAM, 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 !
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 port. 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>
>
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 the 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.
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 tool. 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 offer 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. But 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 love 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 love 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 and 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 learned 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 checkbook 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 started 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 board, 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 amazing 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 houses 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 expected, 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 touchy 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 very 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 back 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 portion. 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.
This 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 Reserve. 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 and 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 intensive 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 word 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 for 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 WordPerfect 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 entire 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 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 advance. 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 hardware 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 each 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 and I
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. There'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 Hazeltine 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 80 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 the 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 the 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 the 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 the 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 use 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 inverse 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 normally 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 with 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 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 third 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. Unless 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, preferably 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'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 sequences 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.
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 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 the 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 that 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 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, "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, having 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 Photoworks (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 picture 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 complete 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
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. 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 address 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)
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 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....... 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.
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
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 bulletin 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 Cleveland 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. Exit 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 suggestions 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 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 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 interrupt 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 polling, 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 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 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 free).
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 occurred 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 modes (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 was 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 (in/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 Mark 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) ]
In 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 VDP 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, write 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 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 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 programs 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 away 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 read 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 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 incorporate 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 INIR :)
>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 interrupt 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. >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 interruptdeferral 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.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 its 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 if 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 which 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
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
;*NOTE* 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 from
;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 be 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
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 ;...then 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=0 ;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 ;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
;it must save AF, HL and any other used
;registers, and end in RET
NMI: 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 ;return 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_routine ;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
;(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
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) ;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_VRAM2:
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 description of ADAMserve (which I have been meaning to do for quite some time).
See you next week!
*Rich*
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 active 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 been 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 of 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 device 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 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 initiated 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 particular 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 EQU 6
Note: the current version was assembled with Mini Wini HDdrivers 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,
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 desired. 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.
*****************************************************************
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 initialization, 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 has 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 into 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 knowledge, 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 relative 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 unfortunately 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 backwards. (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
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 yet 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_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
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
*****************************************************************
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: ;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 EOSfunction 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 table 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 character 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!! *** ; *** DO NOT ADD TO THE END OF THIS TABLE!! ***
[...]
65196 TRIGGER_CHAR:
DS
65197 USR_DFND_RTN:
DS 265199 NUM_FCBS:
DS
;begin EOS8 global RAM
65200 EOS_60TH:
DS 1 ;RFD65201 EOS_SECOND:
DS 1 ;RFD65202 EOS_MINUTE:
DS 1 ;RFD65203 EOS_HOUR:
DS 1 ;RFD65204 EOS_WEEKDAY:
DS 1 ;RFD
65205 INTERRUPT_FLAGS: ;store INT/NMI flags for VRAM routines
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_SIZE65220 DCBS: ;only 12 real ADAMnet devices permitted
DS 12*D_SIZE
;****************************************************************
DUMMY_DCBS:; Note: these will *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 forreference ;*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
*****************************************************************
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 the 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 this 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, and 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
;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_OFFLINE_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 ;not 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 counterINNR_LP_MI_RD:
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
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 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 A,(C) ;get characterRDY2:
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 counterINNR_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
AND 56 ;YES, 00111000 any framing/parity/overrunerrors?
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
DEC 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 for ok exit, leaving character in A
;********
SET_ZF:
PUSH HLSET_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 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 ;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 counterINNR_LP_MI_SND:
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
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 outSER_SEND_BYE: SER_READ_BYE:
POP DE ;clear AF off stack
POP DE ;the real DE
POP HL ;restore HL
DEC C ;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 ;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
(part 4 of 4)
OUTR_LP_EO_SND:
LD HL,65535 ;inner loop counterINNR_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?ELSE ENDIFJR NZ,OR_FR_P_ERR ;YES, so exit LD A,E ;NO, so check status again
AND 1 ;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_RDY_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 version 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 loop counters
PUSH AF ;save character
LD B,9 ;big loop counter
LITTLE_LOOP:
LD HL,65535 ;little loop counterONLINE_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
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_ERR ;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 ;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 algo 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*
*****************************************************************
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.
*****************************************************************
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 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 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 Dynomite 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 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 '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 contained 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 users 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 Z80 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.Z80The 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 place 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 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 rename 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.COMwhich 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 from 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 ADAM.
-Ron
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 way 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 accept 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. Either 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 than 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 something
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)quote 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!
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've 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)
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 of 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 Professional 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 enough 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 Smartkeys 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
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 CompuServe 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
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 replied 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 the 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 programs. 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 have 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 I 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 disk 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 REALLY started
bugging out at how many possible combinations of tdos there would
have to be to cover PBBS!!
" End Quote
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 Racing 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, and 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 of 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
Return to adamcon.org | Adam News Index | Volume 97