On the Apple II, there are three 40 column text modes: normal (white on black), inverse (black on white) and flash. A text screen can contain a mix of text in all three of these modes.

Flash mode is roughly a 0.5s delay between cycling text between a normal and inverse mode. However, unlike the console cursor, the rate of the flash does not appear to be influenced by the speed of the CPU - my personal experience is with a RocketChip 5MHz and while the cursor flash is proportionate to the CPU speed, flashing 40-column text remains the same.

Speaking of the cursor, on the II and II+ machines it is a flashing white block - if you backspace over a character, it appears to go between inverse and normal in this 0.5s cadence. On later machines, it was replaced by a matrix of dots. So the question is not only how is flashing text implemented on the II, but perhaps an extension would be is why is the cursor affected but not the flashing characters of the text display? Is flashing text CPU-timed or something else?

  • Any cursor flash proportional to CPU speed is being "faked" by software. There are some reasons for doing that. For instance, the cursor can be made to appear solid while characters are typed, and always begin flashing after a predictable inactivity delay, rather than in sync to an arbitrary hardware timer.
    – Kaz
    Feb 28, 2020 at 7:13

2 Answers 2


How is the Apple II text flash mode timed?

It's a fixed timing signal generated by an NE555 timer (at position B3 on the original II+).

enter image description here (From the Apple II Reference Manual / Red Book p.151)

Entering the values of C/R1/R2 into an online calculator for NE555s will give about 2.1 seconds cycle time (*1)

The II's video logic used bit 2^6 and 2^7 to control the level in text mode.

7  6
0  0  - Inverted
0  1  - Inverted depending on the timer
1  0  - Not inverted

This is as well visible in the (screen) character set:

enter image description here

This as well shows that the Apple II character generator only holds 64 different glyphs - using above logic to produce them in Normal/Inverted/Flash.

There is no hardware cursor. It's essentially done by setting the two top bits of the character were the cursor should be shown to 01 (*2).

For the second part:

an extension would be why is the cursor is affected but not the text display?

I'm not entirely clear what you describe/ask.

*1 - These are analogue parts with up to 10% or more variation.

*2 - this is also, why pressing Reset may result having the 'old' cursor still blinking while a new one is displayed.

  • 2
    I think he means, "why is the cursor affected but not the text display?" Feb 27, 2020 at 15:27
  • 1
    I read it as "why was the cursor changed from a flashing square, if colour inversion was still available?" So possibly it's more a follow-on query about the way in which the character set was expanded in the IIe and IIc?
    – Tommy
    Feb 27, 2020 at 15:46
  • 2
    Could be either, I guess I'll have to wait for the OP to clarify.
    – Raffzahn
    Feb 27, 2020 at 15:52
  • 1
    Instead of saying "Fixed", I'd say "hardware-controlled" since, as you later note, the time is variable depending upon temperature, phase of the moon, etc.
    – supercat
    Feb 27, 2020 at 16:50
  • 5
    On my Apple II+, the 555 or the cap died and I was left with no cursor at all. As a stopgap measure, I pulled the 555 and replaced it with a wire between I guess pins 1 and 3. That gave me an inverse cursor which made the machine usable again. Feb 27, 2020 at 20:25

Regarding the cursor, the character under the cursor is replaced with flashing text by RDKEY:

fd0c: a4 24        RDKEY       ldy     CH
fd0e: b1 28                    lda     (BASL),y        ;set screen to flash
fd10: 48                       pha
fd11: 29 3f                    and     #$3f
fd13: 09 40                    ora     #$40
fd15: 91 28                    sta     (BASL),y
fd17: 68                       pla
fd18: 6c 38 00                 jmp     (KSWL)          ;go to user key-in

Note the character from the screen is still in the accumulator. The default KSWL function is KEYIN at $fd1b. After you hit a key, KEYIN writes the new character, or in the case of ESC key movement the previous character, onto the screen before continuing:

fd1b: e6 4e        KEYIN       inc     RNDL
fd1d: d0 02                    bne     KEYIN2          ;incr rnd number
fd1f: e6 4f                    inc     RNDH
fd21: 2c 00 c0     KEYIN2      bit     IOADR           ;key down?
fd24: 10 f5                    bpl     KEYIN           ;  loop
fd26: 91 28                    sta     (BASL),y        ;replace flashing screen

Replacing the flashing (or, for 80-column mode, inverse) text with an alternating checkerboard, as is done on the Apple //e, requires a bit more work in the ROM; KEYIN jumps to code in the 80-column firwmware. The logic is the same though -- replace the on-screen char with something else -- it's just done repeatedly. (The hardware handles flashing text, but does not handle replacement with a checkerboard. If you hit the reset key at the right time, you'll see a checkerboard character left behind.)

  • 1
    And the reason the IIe used the checkerboard was that the IIe supported lowercase, and there's no lowercase flashing (or inverse) text. So you couldn't have the cursor over a lowercase character if it was implemented as flashing. (Interestingly, the Franklin Ace 1000 clone, which had lowercase before the Apple II, addressed this by having lowercase characters become uppercase when the cursor was over them.) The 80-column mode had inverse lowercase, but no flashing, which is why the cursor was an inverse block there.
    – kindall
    Apr 23, 2021 at 21:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .