RasPiQL

[Peter]

Yes, I would be happy with a hardware QL (in addition) for my QL "work", but I NEED MORE SPEED for that to make it viable. I could possibly manage with 3-5 times the speed of the Q68, 128Mb and a more flexible display geometry (eg HD) but right now that seems over the horizon, so we soldier on with the possibilities we have..

Not completely over the horizon, as the 68060 provides this speed and I have (rusted) experience in designing with this CPU.
I'm not sure what you expect in terms of graphics. 1920 x 1080 in highcolor consumes over 100 times more memory than the QL graphics routines were designed for.
Would a resolution like 960 x 540 that just maps to 1920 x 1080 by doubling pixel size cover your needs?

Sorry to disappoint, but its unlikely to suffice. For starters, as you know, I had a Q60 @ 80MHz back in the day, the fastest QL hardware available then (and now?) It still didnt feel "comfortable"

I remember you saying that, but the 68060 @ 80MHz is 3-5 times faster than the Q68. So I thought you might have reduced your requirements. Some speed can be squeezed out of faster DRAM in a modernized 68060 design, but nothing overwhelming.

I already use 960x540 on my 13" laptop (as 1920x1080 has become unreadable on such a small screen for my aging eyes.)

I have not yet understood whether a 960x540 resolution (in addition to 1024x768 which I personally prefer), coming as a 1920x1080 signal to the monitor, is sufficient for you.

I know Ive harped on this before (and you have disagreed with me before ) but methinks some kind of graphics card (with as a minimum block drawing and scrolling functionality) might work and make all the difference.

A decent graphics accellerator for (DDR2...5) SDRAM is way too much work for me, plus I have too many doubts about software support. A new 68060 mainboard is crazy amount of work even without that.

Another thing: Have you ever considered Buffee? They claim their product will be a MC68040 drop-in replacement (when its finally ready). The "microcode" will be ARM assembler - no Linux middleman.

Yes, I think it was me who first brought it up at this forum.

[XorA]

I know Ive harped on this before (and you have disagreed with me before ) but methinks some kind of graphics card (with as a minimum block drawing and scrolling functionality) might work and make all the difference. Another thing: Have you ever considered Buffee? They claim their product will be a MC68040 drop-in replacement (when its finally ready). The "microcode" will be ARM assembler - no Linux middleman.

That already exists in Emu68 and PiStorm boards. Buffee has been vapourware for a very long time!

Everything is vapourware until it arrives! At least there has been continuous movement since 2019, and all the excuses for delays appear (to me) to be reasonably explained.

So if drop-in replacements for some faster variant of the MC68 already exist, whats happening with these? Arent they any good?

I guess you should ask that of the 10000s of users in Amiga forums

32 bit version of PiStrom for 020+ CPUs has just gone out to developers too.

But who would write the drivers needed for SMMSq/e to run on Emu68?

[Peter]

32 bit version of PiStrom for 020+ CPUs has just gone out to developers too.

But who would write the drivers needed for SMMSq/e to run on Emu68?

And why plug into the QL mainboard at all for such an emulator? For the Amiga, the original keyboard and storage were popular. Not so true for the QL.

[pjw]

<>
So if drop-in replacements for some faster variant of the MC68 already exist, whats happening with these? Arent they any good?

I guess you should ask that of the 10000s of users in Amiga forums

32 bit version of PiStrom for 020+ CPUs has just gone out to developers too.

But who would write the drivers needed for SMMSq/e to run on Emu68?

If Ive understood correctly, Emu68 is the MC68 emulation software for the PiStorm, which itself is a sort of Open Source hardware interface between a RaspberryPI and an Amiga. Clearly, the project is specific to the Amiga and thus wholly unsuitable for a building a next gen QL project. It may be an inspiration for someone wanting to upgrade a BBQL or something.

A better example might be the Apollo68080 FPGA CPU, which claims to be

..an affordable processor for your Amiga that is way faster than the fastest 68060. It is 100% code compatible with all CPUs and FPUs of the Motorola 68000 family [my emphasis]..

.. It is a new processor you can code as easy as any previous Motorola 68K CPU. The Apollo68080 can execute all the instructions of the 68k processors before it..

If one were designing a Q68 successor around a MC68060 from scratch, one might as well use the faster processor! According to one source:

Gunnar von Böhn which is the head of Apollo Team offers regarding this a1k.org post, to make his 68080 reimplementation of a 68k processor available to other hardware manufacturers..

.. From Böhn’s offer provides that a hardware manufacturer can license a free version of the 68060, which is throttled after booting to the speed of a real 68060 processor, but otherwise has the full range of features of the 68080. This “shareware output” of the CPU could then end users by acquiring a Keycode from Böhn from throttling.

