S'More For Commodore 64

Art Hunkins

Requirements: Commodore 64 or a Commodore 128 in 64 mode.

---

Commodore 64 owners who wish to upgrade their computers have two main options: Buy a Commodore 128 or install a S'more cartridge from Cardco. Each choice has its advantages. If money is no object (and you aren't overly attached to your 64), you might consider the 128. But the choice isn't that clear-cut. For those who write their own BASIC programs, S'more has some significant advantages of its own. Frankly, it's difficult to know which to compare S'more to-the 64 without S'more, or the 128.
    Of course, the 128 does have some things going for it: twice the available user memory (122,365 bytes) as the 64; BASIC 7.0, with powerful commands for graphics, sprites, sound, and windowing; and a FAST mode for doublespeed operation. So if it's raw computer power and extra memory you want, the 128 is hard to beat.
    On the other hand, S'more BASIC is more comprehensive than BASIC 7.0 in its utilities; it defaults to disk LOAD, offers a greater variety of input options as well as more flexible screen formatting, and includes varied reset options. The built-in utilities are a real boon: MERGE, AUTO, HEX, DEC, FIND, CHANGE, reNUMBER, DUMP, and OLD-all familiar to BASIC AID users. The LIST command can scroll up and down, not true of BASIC 7.0. On the 128, only AUTO, RENUMBER, and a disk file APPEND are implemented.
    Compared to the unenhanced 64, S'more frees up 57 percent more user memory-61,183 bytes instead of 38,911 bytes. The memory is contiguous and can be used in any way you desire. (As we'll see, there are other protected locations where machine language routines up to 512 bytes long may be stored.)

Improved Disk Commands
S'more BASIC and BASIC 7.0 come out about even when it comes to disk commands (a notable weakness with the unexpanded 64); only the approach is different. Whereas 7.0 gives a wealth of specific commands, S'more uses only one-DISK, an all-purpose "wedge" followed by the traditional disk access symbols. Both BASICs also offer numerous enhancements of standard commands (such as a RUN that LOADs and RUNS a BASIC program from disk). Both permit the SHIFT-RUN key combination to LOAD/RUN the first program on disk.
    Both BASICs offer about the same range of programming structures (DOLOOP, WHILE-UNTIL, IF-THEN ELSE). Both implement error-trapping and HELP, and both have programmable function keys, though 7.0 sets aside almost twice the buffer (246 bytes versus 128) for key definitions.
    S'more is also handy in that its LOAD and SAVE commands default to disk (there is no DLOAD or DSAVE), and that it includes a disk CATALOG/ directory option. In fact, due to the way the disk default option works, you can display the CATALOG, cursor to the program you want, type LOAD (or RUN), and hit RETURN-without worrying about what is displayed after the program name.

ML Limitations
For BASIC programs, S'more is superb. But let's look at ML applications. Here the picture is not so clear.
    Although S'more has a MONITOR command, it doesn't have a built-in monitor; MONITOR just links you to a monitor if you've loaded one into memory. S'more comes with a disk of software that includes a version of Micromon called Smon. (Other programs on the disk illustrate applications of the more noteworthy S'more BASIC extensions.)
    Cardco's manual is thorough, clear, instructive, and particularly forthright when it describes S'more's limitations with memory addressing and machine language. Here's the catch: To make so much contiguous BASIC memory available, Cardco had to change a lot of memory locations and reconfigure memory. Cardco did what it could to maintain compatibility with Commodore 64 BASIC (BASIC 2.0), but there were limits on what was possible.
    It's remarkable that low memory with S'more is so highly compatible with BASIC 2.0. Only two differences will be noticed by the average programmer. First, and most importantly, the cassette buffer has been moved. ML programs designed to reside there will have to be transported to the new location. Also, some of the previously free bytes (which you may have used for flags or temporary data storage) are free no longer (zero page 251-254 remain available, however). There is a bonus, though-a 512-byte RS-232 input/output buffer, protected from BASIC, which can be utilized for ML routines in most cases.
    The most critical low memory locations for the BASIC programmer, the keyboard buffer and its corresponding character counter, remain intact. As the manual clearly states, however, ML routines that access ROM are in for major rewrites. The only ROM routines that are safe to use are the Kemal routines when they are accessed through the vectors in low memory (these vectors are unchanged in location). You cannot access ROM subroutines directly. This is a problem particularly with the SID, VIC, and CIA chips-that is, when working directly with screen, sound, and input/output peripherals.

The S'more Solution
To get around these limitations, the manual suggests that perhaps most ML routines are best written in S'more BASIC, then compiled with the (not-yet-released) S'more BASIC Compiler. This suggestion indicates the degree of potential difficulty in converting most ML programs for use with S'more.
    But there's another alternative, too. S'more establishes a set of CIA, VIC, and SID reserved variables (DIMensioned arrays). Each variable corresponds to a CIA, VIC, or SID chip location you might wish to PEEK or POKE. To POKE the location, just assign the variable the desired value; presto, the POKE is done. To PEEK the location, just use the reserved variable in an expression. It works fine and is simpler than actually PEEKing and POKEing. For sound and the SID chip, for example, it is not too far from the convenience of using BASIC 7.0's new sound commands (PLAY, FILTER, ENVELOPE, etc.)
    Of course, this technique works only from BASIC, not machine language. There are times when, for speed and efficiency, ML is required. Although conversion of ML routines accessing the support chips is possible, it is apparently far from trivial. (The manual does not attempt to explain; it only hints that RAM/ROM bank-switching is involved, and that the banking system is similar to that of the Commodore Plus/4.)
    There is but one other limitation I've noticed with S'more. When writing or editing a BASIC program, the enhanced BASIC often responds slowly, particularly with long programs. The cursor can take 1.5 to 2.5 seconds to reappear after you hit RETURN to enter a new line; it takes longer toward the beginning than at the end of a program. On the other hand, garbage collection purportedly is speeded up dramatically over 2.0 BASIC.

Works With 128, Too
These are the only problems I've experienced working with the S'more cartridge. Overall, S'more maintains a high degree of compatibility with BASIC 2.0 (and its associated memory configuration), offers more than 50 percent additional memory accessible to BASIC, and a greatly enhanced language. It makes working with the screen and sound a simpler task for BASIC programmers.
    In short, S'more is a cost-effective alternative to a Commodore 128 upgrade. (Cardco's literature describing S'more as a "bridge to the 128" is on target.) And even if you do decide later to acquire a 128, S'more works identically on the 128 in 64 mode.

S'more
Cardco, Inc.
300 S. Topeka
Wichita, KS 67202
$69.95