5 ms·

That seems like a big price to pay for slightly better text spacing. Virtually every other home computer used 6 or 8 pixels per char/byte. I don't think oversc

That seems like a big price to pay for slightly better text spacing. Virtually every other home computer used 6 or 8 pixels per char/byte. I don't think overscan would be an issue. The TMS9918 is also (the equivalent of) 320 pixels wide, and it was used in many different home computers and game consoles intended to connect to the family TV. There's no overscan issue, unless it's connected to an Apple II monitor. When the TMS9918 is connected to an Apple II monitor there is a huge overscan issue, since the monitor is tuned for the narrower Apple II screen. It looks like this: https://imgur.com/rGcRpw0 https://imgur.com/rGcRpw0 That's what got me thinking about this issue is the first place.

tlb 6y ago
OK, but the Apple ][ was sold before special computer monitors were common. It was meant to hook up to your existing home TV. So what mattered at the time was the way most people's TVs were calibrated. They usually had a lot of overscan, because (a) 1970s picture tubes weren't square, they had a lot of rounding at the corners (b) the (all-analog) deflection & blanking circuits made fairly ugly artifacts at the edges which TV makers tried to hide. If they'd shipped with 320-wide video, a lot of people wouldn't have seen the prompt on the left hand side.
- thought_alarm 6y ago
  The Atari 400/800 and the TMS9918 (TI 99/4A, Colecovision, etc.) are 320 pixels wide and were designed to run on those same 1970s home television sets, and they didn't have an overscan problem (maybe some sets did, but most didn't). I don't think the Apple II had to cut the screen width down to 280 pixels. That's the heart of the question. Did Woz think that 320 pixels would not fit, or did he cut the width down for another reason, like more color.
  - joezydeco 6y ago
    Or, perhaps, he didn't want to pay for a video generator IC like a 9918 or 6845. If you look at the video generation circuit on an Apple ][ it's all done in real-time in TTL, alongside the DRAM refresh activity. And it's all crammed into the normally unused tock of the 6502, making this work with virtually zero overhead on the CPU. That's the reason why the memory mapping of the screen isn't linear to the physical display. The software tradeoff was cheaper than the hardware one. http://twimgs.com/informationweek/byte/archive/Apple-II-Description/The-Apple-II-by-Stephen-Wozniak.pdf http://twimgs.com/informationweek/byte/archive/Apple-II-Desc...
    - ddingus 6y ago
      And it made add on cards simpler, as well as cycle counting. In addition, the overall throughput of the CPU is better than most other machines, giving the Apple an effectively higher speed at that clock rate. Overall, given memory expansion, the goofy screen didn't end up being too big of a deal. Most programmers made Y axis lookup tables and called it a day. The fact that the artifact color mapping repeated every word, two bytes, did have an impact in that it was generally faster to maintain two pre-shifted copies of software sprites though.
      - thought_alarm 6y ago
        Speaking of add on cards, I own a TMS9918 video card for my Apple II. It's remarkably simple. The 9918 manages its own 16 kB of VRAM and it doesn't place any timing restriction on the host system. You'd think that the 9918 would be a bottle neck between the CPU and the VRAM, but the Apple II can write to the 9918 VRAM as fast as its own internal RAM. Faster, actually, since the destination address auto-increments. That was a surprise.
        ddingus 6y ago
        Interesting! Hmmm, is the bitmap linear by line, or C64 style? Auto increment + C64 style would rock pretty hard. It's still good per line. Both have their merits.
        thought_alarm 6y ago
        Bitmap mode is made up of 8x8 tiles. The screen is 32x24 tiles, or 256x192 pixels. 2 colors per line per tile. So a single tile can contain up to 16 colors. A single screen is divided into 3 separate tile maps, each 256 bytes long. It also supports 32 spirtes but only 4 sprites per scanline, which is its biggest limitation. The Sega Master System used an upgraded version of the 9918, adding 64 colors, smooth scrolling, and 8 sprites per scanline, all within the same 16 kB of VRAM.
        6y ago
  - exsf0859 6y ago
    Err, as an Atari 400/800 owner, I can assure you that they did in fact have an overscan problem. Atari BASIC even defaulted to not printing to the first 2 characters and last 2 characters of each line. Here's an example Atari BASIC program that uses POKE statements to change and then restore the default margins. https://www.atariarchives.org/c2bag/page003.php https://www.atariarchives.org/c2bag/page003.php
    - ddingus 6y ago
      Those margins make almost exactly the Apple display region active text. Interesting! I never noted that before.
- sowbug 6y ago
  Tangent: when we bought our Apple II in 1980, the salesperson explained that the "Sup'R'Mod" extra video box we also needed to connect to a TV was sold separately, manufactured by a different company, so that neither needed FCC certification. I don't know whether this story is true, but it's what we were told.
  - wlesieutre 6y ago
    Wikipedia has a page on the Sup'R'Mod and cites this page for the same story with some additional detail: https://apple2history.org/history/ah03/ https://apple2history.org/history/ah03/ (see "Other Design Features" section) That's a funny little piece of computer history.
  - apricot 6y ago
    That's also how it was explained to me, back in the days.
