questions about the display register

In post #1, 'zapcircuit' wrote:

"... the result was different across different simulators  ..."

Right there is your problem: don't try to explore the Apple-1 video hardware using any emulator. I found that none of those I investigated are 100% faithful with the video timing, and hence, their video handshake process is different from the real Apple-1. But as long as your code follows the 'ECHO' routine in the Wozmon, all emulators work. The video output speed may be different, however. This would be only important for action / reaction skill games on the Apple-1, none of which exist so far.

To understand why it is so, here is how the Apple-1 'Terminal Section' works, in a nutshell:

There are the usual counters which count character positions and TV scan lines and generate the HSYNC and VSYNC pulses, but none of those address the character memory, which in later computers is RAM, and can be addressed directly, but the Apple-1 uses six 1024 bit long shift registers (the 2504 type) instead. Which do not have any address inputs ;-)

The screen contents 'circles' in these shift registers with one clock per character. Some padding clocks are added to arrive at exactly 1024 clocks per TV 'field' which is one vertical period, or, in other words, the time the electron beam of a CRT needs to write the whole screen and be back at the same spot where it began.

As each character line comprises eight TV scan lines (one scan line is the electron beam travelling from the left to the right), the six character bit sequence for the 40 characters per line must repeat eight times, such that the character generator ROM (the 2513) can translate them to dot patterns, and thus the ROM has nine address inputs: six to select one of 64 characters, and three to select one of the eight rows, the last low always being blank (the characters use a 5 x 7 dot matrix).

It is obvious that there is no way to feed the character generator ROM with eight times the same 40 character sequence directly from the 1024 bit shift registers. This is where the 2519 shift register comes into play: when the last, blank row of the previous character line is being written to the TV screen, the 2519 receives the 40 characters for the next character line from the 2504 shift registers. It is a 40 x 6 bit shift register which then recirculates the 40 characters multiple times, generating the same 40 character sequence again and again, so that the character generator can produce each of the seven rows of TV scan lines needed to make a character line (the three row bits come from the counters).

So far, so good. We understand now how the Apple-1 video memory works, despite it's just dumb shift registers, and we know how we get a TV picture with all the screen memory contents.

But how does the write process to the video memory work ?

This is where the 7th 2504 shift register comes in. It sits below the DS0025 clock driver, and contains the 'cursor', which is just a bit marking where the next character could be written. The cursor 'circulates' in its 1024 bit shift register in the same way as the character codes circulate in the other six 1024 bit shift registers, so the relative position always stays the same. This cursor bit is mixed with the output of the 555 timer to make the cursor flash.

When you write to the PIA port PB at $D012, the PIA will clear its CB2 output, which gets inverted by NAND C15-11 (see "Processor Section" schematic, the '11' of the "C15-11" means the output pin number) and this signal, now logic "1", does two things: it feeds into PIA input PB7 (this is the MSB of $D012 when read and signals that the "Terminal Section" is busy) and it will 'arm' the cursor state machine as signal 'DA', which is the separate circuit block on the "Terminal Section" A/B-2/3 (the lower right corner). You can see that the DA signal from the PIA goes into a 74174 containing D-Flipflops, clocked by MEMO, which is the same clock as the video memory shift registers. The particular flipflop has input D1, and its output Q1 is combined with 'CURS' signal (the cursor signal) in NAND gate C6-6 which eventually leads to a '/WRITE' signal to the video memory shift register. The write is done by signal /WRITE changing the input select of the 74157 multiplexers C4 and C14 from the recirculated data coming from the 2504 shift register outputs to the pending character from the PIA port PB[6:0], outputs of course,  while PB[7],  the MSB, is the 'BUSY' flag. After the character has been written, the cursor state machine advances the cursor by one position (this is done by 'killing' the old cursor with the signal '/WC2' and then setting a new cursor bit one character clock later). Then the cursor state machine signals the PIA that the character has been written (signal /RDA), which involves a 3.5 us oneshot driving the PIA handshake input CB1, which proceeds to set CB2, causing the MSB of $D012 (the BUSY) to clear. Scrolling and carriage return is also controlled by the cursor state machine, but this is too much to write here, and not needed to answer the questions of the OP.

The takeaway from this description how the Apple-1 video system works is as follows:

- You can write as many characters to $D012 at any speed, but only the character being present on the PIA port at the point in time where the cursor signal arrives is written into the screen memory. All the other characters are ignored.

- The cursor signal appears once per TV 'field', which in the Apple-1 is every 16.67 milliseconds, corresponding to the 60 Hz field rate. So the maximum speed for screen output is 60 characters per second.

- Maximum screen output speed can only be reached if the next character is ready at the PIA when the cursor signal arrives. If your program misses that opportunity and writes the next character too late (i.e. just after the cursor pulse), then this character will be written with a delay, until the cursor pulse arrives again. For most programs this won't happen because they are fast enough and keep the PIA filled, but if the character stream is generated by a more complicated algorithm (such as decompression / decryption) then the screen output may 'stutter' and become slower than expected.

So far I have not seen any Apple-1 emulator which reproduces the cursor state machine faithfully. Some emulators model the PIA only rudimentary, and the $D013 register 'zapcircuit' did ask for in the OP isn't there, or only partially implemented. It is the configuration register for PIA port B. For more information on the inner workings of the PIA look here:

https://archive.org/details/rockwell_r6520_pia

