RasPiQL

[Peter]

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!

Hmmm... how about emulating a Q68 for that purpose?
In a first attempt, you could try enlarging RAM to 28 MB, load the Q68 SMSQ/E binary to $32000 and just jump there... The Q68 is quite close to a QL, so SMSQ/E might even boot. IIRC Richard had emulated several portions of the Q68 in his private UQLX variants. Maybe that code can be recovered if you are interested.

[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!

Hmmm... how about emulating a Q68 for that purpose?
In a first attempt, you could try enlarging RAM to 28 MB, load the Q68 SMSQ/E binary to $32000 and just jump there... The Q68 is quite close to a QL, so SMSQ/E might even boot. IIRC Richard had emulated several portions of the Q68 in his private UQLX variants. Maybe that code can be recovered if you are interested.

Now that is a GREAT idea.

[pjw]

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.

I thought Böhn had opened up his design? Well, you know your own business, of course. I can only dream.

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

I dont know how I can make it any clearer. Lets just say: The Pi4 with SMSQmulator is just within the border of feeling comfortable; the Q68 and Q80, for whatever reason, never achieved that for me. As you saw from my simple timing test, the Pi4 setup is >5x faster than Q68, so perhaps I was just trying to be too kind with the numbers ..

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.

Scroll without jerking in hicolor; move window without lag for saving background, dragging, and then again on dropping it; screen geometry that matches modern displays.

But if Im the only one here who wants anything like it - I dont hear anyone else piping up - you can safely ignore me. I can soldier on with the existing options. Thanks for engaging, though!

[Peter]

Scroll without jerking in hicolor; move window without lag for saving background, dragging, and then again on dropping it;

Those are memory intense operations and might improve significantly by the (possible) use of faster DRAM. Roughly factor 2 compared to Q60 might be possible here.

screen geometry that matches modern displays.

When using FullHD 27" display with an emulator, I usually double pixels, otherwise most QL stuff simply looks too small for me.
So my personal interest in such a enormous memory/speed hog (in 68K dimensions) is quite small. 1024 x 768 remains my favorite as maximum resolution. Also, the FPGAs I use can not generate HDMI signals if I go higher (even 1024 x 768 @ 60 Hz already means overclocking the chip).

[RalfR]

Meanwhile it is wonderful to have *very* big screen resolutions. Wonderful to look at JPEGs but awful for programs, the letters are too small.

On my QPC2 setup on an 19" Monitor I use 640x512 with a Windows 7 size of 1280x1024, the pixels are not interpolated and all is readable.

And the idea of a proportional font (as Peter has done it in his demonstration) is still good. QDT has a bit of D&D, so it should be possible.

[Peter]

In a first attempt, you could try enlarging RAM to 28 MB, load the Q68 SMSQ/E binary to $32000 and just jump there... The Q68 is quite close to a QL, so SMSQ/E might even boot. IIRC Richard had emulated several portions of the Q68 in his private UQLX variants. Maybe that code can be recovered if you are interested.

Now that is a GREAT idea.

Don't forget to configure SMSQ/E to DISP_MODE 1 (normal QL mode 4) before you try.
Also I would disable SD card 2 in the SMSQ/E configuration and set the "boot from" option to "none".
Maybe all drive image options should also be set to "none".
If RAM size is a problem for sQLux, I think I have a 16 MB variant of SMSQ/E somewhere.

[XorA]

In a first attempt, you could try enlarging RAM to 28 MB, load the Q68 SMSQ/E binary to $32000 and just jump there... The Q68 is quite close to a QL, so SMSQ/E might even boot. IIRC Richard had emulated several portions of the Q68 in his private UQLX variants. Maybe that code can be recovered if you are interested.

Now that is a GREAT idea.

Don't forget to configure SMSQ/E to DISP_MODE 1 (normal QL mode 4) before you try.
Also I would disable SD card 2 in the SMSQ/E configuration and set the "boot from" option to "none".
Maybe all drive image options should also be set to "none".
If RAM size is a problem for sQLux, I think I have a 16 MB variant of SMSQ/E somewhere.

RAM is not an issue, its just a malloc away from being bigger. I just stupidly had never considered trying to boot Q68 on it! Let me ponder on it a while (still struggling for personal coding time with work and illness).

[Derek_Stewart]

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!

Hmmm... how about emulating a Q68 for that purpose?
In a first attempt, you could try enlarging RAM to 28 MB, load the Q68 SMSQ/E binary to $32000 and just jump there... The Q68 is quite close to a QL, so SMSQ/E might even boot. IIRC Richard had emulated several portions of the Q68 in his private UQLX variants. Maybe that code can be recovered if you are interested.

Now that is a GREAT idea.

Hi,

I can only allocate maximum of 16Mb in sQLux and UQLX, how do I increase the memory size?

[Derek_Stewart]

I dont know how I can make it any clearer. Lets just say: The Pi4 with SMSQmulator is just within the border of feeling comfortable; the Q68 and Q80, for whatever reason, never achieved that for me. As you saw from my simple timing test, the Pi4 setup is >5x faster than Q68, so perhaps I was just trying to be too kind with the numbers ..

Whats a Q80?

The Vampire for the Amiga is over £400, only the A1200 version and the standalone version is available.

Even if the hardware could be made, the Vampire Core is closed source.

A better option would be the A500 PIStorm with a 68008 adpter, then the drivers to drive the PI....

All easy, just a bit of soldering for the hardware and typing for the software... LOL

[Derek_Stewart]

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

Back in the olde days, with the Q60 production, GCC-QL has just been ported to Linux and could cross compile C ported programmes with a up-to 30% speed increase in the some application software.

I thought that this was great, bu the QL expert of the day in QL Today, cast doubts on the validity of the timings.

I think a 3.5x speed increase is excellent, not to be scoffed at.