Superscalar 68000, have you seen the Apollo core ? What do you think about ?

[andersm]

(word on the street was Apple got a HUGE discount on Intel chips for a number of years)

They probably did, but the main reason Apple switched to Intel is that neither IBM nor Motorola could make the laptop chips Apple needed.

[Rasz]

guys, anybody has seen a 68060 evaluation board around ? looking for something with just the CPU, ram, serial, and the expansion bus
in case, have you seen a full 3.3V system ? (both 68060 Vcore & IO powered at 3.3V)

ebay old nortel telephone switch boxes ~$50
http://www.ebay.com/sch/i.html?_nkw=NORTEL+NT5D10EA+CP+68060

[legacy]

Differences between 680x0 family and ColdFire

Although the ColdFire architecture is closely related to the 680x0, there are many simplifications to the instruction set. Nearly all of the differences are omissions from the 680x0 instruction set and addressing modes. This means that (with a few important exceptions detailed below), a 680x0 instruction which is implemented in ColdFire behaves in exactly the same way under the two architectures. In fact, almost all user-level (and much supervisor-level) ColdFire code can be run unchanged on a 68020 or later 680x0 processor (apart from new instructions introduced in the Version 4 ColdFire core). The converse, however, is not the case.

In outline, the main omissions fall into five categories:

Missing addressing modes
Missing instructions
Non-availability of word- and byte-forms of nearly all arithmetic and logical instructions
Many instructions act only on registers, not on memory
Restrictions on available addressing modes for particular instructions
Simplification of the supervisor-level programming model
Principles behind the differences

In order to understand the ColdFire instruction set in relation to that of the 680x0, it helps to have an appreciation of why the simplifications have been made. The philosophy behind ColdFire is influenced by the success of RISC processors in providing high performance - for a given degree of chip complexity - by eliminating seldom-used instructions and complex addressing modes, and by regularizing the instruction set to make it easier for the hardware to optimize despatch of the instruction stream.

However, standard RISC processors such as the PowerPC achieve high performance at the expense of low code density, in part because all instructions are the same width (generally 4 bytes) and also because only very simple addressing modes are available. In addition, RISC processors do not allow direct modification of memory locations; all memory reads and writes have to go via registers. This all means that programs compiled for RISC processors tend to be substantially larger than those compiled for CISC architectures such as the 680x0. This penalty does not greatly matter for desktop systems or servers with 32MB or more of RAM, but for embedded applications it can be a significant disadvantage, both in terms of system cost and power consumption.

The ColdFire architecture - which Freescale Semiconductor characterizes as "Variable-Length RISC" - aims to share many of the speed advantages of RISC, without losing too much of the code density advantages of the 680x0 family. Like most modern processor architectures, it is optimized for code written in C or C++, and instructions which are not frequently generated by compilers are amongst those removed from the instruction set. Some of the complex addressing modes - again not important for compilers - are eliminated, and the additional hardware complexities involved in supporting arithmetic operations on bytes and words also disappear. In order to regularize the instruction stream, all ColdFire instructions are either 2, 4 or 6 bytes wide; this is why certain combinations of source and destination operands are not available.

Missing addressing modes

The ColdFire addressing modes are quite similar to those of the original 68000, i.e. without the extensions introduced in the 68020 and later processors, but with some differences in indexed addressing. Compared with a 68020 or later processor, the comparison is as follows:

Fully supported:

Data Register Direct
Address Register Direct
Address Register Indirect
Post-increment
Pre-decrement
Displacement (16-bit displacement)
PC Displacement (16-bit displacement)
Absolute Short
Absolute Long
Immediate

Partially supported:

Indexed
PC Indexed

The restrictions on these two modes are:

The displacement constant is 8-bit only;
"Zero-suppressed" registers are not supported;
The Index register can only be handled as a Long. Word-length index registers are not supported.
The scale factor must be 1, 2, or 4. Scale factors of 8 are not supported.
Not implemented at all:

Memory-indirect post-indexed
Memory-indirect pre-indexed
PC-indirect post-indexed
PC-indirect pre-indexed
Note that further restrictions may be imposed on the addressing modes supported by particular instructions, even if a particular addressing mode is itself available on ColdFire.

Missing instructions

A number of instructions are not implemented at all under ColdFire. These include:

DBcc, EXG, RTR, RTD, CMPM,

ROL, ROR, ROXL, ROXR, MOVE16

ABCD, SBCD, NBCD

BFCHG, BFCLR, BFEXTS, BFEXTU

BFFFO, BFINS, BFSET, BFTST

