WRX 16 Hi-Res for the 1000

For several years, ZX81/TS1000 owners have dreamed of a simple bit-mapped high-resolution system for their machines. The quest began with the appearance of “software-only” high-resolution packages, which offered an improvement over the crude 44×64 block pixels, but left much to be desired regarding precision and ease of use.

Several manufacturers came out with hardware add-ons that provided true high resolution displays. Memotech’s HRG modified the existing Sinclair “cheap video” approach, and represented the first viable alternative. Later, two different designs (John Oliger and Kolorworks) employed the Texas Instruments video display processor to add high-resolution color to these machines. All of these require substantial additional hardware, making them relatively expensive. Furthermore, software support for at least one of them (the Kolorworks) is practically non-existant.

More recently, Gregory C. Harder discovered that the TS1500 is capable of true bit-mapped displays. Unfortunately, we haven’t found a way of making this system work on the ZX81/TS1000. Also, the inability to set every eighth horizontal bit compromised this system’s usefulness for some applications.

Finally, almost five years after the introduction of the ZX81, a TRUE bit-mapped high resolution package has been developed, using minimal additional hardware. Would you believe that with nothing more than a CMOS memory board (such as a modified “Hunter” board) you can now have 256×192 bit-mapped displays? Believe it! WRX16 HI-RES is here! (WR=Wilf Rigter, “x16” is the degree of resolution improvement.)

WRX16 HI-RES was developed by Wilf Rigter with the ZED Team, a sub-group of the Vancouver TS User Group, consisting of Mr. Rigter, Dave Ross and James Horne. It has been extensively tested; in fact, if you bought “SINC-ARTIST HR” from Weymil Corp., you’ve already seen the spectacular displays that this system can give.

Before we get on with the details, here is a summary of the advantages of this remarkable software:

• 256×176 resolution, expandable to 256×206 (26 lines). ALL bits may be set/reset.
• A single POKE instantly reverses any of the 32 columns; a short machine-code routine instantly reverses the entire screen. Software-only video reverse!
• The high-res display file does NOT require stop bytes at the end of each display line, as does the standard Sinclair video or any of the other software-only hi-res packages. This considerably simplifies bit computations. Furthermore, you CANNOT crash the system by POKEing illegal codes into the display file.
• Easily adapted to fill entire screen (to 26 rows), or leave the bottom two rows avail- able for standard video (allowing INPUT, report codes, and BASIC command or program line entry).

Suddenly, the door is open to all the projects we have so far only dreamed about; 40+ columns, “what you see is what you get” word processing, CAD, $100 “MAC-alikes,” and on and on.

The key to the system Is a succinct 76-byte algorithm, presented in this article, which utilizes the built-in display and memory refresh facilities in a novel way. This routine creates the hi-res screen, which can be POKEd, scrolled, inverted or blanked out with all the ease of a true bit-mapped display.

Hardware Requirements

As stated, the hardware requirements for running WRX16-HR are minimal. Most of you already have what it takes. The CPU must be able to activate all 8 low address lines during the refresh cycle, instead of the conventional 7, and 8K of static RAM is required to store the hi-res display file.

Although most TSIOOO’s have been supplied with a suitable CPU, some of the ones we have encountered have not. Suitable CPU’s are, however, readily available at low cost. You’ll know that you need a different Z80A or Z80B if every eighth horizontal bit is missing.

The 8K static RAM is mapped in the 8-16K address space for simplicity and convenience. Note that this must be STATIC RAM; dynamic RAM (such as used by 64K RAM packs) will not work. This is because this hi- res system relies on being able to fetch the video data during refresh time. On dynamic RAMs this is not possible; you must therefore arrange for 8K of static RAM in the 8-16 K region.

The NVM circuit published in the last issue of SWN will work with no changes whatever. So if you’ve put off building this, here’s a good reason to get out your soldering iron and go to it.

Another possibility is the ubiquitous “Hunter” NVM board. However, you will have to make a slight modification to make this work properly. The Hunter board uses the RD NOT signal to control the OE NOT pin of the CMOS RAM chips. As a result, the contents of RAM are gated onto the data bus only when RD NOT goes active low. However, during refresh time, the CPU holds RD NOT high, making it necessary to OR the RD NOT and RFSH NOT signals.

