Passing channels to jobs

Anything QL Software or Programming Related.
Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Passing channels to jobs

Post by Tinyfpga »

I am trying to write a "crap game" in BASIC on a Q68 for the 2021 Sinclair Crap Game Competition. The game is not very dynamic at the moment because
I am unable to get two jobs to write to a window concurrently. I am using QLiberator, set to "no-windows-open", to compile my programs using its facility to
pass channels to daughter jobs.

Passing channels to jobs is described on pages 60-61 of the Qliberator PDF manual but no matter what I do I am unable to get a daughter job to write to the
window of the calling job concurrently.

Have any Qlers managed to do this and if so how did they do it in BASIC?


EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Passing channels to jobs

Post by EmmBee »

Hi,

In the manual, on page 61, it does say that the channels must be already open.
I have tried the example given there, in the manual, and it does seem to work.

So, the suggestion is to compile with Winds ON
And remember to LRESPR the file, before testing.

I hope you can get this to work. Good luck!

EmmBee


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Passing channels to jobs

Post by Tinyfpga »

Thank you, emmbee, for your reply.
I tried with windows open and my test programs worked, or so I thought.

When I looked at the job list I could see two jobs executing , with one as a daughter job, but when I looked at the channel list I saw that
the daughter job had opened its own channel and was writing to that channel over the calling job's window.
The instruction within job1 that I used:- QX win2_job2,#1 had been compiled as QX win2_job2

In practice this looks like two jobs are writing to a window concurrently which is what I want to achieve. The only limitation being that the calling job
cannot write to the same area defined by the daughter's window.

I then remembered that QD consists of a two jobs executing concurrently and on looking at the job and channel list I could see that
the daughter job's channel is open within the calling job's channel list. I am sure that what can be achieved in assembler is greater than
in BASIC.

The part of your advice I could not understand was " remember to LRESPR the file, before testing". Could you explain what I have to do
to achieve this and which file I need to LRESPR ? What is the significance of LRESPRing a file?

The problems I describe in my posts may have something to do with the fact that I am writing my programs within the Pointer Environment.
Qliberator was probably conceived before the PE and getting two BASIC programs to write to an OUTLNed PE display channel may not be possible using
compiled BASIC. The QD example proves that it is possible in principle but only from assembled programs.


EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Passing channels to jobs

Post by EmmBee »

Hi again,

I believe you need to add another comma in your instruction ... QX win2_job2,,#1
Doing that should link job1's #1 to job2's #1. Both jobs will then write to the same window.

About LRESPR, the idea is to LRESPR win2_job2_obj produced by QLiberator.
That would create new KEYWWORDS from any external procedures or functions defined.
This can be quite useful. Read about all this in the QLiberator manual from page 74.
Although I note you are not using these features so this can be ignored.

EmmBee


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Passing channels to jobs

Post by Tinyfpga »

I am not an owner of a QL have only recently tried to learn how to program a Q68 in BASIC. There is a lot
to learn and although there is extensive BASIC programming information on Dilwyn Jones's website much of it
(actually all of it I think) relates to programming QLs and their variants. So any replies to my, maybe foolish questions, are much appreciated.

I have made many attempts to get two programs to write to a window and have already tried your suggested variant.
The results of this fiddling has produced a myriad of outputs, some really odd but none so far that seem to work in the
way of the QD editor. ie. JOB1 - Daughter JOB2 and display channels open only in JOB1

I think I understand your LRESPR expanation. It seems like a very useful thing to be able to do. I will read the manual
and perform some experiments when I find the time.

I don't consider the Q68 a QL variant but an enjoyable learning tool in its own right. I have bought various
learning systems recently including a Microbit, a PICAXE, a Raspberry Pi and an Arduino.
I know they were all designed to do different things but as a beginner learning to write simple programs,
the Q68 is by far the most accessible. What is missing is a beginners guide for the machine a bit like the very good guide that was produced
for the QL some twenty seven years ago.

One of the reasons for my wanting to have two jobs writing to a window is to learn how to write a program that consists of more than one
job running concurrently to solve a problem. The next step would be to have multiple jobs running in separate Q68s
solving a problem. (Could this be classed as multi-processing?).

If Peter Graf were to start producing Qzeros I could realistically build a box containing many Zeros to do this kind of thing. Peter Graf writes that a Qzero can be configured to be dual processor/memory system. This would double the proceesing capability of a box. There is as yet no mention how the two systems would comunicate with each other but I imagine it could be within the FPGA and therefore very fast.


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: Passing channels to jobs

Post by dilwyn »

The notion of a new User Guide for modern systems has been raised many times and sank without trace each time. Generally because each system is probably sufficiently different to need its own manual, especially in regard to filing systems. Although thanks to people like Marcel there is more convergence these days with more and more systems able to use the QXL.WIN filing systems, for example.

Broadly, you would need to take the original QL guide, and add the Toolkit 2 and SBASIC manuals, plus separate sections for each filing system.