CALLM, RTM, PACK, UNPK

CHK, CHK2, CMP2, CAS, CAS2, TAS (restored in V4 core),

BKPT, BGND, LPSTOP, TBLU, TBLS, TBLUN, TBLSN

TRAPV, TRAPcc, MOVEP, MOVES, RESET

ORI to CCR, EORI to CCR, ANDI to CCR

In addition, DIVS and DIVU (with some differences from the 680x0 equivalents) are available on some ColdFire processors but not others. MULU and MULS producing a 64-bit result are not implemented, but 16 x 16 producing 32-bit, and 32 x 32 producing (truncated) 32-bit, are available.

Long-word forms only

Most arithmetic and logical instructions can act on Long words only. This applies to:

ADD, ADDA, ADDI, ADDQ, ADDX, AND, ANDI, ASL, ASR

CMP, CMPI (word/byte forms re-introduced in version 4 core)

CMPA, EOR, EORI, LSL, LSR,

NEG, NEGX, NOT, OR, ORI,

SUB, SUBA, SUBI, SUBQ, SUBX

MOVEM.W has also been removed from the instruction set.

In fact, the only instructions which do act on the full set of byte, word and long operands are CLR, MOVE and TST (and CMP and CMPI in the version 4 core). EXT.W, EXTB.L and EXT.L survive, as do MULx.W and MULx.L

Instructions which act only on registers, not on memory

Some arithmetic instructions cannot act directly on memory - the destination must be a register. This applies to:

ADDI, ADDX, ANDI, CMPI, ASL, ASR, LSL, LSR,

NEG, NEGX, NOT, EORI, ORI, SUBI, SUBX, Scc

Note that ADDQ and SUBQ can act directly on memory.

Restrictions on addressing modes for particular instructions

Even where a particular memory addressing mode does exist in ColdFire, some instructions are subject to further restrictions. Often, this is because of the limit of six bytes as the maximum length of a single instruction. Specific restrictions include:

Some combinations of addressing modes for MOVE are disallowed. If the source addressing mode is Displacement or PC Displacement, the destination addressing mode cannot be Indexed or Absolute. If the source addressing mode is Indexed, PC-Indexed, Absolute or Immediate, the destination addressing mode cannot be Indexed, Displacement, or Absolute.
The addressing modes for MOVEM are restricted to only Displacement and Indexed - no Pre-decrement or Post-increment!
For BTST, BSET, BCLR and BCHG, if the source operand is a static bit number, the destination cannot be Indexed or Absolute memory.
Miscellaneous Omissions

There are a few miscellaneous omissions for specific instructions:

LINK.L is not supported
MOVE to CCR/SR: Source must be Immediate or Data Register
MOVE from CCR/SR: Destination must be data register
BSR and Bcc accept only an 8- or 16-bit displacement in version 2 and version 3 cores (32-bit displacements are reintroduced in version 4)
Instructions which behave differently from the 680x0 equivalent

In most cases, an instruction/addressing mode which does exist in ColdFire behaves exactly like its 680x0 equivalent, which makes it easy for experienced 680x0 programmers to understand ColdFire code. It also means that user-mode code written for ColdFire can generally run unchanged on a 680x0 processor, provided the new ColdFire-only instructions are not used.

However, there are a few subtle cases where the ColdFire instruction is not exactly the same as its 680x0 counterpart. The most important of these is that multiply instructions (MULU and MULS) do not set the overflow bit. This means that a 680x0 code sequence which checks for overflow on multiply may assemble and run under ColdFire, but give incorrect results.

ASL and ASR also differ in that they do not set the overflow bit - but this is less likely to cause problems for real programs!

Simplification of the supervisor programming model

Various members of the 68000 family have different register sets available at the supervisor level. The most important simplification in ColdFire's supervisor-level model is that there is only one stack pointer, shared for all code including interrupts, supervisor-level services, and user code. It follows from this that, on ColdFire, it is never safe to write below the stack, since any interrupt which occurs would overwrite the stored data. (Writing below the stack, though not recommended, is possible in some 680x0 systems in user mode, because interrupts cause a switch to the Interrupt or Supervisor Stack Pointer). A further issue is that ColdFire processors automatically align the stack to a four-byte boundary when an exception occurs, which can cause problems if code is reading or writing at a fixed offset from the stack pointer. In fact, it is strongly recommended (for performance reasons) that the ColdFire stack should be kept long-word aligned at all times.

New features in ColdFire Version 4 core

Version 4 of the ColdFire core architecture re-introduces some familiar 680x0 instructions, and also adds some new instructions. The main changes are:

