by Richard F. Drushel (drushel@apk.net)
This week I received two disks in the mail from Bob Slopsema (72117.3003@compuserve.com). The first was an ADAM disk containing a Spanish vocabulary tutor program for my daughter, Christina (age 9.5). The second was an IBM disk containing text versions of the playing instructions for a number of ColecoVision game cartridges. Let me talk about these two disks in a little more detail:
"The Spanish Vocabularian", © 1986 by Marathon Computer Press, is a BRUNable SmartBASIC program which lets you practice both English-to-Spanish and Spanish-to-English vocabulary. It has several dictionary files grouped by letter of the alphabet (you practice words which all begin with the same letter). Depending upon the mode chosen, the program gives you words in one language, and you have to type the equivalent in the other language. The program does tell you what part of speech the word is (noun, verb, adjective, etc.). Christina has been taking Spanish in school for the last 2 years, but it's all been conversational Spanish so far, so she doesn't know how to spell many of the words yet. Later on in her education, however, this program should be a useful tool for her. A final technical note: even though the program (as I received it) must be BRUN, when you exit normally to SmartBASIC, the program is left in memory in LISTable form. Maybe Bob put it into BRUN form from a regular A-type original?
Also on the disk, perhaps unbeknownst to Bob, were several SmartBASIC games. A bunch of these were A-type files masquerading as H-type (but a little work with FileManager fixed that). The games include GOLF (clearly based on a BASIC-11 version I played 15 years ago on a PDP-11/34 mini- computer, which BTW was one of the first games I ported to Microsoft BASIC for the IBM-PC waaaaay back when), HANGMAN (the classic guess-the-letters- in-the-word game), ICECREAM (really a GR-mode graphics demo; it asks you for ice cream flavors and draws a low-res picture of the resulting ice cream cone), GORKY (some kind of ADVENTURE/ZORK text-based adventure game), GRANPRI (a Grand Prix racing game), and FLUTE (another adventure game, the object being to retrieve a magic Golden Flute). My daughters didn't have much time this week to play these games, but I'm sure they will later.
As for the IBM disk with the ColecoVision game instructions, they will be very useful for figuring out some of those games that came with the ColecoVision emulator. Bob sent me them in some rather obscure word processing format (something called First Choice), leading me to believe that he typed all these in himself--a lot of work, for which I'm grateful. Possibly I can figure out a way to convert them into plain text so that others can read them. I can't recall if Norm Sippel has any ColecoVision game instructions on his home page (http://www.infinet.com/~ngsippel/cv.html).
I had mentioned a few weeks back that my Mini Wini hard drive system was dead due to a bad power supply. Using a power supply borrowed from George Koczwara (aa432@po.cwru.edu), I tried to bring the hard drive back to life. This particular hard drive has been on its last legs anyway--the motor bearings are shot, and it howls loudly--and all I wanted to do was back up all the data on it and then put it into my junk pile. I've had a spare 3.5-inch 20MB MFM replacement drive for over a year now, and just had never gotten around to doing the backups. Saturday was the day I'd get around to it.
Believe it or not, I don't think that there is *any* hard drive backup software available for the ADAM, EOS or TDOS. Since, as I've said before, I have hardly anything on the TDOS partition of my hard drive, I was only worried about backing up the 10 1-meg EOS volumes. How to do it?
Most authorities simply use FileManager to block-copy the contents of each volume onto a floppy disk. Before the advent of the Micro Innovations 1.44 MB floppy drives, most people I know would use a 720K disk and make sure that they never put more than 720K of data in any one EOS volume. The hardest volume to enforce this limit on is volume 0, because that's where all the boot blocks are stored, as well as entire software distributions that are so badly behaved that they will only run from particular blocks in volume 0 (I believe SmartLOGO is like this). Since I have a 1.44 MB disk drive (and also my ADAMserve systems will have access to a 1.44 MB PC disk drive), I decided to do block copies; but I decided *not* to use FileManager to do it.
Instead, I wrote two simple programs in SmartBASIC 1.x (the enhanced SmartBASIC interpreter I released in 1991): one to do backups of individual hard drive volumes to a disk, and another to restore volumes from a saved disk. Here are the programs. Remember, they're in SmartBASIC 1.x, and will abort with an error message if you try to run them under regular SmartBASIC 1.0.
1 REM backuphd5 / created 9610.12 by Richard F. Drushel 2 REM back up a 1024-block EOS volume onto a 1.44MB disk in d5 3 REM note: requires SmartBASIC 1.x!!! 4 REM ********************************************************* 5 IF VER(0)>=20 THEN GOTO 10: REM we have SB1.x 6 HOME: PRINT CHR$(4): INVERSE 7 PRINT " WRONG SMARTBASIC VERSION ": NORMAL: PRINT: NEW 9 REM ********************************************************* 10 LOMEM:MEM(0)+1024 20 TEXT40: DSIZE(5)=1440: DSIZE(2)=1024 25 PRINT "HARD DISK BACKUP TO d5": PRINT 30 INPUT "Enter volume: ";v 40 v=INT(v): IF v<0 OR v>9 THEN BEEP: GOTO 30 50 POKE 58343,v 54 PRINT 55 y=VPOS 56 REM ********************************************************* 60 FOR n=0 TO 1023 65 n$=STR$(n) 66 WHILE LEN(n$)<4 67 n$="0"+n$ 68 WEND 70 LOCATE y,1: PRINT n$; 75 ONERR GOTO 1000 80 BLREAD 2,n,MEM(0) 85 CLRERR 86 ONERR GOTO 2000 90 BLWRITE 5,n,MEM(0) 95 CLRERR 100 NEXT n 110 LOMEM:MEM(0): END 999 REM ********************************************************* 1000 BEEP: PRINT: PRINT "Bad Read ";n 1010 y=VPOS: RESUME 85 1099 REM ********************************************************* 2000 BEEP: PRINT: PRINT "Bad Write ";n 2010 y=VPOS: RESUME 95 1 REM restorhd5 / created 9610.12 by Richard F. Drushel 2 REM restore a 1024-block EOS volume from a 1.44MB disk in d5 3 REM note: requires SmartBASIC 1.x!!! 4 REM ********************************************************* 5 IF VER(0)>=20 THEN GOTO 10: REM we have SB1.x 6 HOME: PRINT CHR$(4): INVERSE 7 PRINT " WRONG SMARTBASIC VERSION ": NORMAL: PRINT: NEW 9 REM ********************************************************* 10 LOMEM:MEM(0)+1024 20 TEXT40: DSIZE(5)=1440: DSIZE(2)=1024 25 PRINT "HARD DISK RESTORE FROM d5": PRINT 30 INPUT "Enter volume: ";v 40 v=INT(v): IF v<0 OR v>9 THEN BEEP: GOTO 30 50 POKE 58343,v 54 PRINT 55 y=VPOS 56 REM ********************************************************* 60 FOR n=0 TO 1023 65 n$=STR$(n) 66 WHILE LEN(n$)<4 67 n$="0"+n$ 68 WEND 70 LOCATE y,1: PRINT n$; 75 ONERR GOTO 1000 80 BLREAD 5,n,MEM(0) 85 CLRERR 86 ONERR GOTO 2000 90 BLWRITE 2,n,MEM(0) 95 CLRERR 100 NEXT n 110 LOMEM:MEM(0): END 999 REM ********************************************************* 1000 BEEP: PRINT: PRINT "Bad Read ";n 1010 y=VPOS: RESUME 85 1099 REM ********************************************************* 2000 BEEP: PRINT: PRINT "Bad Write ";n 2010 y=VPOS: RESUME 95
For those of you who have never seen SmartBASIC 1.x, let me explain a few points of interest in the programs:
line 5 The VER(0) function returns an internal revision number for SmartBASIC 1.x. Under regular SmartBASIC 1.0, VER(0) will cause a default 11-element array to be allocated, all of whose elements are 0. Thus, if this statement is run under SmartBASIC 1.0, it will return 0, thus causing the program to fall into the ensuing error message code and abort. line 10 MEM(0) is a pointer to the default start of variable space in the SmartBASIC 1.x interpreter. Moving LOMEM to 1024 bytes above this pointer reserves a 1K disk block transfer area. By using the MEM(0) pointer instead of a hard-coded number (like 27407, the equivalent in SmartBASIC 1.0), I can run this program under any future version of SmartBASIC 1.x, which might have a different memory map and a different absolute address for MEM(0), and it will still run correctly. Portability of programs was a key design consideration for SmartBASIC 1.x. line 20 The DSIZE(drive) command sets the maximum valid block number for the particular drive 1-7. This value is used for range- checking the BLREAD and BLWRITE block I/O commands. DSIZE(0) sets the number of directory blocks allocated with a subsequent INIT or FORMAT command. line 50 The "magic" address 58343 is where all known versions of EOS patched for hard drives (by HARDDISK) store the current volume for the hard drive. In a future revision of SmartBASIC 1.x, I should also have a pointer to this address as a system function; but in 1991, I didn't have a hard drive system of my own, or access to one. line 55 Note that VPOS does not require the dummy argument VPOS(0) like it does in SmartBASIC 1.0. lines 66-68 WHILE...WEND is a looping construct found in many other programming languages, such as C, Pascal, and Microsoft BASIC. As long as the condition in the WHILE statement is true, it will continue to execute all the statements up to the WEND. When the condition becomes false, execution begins at the first statement after the WEND. It's possible to use an IF...GOTO constuct to perform the same function as WHILE...WEND; the demonstration of this is left as an exercise to the reader :-) The purpose of the WHILE...WEND loop in these programs is simply to make the block counter a 4-digit 0-padded number, for convenience of display. line 70 The LOCATE line,column statement does the same thing as VTAB line: HTAB column in SmartBASIC 1.0. I borrowed this syntax from Microsoft BASIC. lines 80,90 The BLREAD and BLWRITE commands read and write blocks from a drive, respectively. These were the very first two commands I wrote for SmartBASIC 1.x, and the need for them was my inspiration to attempt SmartBASIC 1.x. I *hated* all the programs from NIAD et al. that were nothing but obscure PEEKs, POKEs, and CALLs. I also *hated* having to POKE in the same machine code into every program I wrote that needed to do block I/O. "Why not have a command...?" so I made one. To do this in SmartBASIC 1.0, you'll need to write some machine code, reserve space for it with LOMEM, POKE it in, and CALL it. line 110 Putting LOMEM back to MEM(0) deallocates my 1K transfer area and puts SmartBASIC 1.x's memory map back the way it was. lines 1010,2010 RESUME can take an optional line number in SmartBASIC 1.x, thus allowing you to precisely control what happens after an error occurs. Sometimes you *don't* want to just go back and try the same thing again. If you use GOTO, you are leaving the internal error handlers in an unstable state, and the system is likely to crash. Indeed, error handling in SmartBASIC 1.0 is *completely* broken; if another error occurs inside an error handler (i.e., code after the line you ONERR GOTO), the system crashes. I'm happy to say that I fixed it in SmartBASIC 1.x.
Hmmm, this is turning into a big plug for SmartBASIC 1.x (which I hadn't really intended). The software is still available, from me direct, or from HLM-GMK. If you're interested, ask me questions and I'll post them to the mailing list. I must say that SmartBASIC 1.x has been a wonderful debugging environment for me, and has been an indispensible tool for investigating hard drives, serial communications, memory bank-switching, RAMdisks, and ultimately the ADAMserve system.
I had a few more things I'd intended to talk about this week, but it's getting late, and I think I'll save them for next time.
Just a note in closing: it's nice to see the progress/status reports from Ron Mitchell (ronaldm@mars.ark.com) and PJ Herrington (76537.1271@compuserve.com). I also have heard from some of the newer members of the mailing list. Nice job, folks, and keep up the good work!
See you again next week!
*Rich*
Next Article
Previous Article
TWWMCA Archive Main Page