Page 3 of 3
Re: Can we learn from Amiga OS?
Posted: Sun Mar 22, 2020 11:16 pm
by janbredenbeek
janbredenbeek wrote:tofro wrote:
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
Re: Can we learn from Amiga OS?
Posted: Sun Mar 22, 2020 11:16 pm
by janbredenbeek
tofro wrote:
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]
Re: Can we learn from Amiga OS?
Posted: Sun Mar 22, 2020 11:21 pm
by 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!
Re: Can we learn from Amiga OS?
Posted: Sun Mar 22, 2020 11:26 pm
by tofro
janbredenbeek wrote:
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.
Re: Can we learn from Amiga OS?
Posted: Wed Mar 25, 2020 10:12 pm
by 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
Re: Can we learn from Amiga OS?
Posted: Thu Mar 26, 2020 10:53 am
by XorA
Pr0f wrote: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).
Re: Can we learn from Amiga OS?
Posted: Thu Mar 26, 2020 7:56 pm
by bwinkel67
XorA wrote: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?
Re: Can we learn from Amiga OS?
Posted: Thu Mar 26, 2020 11:33 pm
by 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.