4 ms·

> The 6522 chip had a timer which could generate an interrupt at a specified interval. The problem was synchronizing it with the video, since the video generati

> The 6522 chip had a timer which could generate an interrupt at a specified interval. The problem was synchronizing it with the video, since the video generation was not accessible to the processor. Burrell solved the problem by wiring up the spare flip flop to the low bit of the data bus, using it to latch whatever data the video was displaying so the processor could read it. > To synchronize with the video, Burrell had me fill the Apple II's frame buffer so the low bit was on most of the time, but set off at the end of the last scan line. I wrote a routine to sit in a tight loop, reading the latch. When the low bit changed, we would know the vertical blanking interval had just begun. I am confused about this. What is the low bit used for aside from this synchronization scheme? I assumed it would correspond to a color pallet index, or an address into a character ROM. Why is it available to be used for synchronization?

JKCalhoun 5y ago
I was confused as well. Perhaps it did cause a loss in "color fidelity" (which on a palette-based system with so few colors ... that would be bad).
- setpatchaddress 5y ago
  Could be the reason the eventual product ended up with a more complex implementation?
- ddingus 5y ago
  The Apple didn't even have pallets. Each bit represented an absolute color based on its relationship to other bits and the color face signal inherent in the ntsc signal. Lots of color Fidelity most likely meant being limited to only a couple of the four actual color Shades available at the time, due to the use of the pallet bit.
kmeisthax 5y ago
The Apple II has a very weird graphics mode in which each byte stores seven pixels plus a palette bit. On a monochrome monitor, the palette bit is unused and the seven pixel bits just become black or white dots on the screen. On an NTSC color TV there's an additional color signal added to each block of seven pixels, and through the use of artifact color the seven dots per byte becomes three-and-a-half color dots per byte. At first I thought this might be referring to the palette bit - as this was almost certainly intended for B&W operation that bit is free to be used for other purposes. However, that's the high bit. Using the low bit would mean every seventh column of pixels would need to be white. Either that, or the engineer in question misremembered something and actually meant to say the palette bit.
- tenebrisalietum 5y ago
  I can't find any information or examples on it at the moment, but doesn't the palette bit shift the remaining 7 pixels one pixel when viewed as monochrome?
  - a1369209993 5y ago
    IIRC, it shifts them half a pixel, regardless of whether it's color or monochrome, and that's why it affects the palette. In color mode, the on/off pixels form a psuedo-sine wave, and the phase of this wave determines the color: if it's on even pixels you get green, if it's on odd you get purple, if it's on even-and-a-half you get orange, and if it's on odd-and-a-half you get blue (give or take which alignments are even/odd and half/whole, since I can't remember, but that's the basic idea).
tenebrisalietum 5y ago
I think it means the following: - Everything in the Apple II is synchronized with a master clock, including the video. - The video chip in some 8-bit systems in this era could generate an IRQ when it was generating a specific raster line--the VIC-II in the Commodore 64 for example. This enabled split screen effects or updating during vertical blank (set interrupt to happen at last scan line). - Apple II's video did not have this capability. - This hardware adds a VIA, with the timer-generated interrupt. Since the VIA clock is synced with the same clock that everything else is synced with, including the video, it should be possible to generate an IRQ exactly once per frame. If that IRQ can happen at the right time, it can be used to effectively emulate a raster line IRQ. - So--starting that timer at the right time: if you fill the framebuffer with 0x01, except for the last line, and keep peeking at what the video chip is putting out, enabling the timer when you no longer see 1's, you then have a reference point to enable the VIA timer IRQ at a right place. - Once you have the timer set you can clear the frame buffer and use it normally.
joezydeco 5y ago
The IIe, IIc, and IIgs had a means to track the vertical blank signal, but the original II did not. So a hack was discovered to let the 6502 see the video data being clocked out. It's described in great detail in Don Lancaster's book. https://www.tinaja.com/ebooks/enhance_vII.pdf https://www.tinaja.com/ebooks/enhance_vII.pdf The gist is that the last byte of each horizontal raster is not displayed on-screen, but with the hack the 6502 can see it. So if you set the low bit of the last byte to 1 for every horizontal line except the last one, now you know when the hardware has sent out the last byte of the last line. Vertical Blank comes right after that.
- anyfoo 5y ago
  Ah, thanks. Like the poster you responded to probably, the actual bit (hah) that I was missing was that the last bit was apparently no used by the framebuffer in any way, i.e. it's available for synchronization because changes to it are not visible on the screen.
