> <i>"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!"</i><p>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!").<p>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.<p>Later, more-successful systems used a kinder, gentler approach (please use the provided firmware/bios interfaces please).
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.<p>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.
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.
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.<p><a href="https://robterrell.github.io/shape_table_maker/shape_draw.html" rel="nofollow">https://robterrell.github.io/shape_table_maker/shape_draw.ht...</a><p>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.<p>Anyway, if you are curious about shape tables, here's a thing for you.
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.
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: <a href="http://deater.net/weave/vmwprod/riven/" rel="nofollow">http://deater.net/weave/vmwprod/riven/</a>
> I'm going to break with my usual habit of ][ and use "Apple II" for the rest of the post.<p>It very slightly bothered me that "][plus" was typeset before this, but it was "IIe" and not "//e".
> Many vintage computers are defined by their fonts.<p>But the article doesn't mention my favorite ASCII table ever, known as the "running man character set":<p><a href="http://www.lazilong.com/apple_ii/a2font/readme.html" rel="nofollow">http://www.lazilong.com/apple_ii/a2font/readme.html</a><p>It includes open and closed apples, sand clock, and elements to build GUI's: windows, tabs, scrollbars, and even a pointer!
> <i>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.</i><p>So there is no way to race the beam on an Apple II like an Atari 2600/VCS can?
Relevant:<p>How Steve Wozniak Brought Color to Personal Computers
<a href="https://www.youtube.com/watch?v=uCRijF7lxzI" rel="nofollow">https://www.youtube.com/watch?v=uCRijF7lxzI</a>
<i>> "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><p>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.<p>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.