or search the internet for '6520 PIA datasheet' or '6820 PIA datasheet'. The MOS Technology 6520 is a 1:1 functional copy of the original Motorola 6820, and all the second source manufacturers of the 6520 and the 6820 had their own datasheets, which, due to technical obsolescence, may be difficult to find.

(Just as a side note, the 6820 seems to have a better input synchronizer circuit than the 6520, so the 6520 is not a 1:1 transistor level clone of the Motorola 6820, and the process technology was different, too).

- Uncle Bernie

The display memory in the Apple I is in the form of shift registers. A shift register is a silicon structure that is a little like a conveyor belt: each time it is clocked, one bit can be loaded in, and every bit currently stored moves one step closer to the output. The bit that was stored the longest is output and removed from the chip, but it can be recirculated back to the input if it must be kept around. Unlike later memories, shift registers are not random-access: you get all of the bits, in order.

The Apple uses 7, 1 bit * 1024 shift registers: 6 to remember the character at each position in the 40×24 display matrix, and the 7th to remember the cursor position. The only time that the CPU can write a character to the screen is when the cursor "comes past the head", which enables the /WRITE signal. The scan of the screen happens 60 times a second, so the maximum speed for outputting characters is 60 per second. The code in the CPU is asynchronous to the display, so it must wait for this to happen to emit each character.

An overview (with pictures) is available here.

Emulators won't replicate this behavior unless they simulate the gates at a low level.

The 6820 PIA control register at $D013 just sets up the second port of the PIA. The connections to the PIA are fixed, so it just needs to be set up once at reset time. See the doc here.

Edit: Uncle Bernie provided a better explanation. Perhaps he can illuminate one detail that I puzzled over in composing this post: Do the 2504s shift once per horizontal character, but only during the bottom (blank) scanline, thus exhibiting a rough "galloping" cadence? I was trying to locate the gates that should do this, but only gave myself a headache staring at the nasty rats nest of control logic.

Another idea is that after a character is written to the shift registers, the position of the cursor advances by one. What prevents the next character from being written immediately, instead of waiting 1/60 s for the registers to fully circulate?

Hello zapcircuit,

I was curious about this too. I designed a Character Generator Tester, where you can see how a single character is build up on the screen. See here: https://www.applefritter.com/content/character-generator-tester-pcb-and-kits#comment-106815

The schematics are also available if you like to see how it works.

In post #3, 'robespierre' asked:

" Do the 2504s shift once per horizontal character, but only during the bottom (blank) scanline, thus exhibiting a rough 'galloping' cadence ?"

" What prevents the next character from being written immediately, instead of waiting 1/60 s for the registers to fully circulate ?"

Uncle Bernie answers:

1st question: your "galloping cadence" is generated by the gating of the MEM0 clock with the /LINE7 signal coming out of the NAND B2-10, and its three inputs are the row select bits of the character generator (row 7 is always blank). The same /LINE7 signal gets the 2519 out of its recirculate mode (/LINE7 = RC = 0) so the next character line of 40 characters is loaded into the 2519 while these 40 clock pulse train appears on MEM0.

2nd question: the CURS signal (the "cursor pulse") is asserted only for one character clock (MEM0 again), so only one character can be written into the shift registers at any "cursor pulse active" time. After that character was written, the cursor pulse is gone until the recirculation brings the new, moved forward cursor, which is written into the cursor shift register just afterwards.

A small correction / clarification here to what I wrote in post #2, the actual "killing" of the old cursor happens in the 74157 multiplexer when the /WRITE pulse is asserted, and /WC2 acting on AND gate C12-8 then makes the new cursor (the cursor bit is active low). But this new cursor is not getting to the output of the cursor shift register until 1024 MEM0 clocks later.

As a side note, the 3.5us oneshot is just there that the PIA is guaranteed to "see" the /RDA pulse which is only character clock (MEM0 again) wide, and this would not be wide enough for the PIA. This is why the pulse width of this oneshot is not very critical (as long as it is longer than 2us) but there is a metastability problem for certain oneshot runtimes which, if it strikes, may cause occasional output mishaps. I wrote about this somewhere on Applefritter, so if you get occasional dropped or doubled characters, check this oneshot runtime to be close to 3.5us and not near the "critical" runtimes where metastability could occur due to setup/hold time violations within the PIA.

- Uncle Bernie

In post #5, 'zapcircuit' asked:

 " ... it should print at about 60 characters per second, and if an emulator is slower than that its inaccurate, right ? "

Uncle Bernie answers:

Correct. But as far as "inaccurate" goes, some Apple-1 emulators actually allow you to set the screen output rate to any speed you want, and some offer two choices, the "original speed" and a "fast mode" which has no delays.As far as I'm concerned, I like the 60 characters per second, as I can read that fast, at least for a short period of time, and if it is just english language and not machine language. Where "inaccurate" speed would be bad is for reaction games such as the "bowling" game I suggested in post #11 of this thread:

https://www.applefritter.com/content/beta-launch-apple-1-software-library

... and, of course, any other real time game such as the proposed "Lunar Lander" simulation. Of course, this is an issue only of the timing of the game depends on the screen output rate. But it is so convenient to use the fixed screen output rate of the Apple-1 to 'time' any such reaction (or real time simulation) game. The point here is that it is easy to write the screen output loop such that it also accepts keystrokes at the same time. This is then what in game programmer lingo is the "game main loop". It is the same programming technique used for all keyboard controlled Apple II action games.

- Uncle Bernie