Can we learn from Amiga OS?

[janbredenbeek]

that's more or less what SpeedScreen does - It checks whether character positions align with font origins and handles this special case much faster than original QDOS. Well, in the end, QDOS doesn't literally call the PLOT routine, of course.

Not only the character positions, also the various colour and OVER combinations. It's fastest when you write white on black (and with CSIZE 1,0 since that uses 8-pixel wide characters). I've always found it a pity that the QL lacked a character-mapped display mode like the BBC's teletext mode.
Apart from that, I/O will be much faster when handling multiple bytes at once in one TRAP (IO.FSTRG/IO.SSTRG) since you don't have the overhead of switching contexts with each character, but the driver needs to be written with that in mind too. I had to devise my own string-based queue handling in QLTERM to make it as efficient as possible, which was also needed given the poor state of the serial ports at that time...

Jan

[janbredenbeek]

that's more or less what SpeedScreen does - It checks whether character positions align with font origins and handles this special case much faster than original QDOS. Well, in the end, QDOS doesn't literally call the PLOT routine, of course.

Not only the character positions, also the various colour and OVER combinations. It's fastest when you write white on black (and with CSIZE 1,0 since that uses 8-pixel wide characters). I've always found it a pity that the QL lacked a character-mapped display mode like the BBC's teletext mode.
Apart from that, I/O will be much faster when handling multiple bytes at once in one TRAP (IO.FSTRG/IO.SSTRG) since you don't have the overhead of switching contexts with each character, but the driver needs to be written with that in mind too. I had to devise my own string-based queue handling in QLTERM to make it as efficient as possible, which was also needed given the poor state of the serial ports at that time...

Jan[/quote][/quote]

[janbredenbeek]

Oh dear - seems that something goes wrong when I edit a quoted reply - the forum software keeps adding quotes, even my own text got quoted!

[tofro]

I've always found it a pity that the QL lacked a character-mapped display mode like the BBC's teletext mode.

Same here. I've just recently analyzed a game for the Commodore Plus 4 which isn't able to use hardware sprites like the C64. But that game uses UDG graphics in text mode where it simply supplies pre-shifted UDG variations of the same character to enable pixel-perfect movement. That game is fast, even compared to the C64's hardware sprites, and by far not as limited in sprite size and colouring.

Tobias.

[Gromit337]

The situation with the latest versions of the 'genuine' Amiga OS is... complicated. And litigious. However, AROS and MorphOS are both reverse engineered, built from the ground up without access to the original codebase. Aros 68K is slower than Amiga OS on the same hardware, but it's more extensible and still a work in progress. And it's free.The x86 version is very fast compared to Linux or Windoze, and it incorporates fairly transparent 68K emulation for 'classic' Amiga software. I daresay the Aros team or the team behind AOS 3.14 could provide more info on the efficiency of 68K C compilers.

It would make much more sense to get a £10 Raspberry pi zero W (or perhaps the compute module) to do the heavy lifting, using a stripped down Linux kernel. There's loads of ready made versions available. Boots in a few seconds, USB, ethernet, WiFi, and modern file systems are all baked in. Use the Pi as a shared data storage device, a co-pro and a means of accessing USB devices etc. Network the QL and pi together using your preferred method, and using high level scripts, get the Picto crunch numbers and pass results back to the QL. From the QL, browse through files on the shared storage, use a script on the QL to instruct the pi to decompress a zip file and store it in the shared storage. Or to resize a photo with parameters you supply, play an audio file, sort your database files and make your lunch. The QL is oblivious to the fine details, it just sends a message to the Pi and gets a message saying the files are now ready to use. Relatively simple, high level programming on both sides.

Discuss!

Gromit

[XorA]

C compilers - certainly in the microcontroller world - can produce assembler as output, so that any critical timing loops can be tweaked. Optimising compilers usually produce quite efficient code, so there is no outright reason why c could not be used.

The hard task would be rewriting all the routine to use C instead and then abstracting out hardware and driver code - so that it would be more portable.

Someone ported (mostly by script I beleive) Frontier (Elite 2) 68k code to C.

And aren't the hardware abstractions already done in SMSq/e (they must be for the SMSQmulator version I assume).

[bwinkel67]

Someone ported (mostly by script I beleive) Frontier (Elite 2) 68k code to C.

And aren't the hardware abstractions already done in SMSq/e (they must be for the SMSQmulator version I assume).

I just started a thread, partially because of Elite, here viewtopic.php?f=12&t=3212 asking about a port on the QL.

Is it being worked on?

[Derek_Stewart]

Hi,

The first version of Elite is available in 6502 source code, to run on an Acorn BBC B Micro, which is available at Ian Bell's web site:
http://www.ianbellelite.com/

I have already ported txtElite, which is a non-graphical version of Elite.

There are other conversions of the original Elite which uses Allegro or SDL libraries.

I was converting the 6502 Elite source code to 68K, bit, I have been a little busy lately. I might revisit the project to see if the Q68 could be a suitable platform.