jecel 6y ago
Actually, the TMS9918 has a 240x192 text mode with 40x24 characters of 6x8 each and several 256x192 graphics modes with 32x24 characters of 8x8 each. This is always fewer than Apple II's 280 pixels per line.
- thought_alarm 6y ago
  Right, but in text mode the 9918 draws 6 native pixels for every 8 NTSC color "pixels". So, measured in NTSC color pixels, it's 320 wide (40x8) compared to 280 (40x7) for the Apple II. This image (white text on a blue background) shows how the 9918's native pixels line up with the NTSC color burst frequency: https://imgur.com/rGcRpw0 https://imgur.com/rGcRpw0

tlb 6y ago

OK, but the Apple ][ was sold before special computer monitors were common. It was meant to hook up to your existing home TV. So what mattered at the time was the way most people's TVs were calibrated. They usually had a lot of overscan, because (a) 1970s picture tubes weren't square, they had a lot of rounding at the corners (b) the (all-analog) deflection & blanking circuits made fairly ugly artifacts at the edges which TV makers tried to hide. If they'd shipped with 320-wide video, a lot of people wouldn't have seen the prompt on the left hand side.

thought_alarm 6y ago
The Atari 400/800 and the TMS9918 (TI 99/4A, Colecovision, etc.) are 320 pixels wide and were designed to run on those same 1970s home television sets, and they didn't have an overscan problem (maybe some sets did, but most didn't). I don't think the Apple II had to cut the screen width down to 280 pixels. That's the heart of the question. Did Woz think that 320 pixels would not fit, or did he cut the width down for another reason, like more color.
- joezydeco 6y ago
  Or, perhaps, he didn't want to pay for a video generator IC like a 9918 or 6845. If you look at the video generation circuit on an Apple ][ it's all done in real-time in TTL, alongside the DRAM refresh activity. And it's all crammed into the normally unused tock of the 6502, making this work with virtually zero overhead on the CPU. That's the reason why the memory mapping of the screen isn't linear to the physical display. The software tradeoff was cheaper than the hardware one. http://twimgs.com/informationweek/byte/archive/Apple-II-Description/The-Apple-II-by-Stephen-Wozniak.pdf http://twimgs.com/informationweek/byte/archive/Apple-II-Desc...
  - ddingus 6y ago
    And it made add on cards simpler, as well as cycle counting. In addition, the overall throughput of the CPU is better than most other machines, giving the Apple an effectively higher speed at that clock rate. Overall, given memory expansion, the goofy screen didn't end up being too big of a deal. Most programmers made Y axis lookup tables and called it a day. The fact that the artifact color mapping repeated every word, two bytes, did have an impact in that it was generally faster to maintain two pre-shifted copies of software sprites though.
    - thought_alarm 6y ago
      Speaking of add on cards, I own a TMS9918 video card for my Apple II. It's remarkably simple. The 9918 manages its own 16 kB of VRAM and it doesn't place any timing restriction on the host system. You'd think that the 9918 would be a bottle neck between the CPU and the VRAM, but the Apple II can write to the 9918 VRAM as fast as its own internal RAM. Faster, actually, since the destination address auto-increments. That was a surprise.
      - ddingus 6y ago
        Interesting! Hmmm, is the bitmap linear by line, or C64 style? Auto increment + C64 style would rock pretty hard. It's still good per line. Both have their merits.
        thought_alarm 6y ago
        Bitmap mode is made up of 8x8 tiles. The screen is 32x24 tiles, or 256x192 pixels. 2 colors per line per tile. So a single tile can contain up to 16 colors. A single screen is divided into 3 separate tile maps, each 256 bytes long. It also supports 32 spirtes but only 4 sprites per scanline, which is its biggest limitation. The Sega Master System used an upgraded version of the 9918, adding 64 colors, smooth scrolling, and 8 sprites per scanline, all within the same 16 kB of VRAM.
        6y ago
- exsf0859 6y ago
  Err, as an Atari 400/800 owner, I can assure you that they did in fact have an overscan problem. Atari BASIC even defaulted to not printing to the first 2 characters and last 2 characters of each line. Here's an example Atari BASIC program that uses POKE statements to change and then restore the default margins. https://www.atariarchives.org/c2bag/page003.php https://www.atariarchives.org/c2bag/page003.php
  - ddingus 6y ago
    Those margins make almost exactly the Apple display region active text. Interesting! I never noted that before.
sowbug 6y ago
Tangent: when we bought our Apple II in 1980, the salesperson explained that the "Sup'R'Mod" extra video box we also needed to connect to a TV was sold separately, manufactured by a different company, so that neither needed FCC certification. I don't know whether this story is true, but it's what we were told.
- wlesieutre 6y ago
  Wikipedia has a page on the Sup'R'Mod and cites this page for the same story with some additional detail: https://apple2history.org/history/ah03/ https://apple2history.org/history/ah03/ (see "Other Design Features" section) That's a funny little piece of computer history.
- apricot 6y ago
  That's also how it was explained to me, back in the days.

jecel 6y ago

Actually, the TMS9918 has a 240x192 text mode with 40x24 characters of 6x8 each and several 256x192 graphics modes with 32x24 characters of 8x8 each. This is always fewer than Apple II's 280 pixels per line.

thought_alarm 6y ago
Right, but in text mode the 9918 draws 6 native pixels for every 8 NTSC color "pixels". So, measured in NTSC color pixels, it's 320 wide (40x8) compared to 280 (40x7) for the Apple II. This image (white text on a blue background) shows how the 9918's native pixels line up with the NTSC color burst frequency: https://imgur.com/rGcRpw0 https://imgur.com/rGcRpw0