The Sinclair QL Forum

Hi,

All we need now is: Java, HTML5 implementations.

But I suspect that this will not quick to do as most people will use a PC for the Internet access.

Back in the good old days of BBS comms, all we had was a QL and comms software, it was surprising the development that took place. The stopped with the use of QL Emulators which all the QL system to run in parallel with the Windows/Linux/IOS comms software.

Or have I got this wrong...

tofro wrote:Dilwyn,

following the experiments of Martin, I am convinced the TCP/IP implementation in Q-Emulator is somewhat limited (He mentions something like that in the thread referenced above).

QPC, uQLX and SMSQmulator should work somewhat identical, as their implementation is based on the same specification (That of uQLX).

Tobias

Thanks tofro. I rather suspected that, but having been so wrong so many times on this subject I did tend to assume it was me doing something wrong.

I just downloaded SMSQmulator and ran the test program on it. Seems to work fine (phew)

Derek_Stewart wrote:Hi,

All we need now is: Java, HTML5 implementations.

Erk...

Derek_Stewart wrote: But I suspect that this will not quick to do as most people will use a PC for the Internet access.
Back in the good old days of BBS comms, all we had was a QL and comms software, it was surprising the development that took place. The stopped with the use of QL Emulators which all the QL system to run in parallel with the Windows/Linux/IOS comms software.
Or have I got this wrong...

I think developments of that kind had largely stopped by the time QL emulators came along anyway.

Derek,

it's mostly about what it takes in terms of CPU to run a browser over contemporary web sites:

I have an overclocked 60MHz 68060 Amiga with plenty of memory here (i.e. well beyond the range of any QL hardware ever produced and probably even faster than some emulated hardware) that still struggles with some of the more modern, decently complex web sites - Other than having a bit of fun with a nice tech demo, I would still prefer my Mac to browse the web. The modern web just eats any CPU you throw at it for breakfast...

On a real-hardware-QL, web would not be the least bit of fun. And the effort you'd need to put into a browser that is only barely equipped with https and JavaScript, would be immense. Even the Amiga community that is much larger than the QL's was without an even somewhat decent browser for a long time.

Tobias

Hi,
And now applications must be multi-platform, things are even more complicated. Or are they? In fact with open-source getting popular, programming tends to get back to basics, ie c++ or even c, which can be compiled and run on just about any system.
So take a look at Ql C languages again : They may come in useful if we want to write for TCP devices in superbasic and CPort them for our PCs.
But converting from C to superbasic is another kettle of fish... So two-way QL links will be harder to achieve. KISS!
Is there a compromise?
Steve Poole.

EDIT - Sorry did not realise we had skipped over to another page....


From my experience of the IP drivers.

UDP connections don't work at all in Qemulator (you cannot even open them). And you have to be careful with TCP connections when Qemulator is acting as the 'server' side, When you accept connections. It will effectively hang the emulator until the connection is actually made.

UDP connections in QPC2 are a bit flaky. And they don't like working bi-directionally. (which they are supposed to) So you tend to have to open two channels, one for each direction. Also I could never get SEND_TO and RECV_FROM to work. TCP connections seem to work OK though.

Dilwyn - I assume you are using the full version of Qemulator, as the shareware one does not support the IP driver.

If you want to receive blocks of data, you can use the IP_RECV function in my IPBasic package to read data straight into memory. It's not limited to 32K, and you can 'peek' the data without actually removing it from the queue.

Martin_Head wrote:EDIT - Sorry did not realise we had skipped over to another page....
From my experience of the IP drivers.
UDP connections don't work at all in Qemulator (you cannot even open them).

OK, good to know that before I even tried to tinker with that.

Martin_Head wrote:And you have to be careful with TCP connections when Qemulator is acting as the 'server' side, When you accept connections. It will effectively hang the emulator until the connection is actually made.

Good to be warned about that too, though in my case it was used simply as a client.

Martin_Head wrote:UDP connections in QPC2 are a bit flaky. And they don't like working bi-directionally. (which they are supposed to) So you tend to have to open two channels, one for each direction. Also I could never get SEND_TO and RECV_FROM to work. TCP connections seem to work OK though.

I noticed that in your writings, thanks.

Martin_Head wrote:Dilwyn - I assume you are using the full version of Qemulator, as the shareware one does not support the IP driver.

Yes I am, and TCP/IP was ticked in the configuration, and QemuLator was listed in the Firewall list of allowed programs.

What was interesting was that Minerva QDOS, Aurora/Gold Card SMSQ/E and QemuLator SMSQ/E all produced the same result (apart from the fact that both SMSQ/E's managed to print an error line number without a message) implying that whatever is happening is part of the emulator routines as opposed to the OS itself.

The OPEN#3,"tcp_..." statement worked OK. It was PRINT #3,... which failed. And without an error, the program just stopped.
ToFro did say that you had experienced some difficulties, so I didn't pursue QemuLator any further as QPC2 and SMSQmulator seemed to work fine.

Martin_Head wrote:If you want to receive blocks of data, you can use the IP_RECV function in my IPBasic package to read data straight into memory. It's not limited to 32K, and you can 'peek' the data without actually removing it from the queue.

That's good to know, although even without your code splitting up into smaller chunks at a time with something like INPUT$ is still a good deal faster than reading tens of K of data with INKEY$, as you might expect.

I'm only worrying about getting the basics working at the moment, just to document enough so that users have a couple of working examples of how to download an html page or email. Derek said he was doing a browser, html 5,flash, php, Javascript etc (only joking Derek!)
At the moment, I'm sticking with "vanilla" BASIC to see what can be achieved so I can write up some simple basic documentation and examples. When the page goes live people will be able to see and use your material as well as mine, may as well make as much information available as possible in one go.