I’ll start out the software part of the reviews with a package you may have seen the ad for and been a little leery of: a software-only high-resolution program for the ZX81 that sounds too good to be true. After all, how could it possibly do the same thing as those $100 add-ons that turn your TV screen into a map of, say, 256 by 176 pixels? What do you REALLY get for your $20; another hyper/meta/supergraphics curiosity, or can you actually do something with it? Well, to make this review a real cliffhanger, let me answer that with a definite “that depends.”
Before I go any further, I should give a brief description of how it works and what options this program allows. The first routine that you eall after LOADing makes space in the program and inserts a line 3 REM statement some 5800 bytes long. This becomes the high-resolution display file, and consists of 174 lines of 32 characters, each terminated with an end-of-line marker. The whole program with display file takes about 7.6K, so you have only about 8K for your programming in 16K.
Since all of the routines are defined as BASIC variables in the basic demo supplied, you can just delete the demo part of the program and keep the variables definitions to make it easy to use the program from BASIC, So to get into hi-res mode, RAND USR HRDF and to get back to the normal display file you RAND USR DF, You can have information in both “screens” at the same time, and toggle back and forth at will (and impressively fast) from within a BASIC program. Unlike the normal display file, the HRDF isn’t cleared when you enter an immediate command (a nice feature during debugging). Programs will run fine in either high or low res mode, as long as they don’t mess with system variable D-FILE, NXLINE, or some other things. You can PLOT or UNPLOT on a 174 by 256 grid, DRAW individual line characters, (“characters” that are 1 bit high and eight bits wide), PRINT standard ROM characters to the screen, and PRINTC, which allows you to make your own custom 8-by-8 bit characters. Yes, “sprites” (though I use that term loosely) on a ZX81 with no extra hardware. You can also scroll up, down, left, right.
Ah, but wait; the PLOT thickens. You can’t just plug this into your application program and mess around for a couple hours and have something that “looks like IBM.” For one thing, the hi-res representation is not perfect, being derived from available ROM patterns; not all combinations are possible, and the program gives you the closest pattern it can. So pixels will be in the wrong place or missing sometimes, Also, characters won’t quite come out quite like you defined them; you have to get practice and experiment to get a bit pattern that looks good for a given starting line (though you can print the characters vertically at any of the 174 positions, they look a little different -at each of the eight starting lines in each “normal” line). Continuous PLOTs sometimes look raggedy, but can be substantially improved simply by running the plotting loop several times (4 repeats usually is the most that will result in visible change). But the final product, “doctored” or not, looks better and conveys more information more pleasingly than the 44*64 block-graphics of the ZX81 ROM. The exception is the standard ROM characters, which have a decidedly “funny” look (though they’re usually quite readable).
The PRINT routine works like this; you POKE the X and Y positions, then you put your PRINT string in a REM statement (without quotes) and follow by RAND USR PRINT. this works fine for the usual legends, etc., but it won’t print strings or numeric variables, There is a way to do it (not covered in the docs), but involves messing with NXLN from machine-code; you have to convert any numbers to strings, then POKE (or LD) the string into a predetermined “buffer” such as a REM statement or BASIC variable before calling your subroutine to set NXLN and call PRINT.
Another drawback is, if you’re using the program entirely from BASIC. Though you can draw circles, etc., and can use FAST mode if you have to, it seems to take 4E4 to plot the DEMO display, or any other pure-basic attempts. Don’t forget, you’re plotting eight times as many points, so it takes eight times as long to fill a given length of screen, 64 times as long to fill a given area using PLOT. ALSO, PRINT and PRINTC are slower than the usual PRINT statements. But: if you call the HR routines from machine code, the result is quite impressive indeed. I wrote a few routines to draw axes, markers, and the like, and draw in a graph of some externally obtained data (voltage vs. time), and the whole show happens in a couple seconds, including data scaling, over-range checking, and plotting routines. Plotting a line across the screen is actually faster than calling the standard ROM PLOT/UNPLOT routines! So, if you’re excitedly getting into assembly-level machine code, this is an ideal package for you to work with; you’ll find tearing into it as challenging as any adventure game. But if you’re mainly interested in dressing up your BASIC programs, you might be a little disappointed by the slowness of the result.
But assuming you can assemble your own graphics routines (see Harry Doakes‘ series in SYNC for some neat routines you can adapt to this, and expand from) this package, after some work of your own, can impress the hell out of people who will be looking around for some mysterious black box, since “everyone knows you can’t do hi-res with the Sinclair’s limited hardware.” The fact that it was done is quite an impressive feat, and it is no surprise that the programming is somewhat unorthodox. In a sense, it’s a “dancing dog” program, but this particular pup can dance, pretty durn good, It does some funny things with the stack, messes with system variables like D-FILE, NXLN, and others, and jumps to “hidden” entry points. Don’t EVEN attempt to make sense of the program without HOT Z, preferably HOT Z II, so you can make changes easily; some of the code could be optimized, the package to date appears to have some rough edges which should settle out as time goes on. Example: the CLS routine scrolls the display up; very slowly. With some experimentation and thought it isn’t too hard to write a fast and “neat-looking” CLS by filling in the 21-3/4 lines of 8 smaller lines with the right values for a clear screen. (No, they’re not all zero and not all eight lines the same.)
I have spent a great deal of time with this program and HOT Z II in an attempt to re~locate the SHR program and display file into the 8-16K area. Even after getting past the “traps” and other oddities, and even with the help of HOT Z’s potent “RELOCATE” command, I haven’t had any success yet, Though I can move the display file around in the 1632K range, something hangs up when it goes “downstairs.” Hopefully someone will break this barrier, as it would free up enough space for BASIC and machine-code applications programs of reasonable complexity. It would also allow EPROM versions, say in a Hunter board with the EPROM in the first slot and CMOS RAMs (for the display file, variables and program data) in the other three. What do you say, Nissim?! How about re-writing it into a Hunterboard-able version?
Is this program something for you? If you’re interested in the highest possible accuracy, you may not be too happy; you might get more out of Russell’s HRP package (reviewed last issue) which gives you an exact bit pattern (albeit only on the printer) and includes point-to-point plotting which is very often useful in scientific work, Although Nissim’s SHR has a COPY to printer option, you get the same distortions on the printout as you have on the screen, If you really need “the mostest” you should maybe pop for a hardware add-on such as Memotech’s HRG or (better yet) JLO’s TI video upgrade board, But if you’ll settle for “semi-hi”res, this one will do it for you. Some pretty radical games could be written around this program, perhaps with the help of a compiler. For math, technical and other serious work, it can serve quite well to increase the information density of your graphs when coupled with machine-code “drivers” for speed, What do I think? I recommend it highly. Even though it’s hard to disassemble, being riddled with protection schemes, it has proved a fascinating subject for study and experimentation. It is, after all, a “first,” and a certain raggedness is to be expected of all major new releases. It is certain to undergo further evolution as the author and users discover refinements. Order from Nissim Elmaleh, 5100 Highbridge St. 53, Fayetteville, NY 13066 Cost: $20 + $1 S&H.
By the way, Nissim Elmaleh also has a high-res machine~code driven word-processor program ($25), that actually gives you lower-case letters on the screen! Again, they’re a little off-beat looking, but they’re definitely lower-case. Interestingly, the distortions don’t show up in the printed output (TS2040 only at this point) which looks as good as either of the other major software-only wordprocessors on the market. You can print various ways, and enough options are provided to make it a usable tool for TS2040 purposes,