Reintroduced:

32-bit displacement forms of BSR, Bcc and BRA
Byte and Word forms of CMP and CMPI
Slight relaxation of restrictions in addressing modes for MOVE
Restoration of the TAS instruction

New:

MOV3Q for moving immediate values in the range -1 to 7 to destination
MVS moves and sign-extends in one operation
MVZ moves and zero-extends in one operation
SATS Saturate register if overflow set

[legacy]

I have eaten a look at what’s still in production of 68k family and it seems there is not much else besides legendary 68000. Out of those, 68SEC000 version seems as best choice. It’s bvased on freshest manufactiuing process, and it comes in small package, low inductance

Also, SEC should be easier to OC while working at 3.3V Using 3.3V might be benefitial for:

– being able to find better other components at lower prices ( fpga )
– lower power drain
– lower noise on the bus

Other options fall off for one reason or another:

• 68010, whole point of it was to fix a few bugs in 68000, that was needed to work good with external MMU. Since MMU brings extra waitstates and since 68010 is hopelessly obsolete for classic OS with virtual memory, this option makes no sense
• 680(EC){020,030}, nice but not in production anymore
• 68040, there are some 3.3V models stil in production, but it is outrageously expensive
• 68060, not in production anymore
• ColdFire, not really 68000 compatible

[theoldwizard1]

What surprised me most about Coldfire was the fact that it did not make a big impact in the automotive world.  GM had already been using the 68332 (IIRC, the CPU32 cores was not compatible with all 68k family member).  With its minimized instructions and addressing modes the Coldfire should have out performed the CPU32.  Additionally, Coldfires variable length instruction, which do require a bit more decoding than a fixed length RISC instruction set, should be a big benefit for application that execute out of Flash memory.

TPU and eTPU were criticized by some as too complex and in the early days lack of development/debugging tools were a major issue.  Motorola set themselves up to be the supplier of TPU firmware, BUT their solutions did not meet all customer requirements.


Designing an embedded system chip is quite different than designing a general purpose CPU chip.  Advanced designs that might have been dismissed, such as a 2 bank of general purpose/address registers (user, interrupt), are extremely beneficial in reducing context switch time.  Harvard architectures look like a good way of improving performance until you realize that much embedded code has literally thousands of constants.  The processor stalls while extra cycle are required to access the one bank of Flash memory.

[legacy]

GM had already been using the 68332

…

TPU and eTPU were criticized by some as too complex and in the early days lack of development/debugging tools were a major issue.  Motorola set themselves
up to be the supplier of TPU firmware, BUT their solutions did not meet all customer requirements.

i have bought a 68332EVS board (with a debug processor on it + original debugger software, x86, it needs DOS v6.22, it does not run on XP/NT/2K)

the TPU is amazing, i have coded a TPU-uart, TPU-pwm tasks very easily for micro robotic purposes 

[legacy]

This is just a list of HDL resources that may be helpful for fpga/68k

• Minimig-v1
• Minimig on de1 board
• fpgaArcade
• Majsta's Vampire fpga accelerator
• TiNA project
• Mist
• Natami (possibly dead)
• TG68k at opencores
• Apollo 68k superscalar core
• ao68000 for Wishbone SoC, more
• OpenCores K68
• fpga in a 68k CPU socket (possibly dead)

[IanP]

The Apollo developers recently got their hands on the Vampire V2b card http://www.kipper2k.com/vampire/top.jpg. This is not the final V2 production card, that will have double the ram and double the data bus width. The much larger FPGA on the V2 card will allow a full Apollo implementation unlike the severely restricted, cut down Pheonix core on the V1 board which already performs pretty well. There's a lot still to do to have the full implementation of the Apollo core working on the V2 at it's full potential but work is progressing well http://www.apollo-core.com/bringup/index2.htm

[John_ITIC]

I will say that those who do actual programming (aka assembly, aka Real Men) would find 68k a breath of fresh air compared to ARM.

That's the point or ARM's RISC concept; the Acorn people realized that the complexity of a CISC CPU that was intended to be programmed in assembly had to implement very complex/powerful instructions to simplify the assembly programmers work. The RISC concept, in contrast, implements very basic instructions and pushes the complexity into the compiler. This makes the hardware much simpler, which lowers the cost and complexity (allowing Acorn to build their own CPU for the BBC micro series computers). RISCs are simply not intended to be programmed in assembly.

Acorn RISC Machines then became ARM, which now licenses the RISC concept to lots of companies.

https://www.google.com/?gws_rd=ssl#q=Acorn+risc+machines+

