68060 based QL system?

[Dave]

I stipulate that SMSQ/E and Minerva use a couple of key quirks of the 68K instruction and register set to accomplish things that would need to be re-implemented in ARM assembly.

I stipulate that the amount of work required to do a port would be extraordinary. If it were undertaken it would be a labor of love for many people over many years.

I also believe, however, that the payoff would be spectacular. We'd have one of the fastest and leanest OS on any platform or architecture. It would be a prime RTOS. The ease of use would push it to the forefront of education and IoT hacking. It would find an easy home in embedded uses.

SMSQ/E is a several hundred Kilobytes origin OS, but Minerva is 48K. Commented sources are available. Automated tools could do the first 90% of translation poorly, and then with careful thought and planning the last 10% (which would require 99.9% of the effort) would give you Minerva on ARM. For all the 68K code, an emulator could easily take care of that.

It'll never happen, although it should because one day in the next decade or two 680X0 CPUs will become extraordinarily rare. Only CPUs constructed in FPGAs will be available in quantity, and while there's nothing wrong with that it seems wasteful to put that amount of effort into recreating a 70s architecture 6 decades later, when for within an order of magnitude of effort we could be using a modern (4 decades old ARM) architecture that is still growing and developing.

I'd propose re-implementing Minerva in C, modernizing the filing system and screen handling code, adding TCP functionality and....

But then, when the size of the QL economy appears to be around 40 units of anything, no matter how radically new or better it is, why bother at all?

So what's the real question Peter is asking?

It seems to me the heart of the question was this sentence: "The topic is how people see 68060 QL systems today, in the light of the fact that emulation on PCs is faster." He could develop the fastest hardware humanly possibly and emulation will *still* be leagues faster. The only thing quicker still would be native on fast hardware.

I suspect that over the next ten years our ranks will start to swell with returning QLers. People who have the time and the financial resources to recapture those moments of their youth and to buy or build their dream machine. Sure, it's easy to install an emulator and plink at it for a few hours and think, "oh, this was a nice blast from the past" but if we want those people to stay at the end of the day we'll need to arrange things so they invest in dedicated* hardware. Something that requires a bit of space on a desk, a single function, something occupying all of one's attention.

Either way, at some point original hardware won't be viable, the difference between emulators and FPGA-configured hardware will be too great to justify that hardware and the skills to even attempt a port to ARM or x86 or whatever will be gone. And SMSQ/E will have a day when the last "talker" dies and it becomes a historical wikipedia entry with no further changes. That'll be around 2045 or so.

* I say "dedicated hardware" because the next logical step for Q68 is Q68+ -- an FPGA system of higher performance and capability that is entirely software defined off the SD card, so it can configure itself as ANY retro computer and not just a QL, and where its core functionality is a proto system that is little more than a boot loader.

[pjw]

<>And SMSQ/E will have a day when the last "talker" dies and it becomes a historical wikipedia entry with no further changes. That'll be around 2045 or so.

No, itll be on 2097 Feb 06 06:28:15

[Peter]

If it were undertaken it would be a labor of love for many people over many years.

Love for ARM? I would understand that on an Archimedes forum, but not here. Love is about beauty, most of us love the beauty of the 68K architecture and assembler language.

It would be a prime RTOS.

SMSQ/E is by no means an RTOS. (And especially some SMSQ/E storage drivers are the worst case when it comes to RT requirements.)
But RTOS mention gets us closer to reality. If you put your huge effort into a completely new RTOS, instead of an SMSQ/E port, you might have a chance on at least a niche market.

(RTOS does not mean that an OS is usually fast or efficient. RTOS means it can meet a deadline deterministically. This is required for some embedded systems, e.g. motion control.)

Either way, at some point original hardware won't be viable, the difference between emulators and FPGA-configured hardware will be too great to justify that hardware [...]

The difference between FPGA and emulation will not necessarily get larger over the years. Semiconductor progress also goes into FPGA, not just ARM CPUs.

[Dave]

Love for ARM? I would understand that on an Archimedes forum, but not here.

*strokes RiscPC with StrongARM, remembers working on it.*

It would be a prime RTOS.

SMSQ/E is by no means an RTOS. (And especially some SMSQ/E storage drivers are the worst case when it comes to RT requirements.)
But RTOS mention gets us closer to reality. If you put your huge effort into a completely new RTOS, instead of an SMSQ/E port, you might have a chance on at least a niche market.

(RTOS does not mean that an OS is usually fast or efficient. RTOS means it can meet a deadline deterministically. This is required for some embedded systems, e.g. motion control.)

Thanks for explaining what an RTOS is.

If SMSQ/E was running on a 2GHz processor, with time slices 1/1,000,000th of a second instead of 1/50th of a second, and only very slightly revised job control, the distinction becomes moot.

The difference between FPGA and emulation will not necessarily get larger over the years. Semiconductor progress also goes into FPGA, not just ARM CPUs.

Emulation will be able to go massively multicore. FPGA will get a little faster, but to go massively multicore on an FPGA, you're going to be configuring 20 68000s for one 68060. But yes, you're right, there will be some interesting hardware in the future.

[Peter]

*strokes RiscPC with StrongARM, remembers working on it.*

Aha! That explains everything for me.

Thanks for explaining what an RTOS is.
If SMSQ/E was running on a 2GHz processor, with time slices 1/1,000,000th of a second instead of 1/50th of a second, and only very slightly revised job control, the distinction becomes moot.

No. If CPUs had such a performance, other RTOS would benefit likewise, and you'd come back to the question of deterministic timings. SMSQ/E will not by slight modifications be an RTOS that can compete on the market, additionally it depends on drivers that are not useable for RT right now. I have actually used several RTOS on a number of architectures. Even on 68K, SMSQ/E is no match, I had to resort to a different solution. You'd have to implement something new for ARM, maybe based on Tony Tebby's "Stella" concepts.

Emulation will be able to go massively multicore. FPGA will get a little faster, but to go massively multicore on an FPGA, you're going to be configuring 20 68000s for one 68060.

I doubt that emulation could go massively multicore if the emulated system (Minerva, SMSQ/E) is strictly singlecore. We were just talking performance factor between FPGA and emulation. Not the obvious structural benefits of one fast CPU versus many slow CPUs on FPGA.

Structural benefits can also be achieved for 68K on FPGA. And actually have been achieved by an Amiga accelerator core which claims 68060+ performance. Which brings us back on topic.
I'm still waiting for one of the Amiga + Vampire owners on this list, on feedback how well its runs Amiga-QDOS or QDOS Classic.

[Pr0f]

What about potential instruction time improvements that could be had with FPGA design, and in addition to that, the possibility of building in some primatives that could provide functions to accelerate parts of the code that are involved in repetative data movements ?

The original coprocessor architecture of the 68K was supposed to be extensible, but I only recollect FPU and MMU being made availabe, were there any others??

[tofro]

The original coprocessor architecture of the 68K was supposed to be extensible, but I only recollect FPU and MMU being made availabe, were there any others??

There were at least the 68440/450 DMA controllers, 68681 DUART, 68901 MPU and 68230 PIT

Tobias

[Peter]

What about potential instruction time improvements that could be had with FPGA design

For many register-to-register instructions, the Q68 takes just one cycle already, if run from internal RAM. The much larger factor is SDRAM access, i.e. lack of cache.
Further improvements could come from newer, high clocked chips, wider memory, and fundamental changes like dual-execution units, branch prediction, etc. (Not that I have plans to become a CPU guru.)

and in addition to that, the possibility of building in some primatives that could provide functions to accelerate parts of the code that are involved in repetative data movements ?

If the Q68 is the reference, a cache controller with burst implementation and copyback would gain more. But yes, if you had that already, your proposal means further performance improvement. IIRC the Amiga/Vampire guys did similar. Problem: Requires CPU specific code.

Which reminds me I must try the QL-Amiga with the Vampire.

Could you try with QDOS Classic for Amiga also? http://www.dilwyn.me.uk/emu/index.html# ... _for_Amiga

[Pr0f]

The original coprocessor architecture of the 68K was supposed to be extensible, but I only recollect FPU and MMU being made availabe, were there any others??

There were at least the 68440/450 DMA controllers, 68681 DUART, 68901 MPU and 68230 PIT

Tobias

The last 3 on your list are purely support chips, and don't extend the instruction set of the processor at all. I don't think the DMA controllers did either, but I don't have much documentation for those.

I am specifically talking about devices that share the processor bus and are addressed in CPU space, and use the A line and F line instructions.

[tofro]

I am specifically talking about devices that share the processor bus and are addressed in CPU space, and use the A line and F line instructions.

So you meant the peripheral chips that used the official coprocessor interface of th m68k. Indeed , these were only the MMUs and the arithmetical co-processors. None of them, to my knowledge, ever used Line-A instructions. Both used Line-Fs.

And the other chips btw were in no way "pure support chips", as you say - They are "processors" as well, but simply don't use a shared instruction space (wouldn't make a whole lot of sense for their functions anyhow), but rather a register interface.

Tobias