The Memotech WP “Memotext” is the best one I’ve seen for the ZX81/TS1000 to date (and as of Thanksgiving, 1984, still is-ed.); after owning one for some time I can’t imagine life without it. Unfortunately, Memotech only provides the bare minimum of documentation and support needed to get your system working; there is little or no material available that delves into the fine points of the Memotech devices (specifically, CIF/SIF and Memotext). So here are some comments, observation and other info which might help you get the most out of the Sinclair/Memotech system.
First off, there’s the hardware aspect of these units. Memotech took the liberty of taking over the operating system quite completely, and you can run into problems if you use other than Memotech 32-64K RAM packs, with their ROM-based decoding scheme. With 16K packs there is generally no problem, since there’s no possibility of conflict in the 8-16K range. But even if your 32K-up pack allows you to turn off this range, some inexpensive 64K RAM packs still won’t work; you might turn off the 8-16K range, install CIF and PEEK the 10-10.5K region to find the conversion table and IF program where it should be; but the printer simply won’t print, or the system crashes. Your best bet in such cases may be to get a different 64K to replace it. If you’re not interesed in paying Memotech’s price for their 64K, read on!
Now for some good news, The 64K RAM board by John Oliger (see review) works fine with the CIF/Mtext combo, The bad news is that, as assembled per instructions, the board won’t work with CIF alone (useful for dumping older BASIC files, LLISTing programs, graphics, etc.) The good news is that this is easily corrected on most machines by inserting a 1N914 diode in series with the ROM CS NOT line (pin 23B) to the RAM, anode end toward the RAM.
Another hardware oddity is the switch on Memotext. The manual implies that it must be ON for Memotext to work, but doesn’t delve into much detail. Basically, when you flip the switch ON, the M/text program is engaged but you remain in BASIC until a key is depressed. Memotext then takes over and initializes the WP. Once in, there’s no way to exit or return to BASIC.
A highly recommended addition to your 32K-up machine is to install a RESET switch (a momentary contact push-button, normally open, connected through a 100 ohm resistor between CPU pin 26 and ground, i.e., across capacitor C5). If you have a Hunter board you already have a reset switch (yet another reason to get one). Hit the reset button at the same time as you turn off Memotext, and you’ll restart the computer (and clear the 16-32K range) while leaving the other ranges alone (i.e. where you keep your vital utilities, other files, or whatever).
This “auto-boot” feature makes it rough to disassemble the program if you’re interested in such things. Tom suggested a way of doing this: Generate a REM statement as long as the length of code you want to examine, then write a loop to POKE the values from the 8-16K block into the REM; precede the loop with a PAUSE 300, and place a PAUSE 4E4 (pron, “forever”) at the end. Run the program in FAST mode, and during the first PAUSE flip Memotext on; the loop will now work, since you haven’t pressed a key since turning Mtext on. When done, the screen will go white again, (pausing 4E4) and you may turn M/text off, then BREAK to get into your program. You now have the desired code in your REM statement, whence you can SAVE it for later disassembly.
A much easier way is to simply LOAD HOT-Z II (16K “version”), turn Memotext on and wander about in the 2000h-4000h (8-16K) range to your heart’s content. HOT Z II is such a “universal solvent” that it maintains control even over the built-in “Memotricks” in disassembly mode, but my meager efforts at single-stepping have left my machine in knots. When leaving HOT Z II (shift Q) you will return to BASIC if the switch is off, or to Memotext if it’s on.
Memotext automatically appropriates all of available RAM, regardless of your inital RAMTOP setting. However, if you’re careful not to fill up your RAM beyond, say, the 32K mark (16K of text), you can store other “goodies” (e.g. Hot Z) in high memory; when you hit the reset button to escape Memotext, the goodies will still be there except for the very top where Memotext places the machine stack. (In the original SWN 1:4 I incorrectly reported that M/text doesn’t mess with RAMTOP; if any of you have had trouble as a result, so sorry. In the RAM-~-based version I’ve worked up, this oddity has been eliminated, and you can either use all of available RAM as supplied, or else make M/text respect your RAMTOP setting.)
Now, some comments on the software and hints on using it. One valuable tool sometimes overlooked by beginners is the “extended cursor movement” (fast scan) which flips through your text a screenful at a time. E.g., if you’re looking at the first screenful of a long piece of text, shift “3” shift “6” shows the next screen, starting with the last line of the first screen for continuity.
When writing several different text files holding a control sequence in common, you can SAVE the control sequece only, then LOAD it whenever needed; rename it after loading, and you’ve saved yourself re~typing the sequence. Example: when originally writing this newsletter, an article usually started out by setting character width to 1/10″, page width to 65 characters, line feed to 1/6″, enhanced mode, and expanded characters for the headline. While I’ve gotten pretty good at typing these controls as needed, I could have saved some time by saving the most often used sequences, (e.g. “PICA”, “ELITE”, etc.) then load text file PICA and rename it “ARTICLE” and then amend text file “ARTICLE.” The next file might be an editorial, so I’d load “ELITE” and rename it “EDITORIAL.”
Now, a few words regarding speed. While it is indeed almost impossible to out-type when your current typing line is near the top of the screen, things slow down as the screen fills and takes longer to print each time. The faster you are as a typist, the sooner you’ll notice the slow-down as the screen fills. There is an easy fix. As you’re typing along, when you get about 2/3 of the screen filled, hit shift “3” shift “6” (forward fast scan) and your current position is relocated at the top of the screen, and you may resume full-speed typing. If you wish to see the last couple lines of your text, shift “7” as required, then shift”6″ (and shift “8”) to get the cursor to the desired typing position. When inserting text during editing, use the cursor control keys to put the cursor near the top of the screen for optimum speed. Things get kind of slow in this mode anyway, particularly if there is a large body of text after the current cursor position. In such cases you need all the speed up you can get and will find it worth the trouble to figure out how to get the cursor to the top of the screen when typing.
I don’t need to belabor the convenience of the other extended (prefaced by shift 3) commands; finding/exchanging/moving, blocks of text. The only problem is that it only works within a given file, ie., you can’t exchange text from another file. You can simulate some of these features with clever tape recorder use as described above, but in general you’ll just have to grin and bear it. Another thing that would be nice is if data files could support control codes; the closest thing to this is the HINT on page 14 of the manual, using dummy strings for your controls and then using the exchange function to stick in the actual control sequence.
I got a couple requests for data on what areas of memory are used by CIF and Memotext. CIF uses the 10-10.5K area (10240 to 10751 or 2800h-29FFh). Memotext takes up 8-10K AND 12-16K (2000h-27FFh and 3000h~3FFFh), The 10.5-12K area is not used at all (not even for paging the hardware as previously suspected), The Sinclair-ASCII conversion table for CIF is at 2800h, the table for Memotext is at 3000h. (This is necessary because Memotext reverses the cases), ONE SMALL PROBLEM: when Memotext is used, the apostrophe ‘ is re-defined. When using the CIF table, the apostrophe is the inverse colon (graphic shift Z); but when using Memotext, the apostrophe is on inverse comma (shift Enter shift comma) and the inverse colon is redefined as the reverse apostrophe. As a result there were a lot of reversed apostrophes in issue 3, left over from before we found out about it (and broke our habits). Again, Memotech was of no help. The CIF manual even has a typo for this, showing the apostrophe as being on “inverse apostrophe” (Say again?)
For those of you who haven’t figured out how to get the control commands (edit U) to work, have no fear; it’s really quite simple. Much like the “back door” in CIF, which allows us to send ASCII code in a 1 REM statement, the edit commands can be used to send characters or control codes. Example, to send a capital “X” use edit U 58 edit U (58h=88d=ASCII code for “X”), Similarly, edit U 0E edit U will send the control code for double width printing (SO). This takes care of the Group I controls and all available characters (see last issue). Group II controls are just as easy, just preface the command with 1Bh or 9Bh (27/155d = ESC). Example, to set 12 CPI on the Gemini use editU 1B 42 02 edit U (ESC B 2 – same example used on page 12), One minor bug is that characters (but usually not controls) sent in this way screw up the justification by the number of such characters on the line. We haven’t found a good way around this, the closest I’ve come is to add dummy characters (such as apostrophes) after the last word on such lines, then use good old “wite-out” to remove them later. (A good way to accomplish this is to double type a letter in the same line and follow it with an editU 7F editU. Essentially, you are adding and deleting in hex, and the word processor never counts it. ed.) Also, you can’t put more than 9 such characters in any one line; the system crashes if you do. If you have a lot of special characters on a line, the only way to send them successfully is to put the ENTIRE LINE in hex code between editU markers. This is a pain, but the only way I’ve found. (Thanks to Cedric Bastiaans, who ran into this problem and made me come up with a solution.)
Well, that’s about all the space I can afford for this. Further discussion of the M/text system is reserved for Volume 2, where I show you how to run M/text in RAM to get rid of some of the annoyances.