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...
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.
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.
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.
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.
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.
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.
Here's an example Atari BASIC program that uses POKE statements to change and then restore the default margins.
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.