Rockwell and WDC had 65C02's up to 4 MHz relatively early on, but the 4 MHz versions seemed to be quite rare. WDC now has 65C02's rated at 14 MHz, but they go quite a bit higher than that if you've got fast enough RAM.

There are some technical details on why a 4MHz Z80 is roughly equivalent to a 1MHz 6502. As always with processor design there are tradeoffs in every decision. The Z80 had a 4-bit ALU, but I'm not sure if that slows it down.

The Z80 has a more complex architecture than the 6502. A 6502 clock cycle is one bus cycle and simple instructions can execute in one clock cycle. For the Z80 a clock cycle is called a T-state, and one machine cycle consists of multiple T-states. A simple instruction like INI takes 4 T-states.

Not quite: the design is such that even the fastest 6502 instructions are two cycles. Still, generally quicker clock-for-clock than a Z80.

There is also some tiny pipelining at play: the 6502 needs to access (read or write) memory on every clock cycle. A 2-cycle instruction reads the opcode on the first and the actual work is done on the second. This leaves the second cycle's memory access open for doing something cool like fetching the next instruction's opcode.

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.

>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.)

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

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>

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?

> 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.

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/

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

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

I don’t know how you remember that considering it doesn’t.. I’m as rabid a 6502 fanboy as you might meet (and have been programming them for some 40 years or so), but that’s not a competition it wins, all 6502 coders know that ;) We think it does because usually the 6502 machines have oodles of (ab)useable hardware ;)

Per clock cycle, the 6502 could do a lot more compared to the Z-80. For instance, a 6502 can read from memory on every cycle, so it can execute one instruction while fetching the next. A NOP takes four cycles to complete on a Z-80 and only two on a 6502. The Z-80 also has a 4-bit ALU and has to operate on 8 bits on two passes. Finally, another very clever thing with the 6502 is the single byte addressing, which kind of gives it 256 “registers”. Of course, it has a single byte stack pointer, which makes languages like C or PASCAL a terrible match for it. Z-80s on the other hand have much more complex instructions, which make Z-80 code denser, something very important in those days.

Apple /// was 2MHz and it was a disaster.

It slowed down to 1 MHz for I/O and Apple ][ compatibility.

I wouldn't call it a disaster, sales and marketing wise mainly, but that also had a lot to do with the IBM PC coming out around the same time.

It was probably the most complex 6502 design, and mainly consisted of discrete logic chips rather than custom chips that other manufactures were starting to use. It had advanced features like an additional addressing mode to access up to 512k RAM without bank switching. (Plus two speed arrow keys)

It was a disaster for a lot of reasons but not because it was a bad architecture.

It overheated, unseated chips, had a non-functional clock chip and other kinds of terrible quality controls. It also had to compete against the IBM PC while Apple still didn’t even had added lowercase input to their II+.