16

The CSG 65CE02 is an improved 6502 microprocessor that was shipped in small quantities by Commodore around 1988. It is used in the Amiga A2232 multi-port serial controller card, and that would be the source for scavenging one for the Apple.

The 65CE02 contains too many performance improvements to list here. Suffice to say it can at least be a performance-enhanced 4 MHz 6502 replacement (I think!), and might be capable to be overclocked to 10 MHz. I am familiar with over-clocking the Apple //c+ to 8MHz and 10MHz. The "dream machine" would be to swap the 65CE02 with the 65C02 in the //c+ and overclock the system to 10 MHz.

Even just running the 65CE02 in an Apple //e at the stock 1 MHz speed would seem to provide some acceleration, because the 65CE02 is an improved CPU in a number of ways.

Is such a CPU swap for any Apple //e, //c, or //c+ possible and worthwhile?

Improve this question
2
  • 2
    There is a data sheet for the 65CE02 here: archive.6502.org/datasheets/mos_65ce02_mpu.pdf
    – Brian H
    Commented Mar 9, 2017 at 22:27
  • You could get a small improvement doing this on a BBC Micro. But there were drawbacks. The principle should be similar on an Apple.
    – Chenmunka ♦
    Commented Mar 10, 2017 at 6:28

4 Answers 4

Reset to default
14

I don't think it would work. Two main reasons come to mind:

  1. You probably need an external clock that is running at (say) 4MHz to have the chip run at speeds over the default 1.024MHz.
  2. The ZipChip / RocketChip were more than just a faster 65C02 as they also had intimate knowledge of what memory addresses could run faster and which ones couldn't.

The Zip/Rocket chips probably had internal multipliers to get the variety of speeds that they would run at since the clock provided by the Apple II was not modified. However, the chips were smart enough to know where to slow down since some of the hardware on the Apple II was CPU timing dependent. Two items in particular are the analog paddle inputs and (somewhat famously?) the 5.25" disk controller.

The disk controller completely relied on the exact timing of the CPU since all of the read/write operations were done in software rather than in hardware (e.g. the smart Commodore 1541 or Atari 810 were separate computers with their own CPU). For example, if it was reading a track, the CPU was furiously tracking the bits coming out of the controller to detect sectors, data, etc. This design may not be very efficient from a CPU perspective, but from the hardware point of view it saved a massive amount of cost and chips and also enabled the Apple II disk to be more flexible than anything else in the home market at the time.

With Zip/Rocket chips, you can disable this speed throttling for just about everything; WAIT routine, speaker access, any slot (and their I/O mapped ROM/RAM space) and so-forth. While you would be able to boot the machine with everything running at full speed, you wouldn't be able to use the 5.25" disk unless your disk was spinning 4x faster :-)

UPDATE: to make one other point, if the 65CE02's improvements are simply additional OpCodes and the timing of everything else remains the same, then there shouldn't be any reason that the swap wouldn't work. In fact, I believe I've read of people swapping out their 65C02's for a version of the 65816 that fit in the 40-pin DIP package and thus they'd get the benefit of a 16-bit processor and instructions, though still limited to the 16-bit address bus.

Improve this answer
5
  • 2
    I didn't mean to suggest the 65CE02 would run at a different clock speed than the machine was already capable of running with a 65C02. For example, the 65C02 in the //c+ is already clocked to 4 MHz. I was also thinking that a //e with a 1 MHz 65CE02 would still be an improvement over the stock chip, based on other performance enhancements. I edited the question to reflect this more precisely.
    – Brian H
    Commented Mar 9, 2017 at 19:41
  • 3
    @BrianH, I don't know how the //c+ gets its clock, though from what I've read it is basically a ZipChip disassembled on to the motherboard (thus either has its own 4MHz clock or the multiplier is on the board rather in the DIP package). That being said, I'd still think you might get yourself into trouble if the 65CE02 has instruction-level performance improvements; i.e. if the timing is different, then the critical bits like the 5.25" drive may not work quite right. If it is just that there are additional OpCodes available, then sure.. go for it :-)
    – bjb
    Commented Mar 9, 2017 at 21:05
  • 1
    Interesting. I hadn't heard about this chip, and it would be interesting to see if it worked, but as bjb says, given that instruction timings have changed (branches etc) any disk access routines wouldn't work as is. Here is the data sheet.
    – Nick Westgate
    Commented Mar 9, 2017 at 21:16
  • 1
    I was considering it important that the 40-pin DIP 65CE02 is pin compatible with the 65C02. Basically hoping its a direct swap of socketed CPU chip without breaking anything, and may be combined with higher clocking adaptations that already exist for the machine.
    – Brian H
    Commented Mar 9, 2017 at 22:36
  • 3
    The 65CE02 had different cycle counts for some instructions. For example, all the one byte instructions that took two cycles on a 6502 only took one cycle on the 65CE02.
    – JeremyP
    Commented Mar 10, 2017 at 10:11
5

In 2014 I installed a 65CE02 (removed from an Amiga A2232 serial card) into an Apple IIe, for the purpose of confirming the bug in the 65CE02 decimal subtract, said bug having been discovered by Pavel Zima by reverse-engineering of the chip layout. In general the 65CE02 worked fine in the Apple IIe, but any speedup due to some instructions taking fewer clock cycles wasn't particularly obvious when e.g. running Applesoft BASIC programs, though I didn't measure timing of any benchmark programs.