So, the closest you'll get at the moment is to read the QL user guide and then the Toolkit 2 guide and finally the SBASIC guide. And that's before you start on the QPTR and QDOS/SMSQ Reference guides.

Guess there's nothing to stop anyone doing this, although it's be a massive job - I did the SBASIC guide on my site and even though it was based on the original SBASIC/SMS manuals which Jochen Merz used to supply with SMSQ/E, QPC2 etc it still took me a long time and my head hurt a bit after doing it. Even now, it has little by way of examples like the original QL user guide has. It's pretty strictly a keyword documentation, not a user guide, and it only really gets updated if one of the SBASIC maintainers tells me of new keywords (I don't routinely go through all releases to try to see what they've added).

Incidentally, what you are trying to do is pretty complex if you didn't even know about something as basic as LRESPR, sounds like you are trying to run before you can walk as people tend to do these days.


Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Passing channels to jobs

Post by Derek_Stewart »

Hi,

I would use a PIPE to connect to the JOB with the screen output.


Regards,

Derek
Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Passing channels to jobs

Post by Tinyfpga »

I have to thank dilwyn for creating and maintaining his site. I find it well constructed and easy to navigate.Without it, I would have had a much harder time obtaining the documentation and software needed to build a Q68 system to suit my programming needs.

When I started my Q68 programming quest I did as he suggests and downloaded and printed the QL guide, TK2, QPTR etc.
I learned to write simple pointer programs with the aid of Wolfgang Lenerz's articles in QL Today. I collated the series and posted it on this forum some time ago.

Right from the start I decided to run before I could walk and chose to only write windowing programs. Without a QL and only having access to SMSQ/E without a user guide I felt I had no other choice. As you suggest it took a long time, and a lot of experimentation to get going. I suppose one could describe this as a crawl.

I have ground through a large number of essential keywords to determine what they actually do. Each program I have written, tests in a visual fashion, the characteristics of these keywords. I have developed a system of documenting the programs in the source code itself. In theory this could be converted into a BASIC programming guide for the Q68 that would include a large number of examples. Every example demonstrates some aspect of BASIC in either a static or moveable window.

To date I have written close on to a hundred test programs each getting more complex as I proceed.
If I were to write a guide it would be very much simpler if I were to produce it exclusively for my Q68 setup.

On my "Passing channels to jobs" problem, when I have a set of programs that demonstrate my failure to achieve this I will post them here and
then, maybe a solution can be suggested.

As an aside I have noticed the thread titled "FPGA Anyone". I managed to get SMS2 (the precursor to SMSQ/E) to run in a MIST (Altera Cyclone EP3C25) and on a PC.
I did this before the Q68 was announced. The main reason I bought some Q68s was because they had superior I/O capabilities.
I still occasionally use SMS2 to remind how good it was.


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Passing channels to jobs

Post by Tinyfpga »

derek_stewart suggests using PIPES.
I have experimented with them internally and across a network but I haven't actually read the Qliberator chapter on PIPES
yet, so serious PIPE experiments are yet to be tried. If I achieve useful results I will post them here. Meanwhile if anyone has some examples of PIPES
used for writing to another window I would be pleased to see them.

I am not sure that PIPES can be used to draw graphics.


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Passing channels to jobs

Post by pjw »

Tinyfpga wrote:I am trying to write a "crap game" in BASIC on a Q68 for the 2021 Sinclair Crap Game Competition. The game is not very dynamic at the moment because
I am unable to get two jobs to write to a window concurrently. I am using QLiberator, set to "no-windows-open", to compile my programs using its facility to
pass channels to daughter jobs.

Passing channels to jobs is described on pages 60-61 of the Qliberator PDF manual but no matter what I do I am unable to get a daughter job to write to the
window of the calling job concurrently.

Have any Qlers managed to do this and if so how did they do it in BASIC?
I experimented with writing to another job's channels some time ago. A looong time ago, actually, which is why I havent spoken up before: I dont remember the details, except that the results were not what I expected or wanted. However, I believe that that must have been in the dark ages of the Qdos era. IIRC, the output was slow, jerky and bits and bobs seemed to get lost on the way.

But just now I revived an old toolkit command I wrote then, basically a home grown version of PRINT, that would take a "real" channel ID (as opposed to a S*BASIC channel number) and print to that, thus enabling me to print to any channel, provided I could get its channel ID. So, now I tried printing from one daughter job to another in SMSQ/E's SBASIC - and works a treat! (Mind you, it was just a very quick and basic test.)

Dilwyn, one of those experiments involved displaying animated sprites. Ie the sprite would be displayed by one job, while being "animated" by another, background, job. This didnt work very well under Qdos, but may be ok now, with SMSQ/E. You might like to try something along those lines for sprites larger than 64x64 pix. Just a thought.

However, your, Tinyfpga, issues with Q-Liberator, I know nothing about, as I never liked the idea of LRESPRing large chunks of compiled S*BASIC, and so never really tried.


Per
dont be happy. worry
- ?
Post Reply