Hacker News Reader

Comment by thought_alarm | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com