Page 2 of 2

Re: Native QL?

Posted: Thu Oct 08, 2020 10:59 am
by Pr0f
Ruptor wrote:
Derek_Stewart wrote:What use would the system be put to use, when other existing systems like Q68, QL-SGC Minerva I2C, QPC2 with PC I/O, could be used or enhanced to use?
I think the same about all the different emulators what is the point when one is enough. For me a native QL OS would show that GHz & Gbytes are not required and highlight the ridiculous path software engineering has taken. The QL does most stuff with 48K and Windows did everything with 10Meg so I dream of an old OS on a modern CPU. :)


I think multiple emulators exist because of 2 reasons - different platforms that the emulator runs on, and also for competition - so there are several emulators with similar feature sets but subtle differences - I have no problem with there being more than one - you can't deny someone a lively-hood or hobby because of a desire to have only one uber emulator.

Emulators are good for testing out ROM's and running QL programs at very fast speeds, and for getting programs in and out of the QL environment from the wider world.

I like hardware myself so also have an interest in building / designing hardware that can run on the QL / Spectrum and some other obscure platforms - like the old GESPAC G64/G96 stuff - vintage industrial !

Re: Native QL?

Posted: Thu Oct 08, 2020 11:17 am
by Derek_Stewart
Pr0f wrote:
Ruptor wrote:
Derek_Stewart wrote:What use would the system be put to use, when other existing systems like Q68, QL-SGC Minerva I2C, QPC2 with PC I/O, could be used or enhanced to use?
I think the same about all the different emulators what is the point when one is enough. For me a native QL OS would show that GHz & Gbytes are not required and highlight the ridiculous path software engineering has taken. The QL does most stuff with 48K and Windows did everything with 10Meg so I dream of an old OS on a modern CPU. :)


I think multiple emulators exist because of 2 reasons - different platforms that the emulator runs on, and also for competition - so there are several emulators with similar feature sets but subtle differences - I have no problem with there being more than one - you can't deny someone a lively-hood or hobby because of a desire to have only one uber emulator.

Emulators are good for testing out ROM's and running QL programs at very fast speeds, and for getting programs in and out of the QL environment from the wider world.

I like hardware myself so also have an interest in building / designing hardware that can run on the QL / Spectrum and some other obscure platforms - like the old GESPAC G64/G96 stuff - vintage industrial !

Hi,

Okay, I concede that point, still a hard job to convert M68K to RISC, though, maybe RISC processor registers can be made to look like like a 68000 style CPU

D0.L could be the same as R0 and the M68K OP Codes could be defined in a macro, assuming there is a good enough macro assembler for R-PI.

Re: Native QL?

Posted: Thu Oct 08, 2020 11:17 am
by tofro
Trying to port QDOS to ARM (or C, compiled to arm), what would it achieve? Well, it would be possible: building an API aligned with QDOS, implementing stuff like an IO.FBYTE trap and the likes as a C API, would be technically possible, you could even compile native QDOS C programs to that API and run them.

But what would you achieve?

Well, just another ARM OS - amongst hundreds. It would not (could not) be compatible with native QDOS or SMSQ/E programs, and it would compete with newer designs that are actually prepared to make best use of megabytes of memory, modern storage devices, networking, multi-core, whatever.

IMHO, QDOS/SMSQ is actually best at what it was designed for: Running specialiced, lean and mean applications natively on 68k hardware (real or emulated).

Re: Native QL?

Posted: Thu Oct 08, 2020 12:04 pm
by Peter
stephen_usher wrote:You could potentially create a "just-in-time" compiler which interprets the 68000 op codes and translates them into the native processor instructions and replaces calls the hardware or ROM with function calls.

68K emulation with JIT already exists, e.g. for Basilisk and UAE.
Not sure, but if my memory does not fail, Daniele even had a special Qemulator version with JIT.

Re: Native QL?

Posted: Thu Oct 08, 2020 12:17 pm
by Pr0f
Peter wrote:
stephen_usher wrote:You could potentially create a "just-in-time" compiler which interprets the 68000 op codes and translates them into the native processor instructions and replaces calls the hardware or ROM with function calls.

68K emulation with JIT already exists, e.g. for Basilisk and UAE.
Not sure, but if my memory does not fail, Daniele even had a special Qemulator version with JIT.


When I was disassembling GC roms mounted on Qemulator to see where the OS patching was done, I found that the calls to I/O devices are replaced with an a-line trap so that the emulator could service the request - a clever way of dealing with the issue of emulating hardware

Re: Native QL?

Posted: Thu Oct 08, 2020 2:21 pm
by Derek_Stewart
Hi,

This sounds like my original thinking, there is a good RiscOS for the RPI, which has many good applications software, which look better than any QL equivalent.

Many be the best idea is to write applications programmes for the QL environment, with all the colours we have now.

I think QL assembler is easier than other M68K alternatives.

Why not leave the RPI doing what it does best and use the Q68, which has all the QL advantages and good I/O facilities.

Re: Native QL?

Posted: Sun Oct 18, 2020 9:13 pm
by XorA
I think QL assembler is easier than other M68K alternatives.


I doubt it, an aweful lot of Amiga and ST software written in assembler, and both OSes had assembler friendly entry points.

Having coded for AmigaOS myself its significantly more useful from assembler than I have found QDOS.