3

The candidates are:

  1. Apple IIgs, with its 2.8 MHz 65816 CPU, running in 65C02 "emulation mode"
  2. Apple //c+, with 4.0 MHz 65C02, but overclocked to 8.0 MHz
  3. Laser 128EX with 3.6 MHz 65C02

I want to know which is fastest for real world applications, like running AppleWorks, a BBS, terminal emulation, assembler/debugger, etc.

The reason I'm thinking the answer is not simply "It's the 8 MHz one, dummy" is because of memory architecture - i.e. How does each machine access standard program RAM and at what speed. I know the //c+ essentially has an on-board accelerator that relies on SRAM cache for full-speed CPU operation. The IIgs has no cache. I don't know about the Laser memory architecture.

NOTE 1: It's reported that the //c+ can be successfully overclocked to 10 MHz, but I have not had that working with any stability. 8 MHz seems stable.

NOTE 2: I'm sure we (meaning me personally) could try to validate the correct answer with a suitable benchmark run on all 3 machines. I don't know a good benchmark to use, and would welcome that info as part of an answer. The key is the benchmark would have to account for use of cache appropriately. Any benchmark that runs fully from cache would skew results in favor of the //c+. A realistic benchmarking suite probably existed at some point in the Apple II's lifespan.

NOTE 3: The correct answer is certainly NOT the IIgs running in native mode. That's not even an "Apple II", since it wouldn't run the legacy software library in that mode.

NOTE 4: I know this is a "hard question". I've not found any information online about how the 65C02 was interfaced to main memory in these machines, and what impact that had on overall system performance. My gut feeling is that the SRAM cache is a hack, and high-speed access to main memory should be the big performance differentiator.

  • 1
    Are you claiming that in 15 years of Apple II usage nobody ever created a realistic benchmarking suite, and there is also no way to make technical inferences about the relative performance of these 3 machines given in-depth knowledge of the 6502 and their respective memory architectures? – Brian H May 24 '18 at 16:30
  • 4
    In 60+ years nobody has made a "realistic" benchmarking suite of any kind (IMHO as somebody who has spent a lot of time with interpreters, compilers, and graphics hardware), but that's a pedantic point. I don't recall any dedicated Apple II benchmarks, though there were things like function plotters and fractal landscape generators that could fill the role. Assemblers are a poor choice because you can only fit so much source code into RAM, so either it finishes quickly or it's I/O bound. Related: groups.google.com/forum/#!topic/comp.sys.apple2/buTFvk-VnTo/… – fadden May 24 '18 at 16:45
  • 1
    I'd take any benchmark as just empirical evidence to backup a sound technical claim of performance superiority. single benchmark never tells the whole story. – Brian H May 24 '18 at 16:58
  • 3
    Given that the 6502 performs a memory access every single cycle regardless of need and (mostly) without any indication as to necessity, I would guess that every faster Apple II is going to need a faster memory cache and that the only difference you're going to see in terms of how the Mhz compare is whether the cache is write-through or write-behind, and that the latter feels improbable. So unlike other commenters, I think a real how-the-hardware-functions answer is available here. Somebody who knows the three memory subsystems can give a definitive, compelling answer. – Tommy May 24 '18 at 17:33
  • 1
    @BrianH It's not if someone created a benchmark, it's that YOU need to tell what's the metric you want to be measured. As said before it depends on the task you're seting whoch computer comes out fastest. – Raffzahn May 24 '18 at 20:06
4

The simple answer is MHz wins.

Why?

Because otherwise, what's the point. What's the point of making a "faster" machine, if it is not, indeed, faster.

To specifically highlight the details of the question, the IIgs has "slow RAM" specifically designed to maintain compatibility with the the original Apple II. It down clocks to the 1MHz range for low RAM so as to better behave with legacy software and the legacy video. In this mode its as legitimate an "Apple II" as it can be. So, in this case, it's not faster.

