by Richard F. Drushel (drushel@apk.net)
The Cleveland B.A.S.I.C. users group held its monthly meeting in my basement on Sunday, 28 September 1997. It really wasn't too elaborate of a meeting, because only me and George Koczwara were in attendance. Pat Williams was out with the flu, and Jean Davies didn't want to come by herself. As for Herman Mason, well, nobody knows were he is :-)
George and I made the most of the situation, however. He had brought a disk containing the HTML source files for his personal webpage, which he had been working on. He wanted to make a wallpaper (background) consisting of the various logos for the 9 ADAMcons, and wanted to know if
I had photos of the banners,
if so, could I scan them, and
if I already had scanned photos, could we make a wallpaper?
At ADAMcon VIII, I had photographed all the banners which were on display at the banquet. I subsequently scanned the photos, used Adobe Photoshop on one of our lab PowerMacs to resize them and make them into JPEG images of suitable size for download (about 15-20K each), and sent them to Dale Wick, where he put them up on his Coleco ADAM Home Page. The URL is:
I still had copies of the final JPEGs on my home 486 system, so I gave these to George.
As for the ADAMcon 09 banner, I had photographed this as well at the ADAMcon 09 banquet, but had not yet scanned/processed the photographs. This is something I should do soon, some evening when I'm in the lab late and have accesss to the scanner. I'll get the JPEG of this (and of the ADAMcon 09 cake) to Dale as soon as I make it.
I then set out to make a webpage wallpaper out of the 8 banner JPEGs. Any image (GIF or JPEG) can be used as a basis for wallpaper; the web browser simply tiles it all over the screen (i.e., repeats it over and over like covering a floor with tiles) until the screen is covered. Text and other images are then displayed on top of it. To create the wallpaper image, I used a Win3.1 graphics program called Canvas 3.5. In brief, I loaded each of the 8 banner JPEGs and pasted them into a single window as separate objects (which means that I could move/manipulate each one separately). This window would be the basis for the final wallpaper image. I then moved each banner image into position, aligning them as best I could (the banners are of different sizes) so that a 2 column by 4 row array was created. I then created a solid blue rectangle (in ADAM cyan) and placed it *behind* the 8 banner images. Finally, I grouped all 9 objects together into a single bitmap image (i.e., there were no more separate objects, just one image) and saved it as a GIF file.
I wrote a quick and dirty HTML source file which I could load from disk in Netscape (3.0 for Win3.1) to see how the wallpaper looked. It looked quite nice, and was a small file for as large a bitmap as it was (about 60K). Unfortunately, both George and I agreed that the wallpaper was so visually "busy" that any text displayed on top of it would be rather illegible. Thus, George decided that he would find something else ADAM-oriented to serve as wallpaper for his webpage. What could be done, however, is to use Adobe Photoshop and its image manipulation features to tone down or fade the image, so that it would look more like background than foreground. If I get a chance, I may play with this. In any case, if there is interest, I can put the GIF wallpaper that we did make up for download. You could also go to the Coleco ADAM Home Page, grab the banner JPEGs yourself, and have your own go at it.
I had couple of responses to my USENET repost of TWWMCA 9709.26, the one which documents the ADAMserve serially-linked device protocol. The gist of the comments was, "You're reinventing the wheel: the TCP/IP protocol does everything you're trying to do here and more. Why not use TCP/IP?"
TCP/IP is the main protocol used over the Internet to transmit data. Indeed, other protocols (like Real Audio for sending stereo sound) are themselves transmitted using TCP/IP. I would love to use something as robust and full-featured as TCP/IP with the ADAM.
The only problem with using TCP/IP for ADAMserve-like functions is that it takes too much Z80 machine code to implement TCP/IP. The entire ADAM EOS operating system must fit into 8K of RAM (less, if you leave room for the ADAMnet device control blocks at the very top of memory). Even after squeezing out all the dead space and optimizing the existing EOS code, there was only about 500 bytes available for all of ADAMserve. About 100 bytes of that is taken up by the low-level serial I/O routines, and another 64 bytes by the logical-to-physical device table. Managing NMIs (non-maskable interrupts) is another 20-odd bytes. There just isn't enough room to do much with what's left. I couldn't even put in a CRC (cyclic redundancy check) calculator for block I/O; I had to use simple (and not as capable of detecting transmission errors) checksums because they require minimal machine code to implement. Similarly, automatic retries in case of error are not implemented at the EOS level; the user program has to do the retries itself if desired.
Thus, ADAMserve in its current form represents a number of compromises from the ideal. About the best that I can say is that it does work: it allows the ADAM to use server hardware transparently (through the established ADAMnet device interface and standard EOS function calls), and it fits within 8K.
One feature that I'd like to add (before I freeze the protocol) is a Set ADAMserve Version function:
*****************************
** **
** SET ADAMSERVE VERSION **
** **
*****************************
ADAM SERVER
==== ======
V [version] [1's complement of version] ---------->
<------------------------------------------------- ACK (or NAK
VER_NOT_AVAIL_ERR)
VER_NOT_AVAIL_ERR EQU 8Fh ;server doesn't support the requested
;level of ADAMserve functionality
This would allow server software to evolve to support greater levels of functionality (perhaps even on non-ADAM computers; I have in my moments of delusion of godhood imagined that ADAMserve could be a general-purpose way for 8-bit computers to access other hardware resources), while remaining backward-compatible with earlier versions of the client software. In this case, the client would tell the server what version of ADAMserve it was expecting. If the server supports the requested version, it will acknowledge the request, and all further ADAMserve transactions will follow this level of functionality. If the server does not support the requested version of ADAMserve, it returns an error code, so that the client can either attempt to "downshift" and negotiate a compatible level of ADAMserve functionality, or else abort gracefully. By default, the server should start up in the original (i.e., current) ADAMserve mode, and not change unless specifically requested by the client.
I will hereby define the default version to be the current ADAMserve 4.0 specification. Version 0 will be ADAMserve 5.0, when that specification is finally written and frozen. Note that any clients with 5.0+ functionality attempting to run on a 4.0 server will get an INV_COMMAND_ERR in response to the Set ADAMserve Version command, and hence should either downgrade to 4.0 level or abort.
The relative primitiveness of the ADAMserve protocol, compared to other available protocols which have already been invented and thoroughly debugged, is somewhat disappointing to me. Even though it works, ADAMserve is a dead end because of the stupid 8K EOS RAM limit; ADAMserve 4.0 will let existing applications run, but is not conducive to the development of new applications (assuming that there are programmers out there who will write them).
The only hope for more EOS functionality is to get rid of the 8K EOS RAM limit. The easiest way that I can forsee to do this is to move parts of EOS into expansion RAM. This would allow me to keep the 8K EOS RAM limit in the base 64K of RAM, but add as much functionality as I want in expansion memory (XRAM). The only programs which wouldn't work would be those that appropriate XRAM for themselves. These would have to be identified and modified to leave XRAM alone, or else access it only in a controlled way.
Here's what I propose: a bank-switched EOS. It would require at least a 64K memory expander, and whatever space wasn't used by EOS would be made available as an EOS RAMdisk (device 26, d7 in SmartBASIC).
The only problem with this is the program that's built into every ADAM: SmartWriter. SmartWriter checks for the presence of XRAM, and takes it over as additional program workspace if it finds it. So as soon as anybody aborted to SmartWriter through the _GOTO_WP EOS function call, their ADAM would crash because EOS would be trashed. Thus, prior to any XRAM-banked EOS project, SmartWriter has to be modified, and new, XRAM-friendly SmartWriter ROMs installed in any ADAM wanting to use the new EOS.
This weekend, I made a preliminary disassembly-to-source of SmartWriter R80, using Z80DIS22 under the Z80MU.EXE CP/M emulator. (This is the same disassembler that I used to make ADAMserve File Manager and to fix the ColecoVision game Pitfall to have infinite lives.) There is some nasty code organization in SmartWriter, but nothing I haven't been able to handle so far. (The biggest impediment was what appears to have been an inline macro command for printing strings: a CALL MY_PRINT_STRING followed by the address of the string. This confused the disassembler and required tedious but simple manual intervention to separate code from data areas.)
I believe that I can very shortly create a version of SmartWriter which ignores XRAM. (I also will try to put in the ability to read/write to drive D (device 5), a long-standing omission in SmartWriter). I will test the new binary not by burning new SmartWriter ROMS, but rather by using Marcel de Kogel's ADAM Emulator. When I'm confident that I have been successful, I'll burn a ROM and try it in a real ADAM. When this works, I will release the binary and strongly encourage every ADAMite to upgrade to this new ROM. Only extremely large SmartWriter files which were created by someone with a memory expander would be unreadable under this new, XRAM-ignoring SmartWriter.
I have heard that there are releases of SmartWriter after R80 (I seem to remember an R84 and an R85). If anybody has the binaries of these, I would rather use them as the basis for this rewrite, since presumably they include the last available bugfixes (maybe even the drive D bug already). In the meantime, I will forge ahead with the R80 regeneration, since anything I may learn there will be needed for any of the later versions.
The process of burning new ROMs can be coordinated rather easily if we just agree to do it. The lowest-cost thing to do is to pull the existing EPROMs from your ADAM, send them to someone for reprogramming, the reprogrammer sends them back to you, you put them back in your ADAM, and you're done. Anybody with a Phillips-head screwdriver can open up an ADAM, and anybody with a small bladed screwdriver can pull an EPROM. This would be a good group activity for users groups, or something that could be done (by me or others) on a grand scale at ADAMcon 10. Of course, new PROMs or EPROMs could be made at material cost for those not wishing to have their original EPROMs wiped.
I have an EPROM burner and would be willing to reprogram them at shipping cost (about $1 or so) as a non-profit proposition. I would rather not deal with complete ADAM system units sent by people unwilling to open them up to get at the ROMS, because of the large expenses all the way around; but vendors might be willing to do this.
Just knowing that there was nothing intrinsic to the ADAM that would crash an XRAM-based EOS would make it a more reasonable proposition to implement advanced EOS-8 and ADAMserve functionalities.
Except for my disassembly of SmartWriter, this is all speculative: please discuss this publicly on the Coleco ADAM Mailing List, send me E-mail, etc. I want to know what people think.
Here are the EOS programs I can think of that will appropriate a memory expander if they can find one:
SmartWriter (extra workspace)
ADAMcalc (as a background print buffer)
PowerPaint (original version *requires* a memory expander)
SmartBASIC 2.0 (EXTMEM command allows extra workspace)
File Manager (won't use XRAM unless told to, but detection is destructive)
SeQuel (MIDI I/O buffer)
I don't believe any of the Coleco database-type programs (SmartFiler, Recipe Filer, Address Book) use XRAM, nor indeed any of the other Coleco software. If you know of anything else which does use XRAM, please let me know.
Of the above list, the ones which will be well-nigh impossible to make compatible with an XRAM-based EOS are:
SmartBASIC 2.0 in EXTMEM mode (STDMEM mode will be okay)
SeQuel (overhead of going through an EOS RAMdisk will probably be too much timewise; I think it accesses XRAM through a maskable INT routine during MIDI interrupt--can you comment, Chris Braymen?)
The existing hard drive version of ADAMserve PowerPaint was already patched to ignore expansion memory. The print spooler in ADAMcalc can simply be disabled, forcing printing to the foreground (sorry, Frances Clee!). The destructive testing part of File Manager can be programmed around (indeed, I solved this problem in 1992 in the versions of Mini Wini HARDDISK 2.3 and 3.9 with RAMdisk).
See you next week!
*Rich*
Next Article
Previous Article
TWWMCA Archive Main Page