by Richard F. Drushel (drushel@apk.net)
Now that I have a full-time user ADAM system up and running in my basement, my older daughters have rediscovered the joys of playing ColecoVision game cartridges. Christina (age 9.5) does most of the playing, Elanor (age 6.5) offers comments and criticisms, and Diana (age 3) just watches. Most of their time has been spent with Carnival, Choplifter, Antarctic Adventure, some Keystone Kops game, and (ugh!) Space Panic. About the only game that Elanor has managed to figure out is Carnival; the ducks still get her every time, though.
This weekend, they also spent time trying out various ColecoVision games using the ColecoVision emulator program, COLEMDOS.EXE, by Marat Fayzullin (fms@freeflight.com), which I demonstrated at ADAMcon VIII. (Marat's home page is http://www.komkon.org/fms/ColEm/, which has links to ports to Unix, Macintosh, Windows, MS-DOS, and other operating systems.) I printed out a listing of the \ROMS directory (which contains binary images of game cartridges) so they would know what file names to use, and let them go at it. Most of the games in the 116-game archive I have never seen before, so I was little help for how to play some of the games. Their favorites were Tapper, Mr. Do, and Ladybug.
Some of the games do not appear to work correctly under the emulator: Qbert (locks after the first time you die), Victory (can't steer/rotate the ship), a Dr. Seuss puzzle game (can't rotate puzzle pieces if they get scrambled upside-down). I don't know if this is because of limitations in the emulator, or if the ROM images are bad. If I owned these cartridges, I could make my own ROM image and try them out.
ROM images...the vortex of copyright questions. It's very likely illegal to redistribute ROM images without consent of the original copyright holders. This means that there's no way to put this ROM archive in a conspicuously public place (like CompuServe) without getting someone in lots of trouble. At ADAMcon VIII, I discussed with Pat Herrington how to get around this so that she could safely use CompuServe to redistribute this emulator. The ColEm emulator itself can be freely redistributed--the source code is available for anybody to modify. (Hmm, in my copious spare time, it would be fun to make this into an ADAM emulator.) As for the ROM images, my suggestion to Pat was that a copy-cartridge-to-160K-disk program be written in SmartBASIC, and this program, along with Chris Braymen's ADAMDOS program (to read 160K ADAM disks in PC disk drives), be bundled with the emulator. This way, you can make ROM images of all the cartridges you own, for your own personal use, and not have to worry about copyright issues. I have a SmartBASIC 1.x program already which can copy the cartridges, but the distribution program really needs to be in vanilla SmartBASIC, PEEKs and POKEs and CALLs and all, since the latter is the only software that we may expect every ADAMite to own. If someone already has a program which can copy a game cartridge to a binary file (no headers, no fancy stuff), please speak up.
In September 1990, I bought a Tandy 2800HD '286 12 mHz laptop computer, with EGA-resolution LCD screen and internal 2400 bps modem, for the purposes of writing my Ph.D. dissertation. I also used it as a disassembly platform for SmartBASIC, ADAMlink IVa, PowerPaint, HARDDISK, the Coleco Graphics Processor, and many other programs which exist only as binary images. With the use of a CP/M emulator, Joan Riff's Z80MU.EXE, I could also run CP/M and TDOS programs (mostly uncrunchers and delibrary programs to deal with files I downloaded from George Koczwara's (aa436@po.cwru.edu) BBS, or ftp'ed from the famous, defunct Simtel archive (wsmr.simtel20.army.mil) at the White Sands Missile Range in New Mexico. With WordPerfect 5.0 as my editor and a DOS- based cross-assembler, I could write new Z80 code and assemble it to binaries; I could then either null-modem transfer it to an ADAM, or upload it to temporary storage on the Cleveland Freenet and download it to an ADAM via ADAMlink IVa. This machine served me well (you may remember seeing it at ADAMcon IV), and I took it everywhere there was ADAM code hacking to be done. (I also successfully completed my dissertation with it.)
Unfortunately, laptop computers of that vintage are subject to LCD screen wearout. Specifically, the fluorescent backlighting becomes dimmer and dimmer with time. There is a brightness adjustment to compensate, but eventually you can't get it bright enough to see what's on the screen. This happened to my laptop about 2 years ago. The only way to see what was on the screen was to sit either in a dark room (so you couldn't see they keyboard until your eyes got dark-adapted) or in direct sunlight. Needless to say, these were not optimal conditions.
The fatal blow to this laptop came when my daughter Elanor spilled a glass of milk onto the keyboard. I disassembled the computer and tried to rinse out the keyboard, but it was no use: the milk had gotten inside some of the "sealed" keyswitches and these keys no longer worked.
A $2500 piece of junk now, right? Not yet: fortunately, the Tandy designers had left some room for expansion. On the back of the laptop was an external keyboard port and an external color monitor port (DIP-switch selectable for either CGA or EGA). So, with the addition of an external keyboard and an external monitor, I could have a working computer again. In fact, even though a '286-12 is underpowered for any of my current PC needs, it would be just fine as a dedicated ADAMserve server--it has an external serial port, and its 20MB hard drive is plenty of space for a 10MB EOS partition.
So, I decided that I would pull the motherboard out of the laptop case, leaving behind the dead internal keyboard and dying LCD screen. I would mount the motherboard, hard drive, 1.44MB disk drive, and external power supply into a single box. This would then be a compact, ADAMserve-ready computer, which could be used with one of my spare ADAMs. Better to recycle the computer than to junk it, eh?
To achieve a small size, laptop computers use proprietary-design internal components, which do *not* fit in "standard" cases. Not only would I have to come up with a case, but I'd have to figure out how to mount it using all those nonstandard holes. Fortunately, the motherboard and power supply board of this laptop came out as a nice unit. I could set the board onto a sheet of thin plywood, trace the screw holes, drill them, and mount the board using aluminum sleeves as standoffs. (The board should have an airspace underneath it to allow for cooling.) As for a case, I happened to have a nice 2-piece ventillation-louvered plastic box, courtesy of a former member of B.A.S.I.C., George Harpster. Long ago, George (who worked for the NASA Lewis Research Center here in Cleveland, recently renamed NASA Glenn after Ohio-born astronaut John Glenn) got several of these boxes from cast-off equipment. He used one to build a custom case for his ADAM, which included an expansion bus of sideport connectors for plugging in multiple sideport devices. I got one of these boxes with the intent of doing the same someday, but never got around to it. I decided that it would be good to put the laptop guts into this box. One nice thing about the box was that the front and back panels were open: I could have stuff which stuck out the front and back without having to cut access holes in the box.
With little effort I cut a 1/8-inch plywood base, mounted the laptop motherboard and power supply, and installed it in the lower half of the new plastic case. The back of the motherboard had all the external jacks for keyboard, monitor, serial port, parallel port, and modem, and these faced the rear opening of the plastic case. To accommodate the hard drive and floppy drive, however, I had to build a shelf, because the box wasn't wide enough (front-to-back) to accommodate the drives on the same level as the motherboard. The shelf consisted of 2 1-inch tall pillars cut from a 2x4, and another piece of 1/8-inch plywood. The hardest part was drilling holes in the wood to match those in the bottom of the drives; I used paper templates to transfer the hole locations. The last task was to relocate the on/off switch to the front; I bought a big red switch and mounted it on the drive shelf.
The finished project has all the access ports in the back, and the floppy disk drive and power switch in the front. I didn't bother to fill in the remaining open panel spaces, because it would have been too much trouble. If I may brag, however, the new computer guts were fit together in such a way that no drilling, cutting, or alteration of the plastic box was necessary. If I ever decide to put something else in that box, the laptop guts will come out as a complete unit.
As for the cast-off laptop case, I took the LCD screen out, but reassembled everything else, including the dead keyboard, and gave it to my kids to play with :-)
Now I have to finish ADAMserve :-) :-)
Ron Mitchell (ronaldm@mars.ark.com) posted to the mailing list last week that he couldn't get ADAMserve to boot. He'd gotten the latest version from Herman Mason (aa337@po.cwru.edu) at ADAMcon VIII and was desperate to try it out. From his description, it sounded as if Herman hadn't given him an ADAM boot disk/tape. So, I blithely offered to send (electronically) an image of a boot disk/tape.
First I'll give your the "approved" method. Then I'll tell you all the contortions I actually had to go through.
On paper, there's a simple procedure to create a binary image of an ADAM disk that is itself a stand-alone file (which can be copied, edited, etc.). Minimally, you need CP/M or TDOS and a utility program, IMAGE2.COM, which can save any desired number of consecutive blocks from an ADAM disk as a file, starting from any desired block number. The resulting file is called an image file and has the extension .IMG.
Disk images can be huge. If you're going to E-mail it to someone, there can be problems (due to technical reasons relating to how Internet E-mail is managed) if the message is bigger than 64K. Thus, for safety reasons, it's best to send a *compressed* version of the image. The recipient can *uncompress* it himself. The most common compressor I've seen ADAM TDOS people use is called CRUNCH.COM, which creates a compressed file of the extension .?Z?, where ? is any character; the Z means it's crunched. So, by the book, I would crunch the image file to yield something with extension .IZG.
Now I have to get it to the Internet. This means I'll have to upload it by telephone/modem to my local Internet Service Provider (ISP), and then use Internet tools to E-mail it. Using my favorite TDOS modem program (IMP, MODEM7, whatever), I dial into my ISP, initiate an XMODEM upload of my crunched image file, and send it.
Although things are changing slowly, Internet E-mail is still a 7-bit ASCII world. If you send 8-bit binary data, you run the risk that, at some point, all the high bits will be stripped out and your recipient will be left with a 7-bit version. Thus, you cannot directly E-mail a binary file as-is. It is possible, however, to encode an 8-bit binary file using only 7-bit ASCII characters, making it safe to transmit via Internet E-mail. The program to do this is called uuencode, and there's a reciprocal program called uudecode to convert a uuencoded file back into its 8-bit binary form. My ISP has uuencode available, so I uuencode my crunched image file, by convention creating a file with the extension .uue.
*Now* I can E-mail the file. I use my favorite mailer (elm, pine, mail, Eudora) to compose a message. I include the text of the uuencoded crunched image file, then send it off. My recipient must undo all of the steps in reverse order: he has to save the message to a file, uudecode it, download it to a TDOS disk, uncrunch it with UNCRUNCH.COM, and finally copy the image to an EOS disk ("clone" the disk, using CLONE5.COM). If my recipient did everything right, he should be able to put the final cloned disk into a drive and either boot it or be able to read/write it under the appropriate operating system (whatever was used to create it, EOS or CP/M or TDOS).
"The best-laid plans of mice and men gang oft agley." Here's what I *really* had to do to send Ron Mitchell his ADAMserve boot disk:
Historically, I've done very little with CP/M and TDOS. I don't have anything against them, I've just always had so much EOS work to do that I've never gotten around to the others. Thus, most everything I've ever had for CP/M and TDOS was on the TDOS partition of the Mini Wini hard drive I bought from HLM-GMK. Due to a recent power supply failure, however, my Mini Wini system is dead, and I haven't had time to troubleshoot it. Thus, all those helpful TDOS programs I mentioned above were sitting inaccessible.
My first purchase from Steve Major's ADAM Connection, back in 1991 or so, was ADAM CP/M 2.2. I knew I had made a backup copy of the original for use as a working disk, and I vaguely recalled that I had some TDOS-type utility software on that disk at one time or another. But where in my basement mess was that disk? After some scrounging, I located it, booted it, and saw that it had both IMAGE2.COM and CLONE5.COM. Alas, no CRUNCH.COM, and no modem program. Great, I can image the ADAMserve boot disk, but then what?
While scrounging, I also came across an ADAMlink IVa boot disk. This was one of my working disks while revising IVa to create ADAMlink V. This would do XMODEM transfers. So, if I could get the .IMG file from a CP/M disk to an EOS disk, I could at least get it up to my ISP, where I could further manipulate it and then send it to Ron. How to do the CP/M-to-EOS transfer?
Since I was working with a copy of the ADAM CP/M 2.2 boot disk, it contained the 2 utility programs CPMADAM.COM and ADAMCPM.COM, which are used for CPM-to-ADAM and ADAM-to-CPM transfers, respectively. Hooray for ADAM CP/M 2.2! These 2 files are *not* on any of the default TDOS boot disks, so far as I have seen.
In my collection of ADAMserve boot disks, however, I could not find one that was 160K media. ADAM CP/M 2.2 (unpatched) is limited to 160K disks, and all I could find was 720K and 1440K media. This meant that I had to boot EOS FileManager with a 1440K/160K dual-drive setup, copy all the necessary blocks to a 160K disk, then change to a dual-160K drive setup and reboot under ADAM CP/M 2.2. Arrgh!
Now that I had the ADAMserve EOS boot disk on appropriate media, I imaged the disk with IMAGE2.COM, then copied the ASBOOT.IMG file to an EOS disk with CPMADAM.COM. After setting up the nice serial board/2400 bps modem pair that I won as a door prize at ADAMcon VIII (thank you HLM-GMK), I booted ADAMlink IVa, dialed up my ISP, and sent ASBOOT.IMG by XMODEM.
I still needed to compress the binary file before uuencoding it, because the binary itself was 54K, and the encoding process makes it about half again as big. I thought about using the Unix compress utility, but I wasn't sure if Ron Mitchell had access to Unix uncompress or not. The same for gzip/gunzip. Rats, the only thing to do is download it to my PC, use DOS PKZIP.EXE to compress it, then upload it back to my ISP... which is what I did.
Finally, ASBOOT.ZIP in hand, I was able to uuencode it and mail it out to Ron, with a cover letter explaining what he had to do to resurrect the original image, and a note that the details of how his file had come to pass would be presented in my next This Week With My ADAM column.
As Paul Harvey says on the radio, "And now you know...the rest of the story."
Tell me, Ron, was it worth all the trouble? :-)
See you again next week!
*Rich*
Next Article
Previous Article
TWWMCA Archive Main Page