Details
Double high-resolution is sometimes described as a 140x192 pixel screen with 16 colors per pixel. This point of view can be limiting. SDP II is designed to allow independent manipulation of all 560x192 pixels. The most obvious consequence is in how text appears on different kinds of displays (real or emulated). Compare the below text as it appears under two different video models:
emulated color TV
emulated RGB card
What happens is that if the video is using some sort of "idealized" model, the placement of a specific pixel only affects the color of the four-pixel bin in which it is situated. In a more "realistic" model, this same effect exists, but is blended in a complicated way with the fine-grained pixel position. For the best experience with SDP II, realistic models are better.
Video models matter for hardware too. Specialized adaptors might perform idealized conversions, and modern screens with analog inputs will usually decode the signal "too intelligently."
The above visualizations were created using the AppleWin emulator.
SDP II treats screen bits as the atomic drawing element. Another approach would be to treat color nibbles as atomic. Screen bits were chosen to allow for a wider range of visual effects. Some of the negative consequences are as follows.
- The
&HPLOTcommand will sometimes behave counter-intuitively, e.g.,&DHR: &HCOLOR=1: &HPLOT 101,0 to 101,10will show nothing. The reason is that pixel 101 does not overlap with the given color mask. - Brush strokes will look slightly different depending on the specific pixel where they begin
- Tiles that are an odd number of cells (including font glyphs) will look slightly different depending on whether they start on an even or odd column
Variations on DHRLIB can be produced using conditional assembly flags found in equiv.S. Build scripts may override some flags.
The build scripts require PowerShell 7.4 (need not be Windows), Merlin32, and a2kit. From PowerShell get to the project directory and run build.ps1. You should now have a bootable WOZ in the build directory containing everything needed.
It is assumed Merlin and a2kit are in the path. You may want to set this up in, e.g., $PROFILE.CurrentUserAllHosts.
The lowest level bounds check prevents any stores outside the screen buffer. If an out of bounds store makes it to this level the result is simply a clipped drawing.
The next level of bounds checking is cursor wrap-around. Signed horizontal coordinates work gracefully within the range -1024 <= x < 1024. Outside this range the wrapping is difficult to predict, but will still keep the cursor on screen.
The highest level bounds checks occur during ampersand parsing. Any out of bounds coordinate throws an ILLEGAL QUANTITY ERROR. If this check is active, wrapping is usually prevented.
Optimization for a given purpose can be achieved by using conditional assembly to bypass one or more of the three kinds of bounds checks.
Using graphics page 2 in double high-resolution is hard, because the buffers involved cannot be selectively switched. In particular, one has to switch the entire user space all at once, which tends to wreak havoc with the program counter.
SDP II respects the zero-page location that controls which graphics page is addressed. In particular, the screen pointer will be offset from page ($E6), just as with single hi-res. The &DHR command stores $20 at location $E6. Do not try to override this setting with the default version of DHRLIB. Painting would either be clipped by the bounds check, or else would overwrite the library itself.
The changes needed to support writing to page 2 appear to be (i) assemble DHRLIB to load at $6000, (ii) modify the paint macro to use the $C004 and $C005 switches, (iii) modify bounds checking to allow writing to page 2. The changes needed to support reading page 2 would be far more elaborate.
The original SDP, or "Super Dungeon Plot," existed in some form since the early 1980's. It was developed originally on the Apple II plus, where only normal high-resolution was available. The peculiarity of the SDP approach is that there is no facility for handling bitmaps in the picture layer. Instead, pictures are stored as drawing sequences. This can be efficient if the artist takes care to minimize the number of strokes. This was my youthful idea of compression.
SDP II saves and renders pictures the same way as SDP, perhaps for old time's sake. However it does this much better, with more efficient brushes, trapezoid fills, and bitstream encoding.
Apple II graphics are built upon the idea of spoofing an analog decoder into interpreting digital data as a picture. The decoders in question are those that were found in American color television sets (TV's) circa 1980. These decoders work by separating a primary carrier, which encodes black and white, from a subcarrier, which encodes two color channels in phase quadrature. It can be shown that the black and white signal plus the two color channels carry the same information as three color channels.
The Apple II feeds the decoder a rectangular waveform made out of digital highs and lows in order to approximate a color picture. In regular high-res, When the bits are alternated at the maximum rate, the period of the square wave matches the period of the color subcarrier. The circuitry includes a phase shifter that is used to activate one color channel or the other, depending on the high bits in the screen buffer.
In the case of DHGR, the bits can be alternated at quadruple the subcarrier frequency. This way, the phase of the wave can be directly encoded in the bit patterns. Specifically, four bits correspond to a full period of the subcarrier, so a shift by one bit is a 90 degree phase shift. Call these four bits a color nibble. Now the phase of the analog signal that the TV is expecting is fixed by a reference signal called the color burst. This absolute phase also fixes the alignment of the color nibbles, i.e., the color nibble 0001 is blue only if it is aligned. This alignment is tricky because in DHR the high bits in the screen buffer are passed over. As a result, the color nibbles are aligned to nibble boundaries only if we agree to subtract out all the high bits from the overall bit sequence.
To understand why 0001 is blue takes a bit of analysis. Thinking in reverse, we may roughly say that some superposition of the three analog channels would be needed to produce this digital waveform. Evidently this superposition corresponds to blue. This blue arrangement plus the other fifteen possible arrangements give sixteen colors.
Interestingly it is possible to get more colors out of DHR by taking advantage of the detailed characteristics of the analog color channels. See Kris Kennaway's ii-pix docs.