The Apple II Circuit Description (1983) | Hacker News Reader

The Apple II Circuit Description (1983)

archive.org

84 pointsbookofjoe18 comments

Most of the components in the original Apple II are still manufactured. The character ROM is hard to find. The 16 kilobit DRAMs are definitely obsolete, but not exactly rare (dozens of millions were manufactured). Since it's mostly 7400 LS TTL logic you can easily substitute a different circuit to replace a missing part, use modern EEPROMs, etc. (Beware of subtle timing issues - you can't always swap a modern CMOS part for a TTL part.)

Accordingly, you can still build an Apple II today: https://www.reactivemicro.com/product/apple-ii-rev-0/ Same store also sells a complete kit for an Apple II+ including components, as well as assembled. (Never bought from them, can give no review.)

The Apple II may be one of the last computers so-thoroughly documented. Your 1970s era TI databooks for 74xx TTL components will give you a complete transistor-level schematic of the logic. And the 6502 itself has been completely reverse-engineered. So it's possible to know where every transistor in the computer is and what it does. And the machine is just about simple enough, one person can fit it all in their head, mostly.

> The Apple II may be one of the last computers so-thoroughly documented.

The IBM 5150 came out 4 years later and is insanely well documented. The original documentation included complete schematics, the full BIOS code and a complete BOM. It was mostly protected by legal frameworks, not obfuscation.

FWIW, while this is a reasonably good book (though stay away from the Disk section, IIRC it completely misunderstands the way the Apple encoding works), consensus is that "Understanding the Apple II", by Jim Sather, is the clearly best work on the subject: https://archive.org/details/understanding_the_apple_ii

Mysterious Orange Line — Before leaving the subject of HIRES, we must discuss the “Mysterious Orange (or Pink) Line.” This vertical line appears from time to time along the left edge of the screen (Reference 8.2). The phenomenon is rooted in the hardware. Notice in Fig. 8-28* that when the video is shifted one clock cycle by A11-9, 70 nS of garbage is shifted such that it falls within the unblanked portion of the screen (point Z). This unwanted half-dot ends up in the video output at point AA (the left edge of the screen).

Can we determine where this dot comes from and what its value is? It comes from bit 6 of the memory location that maps to the video address just to the left of the left-most byte displayed on the screen. If bit 6 of this critical location is set, and if bit 7 of the left-most byte is set, then there will be a half-dot at the left edge of the screen (see the last signal plotted in Fig. 8-29). The phase of this dot is such that it will be pinkish-orange in color. The critical addresses themselves can be determined from Fig. 5-8*. They are all within the 16K HIRES page. Of these locations, 128 are legitimate screen locations along the right edge of the screen. The remaining 64 are unused locations. The mapping is indicated in Fig. 8-30. You can see the Mysterious Line by running the following 20 second program.

  10 REM MYSTERIOUS ORANGE LINE
  20 POKE —16297,0
  30 POKE —16304,0
  40 POKE —16302,0
  100 P = 8192
  110 FOR I = P TO P + P
  120 POKE 1,128 : NEXT I
  130 FOR N = 0 TO 7168 STEP 1024
  140 FOR I = 127 + P + N TO 1023 + P + N STEP 128 150 POKE 1,64 : NEXT I
  160 FOR I =  39 + P + N TO  935 + P + N STEP 128 170 POKE 1,64 : NEXT I
  180 FOR I =  79 + P + N TO  975 + P + N STEP 128 190 POKE 1,64 : NEXT I
  200 NEXT N
  999 END

Fig. 8-30. Mysterious orange line.

MYSTERIOUS ORANGE LINE

UNUSED MEMORY LOCATIONS STORE THE TOP THIRD OF THE MYSTERIOUS LINE.

LEGITIMATE SCREEN LOCATIONS ON THE RIGHT STORE THE BOTTOM TWO-THIRDS OF THE MYSTERIOUS LINE.

