No; I'm pointing right at it as a feature, not a bug. I intended explicitly to highlight the bus efficiency. That's why I also said, slap a 16-bit bus on the 65816, and you can reasonably expect it to outperform the 68000 by quite a safe margin.



This is exactly true of the 65816 too. The reason most folks don't actually exploit this is because the 65816 doesn't actually have time-consuming instructions like MUL or DIV. (The time-consuming instructions it does have, MVN and MVP, are block-move instructions which are memory-bound). However, Andrei Fachat has implemented the required circuitry in his PET/65816 project (see http://6502.org/users/andre/pet816/works.html) to properly "eat" internal cycles that don't use the bus.

We also see this (albeit in a different way) on the SuperCPU for the Commodore 64 (at least; perhaps others too), where the 20MHz 65816 is churning along in its fast RAM at native speed while the VIC-II chip continues to access memory at 1MHz. Updates to VIC's frame buffer, then, requires the 65816 to slow down. The SuperCPU does this only for those cycles which touch C64 motherboard memory; all other cycles remain at full speed.

Is there complete information on the SuperCPU published somewhere? I'd sure like to read that.

Thanks for starting the new thread to answer this! But, perhaps better, let's use this previous thread:
viewtopic.php?f=4&t=2437

The SuperCPU has a 1-byte write buffer between the 20MHz and 1MHz buses, so if you keep approximately 20 cycles between writes to the C64 mainboard, the CPU is not required to slow down. IIRC

The Super NES, however, does throttle its 65816 between around 3 different frequencies depending on the memory area you're accessing. It can also do weird bus timing & interleaving with independently running cartridge-based coprocessors. IIRC²

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

For the 65C816, I'd be more interested in a version that has demuxed addresses. I've read that WDC may make FPGA cores like this available. It would have been interesting if Stefany had used such a modified '816 on her Foenix, and preferably one that boots into the native mode. That way, the board logic could have been simpler, the unusual bootstrapping could have been avoided, and it could have been faster. She already used several FPGAs. While it was likely not necessary to use so many, that was done more to give somewhat more of a retro spirit (pretend those are new Commodore ASICs) and for educational purposes (easier to follow).

To be clear, I'm not criticizing Ms. Allaire since she did a great job in creating a system around a stock '816 and it has sound features that many would have coveted during the '80s. Too many have dumped on her unfairly, and she quit making the Foenix. However, if someone wants one, she has made the gerbers and IPs available. Yes, she will only release the compiled versions of her custom chips, to prevent corruption/theft of her design and to help curb intellectual laziness. If you want to add enhancements, then you are free to code your own.
---

While discussing modifications of the 6502 and family, I like the changes that the 65CE02 has brought. It eliminates the side-effect reads and puts those in the pipeline, making single-byte instructions take only 1 cycle, thus improving performance up to 25% at the same clock rate. Plus it adds a few word instructions, adds a few new memory modes, adds a right shift, and adds the ability to move page zero. The additional instructions, memory modes, stack features, longer conditional jumps, and the ability to move page zero allow for faster and more efficient programs. A TTL version of this variant would be interesting.

The W65C265S does just that, However...



I'm not sure about the unusual bootstrapping of the Foenix board, but the '265 has an on-board ROM that can be disabled at power on time, but it needs a little counter/CPLD to accomplish this, otherwise you need to let the on-board ROM start, then let it find a magic sequence in an off-board ROM to enable control transfer. This is (IMO) somewhat sub-optimal and a single pin input - "on-board ROM enable" would have made life much simpler for me and I'd have used it on my own '816 designs. However my own '816 systems use a single GAL for the "top-8" address line generation without any issues.



I was interested in the project in the early days but it took longer than my own '816 system, and it's stupidly expensive in the UK where I am, so I'm sticking to my own for now.



45 years later and I'm mildly curious about what the 6502 could have been, but for me I like to stick to what it was then and work with what I have now. (But the same goes for other 'retro' computing items I have and work with, so maybe that's just me!)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

What would be interesting would be an FPGA that has all the 6502 variants in one place and a system built around that. They each have their advantages.

The original is the most known and most compatible with older software.

The 6507 is the cut-down version used in the Atari 2600, and if you were to make your own 2600, you could likely use a regular 6502 and everything would just work. It would be nice if someone made a 2600 clone that uses the full 6502 and a way to insert 2 different types of cartridges. I imagine if the original game designers had the full 64K available, the games could have been more impressive.

If you want port connections, then you'd need a 6510 or an 8502. The 8502 is much like the 6510, but slight pin differences, faster speed, uses less power and gives one more port bit.

The 65C02 removes some of the undocumented opcodes and adds some new instructions. It may have removed at least 1 useful one that programmers used.

The 65CE02 is an optimized 65C02 that can give 25% more performance due to 1-byte ops taking 1 cycle. Since smaller fabrication was used, they could add the logic to put the side-effect reads into the instruction pipeline. So no need to discard a byte that was read (and assumed to be an operand) during the decode step for the previous byte and then fetch it again to use as an instruction. It also added memory access modes, added a couple of extra registers, and allowed page 0 and the stack (page 1) to be moved around.

And of course, there is the 65C816 that is 8/16 bits and has a 24-bit address bus (multiplexing the data lines) and can theoretically support up to 16MB.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Apparently, I was misunderstood. I didn't mean to make it sound like I was saying the 'C02 added any undocumented instructions, just instructions.

And if you can use the data bits for address bits, that counts as part of the bus.

And as for "theoretical," that is a reference to the boards using them. You don't have to access past 16-bits of address space. So the board makers are who make that theoretical. If you want to keep the design simple, you can stick to 16-bits without adding latches and other complexity.

The 8088 could have been faster if Intel had used a 48-pin form factor (though that was problematic at that point in history). The board could have been simplified and maybe clocked faster due to dedicated data lines. Of course, the address lines were used for everything -- addresses, data, ports, and interrupt signaling (it has to know which interrupt is being requested when the interrupt or NMI lines were thrown, and that goes on the bus). So the 6502 had an advantage over 8088 due to separate address and data lines (and being a true 8-bit CPU). Any seeming 8088 advantage at that point in time was due to its clock rate (4.77 Mhz over 1-2 Mhz).

[oops]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)