Such an OR circuit can consist of nothing more than a IN 4148 diode and a 4.7K resistor. Cut the trace connecting RD NOT (edge connector pin 16 A) to the RAM pins 20. Bridge this gap with the 4.7K resistor. Connect the diode with its cathode towards RFSH NOT (edge connector pin 23 A), and the anode to the RAM OE NOT pins (pin 20; the RAM end of the new resistor).

The only known software which is adversely affected by this modification is TS1500 HI*RES and packages (such as DUNGEON OF YMIR V1) which utilize this. If you plan to run this type of software, install a switch in series with the diode so that the modification can be switched out.

Also see the “Support” section of this article for information on static RAM parts kits, if you want to “roll your own” but don’t care to hassle with parts acquisition.

Finally, a functional equivalent to the “Hunter” board, with additional features, is being jointly developed by Larken Electronics and Silicon Mountain Computers. This will support both types of hi-res software with no changes.

The only other hardware requirement is that the 48- 64K region NOT be decoded. This precludes the use of 64K RAM packs, since this hi-res system relies on the 48-64K “echo” of the 16-32K region. It is conceivable that this restriction will be overcome, but at this writing a satisfactory fix has not been worked out.

And that’s it! Nothing more is required, except of course the all-important software. In fact, the principles of the system can be demonstrated with a completely stock, 2K TS1000, albeit with reduced display size, minimal user friendliness, and some fiddling with the software.

TS1500: These routines will only work on the TS1500 if a 16K RAM pack is installed in addition to the CMOS RAM. Why this is, is unclear at this writing.

The Core Routines

Once you have your hardware properly set up, enter the core routine. Start with a 1 REM statement, 128 bytes long. (Type 1 REM followed by 128 X’s or other character.) While you’re at it, enter a line 2 REM of 104 bytes, and a line 3 REM of 148 bytes, which we’ll fill later. Then enter the loader program of (lines 9000-9991 of Listing 4), and RUN 9000. Enter 16514 for “START” and 128 for “BYTES.” Now enter the decimal values of Table 1, or use an assembler or Hot Z to enter the hexcode / mnemonics of Listing 1.

Theory

This section is not essential reading if you only want to experiment with the WRX16 HI-RES core. However, we recommend that you do read it through at least once. Even if you don’t understand it all at first, you will probably pick up quite a bit of information about this unique type of hi-res specifically, and about “cheap video” in general.

Entry from the Sinclair Operating System (SOS) is made by first calling “HRES”, a short routine located at 40F4h. There, the IX register is loaded with a jump vector pointing to “DPLY”, the entry point located at 40A8h.

When the SOS next encounters the JP (IX) instruction, program control is transferred to the HIRES routine instead of the normal one residing in ROM. This occurs 60 times a second during the NMI service routine.

Part 1 of the Hi-Res routine initiates the main display loop. The maskable interrupt is disabled, the hi-res screen is centered, its vertical and horizontal size is set, and HL is loaded as a pointer to the start address of a 6K memory block reserved for the hi-res display file.

Parts 2 and 3 make up the main display loop. Timing is critical because the routine must trigger the ULA at precise intervals so that it, in turn, will produce line synchronization signals at appropriate intervals.

Part 2 keeps track of how many lines are left to do. If the display has been completed, a jump is made to Part 4, the Exit routine. Otherwise, the various registers are updated. The line start pointer is incremented by 32d, and the line count register is decremented by one. Finally, the start address of the next display line is loaded into the I and R registers.

In Part 3, a jump is made to the high-memory echo of a 32 character dummy display file, DUMY. There, the display facilities of the ULA are triggered and utilized as explained below. Refer to Mike Lord’s “The Explorer’s Guide…” for background on how the ULA operates.