[John_ITIC]

I very much doubt they can get a core to run at >400MHz inside an FPGA. Sure FPGAs can run at these speeds but you can only have a tiny bit of simple logic. As soon as logic gets more complex routing and logic delays severely hamper the maximum clock frequency.

NIOS II can obtain some 150 MIPS in a Cyclone V FPGA; the SoC version (hard CPU core) achieves some 4000 MIPS. That's a pretty good FPGA vs. ASIC speed illustration.

[ale500]

The guys at NatAMI did develop some boards based on an unknown (to me) MC68060 in QFP package. it is labeled MC68060FE133. It doesn't show up in any list of produced parts...:

http://www.natami.net/gfx/NAe60F/NAe60F_2.jpg

The discussion about a faster (and with new instructions) 68k core goes years back... sad that it is closed source

[BloodyCactus]

it was never proved that the 68060fe133 were real. supposedly they were 133mhz 060's but.. these chips have no fpu or mmu. its a 68EC060 processor. the chip mask gives it away as a MC68LC060ZU66, as an overclocked 66mhz EC/LC mask chip.

afaik, after thomas found these in china and they were not found by anyone else again.

from memory, speculation was someone in china found some uncommon FE's and remarked them to 133mhz.  I think the final conclusion from like 2009? was it was a MC68EC060FE75 chip.

i stopped paying attention to natami back then lol

[legacy]

i stopped paying attention to natami back then lol

me too, it's a never ended project, and they have currently switched to Apollo-68K

[richardman]

re:Apollo machines

My first job happens to be programming on the Apollo Workstation. This was before SUN (RIP) was huge, so there were dozens, if not hundreds of 68K based workstations popping up everywhere. The joke was that a workstation vendor would go to the Unix guys (I forgot which one now), and they would hand off a copy of the Unix-de-jour on a tape to them and they would release that.

Anyway, Apollo machines were made by Apollo Inc., not Mentor Graphics as a poster mentioned. They were 68K based, so they used 2 68K core executing the same code, and when one fell over due to memory paging, the other would check the content of the stack so the whole machine can recover. The 68020 solved that finally by putting more machine context onto the fault stack so all instructions can be restarted.

Apollo was bought by HP back in the days, around 1986 I believe.

Motorola/Freescale sold A LOT of Coldfires because that's the device family in the original Laserjets.

[grumpydoc]

Anyway, Apollo machines were made by Apollo Inc., not Mentor Graphics as a poster mentioned. They were 68K based, so they used 2 68K core executing the same code, and when one fell over due to memory paging, the other would check the content of the stack so the whole machine can recover. The 68020 solved that finally by putting more machine context onto the fault stack so all instructions can be restarted.

Apollo was bought by HP back in the days, around 1986 I believe.

I wrote a bit of stuff for the Apollo post the HP acquisition as my university comp sci department had a few. Odd things in some ways and I spent rather more time swearing at them than I would like

The trick with two 68010's was also used by Sun - they didn't quite "execute the same code", one CPU was just behind the other so that when the first encountered the page fault the second could be stopped while the page fault was handled, then restarted - that CPU would never see the fault. Not sure how they synced register contents after the faulting instruction - possibly just execute that instruction, then copy from one CPU to the other? Anyone know?

[richardman]

Yes of course they didn't execute the same code at the same time. Otherwise, they would just fall down together    I used to know the details, but too many things happened between 1980'sto 2015 :-)

What's pretty amusing to me though was that in the production CPU board, which is over 1 foot x 1foot, may be even more like 18" square, the back side is full of jumper wires to fix the hardware problems, and those were second generation production machines or something like that.

It also ran Aegis, Apollo's brand of not-quite-Unix because they wanted to write it in Pascal - I think. Again, too long ago now.

My first job was to rewrite the byte code interpreter from C to 68K asm. Took me a few days and sped up the runtime by 20-50x. This was for a semiconductor test company that had its own test language for the "next-gen" test machines. Those things ran at megahertz, blazingly fast at that time.

There were a lot of 68K workstation companies then, not unlike the PC clones later. At the last year of school, the luck few of us got to play with a Unix based "personal" workstation from Pixel. Think Steve Jobs' NextCube but 10 years earlier with lower resolution. One of my friends got a job at that place before she graduated but then the company went kaboo before she started!

I wrote a bit of stuff for the Apollo post the HP acquisition as my university comp sci department had a few. Odd things in some ways and I spent rather more time swearing at them than I would like