The IIc+ had to be started in either 4MHz or 1MHz mode. If you couldn't be running the "popular software at the time" (whatever that may be) at the faster rate, then, again, what's the value? I'll skip games, as games, especially during that era, were notoriously tied to the CPU speed. (Lode Runner at 8Mhz -- Whee!!) There's a reason IBM PCs came with "Turbo Buttons", and it wasn't for word processors.

I don't know anything about the Lazer.

But, simply, the IIgs was particularly sophisticated because it offered not just the new cpu, but the new video and other peripherals far and away above what the Apple II offered. It was truly a different computer, but had Apple II compatibility vs a "better" Apple II.

But the IIc+, it WAS a "better" Apple II, so it didn't have the Chimera nature of the GS. It just had a switch to make it a faster Apple II.

Any Apple II compatible benchmark, even a Sieves written in BASIC (since I don't think they updated the BASIC in all that time to where one was better than the other) would be a legitimate benchmark. In a perfect world, something that exercised the ram space in machine language (for example a thorough memory test, over the same amount of memory) would be a good candidate as well. CPU and Memory heavy.

  • Re: games in that era being tied to the CPU speed, I believe there are no interrupt sources or other counters or times on an unexpanded Apple II. So you've really no other options. I guess you might be able to do something with vapour lock (i.e. watching the bus for video data which, if you've set it up to be unique, means you can make observations about the scanning position) but you'd limit what you could display and end up spending a decent amount of your time doing that. Unlike programming for the PC with its PIT, where programmers were just in a bad habit. – Tommy May 25 '18 at 0:13
  • Even early PC Games had this problem, I had several games become "unplayable" when the AT came out and other faster machines. – Will Hartung May 25 '18 at 0:21
  • 2
    Except that a) the IIgs can runplain Apple II programs at full speed and b) The IIc doesn't run at full 4 MHz in 4 MHz mode, but gets slowed down a lot depending on memory access. Bottom Line, a 2.8 MHz IIgs can be faster with legacy software than a IIc+ in 4 MHz Mode. – Raffzahn May 25 '18 at 9:35
0

Caveat: This is not realy an answer, as above question can not be answered, as test (benchmarks) can be made up to show either as fastest - or not.


The machines have different features, which are not only defined by CPU speed:

  • A IIgs does have a large memory and can thus handle large amounts of data without any disk I/O. Of course only by using 65816 code.

  • Any 65816 programm will not run on a IIc+ so it can't be compared.

  • A programm using IIc+ memory expansion can also handle huge amounts of memory - but it needs to follow the IIc+' memory structure, thus it can't run (without substantial porting) on a IIgs using it's larger memory

  • Just language card extension and the IIe's 128 KiB are available on all these machine - doing common code would restrict it to only the basic features.

  • Depending on the memory locations used the very same (6502) programm can run at 2.8 MHz, or 1 MHz speed - or somewhare inbetween on a IIgs.

  • On the IIc+ programm structure plays as well a huge role when going for speed - but based on different factors then with the IIgs

It might be noteworth that even Apple themself only claim a 90% compatibility of the IIc with the earlyer models - so it might be even less for models mentioned here.

A comparsion will always give an answer related to the task and its implementation - not just the machine it runs on - unless we restrict everything to some IIe comptible minumum - which ofc, leaves everything the newer machiens offer outside - like restricting a Ryzen based PC to 1 MiB :))

But even then, programs can be constructed to let each machine win at will.

For example by defining the fastest keypoll as benchmark, like this:

KEYIN   BIT  $C000
        BPL  KEYIN

Running this we will note that all of them are the same, no matter what speed is set or if a cache enabled or not. So?


Conclusion: Come up with a real benchmark case, and people may be able to rank the machines - but don't show a surprised face when the next one reverses the list.


For the notes:

NOTE 1: It's reported that the //c+ can be successfully overclocked to 10 MHz, but I have not had that working with any stability. 8 MHz seems stable.

