News AI
June 28th, 2024

Apple II graphics: More than you wanted to know

The article explores Apple II graphics, emphasizing its historical importance and technical features like pixel-addressable graphics and sixteen colors. It contrasts with competitors and delves into synchronization challenges and hardware details.

Read original articleLink Icon
Apple II graphics: More than you wanted to know

The article delves into the intricate details of Apple II graphics, highlighting its historical significance and technical aspects. It discusses the unique features of the Apple II's graphics capabilities, such as pixel-addressable graphics and sixteen colors, setting it apart from competitors like Commodore and Tandy. The author references Jim Sather's book, "Understanding the Apple II," to explore the system's graphics modes and hardware components. The text explains the synchronization challenges in video signal processing and contrasts the Apple II's design with other systems like the Commodore VIC-20. It also delves into the technical aspects of the Apple II's memory layout, character generation, and screen resolution. The article provides insights into the system's hardware architecture, clock frequencies, and memory organization, shedding light on the complexities of early computer graphics systems.

Related

Atkinson Dithering (2021)

Atkinson Dithering (2021)

The Macintosh in 1984 introduced Atkinson dithering, enhancing image contrast with a unique error spreading pattern. iKe allows users to apply Atkinson dithering effects by converting images to grayscale matrices.

Atari 520ST Review in Creative Computing – By Paul Lefebvre

Atari 520ST Review in Creative Computing – By Paul Lefebvre

The Atari 520ST, released in July 1985, impressed with advanced features at a low price. Despite software limitations, it gained popularity quickly, leading to the later 1040ST release.

Round Rects Are Everywhere

Round Rects Are Everywhere

In 1981, Bill Atkinson developed oval routines for Macintosh. Steve Jobs challenged him to create rounded rectangles, leading to the "RoundRects" feature. This anecdote showcases innovation and collaboration in early Macintosh development.

Ghosts in the (Macintosh) ROM (2012)

Ghosts in the (Macintosh) ROM (2012)

A group at NYC Resistor found hidden images in Apple Mac SE ROM from 1986. They decoded distorted data, revealing pictures and assembly code, extracting four images and hinting at audio data.

Programming Like It's 1977

Programming Like It's 1977

The article explores programming games on the Atari VCS, a pioneering hardware platform from the 1970s with constraints that inspired creativity. Coding in 6502 assembly language offers a retro experience. The Atari 2600+ release supports old hardware for modern gaming. Learning on the Atari VCS reveals early programmers' challenges and solutions, fostering creativity.

Link Icon 14 comments
By @thought_alarm - 4 months
> "Randomly reading from various memory addresses might give the modern programmer some concern about security holes, maybe somehow reading leftover data on the bus an application shouldn't be able to see. On the Apple II, there is no protected memory at all though, so don't worry about it!"

Funnily enough, protected memory (sort of) arrived with the Apple III a couple of years later in 1980 and it was met with complete disdain from the developer community ("Stop trying to control my life, Apple!").

Apple III ROM, hardware, and kernel memory wasn't meant to be directly accessible from the application's address space. The purpose was to increase system stability and to provide a backward-compatible path for future hardware upgrades, but most users and developers didn't see the point and found ways around the restrictions.

Later, more-successful systems used a kinder, gentler approach (please use the provided firmware/bios interfaces please).

By @PaulHoule - 4 months
The first generation of home computers used discrete components for the display controller which is crazy expensive because you need lots of counters, comparators, wide data paths, etc which adds up to a lot of parts.

Second generation machines line the VIC-20 and TRS-80 Color Computer used ASICs for the display controller. Apple though the ][ was on borrowed time and has no idea how long it would last so they were slow to come out with the ][e which was cost-reduced.

By @deater - 4 months
the discrete hardware part of the Apple II is fascinating window into 1970s hobbyist electronics sometimes. In the flashing text mode, you might think the flashing text (also used for the cursor) is done in software or something. But no, it's a 555 timer gating off the video signal for that particular character.
By @robterrell - 4 months
This might be a good moment to drop a thing I made last year but never shared the link for. It's a bitmap editor that outputs Apple ][ shape tables.

https://robterrell.github.io/shape_table_maker/shape_draw.ht...

Apple ][ shape tables were a rarely-used vector drawing technique -- rarely used because they were fairly slow to render and there wasn't great tooling for making them. High level of difficulty plus poor results... it was almost as easy to write blitting code, even with the odd Apple ][ video memory layout, so most games ended up doing that instead.

Anyway, if you are curious about shape tables, here's a thing for you.

By @TMWNN - 4 months
Woz is one of the greatest engineers of the 20th century, and the Apple II demonstrates his talent. But his brilliance at simplifying things always straddles the line between optimized and overoptimized. The Disk II might be his greatest feat at doing more with less, while the video circuitry falls just into overoptimization, given the color fringing, NTSC dependence for color, and lack of lowercase. Integer BASIC is somewhere in the middle; great performance (especially given (or maybe because) Woz knew nothing about mainstream BASIC), but the code is so tightly written that it was easier for Apple to license Microsoft BASIC than to add floating-point code to Woz's work.
By @deater - 4 months
if you're excited about Apple II graphics, and also about the new Riven remake, but you don't have the VR hardware for Riven, you can try out the recently released Riven-for-Apple-II subset: http://deater.net/weave/vmwprod/riven/
By @whoopdedo - 4 months
> I'm going to break with my usual habit of ][ and use "Apple II" for the rest of the post.

It very slightly bothered me that "][plus" was typeset before this, but it was "IIe" and not "//e".

By @ffhhj - 4 months
> Many vintage computers are defined by their fonts.

But the article doesn't mention my favorite ASCII table ever, known as the "running man character set":

http://www.lazilong.com/apple_ii/a2font/readme.html

It includes open and closed apples, sand clock, and elements to build GUI's: windows, tabs, scrollbars, and even a pointer!

By @PaulHoule - 4 months
It hurts so much to see how slow that dragon head is animated in that Ultima intro. I remember a lot of really slow updating in games for the ][.
By @Bluecobra - 4 months
> Unfortunately, the Apple II doesn’t give the programmer any ability to know where in its cycle the video scanner is at any given time.

So there is no way to race the beam on an Apple II like an Atari 2600/VCS can?

By @Dwedit - 4 months
Glorious 7-bit graphics.
By @pazimzadeh - 4 months
Relevant:

How Steve Wozniak Brought Color to Personal Computers https://www.youtube.com/watch?v=uCRijF7lxzI

By @pavlov - 4 months
> "Randomly reading from various memory addresses might give the modern programmer some concern about security holes, maybe somehow reading leftover data on the bus an application shouldn't be able to see. On the Apple II, there is no protected memory at all though, so don't worry about it! Loosen up! The hacker doesn't need a security hole if there's no security."

I miss computers that didn't have the capability to send all my important data to an unknown address in Belarus in the blink of an eye.

Maybe someone could design a modern desktop operating system whose outgoing network requests are batched and processed once a day, so you can look through the batch before letting it out. This would of course mean that applications must be designed to be extremely thrifty about what data they want to send, or users would simply ban them for making large opaque requests. No more telemetry, no more ad profile updates, etc.