The trick with two 68010's was also used by Sun - they didn't quite "execute the same code", one CPU was just behind the other so that when the first encountered the page fault the second could be stopped while the page fault was handled, then restarted - that CPU would never see the fault. Not sure how they synced register contents after the faulting instruction - possibly just execute that instruction, then copy from one CPU to the other? Anyone know?

[ale500]

The original LaserJets are from early 80s, there where no ColdFires at that time. They probably had 68Ks. At least The Laserjet 2 Had a 68EC000 in PLCC package. Later machines, post Series 6 had them. Some had i960s...

[legacy]

Yes of course they didn't execute the same code at the same time. Otherwise, they would just fall down together    I used to know the details, but too many things happened between 1980'sto 2015 :-)

What's pretty amusing to me though was that in the production CPU board, which is over 1 foot x 1foot, may be even more like 18" square, the back side is full of jumper wires to fix the hardware problems, and those were second generation production machines or something like that.

never heard before, thank you for the news, is there any paper/AN/article/whatever (paper or digital copy) that tells it in details ?

[richardman]

Correct, the original Laserjet had plain 68Ks, the later ones had Coldfires. Kept that Motorola unit alive for a long time! :-)

re: 68K page fault problem. You can get some links by searching for "68K page fault"  most are hand waving (one processor executes behind the other one...) descriptions, slightly lack of details. On thinking about it, it must be in the order of when the primary processor falls over, the secondary examines the state on the CPU and figures out what address it's having problem accessing (the issue is to implement virtual memory), and then fetches the memory block and restart the primary CPU. I know there are more in depth explanation as I read them before, so if I find them again, I will place a link here.

[ale500]

I got the "SUN 68000 Board User's Manual" where the MMU of the 68000-Based SUNs is described, but it is only single processor. I think I got it from bitsavers. Maybe there is something apollo related there... I'll have a look now...

Another interesting document is this one: http://bitsavers.informatik.uni-stuttgart.de/pdf/sun/sun2/800-1185-01_2-120_CPU_Engr_Sep84.pdf

But nothing on those 2 CPUs systems so far... SUN No, HP No, Apollo also nothing... any other name ?

[legacy]

thank you guys 

[edavid]

The trick with two 68010's was also used by Sun - they didn't quite "execute the same code", one CPU was just behind the other so that when the first encountered the page fault the second could be stopped while the page fault was handled, then restarted - that CPU would never see the fault. Not sure how they synced register contents after the faulting instruction - possibly just execute that instruction, then copy from one CPU to the other? Anyone know?

This is garbled... Apollo built a system with 2 68000s because the 68010 wasn't out yet.  As soon as it was available, they switched to a single 68010.

Sun never built a dual 68000 board, they waited until the 68010 was available to turn on demand paging.

[grumpydoc]

This is garbled... Apollo built a system with 2 68000s because the 68010 wasn't out yet.  As soon as it was available, they switched to a single 68010.

Sun never built a dual 68000 board, they waited until the 68010 was available to turn on demand paging.

I confess I never encountered such a beast so it is an old memory that is 2nd hand - I'm not surprised that it is inaccurate I must admit I thought Sun had used the dual 68000 thing, obviously not.

68010 when I meant to say 68000 was just a typo.

[richardman]

Doing some reading, it's coming back to me. What is fairly certain is this: 2 CPU with one running one instruction behind. When one falls over, some actions happen:

• one CPU examines the CPU state, and paged in the memory in question
• one CPU resumes the program, now without the memory access issue
• normal execution resumes

What is not clear is which CPU does which steps. Some people claim that the 2 CPUs swap roles. Obviously, in normal execution, the CPU executing "behind" cannot have its memory writes actually being executed.

It would be an interesting exercise to reverse engineer this. This hack though, must have been obvious to the hardware engineers at that time, that when one company did it, numerous other companies just went ahead and followed. This is before the sue-happy patent days, I guess.

[edavid]

This hack though, must have been obvious to the hardware engineers at that time, that when one company did it, numerous other companies just went ahead and followed.

I don't think the "numerous" part is right - I don't think it was common at all.  For one thing, 68000s were very expensive, so no one wanted to pay for 2 of them, when Motorola was promising the 68010 very soon.  It made more sense to put the money into RAM.  Also, most of the early 68K systems shipped with a (crappy) Unisoft Unix port, which didn't even support demand paging.

As for the way it worked, what I remember (which may be wrong) was that the second CPU was run far enough behind that it could be interrupted and its pre-fault stack puke saved.  Then, when the main CPU was ready to resume the faulted process, it would reload that good stack puke and resume at the instruction that had faulted.