Sounds good so far! Obviously, Im a punter in these matters, not a pundit, but would this at least be worth looking into? The Apollo is available now, AFAICS..

[pjw]

<>

I already use 960x540 on my 13" laptop (as 1920x1080 has become unreadable on such a small screen for my aging eyes.)

I have not yet understood whether a 960x540 resolution (in addition to 1024x768 which I personally prefer), coming as a 1920x1080 signal to the monitor, is sufficient for you.

960x540 is tight, but a necessary evil on a 13" HD monitor. On a large, say 24"+ monitor, it would still be tight - and just look block-y and dumb (IMHO)

[XorA]

If Ive understood correctly, Emu68 is the MC68 emulation software for the PiStorm, which itself is a sort of Open Source hardware interface between a RaspberryPI and an Amiga. Clearly, the project is specific to the Amiga and thus wholly unsuitable for a building a next gen QL project. It may be an inspiration for someone wanting to upgrade a BBQL or something.

You haven’t, emu68 can be used on pistorm hardware. It can also be used bare bones on Pi hardware. In that mode you would need to write smsq/e drivers for gfx, sound, usb, and anything else you wanted to enable. Emu68 originally came out of running AROS 68k on the pi as AROS arm development has stalled! The developer has actually written AmigaOS drivers for the Pi peripherals!

You could design a next gen board with a pi gpio header to expand to other peripherals off the Pi board.

[pjw]

If Ive understood correctly, Emu68 is the MC68 emulation software for the PiStorm, which itself is a sort of Open Source hardware interface between a RaspberryPI and an Amiga. Clearly, the project is specific to the Amiga and thus wholly unsuitable for a building a next gen QL project. It may be an inspiration for someone wanting to upgrade a BBQL or something.

You haven’t, emu68 can be used on pistorm hardware. It can also be used bare bones on Pi hardware. In that mode you would need to write smsq/e drivers for gfx, sound, usb, and anything else you wanted to enable. Emu68 originally came out of running AROS 68k on the pi as AROS arm development has stalled! The developer has actually written AmigaOS drivers for the Pi peripherals!

You could design a next gen board with a pi gpio header to expand to other peripherals off the Pi board.

Interesting! But it all seems too Pi-like for my liking. Also, the rest of the system would have to be developed from scratch.

If "someone" were toying with the idea of designing a Q68 successor, wouldnt a drop-in CPU replacement instead of the mooted MC68060 be the easier path, as everything else would remain more or less the same?

[Peter]

In that mode you would need to write smsq/e drivers for gfx, sound, usb, and anything else you wanted to enable. Emu68 originally came out of running AROS 68k on the pi as AROS arm development has stalled! The developer has actually written AmigaOS drivers for the Pi peripherals!

Which is awesome and even if we were talking just the USB portion, quite unrealistic for SMSQ/E.

You could design a next gen board with a pi gpio header to expand to other peripherals off the Pi board.

The Qzero already has a RPi compatible I/O header, so it could interface the CPU emulation running on PRi to the QL-specific stuff like gfx.
Especially in combination with the QLbase board, providing connectors for HDMI, etc. I could see this as a relatively decent hardware base.

However, such a hybrid solution is still a huge project. With several other QL projects still undocumented / unfinshed / not in series production, I don't see myself having the trime and motivation.

Maybe classic software emulation on top of a very fast booting, tailormade Linux is almost as good, and much easier to achieve?

[XorA]

Maybe classic software emulation on top of a very fast booting, tailormade Linux is almost as good, and much easier to achieve?

That was certainly the motivation for making sQLux work on linux framebuffer. I just haven't made a cutdown distro to launch it yet!

For the future though would need something that could run SMSq/e!

[Peter]

Sounds good so far! Obviously, Im a punter in these matters, not a pundit, but would this at least be worth looking into? The Apollo is available now, AFAICS..

It has been looked into. "Available" means one has to pay for commercial support of porting/debugging this closed source core to a different hardware. And it is nowhere clear if the core would execute QL code correctly. Just like the TG68 ran Amiga/Atari stuff fine, but failed with QL code. Until Richard and me painfully debugged it over years. Way too risky for me, both in terms of finances and time.

Compared to that, a classic 68060 approach is way more realistic. The question really is, at which speed are folks like you satisfied. On one hand you say 3-5 times Q68 speed is okay, on the other hand you say a 68060 @ 80 MHz (certainly 3-5 times faster) is too sluggish...

Maybe a closer look at what exactly felt too sluggish on the Q60/80 is worthwhile. A new 68060 design could make memory significantly faster, but not the CPU speed behind cache. So it would mainly improve tasks where a lot of memory is involved.