65C816 vs 68000

[sark02]

BigEd wrote:

I'm interested to hear someone familiar with ARM still prefers 68k - can you put your finger on any reasons why?

ARM is a very nice ISA, and I prefer it to MIPS (which I've been using at work for the past decade). What I prefer about ARM is the shift operation available on ALU operations, and the ability to loads/store multiple in one instruction. ARM removed this last feature LDM/STm) from the v8 specification - it was possibly a microarchitecture wart, so perhaps MIPS had it right from the get go. Still, MIPS have delay slots which even they removed from thie r6 specification. So we'll call it a tie. Then ARM has shift ops with ALU and the shadow registers. MIPS fights back with 32 vs. 16 registers. ARM v8 counters with 32 registers. Oh.. and ARM wins _everywhere_. I think I'll call it for ARM.

What I like about the 68000 is the wealth of CISC addressing modes. ARM, being RISC, is a load/store architecture. Calculate an address (possibly by doing some register math), load your data, do some operations, store some data. With the 68000, ALU operations have a nice bag of addressing modes to pick from. It makes (for me) a smoother flow writing code. I do want I want to do in one instruction rather than four or five. ARM may have pipeline architectural advantages, and it may be great for a compiler, but it kinda sucks for a human. After a decade of MIPS RISC, I can confidently say I'm a bit tired of all that load/store manual labor.

I can't and won't defend the 68000's interrupt latency or use of the memory bus. Let's just say the 68000 uses the bus from time to time vs. the 6502 which uses the bus every half cycle. 68000 still wins for me None of my interrupts have ever been _that_ critical (but if they had been, the 68000 maybe wouldn't have been the right choice).

[BigEd]

I can see that CISC could be more convenient, as an assembly level programmer, once you've internalised all the choices available to you. (Early) ARM is simpler, but feels to me not too unfamiliar coming from 6502.

(About the multiple register loads and stores - it seems that the latest ARM offers loads and stores of register pairs. Presumably some tradeoffs went on there, to keep performance high when filling and spilling, and keeping the number of operations per instruction down to a sensible number.)

[sark02]

BigEd wrote:

I can see that CISC could be more convenient, as an assembly level programmer, once you've internalised all the choices available to you. (Early) ARM is simpler, but feels to me not too unfamiliar coming from 6502.

Familiarity is a funny thing. 6502 operates on memory vs. ARM which operates on registers. Yes, 6502 has LDA/STA, etc, which you might map to LDRB/STRB but then something as simple as ADC ADDR translates to "LDRW R2, =ADDR; LDRB R2, [R2]; ADCS R1, R2" vs. "add.b d0, ADDR". (and that first ARM instruction is a load from a literal pool).

For me, that first move from 8-bits to 32-bits was a step. Having to think about operation _width_, as opposed to all ops being simply 8-bit was, I think, the only thing I really had to get used to. Math is the same everywhere, as are conditional branches and subroutines. Syntax is syntax... takes time for the fingers to not reject it. The challenge is the privileged architecture (interrupts and exceptions). That's the stuff that takes time to get right when moving from chip to chip.

That's nonsense, of course, as nobody buys a CPU any more. Today they're embedded into microcontrollers from different vendors and have 10s of peripherals, none of which work the same from vendor to vendor. So now the challenge for a hobbyist using a microcontroller is less in the CPU and more in figuring out how to light the damn thing up at all, what with sometimes imprecise documentation or hard to find errata. The CPU is the _consistent_ part of the picture, and therefore the least challenging.

[ttlworks]

I had started with the 6502, but had what brought my attention to 68000 (and especially the 68020) was,
that I wanted to toy a bit with stepper motors.

Back then, the fastest 65816 was 4MHz, and a 16MHz+ 68020 with a 32 Bit data bus and 32 Bit registers
delivered "quite a punch" when running 64 Bit fixed point math.

The code that moved the motors was part of the ISR, it did load/store all motor related
variables and parameters by using MOVEM.L, and the code was optimized to fit into the cache.

Of course I had freezed the cache containing that code.
BTW: I was using most of the address registers as data registers, too.

A little PCB with eight L6203 full bridge motor drivers:


Nowaday, you probably would use a 200MHz+ PIC32 microcontroller or such instead of a 68020...
but in that time frame, hobbyists only had something like 8031 or PIC16C64 microcontrollers.

Of course, by the time I got the motors up and running all of the 68k CPUs already had disappeared out of the catalogs.

Edit: My tinkering with the 68020 had come to an end in 1998, but tinkering with the 68020 was fun.
...That nice feeling for several years of having built something that could keep up with a state of the art PC
(when state of the art was 80386 or 80486 back then) for a specific application.

[kakemoms]

ttlworks wrote:

After an internet search, to me it looks like there is no 65816 in VHDL yet. //November 2016.

Let's just hope, that the community does a VHDL 65816 before our only source for 65816 chips might run dry "by accident" someday.

Ok, for our 65C816 versus 68000 discussion we had "availability of chips",
and "VHDL cores as a replacement if chips won't be available anymore".

Another interesting topic would be software.
For 68k without MMU, there seem to be operating system kernals, but not so for the 65816.

;---

Another point is, that from the hardware point of view it feels like there is no "standard" when it comes
to 65816 hobby computer projects.

68K at least had the VME bus which was designed with the 68000 DIP package pinout in mind.

While 80x86 certainly wasn't the most beautiful architecture around (sorry for even mentioning 80x86),
it looks like having a standard there (IBM PC, DOS, ISA bus) made it a success.

Its an interesting point that there are no 65816 cores available. But there are numerous examples of 65xx cores that have been extended. I don´t know why WDC doesn´t sell their 65C816 core as IP since the 65C02 has been available for long.

Anyway, I think I will stick to the 6502 and build on that. Its an interesting core since its so small, and one can fit several cores into a single CPLD. The 65816 is basically a 6502 with 16 bit addressing, which shouldn´t bee too difficult to extend (if anyone has the time).

Personally I am more interested in the 6502 and 6509 since an extension of the 6502 to increase address size WITHOUT increasing code size is profoundly more interesting in the long run. Why you ask? Well, I remember when my old workplace made the transition from an IBM System/36 to an IBM AS/400 in which all our code suddenly tripled in size. What a waste!

So I think having 8-bit instruction set with the ability to extend it within an FPGA (to 16/24/32 bits addressing) on a need-to-use basis with CISC-like translations. I think that is more forward thinking with respect of getting more computing power per watt.

What I hope to test (my long-term-plan):

Dual 6502 with pipelined in/out buffer and 32-bit databus. Basically run two instructions in paralell, but in a way that translates the instructions to a CISC. For example:

Code: Select all

LDA #32
STA $02

Which is four bytes that can be read on first cycle. 6502no1 handles LDA and 6502no2 handles STA (with update of register from 6502no1). So value #32 is stored into $02 on the second cycle.

For longer instructions, more data is needed, so a cache would be put up in order to read

Code: Select all

LDA $0234
STA $E421

on one cycle (which is 6 bytes). One could probably extend the databus to 48 or 64 bits (and more processor cores), but CISC like translations are the way to go to speed things up. So for example:

Code: Select all

LDX #$80
loop:
STX $A002,X
DEX
BNE loop

Is recognized as a loop and handled by the two cores with STA in one and DEX in the other, then some logic to keep them in the cores until the branch exits the loop. The output buffer would mean that write only happens when 32 bits can be written (in the case of 32-bit databus).

There are other more complex ways of handling this as well, but I have to start somewere. Currently I have connected a Lattice MACHXO3 to a Vic-20 through some voltage translators, but time has limited progress in the last weeks. I am probably starting with Arlets core as its small (and tags along 45MHz). The WDC core is 2.5 times larger(!) and ran at 75MHz, but its not free..

So what do you think?

[GARTHWILSON]

kakemoms wrote:

Its an interesting point that there are no 65816 cores available. But there are numerous examples of 65xx cores that have been extended. I don´t know why WDC doesn´t sell their 65C816 core as IP since the 65C02 has been available for long.

They do license it, but it doesn't look practical for hobbyists unless you have money to burn. See http://westerndesigncenter.com/wdc/cores.cfm .



Licensing Process



IP License Business Model

The WDC licensing business model is flexible and is a combination of licensing fees and royalties that can be negotiated at the time of licensing. Our Technology License Agreement (TLA) is available to those qualified potential licensees under an NDA. Once licensed, all required views of the technology are transferred under the TLA. Our IP has been proven in volume production standard products and various licensed ASIC products of our licensees on various pure play foundries for example UMC and TSMC at sub-micron geometries. In addition, several integrated device manufacturers have had significant success within their internal manufacturing facilities over the last 25+ years. WDC can retarget to specific process nodes or as a licensee you can retarget to any CMOS process node you desire.

Comments on Lattice FPGA Usage

“Our Lattice XP2 implementation is an instant-on emulation of our GDSII hard cores. Having an emulated ASIC core gives the user the ability to either emulate an ASIC or just stay with the XP2 for complete flexibility in one device. Flexibility in design is one of the hallmarks of the 65xx brand technology over the last 33 years. This legendary flexibility secures a wide breadth of application not available with other processor families especially on an 8-bit cost effective bus. The Lattice XP2 devices help showcase our products while providing the end customer with new value added features.”
- David Gray, WDC Engineering Manager

[GARTHWILSON]

kakemoms wrote:

The 65816 is basically a 6502 with 16 bit addressing, which shouldn´t bee too difficult to extend (if anyone has the time).

The '816 has a lot of added instructions and addressing modes and new capabilities the '02 doesn't have.

Quote:

Personally I am more interested in the 6502 and 6509 since an extension of the 6502 to increase address size WITHOUT increasing code size is profoundly more interesting in the long run. Why you ask? Well, I remember when my old workplace made the transition from an IBM System/36 to an IBM AS/400 in which all our code suddenly tripled in size. What a waste!

I find that when constantly dealing with 16-bit quantities, the '816 makes for more compact code than the '02 does.

Quote:

One could probably extend the databus to 48 or 64 bits (and more processor cores), but CISC like translations are the way to go to speed things up. So for example:

Code: Select all

LDX #$80
loop:
STX $A002,X
DEX
BNE loop

Is recognized as a loop and handled by the two cores with STA in one and DEX in the other, then some logic to keep them in the cores until the branch exits the loop. The output buffer would mean that write only happens when 32 bits can be written (in the case of 32-bit databus).

Interesting idea. The '816 does fills like this in 7 clocks per byte, after the initial setup, using the MVN or MVP instruction. I imagine this could be shortened, still using MVN or MVP.

Quote:

So what do you think?

[BigEd]

Edit - crossed in the post with Garth.

kakemoms wrote:

Its an interesting point that there are no 65816 cores available. But there are numerous examples of 65xx cores that have been extended.

The 65816 is basically a 6502 with 16 bit addressing, which shouldn´t bee too difficult to extend (if anyone has the time).

It's true, there are several extended 6502 cores - and some of them do offer wider arithmetic and/or wider addressing, and it's fun to make and use those. (My own, the 65Org16, is intended as the simplest possible extension to 16 bits. As such, it did get finished, but of course it wasn't enough for many tastes.)

But the '816 turns out to be a lot more than a simple extension - especially if you want your new core to be compatible with all the odd corner cases. I think this is why there isn't one in HDL(*). For details and for insight, see 65C816 Opcodes by Bruce Clark nearby.

(*) Edit: There now is a VHDL 65816 as part of SNES_MiSTer.

[Arlet]

I think Ed's right. Too much work to build a compatible 65816 core, and not nearly enough old and interesting software to make it worth it.

[White Flame]

A curiosity that comes to mind with a custom 65816, is that because there's a separate code bank & data bank, could you run parallel accesses to two memory buses in a Harvard architecture? Say fixed to a 128KB memory layout, 64KB for each. If code & data point to the same bank, it could still work but serialize accesses and run "slower" a la the stock '816. From a software perspective, it could be a transparent speedup.

[GARTHWILSON]

use VDA and VPA?

[BigEd]

There is a little wrinkle with separate program and data space: unless your program is in ROM, at some point you need to write it into place. (Which is to say, loading a program is pretty common, the other case being self-modifying code.)

So, remember to provide some way to write to program space.

[ttlworks]

White Flame wrote:

A curiosity that comes to mind with a custom 65816, is that because there's a separate code bank & data bank, could you run parallel accesses to two memory buses in a Harvard architecture?

Having two separate bus systems, one for code and one for data means having a lot of pins on the chip.

IMHO a good compromise between going Harvard and implementing a cache would be having something
like 256 Bytes of RAM for code inside the CPU, mapped to a specific memory address area.
So one could place code that _has_ to be fast there to reduce traffic on the bus to CPU external
data memory for increasing speed (like I did with the 68020 when freezing the cache).

To the end user, this RAM would have to be transparent of course, means that data writes
to that specific memory address area would have to be mirrored into the internal code RAM, too.

But it feels like such ideas already went mentioned here.

[ttlworks]

But now for another thing that just came to mind:

There were quite a few commercial computers with a 68000: Amiga, Atari ST, the early Macintosh, some workstations etc.
But (if we ignore the SNES) I just can't remember that there was a commercial 65816 computer.

Correct me if I'm wrong, but to me it feels like the 65816 mostly went into accelerator cards for Apples and the C64,
and like there wasn't much software that made full use of the 65816 features and instruction set.

Wikipedia: When 16 Bit CPUs where introduced/released.
TMS9900 -> 1976
8086 -> 1978
68000 -> 1979
Z8000 -> 1979
65816 -> 1983

Maybe the 65816 had entered the market a little bit too late...

[BigEd]

Both the Apple IIGS and Acorn's Communicator used an '816:
https://en.wikipedia.org/wiki/Apple_IIGS
https://en.wikipedia.org/wiki/Acorn_Communicator