Could suitably-written Apple-I software force bytes into the display shift register, and do modern recreations emulate that?

Question

The original Apple I didn't use RAM to hold the contents of the display, but instead used a group of six 1024-bit shift registers to hold the display contents and a seventh 1024-bit shift register to keep track of the cursor position. The normal means of outputting data to the display was to somehow activate a signal that would cause the display to store a byte into the display shifters at the spot where the "cursor" shifter had a 1, and then bump the cursor shifter by a space. This approach was limited to outputting one character per frame.

On the other hand, there are some other approaches which seem able to write more data on a frame. For example, when scrolling the screen, the system seems to be able to clear all 40 of the "new" characters on a single frame, and when clearing the screen it appears to be able to write all 960 characters and then set the single bit in the cursor shift register associated with the upper-left corner of the screen.

Did the Apple I provide any means, or could it be readily modified to provide any means, by which the CPU could manipulate the cursor shifter or force a character into the shift register at whatever part in the cycle it happened to be, allowing suitably-written code to produce faster screen output? If one could e.g. cause 1 bits to be stored into every ninth bit of the cursor shifter, it would seem like it should be possible to write any number of lines of text in nine frames by waiting for display scanning to reach the first line to be written, outputting one useful byte of data every nine cycles, waiting for the next line, outputting one useful byte of data every nine cycles, etc. and then cancel the "write-character" operation once all lines of interest had been written? Do any emulators or recreations of the Apple I support such things?

While being able to simply store screen contents in RAM as was done on the Apple ][ was better than anything that could have been done using shift registers, I would think that the shift-register-based design of the Apple I could have been used much more effectively than it was had it not been so quickly obsoleted.

Answer 1

Video output runs via a 6821 PIA and the interface exposed to the CPU is fairly simple: peripheral register B is configured so that the highest bit is an input and the low seven bits are an output. Checking its published source code, the echo character operation is in the monitor at address FFEF:

ECHO    BIT DSP
        BMI ECHO
        STA DSP
        RTS

i.e. busy wait while the top bit of register B is set. As soon as it is clear, transmit the new character. No positioning, no direct interaction with the shifters, just a push next.

Looking elsewhere, note the implementation of GETLINE at A98D:

GETLINE    LDA #$8D     ; CR
           JSR ECHO

           LDY #$01     ; Initialize text index
BACKSPACE  DEY
           BMI GETLINE  ; Beyond start of line, reinitialize.

NEXTCHAR   ... stuff of getting keyboard input,
           checking it for special characters and echoing it ...

Which suggests two things:

• special characters, such as carriage return are handled in hardware; but
• the only meaningful response to trying to backspace to before the start of a line in progress is to start a new line.

Combine those hints with the diagram below that describes DA, the video data available line that is a signal from the 6821 to the video subsystem, as "(UART style)" and I feel confident answering that: there is no means by which the CPU can usurp the normal serialised store-and-wait procedure. Full-line clears and scrolling appear to be a hardware feature, and I'm sure that screen clearing is implemented in terms of those.

Addendum, from the word of God (a sneaky deep link from here; scroll down to 'Don Lancaster's TV Typewriter' and see text billed as "Here is Steve [Wozniak]'s reply to my inquiry"):

The major cost component of my TV Terminal was the video RAM. ... 1024-bit dynamic shift registers were the most cost-effective solution I could find for the screen memory ... These RAM's had to shift once for each character on the screen ... This also led to only being able to add one character every 60th of a second, which is much lower than microprocessor speeds. [...]

When I turned it into the Apple I by adding my own local processor and RAM, the low character refresh rate was a real slow-down. But I was only modifying a terminal to get something built quickly.