Hacker News Reader

Comment by dhosek | Hacker News Reader

But so much of the Apple II design was focused around minimizing chip usage and counted on exact timings that I don’t know that it would have been possible to change the clock speed. Add in the fact that there was no access to a real time clock so things like timing delays counted on things like run this empty loop 100 times, or the fact that the graphics memory layout was tied to how the electron beam on the monitor refreshed pixels or the reliance on a quirk of timing of the 6502 processor in the disk II controller hardware and I don’t know that a 6502 at a different speed could possibly work.

View on HN

>But so much of the Apple II design was focused around minimizing chip usage and counted on exact timings that I don’t know that it would have been possible to change the clock speed.

A recent Adrian's Digital Basement video <https://www.youtube.com/watch?v=dt1eSXpo1SA> discusses this topic. While showing how a 80286 system runs at 1MHz, he discusses how the PC architecture allows (most) software to run at that clock speed while the Apple II architecture and software are inherently tied into the 1MHz clock speed.

In retrospect it seems so sensible to have the IIe and IIc in 1983 and 1984 move to, say, 2MHz, that I'm sure that fears of breaking software compatibility contributed to that from happening. (That almost certainly would have been a short-term problem. Given how quickly the Apple II software moved en masse to 128K/80 columns by the mid-1980s, developers would have accounted for a faster clock speed too.)

The Apple /// ran at 2MHz but would slow down to 1 for expansion bus IO and Apple ][+ emulation.

The III's II compatibility mode ramps that down to 1MHz, and has other restrictions to make sure that II software cannot use any III-only features.

Without III sucking up all of Apple's R&D budget and attention c. 1979-1980, the Apple II would surely have seen earlier enhancements. The II+ (1979) would likely have had lowercase and better keyboard (which did not occur until IIe in 1983), and a new model in, say, 1981 might have shipped with an optional Apple 80-column card (again, with the IIe in actuality). Built-in 128K RAM probably would not have occurred until 1984, akin to the IIc's introduction, but earlier support for RAM expansion alongside 80 columns is possible. One of these models would likely have had the 2MHz clock, too, while no II in actuality shipped with a faster clock until IIgs in 1986.

I never felt the IIgs to be an actual Apple II. It feels like a different computer that can almost accurately emulate a //e or //c, but has that inelegant impedance mismatch between. I also get the same impression from the Commodore 128, but feels even worse that it needs to drop to 1MHz to use the C64 video modes, and don’t even get me started about its Z-80 side.

Relevant: <https://np.reddit.com/r/AppleIIGS/comments/vaaogf/is_there_e...>

and

<https://np.reddit.com/r/atari8bit/comments/po7m4z/in_defense...>

Also, <https://news.ycombinator.com/item?id=32041096>

Even PCs had a Turbo button for quite a long time.

There was a 4 MHz 65C02 model .. but not until 1988: The Apple IIc+.

You could lower the clock speed to 1 MHz for programs that relied on it, but the 65C02 did not support the unofficial/undocumented instructions of the original 6502 so there were still some programs that did not work.

The IIc+ was such a refined form of the II. Motorized 3.5" floppy, integrated power supply for maximum portability (I'd take it to do basketball stats for the high school team), platinum color that carried through to Macs until the iMac.

I need to fill out the missing pieces of my Apple II collection. Most of it is still in Brazil, and they are all clones. At least a //e platinum and a //c, preferably a plus, but I can’t be picky.

A higher priority is a graphics-capable VT terminal to act as a reference for a promise I made to the VTE team. Unfortunately, they are incredibly rare this side of the Atlantic.

The Enhanced IIe and the original IIc also had the 65C02 (at the original Apple II clock speed).

There were Apple II accelerators, like the Zip chip. Some clones, like the Laser 128/EX, also ran at higher speeds.

The big deal is video and RAM timing. If the memory is twice as fast, you’ll still be able to read from it for the video refresh at times the CPU won’t be able to. Also, I think DRAM refresh was done on the video timing. You’d need to rework all the logic on the board, but that was doable when they built the Mega 2 chip (and done in the IIgs FIP). The trickiest part would be the Disk ][ interface, and disk I/O done on it, as everything was timing-critical. A different disk controller that doesn’t rely on timings would be able to function.

As for program timings, you don’t need an RTC. You want timers and interrupt generators. I believe the //e and the //c could generate interrupts on vertical blanking. For a game you could run all logic and drawing and set up the interrupt vector so that the next interrupt starts the next game cycle. To count time, a cycling timer that increments on vblank would be quite enough. IIRC, MSX had one of those.

> I believe the //e and the //c could generate interrupts on vertical blanking

VBlank interrupts were only available through the Mouse Firmware, which was built into the IIc but a rarely-installed option on the IIe. As a result, there were no interrupt-driven games for the 8-bit Apple II machines.

The complete lack of consistent frame rates and timing is a hallmark of Apple II gaming.

Conversely, screen interrupts were at the core of Commodore 64 games, and of the demoscene. And also of arcade machines, NES and the whole next generation of consoles and non-IBM computers.

So I wonder why it wasn't added. It wouldn't have been hard, exactly (enthusiasts for the TIKI-100, a Norwegian educational 8 bit, have gotten into the habit of repurposing the printer interrupt by means of a dongle in the printer port).

Was the idea that educational machines shouldn't be too game-friendly?

They could at least be aware of real time. A default vblank interrupt handler that increments a 16-bit counter would be incredibly useful.

the idea was the original Apple II was made in 1977 as a game machine (Woz wanted to play breakout in software) but there really wasn't much of a concept of what a "Game Machine" was back then, it was mostly a huge hack trying to get minimal chipcount

years later when the c64 and IBM PC came out, the IIe was released which did have vblank support, but Apple II devs were reluctant to break backwards compatability.

You can still do a lot of cool games w/o vblank support. I'd say it'd barely makes the top 5 list of most annoying things about programming games on the Apple II.

And all these other "better" platforms, tell me do they have a port of Riven? http://deater.net/weave/vmwprod/riven/

> So I wonder why it wasn't added. It wouldn't have been hard, exactly

The answer to the question "Why didn't Apple add X/Y/Z to the Apple II?" is that they did add those features, starting with the Apple III in 1980, and continuing with the IIc and IIgs.

The problem is that there was a 2-year window between the release of the III and the explosion of the home/education market that Apple ignored the II and assumed sales of that quirky, obsolete system would dry up.

The IIe was designed within that window, and the skeleton crew of engineers who worked on the IIe did not have the green light to add significant new features. The only goal was to reduce manufacturing costs and maintain compatibility.

It wasn't until after the IIe was locked in that the Apple leadership began to realize the importance of the II within the suddenly booming home/education market, and only then did they put any significant resources back into the platform.

The IIc (1984) and IIgs (1986) were the result of those renewed efforts, but by that time the cat was already out of the bag. The IIe remained the most popular machine of the platform, and the "modern" features added to the IIc and IIgs were left unused by most developers and users.

Afaik you can do Vapor Lock on Apple - poor mans VBlank detection: http://deater.net/weave/vmwprod/megademo/vapor_lock.html

That’s processor intensive. What’s the minimum number of cycles required to detect a vblank?

yes it is, but it does not matter if you have finished rendering and now just waiting for the next frame.

IIe and IIc have a vsync status bit that you can poll, but IIRC the polarity was flipped between the two models and there are other quirks that can interfere with using it, so it was neither recommended nor popular.

it's more complex than that, I think IIe and IIgs have the same register but polarity reversed, the IIc has a weirder interface that generally involves setting up an interrupt through the mouse firmware

Reply on news.ycombinator.com