QLirc 1.99.8

[dilwyn]

Very little progress made on QLirc last few weeks due to being so busy. Here's the package as it stands, while I continue to work on it.

Connects to QL Forum online chat and other IRC channels on QPC2, and recent versions of QemuLator and sQLux, thanks to the work of Daniele Terdina and Graeme Gregory.

Written in BASIC and uncompiled as yet - runs quite reliably on my QPC2 system at least. Does not work on an unregistered QemuLator, TCP/IP must be enabled.

Before use, make sure you read the document showing how to alter the configuration settings as need be in the variables near the start of the program.

QLirc1_99_8.jpg

QLirc1_99_8.zip

[Derek_Stewart]

Hi Dilwyn,

Could QLirc be adapted to be a web browser?

[dilwyn]

Hi Dilwyn,

Could QLirc be adapted to be a web browser?

Not directly, no. But I do have longer term plans in that direction!

[ppe]

Thank you for sharing, Dillwyn! This is a really nice implementation! The code is very readable and nicely structured. Will it go through Turbo nicely?

I must say that the problem of simultaneously reading keyboard and handling bidirectional network communications at the same time is a pretty tough one to pull off in SuperBasic so you and Tim have done a great job!

I did a bit of prototyping with a minimalistic C-based IRC client compiled with C68. Unfortunately, it uses the CURSES library whose implementation on the QL side seems to be lacking a couple of features. So I have not managed to mangle the implementation into a decent adaptation. Also, albeit based purely on feeling not actual benchmarking, the CURSES library implementation on the QL seems quite slow. But it does make the job of porting sw easier.

[dilwyn]

Thank you for sharing, Dillwyn! This is a really nice implementation! The code is very readable and nicely structured. Will it go through Turbo nicely?

I must say that the problem of simultaneously reading keyboard and handling bidirectional network communications at the same time is a pretty tough one to pull off in SuperBasic so you and Tim have done a great job!

I did a bit of prototyping with a minimalistic C-based IRC client compiled with C68. Unfortunately, it uses the CURSES library whose implementation on the QL side seems to be lacking a couple of features. So I have not managed to mangle the implementation into a decent adaptation. Also, albeit based purely on feeling not actual benchmarking, the CURSES library implementation on the QL seems quite slow. But it does make the job of porting sw easier.

Thanks Petri. ATM it won't compile with Turbo - not tried current QLirc, can't remember why earlier ones wouldn't compile. A previous version was successfully compiled with QLiberator 3.36

The keyboard and bidirectional network communications was Tim Swenson's idea, I simply built on that. No library as such was used, merely uses the bog-standard TCP/IP handling in some emulators. There is a bit of an issue with some emulators concerning timeout on fetching individual characters from the TCP channel - I think Daniele changed something to help in the most recent QemuLator. In order to get the bidirectional working, you had to quickly alternate between reading and writing bytes from/to the TCP channel, and INKEY$(#channel) is the only practical way to do it in BASIC at least. I seem to remember Tim had some issues trying to get it to work on SMSQmulator (can't remember the reason - I don't have SMSQmulator on my computer). And XorA on here did some changes to sQLux (the uQLx derivative) to help deal with the same issue with TCP.

As ever with these things, time is the problem for me, as QL software projects tend to get larger and more complex. I've loads of ideas and part-written projects, but no time! I'd hoped our lockdown period in Wales would have allowed me a bit more time to work on QL software, but if anything the reverse happened

[ppe]

INKEY$(#channel) is the only practical way to do it in BASIC at least.

From perfomance perspective it would be really nice to have an

Code: Select all

INPUT #chan,var$,timeout

with the timeout parameter it would be possible to attempt to read a line but if nothing is available then continue.

As ever with these things, time is the problem for me, as QL software projects tend to get larger and more complex. I've loads of ideas and part-written projects, but no time! I'd hoped our lockdown period in Wales would have allowed me a bit more time to work on QL software, but if anything the reverse happened

I think you are getting an amazing amount of things done

[swensont]

Petri,

> From perfomance perspective it would be really nice to have an
> INPUT #chan,var$,timeout

I was thinking of that, but the problem is that as the user is typing a new message, the program would not be getting any incoming messages.
By quickly getting input from either network or user, there is no lag on either side.

Tim

[NormanDunbar]

This is for Dilwyn, specifically.

Dilwyn, you mentioned, I think, on the Zoom chats over Christmas that you were having problems with the code to convert to and from UTF8 for QLirc. Is this still a problem?

The reason I'm asking is because I think I might know what it could be. (Too many italics?)

As it stands, the code I sent you only considers four of the three byte code points; the Euro and the four arrow keys. Everything else is assumed to be one or two bytes in UTF8. The code doesn't consider any other three byte characters, nor does it consider 4 byte characters (all this when converting from UTF8 to QL)

On top of that, the QL character set, at least the default one as originally supplied, is most likely missing a large number of accented characters.

My though was that if you get an unhandled character from UTF8, which is not in the QL's own codeset, then there will be problems. Perhaps I need to extend the code to return the standard "blotch" character for those unknown ones, if they are detected?

On the other hand, I may just be barking, as usual!


Cheers,
Norm.

[ppe]

Dilwyn, it now runs on a 640 kB Black Box QL:

Oscilloscope not required. Sorry about the mess but am pretty excited to have a working tcp_ device for the black box

The driver currently supports PRINT, INKEY$ and INPUT on a TCP_ device which is enough for this IRC client. Uses the W5300 based network card.

[dilwyn]

Great news, Petri - might even encourage me to continue development of QLirc once present project is complete.