CPU 68080

[Chain-Q]

Which (the 68030 - addition by me) also seems to be the actual most common CPU expansion for all the Amiga models! Very little apart from Demos actually uses/needs 68060+

Well, some Amiga models came with a 68030 on-board already (the A3000, some versions of the A4000), and they still have a CPU expansion slot, plus already Commodore themselves sold a relatively healthy number of 68040 systems for pro users. And in the post-Commodore era, some 4000Ts were actually already delivered with a 68060 CPU from the factory. Given this, I must conclude maybe there's still something about going beyond a '030.

[XorA]

Which (the 68030 - addition by me) also seems to be the actual most common CPU expansion for all the Amiga models! Very little apart from Demos actually uses/needs 68060+

Well, some Amiga models came with a 68030 on-board already (the A3000, some versions of the A4000), and they still have a CPU expansion slot, plus already Commodore themselves sold a relatively healthy number of 68040 systems for pro users. And in the post-Commodore era, some 4000Ts were actually already delivered with a 68060 CPU from the factory. Given this, I must conclude maybe there's still something about going beyond a '030.

By this logic though might as well port smsq/e to PowerPC.

[Peter]

I would not agree, since SMSQ/E with it's deeply 68K dependent/optimized assembler-only code is practically impossible to port to a different CPU architecture (unlike AmigaOS).
While designing QL hardware > 68030 is possible and has been done before.

[Tinyfpga]

Posts by pjw and Peter remind me of a discussion with Tony Tebby many years ago, concerning the use of high level languages to express his operating systems.

If my memory of the discussion is accurate, it went something like this:-
Conventional high level languages were not designed to express the unique architecture of SMS and in particular their compilers can not be relied on to correctly produce the critical elements of SMS. In later documents Tony named these critical elements as "Intsafe" code.( I assume the name was short for intrinsically safe). His view was that one would have to manually check the machine code output of the compiler to see what it had produced. He claimed this would be more difficult than writing the operating system in assembler.

The question of portability was also discussed, in particular porting SMS2 to the PC. The problem here was compounded by the ever changing and under documented I/O capabilities of the PC.
Even if it had been realistic to rewrite SMS2 in X86 assembler or create or modify a high level language compiler to (as pjw suggests) produce "Intsafe" code it would have been near on impossible to keep up with the PC's continuous development. Without a large development team it would be difficult to write TTos code natively on any hardware designed outside the confines of the SMS world.

Recently there were discussions with TT about developing Stella on ARM (as in the processor) but that would have been with ARM's assistance. Development tools were not discussed but TT did not consider the endeavour impractical. He would have had to consider whether it would have been easier to write the OS in ARM assembler or create a novel high level language capable of generating accurate Stella code.

One has to bear in mind that there is less assembler code in SMS2 than in most "portable" operating systems. The SMS2 cartridge contains about 160Kbytes of assembled code and a quick look at Linux kernel 4.20.1 reveals about 260Kbytes of assembled code. So in SMS2 terms Linux 4.20.1 is not exactly portable.
Furthermore the SMS2 kernel is much less than 160Kbytes and Stella, which is significantly more advanced, is not much bigger. It is also unlikely, as Peter has often mentioned, that SMS or Stella will ever need to run in any processor other than the 680XX, so would there be any advantage in developing a high level language for writing a TTos?

To a large extent Peter has solved the problem of operating system portability by making the hardware portable instead. By using a hardware description language to define a 680XX system-on-chip, FPGAs can be used used to make SMS-in-assembler compatible computer modules. This, seems to me to be to be a vastly superior way of building new hardware for followers of SMS. I think Peter would struggle to produce something as small as the Qzero using a 68030, furthermore system-in-FPGA frees the designer from the vagaries of processor manufacturers.

I, for one, would like to read the long article proposed by pjw in his post dated 29 Jun 2021. I agree with pjw on the matter of fast response high display resolution systems, although when I post images of SMS at HD resolutions very few seem to be interested. To achieve a high resolution with the Q68 I have to use mode 3, set to black & white because I think this looks better than when set to 4 colours. I find the speed of the Q68 set to mode 3 is adequate for the kind of applications that I write.

