SMS2 in FPGA

[pjw]

<>

1. Say a multi-GHz MC680x0 compatible CPU magically appeared. Would that make a difference do you think?

2. Emulators work like code interpreters during runtime, something that creates a lot of continuous overhead. Might it be possible that the 68k assembly language were to be considered just another low level programming language, and compilers be made that could compile 68k code into different CPU's native binaries? A virtual MC68 CPU-like environment would need to be created, but many languages appear to need setup code to create the correct base environment for them to work on, eg C68 on Qdos, or Forth on any non-stack platform.

Asking for a friend..

[tofro]

1. Say a multi-GHz MC680x0 compatible CPU magically appeared. Would that make a difference do you think?

Very unlikely. Think of the list of missing features I didn't (and still don't) bother to make up. You're not going to make QDOS a modern OS in a few night shifts.
Me personally, I like the challenge of programming within limited resources (it's the main thing that still keeps me going) and most of the quirks of old operating systems - I'm afraid I wouldn't bother writing any programs for that wonder-CPU would it exist. Where would be the difference to coding for a modern PC for a much wider audience?

2. Emulators work like code interpreters during runtime, something that creates a lot of continuous overhead. Might it be possible that the 68k assembly language were to be considered just another low level programming language, and compilers be made that could compile 68k code into different CPU's native binaries? A virtual MC68 CPU-like environment would need to be created, but many languages appear to need setup code to create the correct base environment for them to work on, eg C68 on Qdos, or Forth on any non-stack platform.

That's what most JIT-compilers (and some old-platform-emulators, like the RiscOS emulators) do (they also take advantage of modern multi-core CPUs that can do this on a second core quasi for free). It makes a potentially faster emulation. Has "your friend" ever complained about a lack of speed on QPC2 on a decent PC?

I think what you, me, and "your friend" see in the QL and derivates is different from what the OP wants - we're fine with what I wrote in my last paragraph - he's not.

[pjw]

<>

I guess we're talking slightly at cross purposes (or my friend and you, rather). I suppose she was thinking rather in terms of hardware platforms for a next gen "QL". The speed of QPC and SMSQmulator is good enough for any of the stuff we use on those systems today. (And no, Im not dissing Q60s, Q68s etc. One does what on can with whats available and possible - and thats pretty damn good!)

But if there were new generations of fast 68k CPUs could there be a revival of 68k systems - with any kind of OS? My friend and Tinyfpga might find some comfort in that possibility however slim.

Wintel and ARMroid have stolen a march on 68k systems, no doubt about it. It would be almost impossible to start afresh with something new. But new things do arise all the time. (Think of the rapidly evolving weapons and methods of warfare!) They have to, as older systems "grow out of their skins" and eventually become impossible maintain, let alone push to new heights.

The saying is that no one wants to know how the sausage is made. Im sure that if we looked inside the sausage that is the typical Intel chip, or in Linux or in many of the established systems the world in blissful ignorance runs on, wed find a frightening mess of patches, fiddles, and archaeological debris that no one living longer knows how works but darent touch in case it does something important! That, I think was the fate of, among other things, MSDOS.

Out of that inevitable entropy something new will have to emerge, usually after some major flustercluck. I dont see why that couldnt be a reversion to an older system that was simple, elegant and hasnt yet reached its full potential. It may be better than starting from scratch.

I love the smell of a bit of bluesky dreamin' in the afternoon!

[Peter]

Is system software bound to 68K really a problem? What's wrong with the 68K?

The problem comes from regrettable business decisions of the manufacturer, not the 68K architecture itself.
They started with messing up the Coldfire, making it incompatible with even a minimal common instruction set.
And continued by merging with a competitor who has (below) zero interest in 68K/Coldfire.
These business policies had no reasonable technical background. I'm sure the 68K architecture would still flourish in the embedded sector otherwise.
But we are where we are, and it's better to be realistic about it.

Me personally, I like the challenge of programming within limited resources (it's the main thing that still keeps me going) and most of the quirks of old operating systems - I'm afraid I wouldn't bother writing any programs for that wonder-CPU would it exist.

I have similar motivations on both the hardware and software side. However, QL software developed far enough to make use of highcolor+highres screens. Not nice if a PC with software emulator is required for a good look & feel. We don't need a multi-GHz CPU, but enough native hardware power to handle it well is desirable.

At the moment, the Qzero with SRAM is the only hardware with non-obsolete semiconductors to achieve this with acceptable look & feel. But it is still somewhat on the slow side for my taste. I also like the challenge of limited resources, but would prefer to see the limit around a 200 MHz 68060-like chip on silicon rather than a 40 MHz FPGA core.

[pjw]

On a practical level I agree with everything you wrote Peter (and tofro)! The multi GHz CPU was about a revival of 68k systems in general.

Im off to the wilds again for the next month or so, so no time to be more specific.