NelsonMinar 5y ago
The Apple ][ display was effectively a 1 bit per pixel display (not exactly, but close enough). I understood this to mean that while synchronizing they painted the entire screen white except the lower right corner pixel which was black. Once synced the 6522 could generate the timing signal it needed independently and the display could do whatever it needed. The prime number offset mentioned in the article is the other necessary piece of the hack. And a beautiful one at that.
- anyfoo 5y ago
  That's weird though, a screen painted like that isn't very useful. It seems to me that the bit used for synchronization here either has no effect, or a not very visible one.
  - a1369209993 5y ago
    I think the idea there is that you only paint it that way for one frame (1/60 sec, usually?). Similar to how some old hitscan light guns[0] on arcade machines worked. 0: https://www.youtube.com/watch?v=Nu-Hoj4EIjU https://www.youtube.com/watch?v=Nu-Hoj4EIjU (c 8:40 - not similar to the light pens earlier)
    - anyfoo 5y ago
      That sounds even more terrible, with the screen flickering intensely to be able to read the mouse?
      - a1369209993 5y ago
        The idea is that you do the calibration once (eg on program start), then the timer interrupt handles it until and unless it get desynced. So only for one frame, total (per run of the mouse-using program).
        anyfoo 5y ago
        Ah, that makes more sense, thank you. I thought this was constant synchronization, but IIRC the Apple II only has one oscillator from which all clocks are derived (as was common for 8 bit machines).

JKCalhoun 5y ago

I was confused as well. Perhaps it did cause a loss in "color fidelity" (which on a palette-based system with so few colors ... that would be bad).

setpatchaddress 5y ago
Could be the reason the eventual product ended up with a more complex implementation?
ddingus 5y ago
The Apple didn't even have pallets. Each bit represented an absolute color based on its relationship to other bits and the color face signal inherent in the ntsc signal. Lots of color Fidelity most likely meant being limited to only a couple of the four actual color Shades available at the time, due to the use of the pallet bit.

kmeisthax 5y ago

The Apple II has a very weird graphics mode in which each byte stores seven pixels plus a palette bit. On a monochrome monitor, the palette bit is unused and the seven pixel bits just become black or white dots on the screen. On an NTSC color TV there's an additional color signal added to each block of seven pixels, and through the use of artifact color the seven dots per byte becomes three-and-a-half color dots per byte. At first I thought this might be referring to the palette bit - as this was almost certainly intended for B&W operation that bit is free to be used for other purposes. However, that's the high bit. Using the low bit would mean every seventh column of pixels would need to be white. Either that, or the engineer in question misremembered something and actually meant to say the palette bit.

tenebrisalietum 5y ago
I can't find any information or examples on it at the moment, but doesn't the palette bit shift the remaining 7 pixels one pixel when viewed as monochrome?
- a1369209993 5y ago
  IIRC, it shifts them half a pixel, regardless of whether it's color or monochrome, and that's why it affects the palette. In color mode, the on/off pixels form a psuedo-sine wave, and the phase of this wave determines the color: if it's on even pixels you get green, if it's on odd you get purple, if it's on even-and-a-half you get orange, and if it's on odd-and-a-half you get blue (give or take which alignments are even/odd and half/whole, since I can't remember, but that's the basic idea).

tenebrisalietum 5y ago

I think it means the following: - Everything in the Apple II is synchronized with a master clock, including the video. - The video chip in some 8-bit systems in this era could generate an IRQ when it was generating a specific raster line--the VIC-II in the Commodore 64 for example. This enabled split screen effects or updating during vertical blank (set interrupt to happen at last scan line). - Apple II's video did not have this capability. - This hardware adds a VIA, with the timer-generated interrupt. Since the VIA clock is synced with the same clock that everything else is synced with, including the video, it should be possible to generate an IRQ exactly once per frame. If that IRQ can happen at the right time, it can be used to effectively emulate a raster line IRQ. - So--starting that timer at the right time: if you fill the framebuffer with 0x01, except for the last line, and keep peeking at what the video chip is putting out, enabling the timer when you no longer see 1's, you then have a reference point to enable the VIA timer IRQ at a right place. - Once you have the timer set you can clear the frame buffer and use it normally.

joezydeco 5y ago

The IIe, IIc, and IIgs had a means to track the vertical blank signal, but the original II did not. So a hack was discovered to let the 6502 see the video data being clocked out. It's described in great detail in Don Lancaster's book. https://www.tinaja.com/ebooks/enhance_vII.pdf https://www.tinaja.com/ebooks/enhance_vII.pdf The gist is that the last byte of each horizontal raster is not displayed on-screen, but with the hack the 6502 can see it. So if you set the low bit of the last byte to 1 for every horizontal line except the last one, now you know when the hardware has sent out the last byte of the last line. Vertical Blank comes right after that.

anyfoo 5y ago
Ah, thanks. Like the poster you responded to probably, the actual bit (hah) that I was missing was that the last bit was apparently no used by the framebuffer in any way, i.e. it's available for synchronization because changes to it are not visible on the screen.

NelsonMinar 5y ago

The Apple ][ display was effectively a 1 bit per pixel display (not exactly, but close enough). I understood this to mean that while synchronizing they painted the entire screen white except the lower right corner pixel which was black. Once synced the 6522 could generate the timing signal it needed independently and the display could do whatever it needed. The prime number offset mentioned in the article is the other necessary piece of the hack. And a beautiful one at that.

anyfoo 5y ago
That's weird though, a screen painted like that isn't very useful. It seems to me that the bit used for synchronization here either has no effect, or a not very visible one.
- a1369209993 5y ago
  I think the idea there is that you only paint it that way for one frame (1/60 sec, usually?). Similar to how some old hitscan light guns[0] on arcade machines worked. 0: https://www.youtube.com/watch?v=Nu-Hoj4EIjU https://www.youtube.com/watch?v=Nu-Hoj4EIjU (c 8:40 - not similar to the light pens earlier)
  - anyfoo 5y ago
    That sounds even more terrible, with the screen flickering intensely to be able to read the mouse?
    - a1369209993 5y ago
      The idea is that you do the calibration once (eg on program start), then the timer interrupt handles it until and unless it get desynced. So only for one frame, total (per run of the mouse-using program).
      - anyfoo 5y ago
        Ah, that makes more sense, thank you. I thought this was constant synchronization, but IIRC the Apple II only has one oscillator from which all clocks are derived (as was common for 8 bit machines).