It's possible that the instruction timing differences may make access to floppy drives unreliable since the Disk II routines (e.g., RWTS in Apple DOS, and the equivalent in ProDOS and other operating systems) are critically dependent on instruction timing. I was able to boot ProDOS, but did not use it extensively, and did not do any disk writes at all.

I took a few photos, including comparing the output of the small decimal subtraction test between the Rockwell R65C02 and the Commodore 65CE02.

To run the processor at faster than the standard clock speed is, as others have pointed out here, very difficult, requiring much additional support circuitry, because the Apple II CPU and bus timing is directly tie to the video timing.

If you have an accelerator card using the 65C02, and can run it within the rated operating frequency range of the 65CE02 (up to 4 MHz for the part I used, though the datasheet claims availability of parts rated up to 10 MHz), there's a reasonable chance that the 65CE02 would work, though with the same caveat about Disk II reliability. Apple II accelerator cards have circuitry to slow to normal speed for disk access, but that doesn't help with the difference in instruction cycle counts.

Improve this answer
4
  • With the mentioned IIc+ the accelerator circuitry is already build in. It's 3.5" drive wouldn't be influenced by the improvements at all. Since this is also the eventually best II platform to be used today it might be worth a shot - just getting 65CE02 is not as easy.
    – Raffzahn
    Commented Jun 19, 2020 at 18:17
  • 2
    Disk reading generally involves reading $C0EC until the MSB is set, processing that byte, reading $C0EC until the MSB is set again, processing that byte, etc. Incoming bytes will arrive at a rate of about one every 30-34 microseconds, and the MSB will be set for about 8 microseconds. There's thus a wide range of acceptable speeds for reading. Writing is another story. STA $C08F,X must read and write its target address on consecutive motherboard cycles, and subsequent writes must occur exactly once every 32 motherboard cycles. Being off by a cycle will write meaningless garbage.
    – supercat
    Commented Jun 19, 2020 at 18:55
  • 1
    Given that the tightest loop you can write to load A from the data register and branch back if the MSB is clear is seven cycles (and that only by using absolute addressing for the load, reading is actually not nearly as flexible on timing as you suggest. A minor change to instruction cycle count in the RWTS read routines can result in losing one "nibble" entirely.
    – Eric Smith
    Commented Jun 19, 2020 at 19:59
  • I was surprised to see it booted from what seems to be a floppy. I assumed the pipelining improvements would make reading the disk (at least the Woz-like ones) unreliable. Not sure it's luck or solid Wozniak design that allows that.
    – rbanffy
    Commented Nov 10, 2020 at 16:23
2

The 65CE02 is a descendant of the 65C02. The 65C02 fixed some bugs in the original 6502 design, and doesn't support the 6502's illegal opcodes. This means that code that depends on those bugs or which uses illegal opcodes will not work. (illegal opcodes were popular in the scene.)

You can check the differences here: http://wilsonminesco.com/NMOS-CMOSdif/

According to the wiki article, the 65CE02 is also not cycle exact compatible to the 6502. It performs particular opcodes in fewer cycles. It is said to be 25% faster at the same clock rate. This means timing sensitive code will not work, either.

Improve this answer
1
  • If the 65CE02 and the 6502 are not precisely identical with the cycle-exactness, then maybe the disk routines will not work?
    – Omar and Lorraine
    Commented Nov 27, 2018 at 10:40
2

The "dream machine" would be to swap the 65CE02 with the 65C02 in the //c+ and overclock the system to 10 MHz.

Might be possible - at least as long as the IIc+ cache runs along.

Even just running the 65CE02 in an Apple //e at the stock 1 MHz speed would seem to provide some acceleration, because the 65CE02 is an improved CPU in a number of ways.

Beside new instructions (which are less fantastic than they sound - not to mention the possible problems added by the Z register), the most important improvement might be the saved 'dead' cycles on single byte opcodes. Since these are also among the most used (e.g. INC/DEC X/Y), an over all speed up of 10-15% is not impossible. Sounds great, but then again, anything below 50% is usually not really visible in everyday life.

Also, the 65SC02 will do the same trick :)

Is such a CPU swap for any Apple //e, //c, or //c+ possible and worthwhile?

Yes and no. Except for WAI and STP the instruction set is exactly the same and unless there are timing specific routines, it should work as well. Thus a IIc+ with it's 800k drive will work fine. Classic DISK II drives may not.

And as said before, the over all gain just from the CPU is not really worth it from an objective POV. Not withstanding of course the pleasure from doing so (I did the same back in the early 80s by plugging a 65SC02 into my II+. I always had that good feeling of having an enormous fast machine - without any proof :))

Raising the clock may gain more - visibly more. Then again, as the higher clock speed on the IIc is only partial (due being a cached system atop a basic 1 MHz design), going past 4 MHz won't be as effective than that step already brought. At least every write operation will slow down (and synchronize) the faster CPU with the 1 MHz backbone.

So, yeah, go for it and don't forget to tell the results :)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .