68060 based QL system?

Nagging hardware related question? Post here!

Do you want a 68060 based QL system?

No, better improve speed of FPGA based 68K
12
44%
Original Q60 with video updates
5
19%
New 68060 system design
10
37%
 
Total votes: 27
User avatar
Dave
SandySuperQDave
Posts: 1976
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 68060 based QL system?

Postby Dave » Thu Apr 19, 2018 4:55 pm

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.


User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: 68060 based QL system?

Postby pjw » Thu Apr 19, 2018 7:15 pm

Dave wrote:<>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 ;)


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
Peter
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Postby Peter » Thu Apr 19, 2018 10:29 pm

Dave wrote: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.

Dave wrote: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.)

Dave wrote: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.


User avatar
Dave
SandySuperQDave
Posts: 1976
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 68060 based QL system?

Postby Dave » Thu Apr 19, 2018 11:51 pm

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


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

Peter wrote:
Dave wrote: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. :D

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.

Peter wrote: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.


User avatar
Peter
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Postby Peter » Fri Apr 20, 2018 9:38 am

Dave wrote:*strokes RiscPC with StrongARM, remembers working on it.*

Aha! That explains everything for me. ;)

Dave wrote:Thanks for explaining what an RTOS is. :D
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.

Dave wrote: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. ;)


User avatar
Pr0f
Gold Card
Posts: 267
Joined: Thu Oct 12, 2017 9:54 am

Re: 68060 based QL system?

Postby Pr0f » Fri Apr 20, 2018 11:00 am

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??


User avatar
tofro
QL Wafer Drive
Posts: 1368
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: 68060 based QL system?

Postby tofro » Fri Apr 20, 2018 11:33 am

Pr0f wrote: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


User avatar
Peter
Super Gold Card
Posts: 637
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Postby Peter » Fri Apr 20, 2018 12:09 pm

Pr0f wrote: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.)
Pr0f wrote: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.

tofro wrote: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#QDOS_Classic_for_Amiga


User avatar
Pr0f
Gold Card
Posts: 267
Joined: Thu Oct 12, 2017 9:54 am

Re: 68060 based QL system?

Postby Pr0f » Fri Apr 20, 2018 12:17 pm

tofro wrote:
Pr0f wrote: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.


User avatar
tofro
QL Wafer Drive
Posts: 1368
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: 68060 based QL system?

Postby tofro » Fri Apr 20, 2018 1:49 pm

Pr0f wrote: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



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 4 guests