Peter has not detailed what he thinks is possible for SMS-in-FPGA or what limits the performance of such systems. When one reads the promotional text for the Apollo 68080 (http://www.apollo-core.com/features.html) it seems a pity that Peter seems to have rejected this processor.

[Peter]

To achieve a high resolution with the Q68 I have to use mode 3, set to black & white because I think this looks better than when set to 4 colours. I find the speed of the Q68 set to mode 3 is adequate for the kind of applications that I write.

The lack of speed in 1024x768 highcolor was addressed in the Qzero by seperating VRAM from main RAM. However, this only cures CPU slowdown. It does not deal with the fact that video memory itself is much larger and therefore slower to scroll, move etc.

When one reads the promotional text for the Apollo 68080 (http://www.apollo-core.com/features.html) it seems a pity that Peter seems to have rejected this processor.

That was mostly based on the time constraints I have, and the fact that I prefer Lattice FPGA over Intel. Other FPGA designers have been active in the QL scene recently, using Intel FPGA, easing the work to integrate Apollo. Licensing issues are likely though - proprietary HDL code collides with the GPL. (Not an issue for me as I designed the whole system minus the CPU myself.)

[Nasta]

The thing with the 68080 core is that QL software including OS really do not need 99% of the enhancements, as far as I know not even the added 020+ instructions are used. Some middle ground would be the CPU32 spec which is slightly over regular 68k. So, in general QL would need as fast a 68k as it can get (which does include all sorts of caching, instruction folding, pipelining, etc). SOME enhacements are interesting for specific apps, like MMX-like and DSP-like instructions (although adding a dedicated DSP is not horribly difficult except that it is it's own processor - and it would not be the first time that sort of thing was done on a 68k based computer, hint: NEXT cube, Atari Falcon).

[Peter]

The thing with the 68080 core is that QL software including OS really do not need 99% of the enhancements, as far as I know not even the added 020+ instructions are used.

Usage ist very rare indeed. My only reason for such a CPU core would be instructions per clock, and achievable clock frequency.
The most realistic path to QL hardware faster than Q60 still seems another 68060 board. Unfortunately.
Until the TG68K.C reaches the 68060 just by newer FPGA technology, I expect at least half a decade, rather a decade, if I extrapolate from the comparison of XP2 to ECP5.

[Nasta]

The thing with the 68080 core is that QL software including OS really do not need 99% of the enhancements, as far as I know not even the added 020+ instructions are used.

Usage ist very rare indeed. My only reason for such a CPU core would be instructions per clock, and achievable clock frequency.
The most realistic path to QL hardware faster than Q60 still seems another 68060 board. Unfortunately.
Until the TG68K.C reaches the 68060 just by newer FPGA technology, I expect at least half a decade, rather a decade, if I extrapolate from the comparison of XP2 to ECP5.

Well, the 060 core is rather advanced compared to the regular 68k but then it (officially) tops out at 75MHz (the EC version at least - though the EC version should be enough).
I still have a stash of (50?) 68EC060RC66 and would be willing to donate them for a project like that. The good thing with 060 is that it's 3V3 and 5V compatible. When I was looking into it for GoldFire, I wanted to have two running on the same bus, one as a sort of IO processor (at least for starters). The reasoning was, it's easier to program a known CPU to do various tasks as simple as DMA, but then it would be also capable of much more. The basic IO operations it would have to do are simple enough for the entire code to fit into the cache, making it quite un-intrusive on the bus and yet very capable. The rest of the circuit would be SDRAM (SDR, possibly run at 2x speed), and some peripherals that would connect over a 5V capable/tolerant buffer, which would include some sort of a QL like bus. Simple peripherals and bootstrap flash could sit on an 8-bit bus, the remaining question would be interfacing mass media and graphics. At one point I even had the idea to use the second CPU to generate VRAM cycles under NMI, which considerably simplifies handling that part of memory, the main design decision here would be if real VRAM (RAM + serial port) is used or a cycle steal mechanism is implemented to use a part of the regular RAM as a frame buffer (where running SDR RAM at 2x CPU clock rate would have added benefit). Originally 2 large CPLDs were envisioned to do the work, one for all the bus and IO hardware (060 needs a bus interface to drive 8 or 16-bit bus widths) which also implemented buffering and 5V tolerance, and the other for SDRAM, bus arbitration etc. These days it's likely a FPGA would be better in this place as it could implement many added and advanced functions (FIFO buffering for video and sound, for instance).

* The 060 (and 040, MCF5102 to an extent) make id dead easy to implement two CPUs on the same bus as the CPU is not assumed to be the default bus master. Instead, when it needs the bus it requests it. This makes it easy for fairly simple hardware to detect multiple bus requests (CPU1, CPU2 and perhaps something else like video refresh) and arbitrate between them using some fair bus bandwidth division protocol. There are details to be sorted as what interrupts go to which (or both) CPUs, and a method for one CPU to be the 'bootstrap' CPU that loads the contents of bootstrap media into RAM and starts executing it.
Unfortunately, the lesser CPUs are bus masters by default and when one isn't, the signals one could use to detect that it is requesting the bus, are switched off, so it is impossible to even know it unless the bus s speculatively granted to each potential bus master (in tis case CPU) in turn. In case it did not need it, the time it was granted and resulting bandwidth is lost to the other CPU that did need the bus, so it's not really possible to make this properly efficient, with a ton of extra bus buffers, adding cost in money and speed.

[Derek_Stewart]

Hi,

The Atari Falcon has a 68060 board that runs at 100Mhz, but I guess the RC version of the CPU can run faster.

The EC version does not have an MMU or FPU, does this figure in the overclocking of the CPU?

[Peter]

I still have a stash of (50?) 68EC060RC66 and would be willing to donate them for a project like that.

I keep a stack of 68EC060RC75 for similar reasons. Actually I did a lot fo work for a new Q60 design at some point, but didn't find the energy to finish.

The good thing with 060 is that it's 3V3 and 5V compatible.

A fine thing indeed. But for simplification, I'd probably stay off the QL bus completely with a '060 machine.

With top 68K cpu that is nowadays avaiable. Which is 68030.

The 68030 delivers less instructions per clock than the TG68K.C FPGA core, so I find it pointless. If speed is desired, it has to be the 68060.