1. The ULA is triggered into the display mode whenever address line A15 is high during an instruction fetch cycle (Ml). The HI-RES software achieves this by way of a jump vector pointing to ECHO, the high memory phantom of DUMY. This method is similar to the one used in the SOS display routine.
2. On being triggered, the hardware swings into action. It generates a line sync pulse, and pulls the data lines low on each Ml cycle. The microprocessor “sees” the 00h NOP code, so for 4 T-states does nothing except feed the R and I registers’ contents onto the address lines during the refresh cycle. It then increments the R register, and fetches the next dummy instruction. This process is repeated to the end of DUMY, where a jump instruction transfers control back to Part 2, completing the loop. This jump is made to its true address, so line A15 will no longer go high, temporarily suspending the ULA’s display activities. This process is repeated until all lines have been displayed.
3. When in the display mode, the ULA forces levels onto the address lines which normally address the font tables resident in ROM. Since the HI-RES screen is mapped elsewhere in memory, this action has no effect.
   Instead, with the contents of the I and R registers applied to the address lines, memory locations in the HI-RES display file are accessed, and their contents applied to the data bus.
4. During the refresh cycle, the ULA loads these bytes into an internal register. From there there are sent serially to the modulator for display.
5. During the Ml cycle, the ULA monitors data line D7 and if high, inverts the video data. For a normal display, characters of the dummy display file are set to 00h. When set to 80h, they serve to invert the display column by column.

As mentioned above, Part 4 of the routine is to return to the SOS after completing some housekeeping chores.

S.O.S. Return

To restore the normal display facilities, “NRML” (a short routine located at 40F9h) is called to restore the IX register to point to the usual ROM-based SOS display routine. The I register is also restored so that it points to the proper font table base address in ROM.

Modifications

As shown, the core routine gives 176 HI-RES lines, leaving the bottom two rows (16 lines) open for the usual error reports and INPUT lines. To change the number of HI-RES lines to, say 192, change the command at 40B4h to LD B,C0. Note that this will still keep the two input lines at the bottom, for a total of 26 lines. This might cause some TV’s or monitors to spill off the top or bottom, and furthermore slows down machine operation slightly because of the additional lines displayed during the interrupt.

If you don’t need the standard-video input rows at the bottom, replace the CALL 02 B 5 at 40E4h with NOPs (00). In principle, you could increase the number of HI-RES lines to 206, with LD B,D0 at 40B4h.

Making these or other changes might mess up the timing enough to visibly displace the HI-RES screen. You can trim this with the commands at 40A9h (“coarse”) and 40AFh (“fine”).

Some Service Routines

Now that you have the core routine installed, how can you use it? In principle, at least, anything you could wish to do could be accomplished using BASIC. For example, to reverse a single column, POKE (16517+N),128 where N is the column 0-31. To restore it to normal, POKE it back to zero. Similarly, you can POKE anywhere in the HI-RES display file to fill any desired byte (row of 8 pixels) with the desired pattern.

Other operations however, such as clearing the screen, printing and plotting, would be painfully slow in BASIC. Such jobs require machine-code routines to be useful. Listing 2 shows a few rudimentary routines (by fn) to CLS, PLOT, UN PLOT and REVERSE. Use the loader (START=16648, BYTES=104) to enter the values of Table 2 into your 2 REM statement. To use PLOT or UNPLOT, first POKE 16438 with the desired X value (0-255) and 16439 with the Y value (0-176, or higher if the core was suitably modified.) Though this is a very “bare-bones” operating system, it is capable of neat displays, as Paul Bingham’s “CRATER” program in Listing 4 demonstrates.

The last routine (Listing 3) is a machine-code “Mandala” program to demonstrate the kind of speed that can be achieved using machine code PLOT and UNPLOT. Use the loader (START=16758, BYTES=148) to input the values of Table 3 into your 3 REM statement.

Finally, enter the rest of the BASIC DEMO lines of listing 4. Run the program. Briefly touching a key during the Mandala portion reverses the screen.
Press BREAK to exit, then CONT to run the Crater portion. It pauses after every line so you can see how it’s progressing. Pretty neat, eh what?

Conclusion

We believe that the WRX16 HI-RES system removes the final obstacle to a more widespread acceptance of the TS1000. Dave, Jim Horne and myself are committed to developing this to the fullest, and will continue to work on user software and hardware enhancements. “In the wings” are at least one comprehensive Extended BASIC utility. Options will include easy plot, unplot and complement pixels; DRAW lines, circles, and other shapes; sprites; smooth (bit-wise) scrolling; upper/lower case, mixed text/graphics, and a form of windowing, to mention but a few possibilities. The goal is to provide a complete system that outperforms similar hardware-based schemes at a fraction of the price.