Hacker News Reader

Comment by thought_alarm | Hacker News Reader

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

That's what got me thinking about this issue is the first place.

View on HN

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.

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.

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-Desc...

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.

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.

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.

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.

So if a person maps them up, one gets basically C64 style display.

Yeah, auto-increment can rock! Blasting characters to the memory would be fast, and only require a precise index for the source data. Perfect for the 6502. Other index can be done every so often, depending on what is being drawn.

Right, but the Apple II video generator is already reading 40 bytes per scan line, and is using all 8 bits of each byte to generate the video signal. I would think that drawing 8 pixels per byte instead of 7 would have been the simpler thing to implement.

Actually, it's not.

In the Apple 1, only 7 bits were output. Expanding that circuit to do graphics would take a byte and still output just 7 bits, simple.

People are pretty sure the Apple 1 video circuit was just expanded to do graphics, which is why it's 7, and that left the high bit for a color shift.

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

Those margins make almost exactly the Apple display region active text.

Interesting! I never noted that before.

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.

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/ (see "Other Design Features" section)

That's a funny little piece of computer history.

That's also how it was explained to me, back in the days.

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.

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

Reply on news.ycombinator.com