Wow. Good to see this here. At age 17, having an Apple ][+ and this book got me started on the path to being an electronics engineer.

You still have to marvel at the fact that Woz didn't quit his job at HP until November 1976. The Apple II was launched in June of 1977. Given the lead time required to manufacture the boards, it means he designed much of what is covered in this 176 page manual in his spare time while holding down a full time job. At age 26.

I have an Apple IIc in good condition. Love that thing. It turned me into a programmer in early childhood.

Wonder what we've missed since we lost computers that turned on immediately to a prompt that you could code in, and the perceived system was "small", no piles of files that you weren't supposed to touch. It didn't feel intimidating. I think we had that magic with the early web, and now in hobbyist circuitboards.

This, and "Understanding the Apple II" by Jim Sather are two of my favorite books. It's a lot of fun to open up my Apple 2 (it's a clone but the motherboard is 99% identical), and imagine all the different ICs doing their specific tasks, and the relations between those task, with these books as a guide.

I had both versions of the Sather book, for the II and //e. I bought the Apple when I decided these computer thingies were catching on, and I wanted to learn how they worked. I had to drop back to Don Lancaster's TTL Cookbook to get a basic understanding of logic blocks.

I always found it useful to have a question in mind when you start tearing into something. In my case, it was "how does it know that an "A" on this TV should be composed of just those dots? Why can't I have other fonts? You can't search for only these answers, or you'll miss the important stuff. Eventually, I learned mostly how it worked (the A2D2 Disk Interface card was a revelation).

Then I decided to close the loop on my question, and modify the Character Generator ROM to use a typeface of my own choosing. The chars were stored backwards, due to how the bits were clocked out of the ROM. So I had to do a bit of fiddling to get everything right, then I burned it into an EPROM (2708, IIRC). The stock ROM used a 2500 series PROM, and the enable pins were different. So I wired up two sockets, jumpering the 3 enable pins to line up for the EPROM. The entire mobo was socketed, which made this sort of hardware hacking easy. After a couple of tries, it was working. My //e still has my own custom font on it to this day.

So I was able to learn at a good time. But I missed out on learning about big systems, which were still the mainstream at the time. I even worked with some of them (a Data General Nova at work, and an IBM System/3 to learn FORTRAN IV), but did not realize they were an opportunity to get in to the scene early. Others my age, who lived in more affluent areas, were able to learn early machines, even being paid to program them.

The past always looks better, or simpler, or more understandable, but it never is. The "Good Old Days" never were. You can learn things with today's systems that I will probably never be able to understand. And that's the proper way of things.

Anyone have info about the author, Jim Sather or James Fielding Sather My searches turned up nothing ....

Can you imagine if documentation like this was available for modern hardware?!

Even something "open" like the raspberry pi doesn't have this level of detail available. The process of deep but accessible technical documentation appears to be a lost art.

You're just using the wrong part. If you get an STM32 or NXP iMX, there are tens of thousands of pages of TRM available to describe the function of every block inside the SoC. The core iMX7 technical document is over 7,000 pages.

You won't get everything, especially anything ARM has licensed out to the chipmakers like the CPU/NVIC/AHB, but it's a lot deeper than you probably need.

This. One of the reasons the i.MX series of SoCs shows up so often in open source circles, and elsewhere.

i.MX isn't perfect, like there are still closed-source microcode blobs for things like SPI DMA, but it's better than nothing. You can at least build it into a design without having to worry that the supply of boards is being strangled.

The Raspi foundation isn't open. Full stop.

They don't share schematics. They don't share source code. They barely tell you anything about the custom chip(s) they're now putting in the raspi for GPIO and ethernet/USB. You can't buy them. Hell, they've used custom SoCs made for them by broadcom for years now, which they have exclusive access to.

The only "openness" that the raspi foundation engages in is upstreaming of drivers into the mainline kernel and into mesa, which is ultimately self-serving in the end. It reduces the burden on their end of carrying patches for their kernel and ensures other linux distros also pick up some of the slack supporting their products.

As for those broadcom chips? get used to it. All modern hardware of any reasonable capability has all the docs sealed behind NDAs that you have to buy a LOT of chips to even get offered. Even then you're expected to take the package deal that the silicon vendor hands you and not invent anything yourself. Chipmakers offer "full ecosystem solutions," not general-purpose parts.

Yep, it is odd that the CPUs on Raspberry Pis have so little documentation.

It's Broadcom. It's totally normal. The docs exist, you just don't get them unless you're buying massive amounts of raw parts.

Reply on news.ycombinator.com