It doesn't matter if overclocked or not, as differences are about the system structure. Especially not how much.

NOTE 2: I'm sure we (meaning me personally) could try to validate the correct answer with a suitable benchmark run on all 3 machines. I don't know a good benchmark to use, and would welcome that info as part of an answer.

Hint, there is none - but beside, if you want a ranking, you need to come up with the criteria. Otherwise it's fishing in the dark - or as it's called here: OPINION BASED

NOTE 3: The correct answer is certainly NOT the IIgs running in native mode. That's not even an "Apple II", since it wouldn't run the legacy software library in that mode.

Why it isn't? Mind to explain? A IIgs in native mode can run next to any IIe programm without much problems. Keep in mind, the CPU is 100% upward compatible.

NOTE 4: I know this is a "hard question". I've not found any information online about how the 65C02 was interfaced to main memory in these machines, and what impact that had on overall system performance. My gut feeling is that the SRAM cache is a hack, and high-speed access to main memory should be the big performance differentiator.

Why should it? Beside being again too broad and opinion based it depends very much on internal structure if a programm will harmonize great with a cache or not. A faster memory only wins in a worst case szenario - wich again could of course be produced with the 'right' benchmark.

  • "...as above question can not be answered, as test (benchmarks) can be made up to show either as fastest - or not.". Pretty much nonsense. It's clear he's talking about an Apple II running Apple II code. Not which machine has higher MIPS or anything else. Any "Apple II" benchmark will answer the question handily if run on each machine in question. If you think it's a bad question, down vote it or vote to close it. – Will Hartung May 24 '18 at 22:07
  • @WillHartung "...It's clear he's talking about an Apple II running Apple II code..." Is it? I can't see that in there, also it's not specified what Apple II code - one using only features for a II, a II+, a IIe? and so on. But come on, if you know any of your easy stated Apple II benchmarks ('Any' as you said' , why not present some? – Raffzahn May 24 '18 at 22:12
  • Follow-up question, if I may. I think the GS provides a write-through cache of the full low 64kb so the rule is that reads occur at native speed, writes occur at 1Mhz. But the IIc+ has a more conventional 8kb of cache (seemingly upgradeable to 32kb if you know how to solder?) that sounds like it's tagged much like a modern CPU cache, so presumably is subject to cache misses and resulting stalls? Have I researched that correctly? If so do you have any insights on the functioning of the IIc+ cache such as it might affect timing? Is it write through? It it loading whole pages en masse? Etc. – Tommy May 25 '18 at 14:45
  • 1
    @Tommy For the IIgs: not realy. it's a bit more complex. When accessing fast memory the 65816 operates on 5 14 MHz cycles per CPU cycle. 2 for phase 1 (internal) and 3 for phase 2 (memory access), giving a 40:60 duty with an effective 2,8 MHz clock. The Mega2 runs on 14 14Mhz cycles as 7:7 (phase 1/2). Now whenever the 65816 accesses slow or shadow memory, it gets synchronized to the next Mega2 phase 2. This may take between 0 and 13 14 MHz cycles. After syncing the 65816s phase 2 will be stretched to 7 cycles - the full 'slow' memory access time. (cntinued) – Raffzahn May 25 '18 at 14:59
  • 1
    @Tommy Thus a memory access for slow/shadow memory does take between 7 and 20 14 Mhz cycles. with the 2 cycles of phase 1 (65816), this is 9-22 cycles or 0,6-1,5 MHz for this access cycle. If programm and data is in slow memory it will result in 1 Mhz effective speed. But wait, then there is shadow memory. Here all read cycles do occure at full speed, only write cycles are slowed down. And legacy application are/can be executed for there - resultin in next to full 2.8 MHz effective speed. And yes, tehre are programms using these sub cycle features for timing on the IIgs. – Raffzahn May 25 '18 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.