This is an article scanned out of the October 1982 Softalk magazine. It was posted to comp.sys.apple2.programmer newsgroup by Paul R. Santa-Maria. I added links and made it display nicely in a web browser (looks good in Netscape and Internet Explorer.) Paul posted gif's of figure 1 and 2 and I added them to this page.
Have an Apple Split
by Bob Bishop
Softalk, October 1982
[This is a plain text file but I have used HTML codes to indicate
italic and boldface.]
Have you ever wanted to create a display with both lo-res graphics and
hi-res graphics on the same screen? Or graphics with more than just four
lines of text at the bottom? Or how about text with four lines of graphics?
As we all know, the Apple II has only five display formats. It can display
all lo-res graphics, all hi-res graphics, all text, lo-res with four lines
of text at the bottom, or hi-res with four lines of text at the bottom. The
latter two formats are sometimes called mixed modes because they allow, in a
very restricted way, the mixing of graphics and text. But, according to page
12 of the Apple II Reference Manual, "There is no way to display both
graphics modes at the same time." Well, not only are there ways of displaying both graphics modes on the same screen, it is also possible to display
any combination of modes!
The technique of mixing display modes by the process of screen
splitting is familiar to programmers who've used the Apple III, the Atari
400 and 800 machines, and several other computers. These machines contain
special hardware that helps detect what is referred to as vertical
blanking and horizontal blanking. What is not generally known is
that the blanking can be detected by the Apple II, even though it lacks the
special hardware found in those other machines.
Example Program. Before jumping into a technical discussion of the
hows and whys of screen splitting, let's look at an example of screen
splitting on the Apple II. Listing 1 and listing 2 present a short Applesoft main
program and a machine language subroutine that the program calls.
Take a few moments now to turn on your Apple and enter these two programs.
Don't worry if you don't understand machine language. Just go into the
Monitor from Basic by typing call-151 followed by the return key. Then
start typing in the hexadecimal values for the listing 2 subroutine that
starts at $0300:
300:8D 52 C0 A9 E0 A2
and so on followed by the return key.
Now run the Applesoft program. What do you see? (Nothing, if you didn't type
in the listings correctly.) You should see a text message in the top half of
the screen and lo-res color graphics in the bottom half. This is a display
mode that's supposed to be impossible to create on a standard Apple II
To understand how to do screen splitting on the Apple II, you must be familiar not only with 6502 machine language but also with how the Apple maps its memory onto the display screen. (The latter information can be found on pages 14 through 21 of the Apple II Reference Manual.) The essence of what we need to know about hi-res in particular is shown in figure 1. Each line of the display is forty bytes long from left to right, and there are 192 such lines from top to bottom. The memory mapping seems somewhat haphazard: consecutive memory locations don't map onto consecutive lines of the display. Finally, for each set of 128 bytes of display memory only 120 bytes (three lines' worth) are displayed. The remaining eight bytes of the 128-byte set are never seen and are therefore sometimes referred to as the "undisplayed" or "unused" bytes. These undisplayed bytes all lie, conceptually, just off the bottom right-hand edge of the display, as shown in figure 1.
Text and lo-res both map in a way similar to hi-res, except that each cluster of eight lines now comes from one set of forty bytes instead of eight sets, and instead of the screen buffer being located at $2000 through $3FFF it lies at $0400 through $07FF. (Compare the Apple II Reference Manual pages 16 and 18 with page 21.)
Some Preliminary Insights. Let's try a few experiments that might give us some clues as to how screen splitting can be accomplished. From Basic type the command call -151 (followed by return) to get into the Monitor. Next, clear the screen by issuing the escape--shift-P sequence. Now type C051 followed by return. (Hitting return will always be assumed from now on.) The computer will probably display:
(If it doesn't, try typing C051 again.)
Typing C051 from the Monitor is the way to turn on text mode if the computer is displaying graphics. But since we're already in text mode, nothing much happens--nothing much except that the contents of $C051 are displayed. But $C051 isn't supposed to be a readable address; it's merely a screen switch. So what does it mean for $C051 to contain $A0? Is it just a coincidence that $A0 is the hex code for an ASCII blank, and that most of the screen is also blank? What would happen if we typed C054? Or C056? Again, we tend to get SA0 if the screen is mostly blank.
Let's try another experiment. Again from the Monitor, type:
C050 C053 C057
You should see some vertical hi-res lines with space for four lines of
text at the bottom of the screen. Now type C050, or C053, or
C054, or C057. Most of the time we now see $73 in the screen switch locations, and once in a while we see $A0. (Remember that the bottom four text lines on the screen are mostly blank.)
The results of the previous experiments suggest that by examining the screen switches we can somehow read the contents of at least part of the screen currently being displayed. But, to determine the time-history of what is being read, we must first find a way to "tag" the screen data and then sample the soft switches very quickly. Doing this would provide us with a cycle-by-cycle map of how the Apple's video is generated. In other words, we could determine which locations in memory the information in the screen switches is coming from during each clock cycle of the processor. Such a cycle-by-cycle map would be extremely useful in the implementation and understanding of screen splitting on the Apple II.
Tagging and Sampling a Hi-Res Screen. Now let's create a special hi-res display. We'll put zeros in the forty bytes of the hi-res memory buffer that correspond to line 0 and ones in all the bytes corresponding to line 1. Line 2 will contain all twos, and so on. In other words, line n will contain all n's, for n = 0 to 191 ($00 to $BF). But we still haven't tagged the undisplayed bytes in the bottom right-hand corner (screen lines 128 through 191). Let's fill these sixty-four sets of
eight-byte "invisible" lines with the values $C0 through $FF. Then every byte in the primary hi-res display buffer ($2000 through $3FFF), whether displayed or not, will contain a known quantity from $00 to $FF.
Listing 3 is a program for creating such a hi-res display of tagged screen data. Two versions are given; one in Integer Basic and one in Applesoft. Use Integer if you have it. It's faster.
Next we need to devise a way of quickly and uniformly sampling a screen switch over and over and saving each sample for later study. One way of doing this might be with a program like the following.
LOOP LDA $C050