Passing channels to jobs

[dilwyn]

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.

Yes, I can see that if we could get it working reliably it would open up all sorts of possibilities. When tinyfpga mentioned what he was trying to achieve, I did play a little with two channels in different jobs printing to the same channel ID. I didn't get much by way of usable results quickly, and I realised it was easy to make things go wrong, plus it went beyond what I was trying to achieve with my little animated GIF viewer. so I gave up as it would have turned into a distraction from what I was doing.

If I get time during the week I might have a tinker purely out of interest.

[dilwyn]

With what little tinkering I did, here's what I achieved. I don't know if this comes anywhere near what you wanted to achieve - it shows that what Per described is possible at least, though it requires a lot more thought than my meagre little effort so far.

What I did was to compile one program (called test2_obj) which does nothing but print a continuous string of just the letters "JOB2" to basic's #1, then a similar program running in basic continuously printing the letters "JOB1" to the same window. What you get is the output of both programs mixed in the same window, which is a little disconcerting at first when you're used to pointer environment. Both programs have pauses in so you can sort of see what's going on, it'd be interesting to vary the pauses and see what effect it has.

This was done on QPC2, not tried any other system. I did expect that something this simplistic would just crash the system, but it seems to run as I didn't expect it to.

job1job2.jpg

The compiled program is (compiled as win1_test2_obj, with WINDS on):

Code: Select all

10 CLS #1 : INK #1,7
20 REPeat loop
30   PRINT #1,'JOB2: ';
40   PAUSE 50
50 END REPeat loop

And an almost identical program running in basic:

10 CLS #1 : INK #1,7
20 REPeat loop
30 PRINT #1,'JOB1: ';
40 PAUSE 50
50 END REPeat loop

Having compiled test2_obj from the first program, start it from BASIC with QX win1_test,,#1
(doesn't need the _obj extension, QX assumes that, and avoid trying to use #2, that's reserved for listings - you can pass #0,#1,#3 etc in the QX command if you want sbasic and the compiled job to write to more than one window as long as they don't overlap. I didn't pass #0, hence the double comma after the filename).

You will notice that it writes the word "JOB2" to basic's window #1. Now run the second program in BASIC. With luck you'll get the results shown in the screen dump where the words JOB1 (printed by sbasic) and JOB2 (by the compiled job) appear alternately in the same window. Press CTRL space (break) in SBASIC and although the basic stops, somewhat unnervingly the output from the compiled program keeps going....

Every instinct tells me this isn't going to work, it sounds like a total recipe for chaos having two programs write to the same window like this. The simplistic demo works on QPC2 anyway. I have no doubt the "experts" will tell me off for trying to do this.....

That's as far as my tinkering took it, so I have no idea if it comes remotely near what you wanted to achieve of course, especially the "daughter job" scenario you described. If nothing else it proves that what QLiberator described can work in QPC2 at least. What I haven't tried so far is to make the QX call from another compiled job to see if the same thing works for two compiled jobs instead of a compiled job and basic.

[pjw]

Dilwyn,
On closer inspection, I dont think it would work with sprites after all. The way jobs are scheduled is not conducive to the more accurate timings needed for sprite animation. That would require it to be done by a task (not in the mis-named DP sense of the word ).The jerkiness I mentioned re-emerges, even with simple IO. Its fine for some things, tho', like simple timers and the like.

[pjw]

<>
Having compiled test2_obj from the first program, start it from BASIC with QX win1_test,,#1
(doesn't need the _obj extension, QX assumes that, and avoid trying to use #2, that's reserved for listings - you can pass #0,#1,#3 etc in the QX command <>

I think this does its magic via pipes. I tried a more direct approach of writing directly to the other job's channel (incredibly naughty, I know!):

Test.zip

Unzip to ram1_ and view readme

(2.48 KiB) Downloaded 88 times

[dilwyn]

Dilwyn,
On closer inspection, I dont think it would work with sprites after all. The way jobs are scheduled is not conducive to the more accurate timings needed for sprite animation. That would require it to be done by a task (not in the mis-named DP sense of the word ).The jerkiness I mentioned re-emerges, even with simple IO. Its fine for some things, tho', like simple timers and the like.

I haven't got that far yet, but I'm sure you're right of course.

What I had in mind was to pass the details of the sprite animation and where to print it in a command string before the channels list, then the 'daughter job' would find the individual sprite frames in the sprite file and the inter-frame timings. The daughter job then printed a frame, PAUSEd or suspended itself for the inter-frame timing, showed the next frame, PAUSEd again and so on. The daughter job builds up a table of pointers to the sprite frames and a table of frame pauses. In other words, the animation is a series of individual sprites with pauses in between rather than a single animated sprite.

Every fibre in me says it won't work at all, never mind the timing issues and the fairly complex parameter handling which would be needed to parse the command string. But it'll still be fun trying - expecting it not to work will probably mean it works after a fashion!

[pjw]

Well, Dilwyn, if I hadnt failed a hundred times, Id never have gotten anything to work! Keep your nose to the grind wheel!

[Tinyfpga]

I have finally written a program that actually works demonstrating two jobs writing to channel #2 concurrently.
I have, though, cheated a bit by using the multitasking job "clock" to prove a point. The program shows that
concurrent writing is technically possible but with one job written in assembler. What CLOCK does to make this possible is not
knowable by me.

The program demonstrates two daughter jobs and two channels working in the QD way. The jobs and channel menus show
correct operation. Both programs need to be compiled with windows turned off and the sound program needs to be referenced
according to its file name.

The sound job uses the keyword WAIT because PAUSE opens a channel by default thus damaging the display.
I have tested the demo in QPC2 and find that it works just as well as in a Q68.

I don't really know how to send the WAIT code on this forum. The code I have attached were .rts or .cde files.
When I tried to attach the files I got an error saying wrong file type, also don't know how to convert an SMS screen image such that I can post it on this
forum so I have taken a photograph of the display instead.
The Photographs shows the source code in two QDs and the resulting compilation in a small window on the left. The Laptop is an elderly Lenovo X220.

The code for the main job is as follows:- Note the rems have all appeared in the wrong place. See rubbish photo for correct layout.

Is any of this important? I think so because if Peter Graf can be convinced to carry on developing his multi core FPGAs, I can foresee a time when huge FPGAs
are so cheap that it will be possible to create SMS systems with multi core/memory systems and thus prove that Tony Tebby's view that shared memory
systems are not the future of multiprocessor computing.
The ability of multi core SMS computers (or currently networked Q68s) to concurrently solve problems would seem to be useful.

Def_integer p,n,a,s :rem must be on first line (I think)

rem +++++ THREE CO-OPERATING JOBS TWO JOBS WRITING TO #2 CONCURRENTLY +++++

rem ---------- Open and define two display channels #1 and #2 ----------


Open #1,con_
Outln #1,300,130,40,256
Cls #1 : Ink #1,7 : Border 1,7

Open #2,scr_
Window #2,145,35,115,275
Paper #2,7 : Ink #2,0 : Cls #2
Border #2,1,5

rem ---------- end section ----------


rem ---------- Create two daughter jobs ----------

Clock #2,"$d %d $m %c%y %s" :rem clock #2,"$d %d $m %c%y %n.%m.%s"
Qx win3_ticktock :rem make sound job

rem ---------- end Section ----------


rem ---------- Program loop ----------
rem << do not place a :rem after IF statement >>

Rep p

If s=0 : s=1 : Else s=0 :rem sets state of switch
b$="" : c$="" :rem define strings
At #2,1,1 : Print #2," " :rem clears #2 on -
At #2,2,1 : Print #2," " :rem window resize effect

For n=1 To 10
a$=Chr$(Rnd(65 to 90))
b$=b$&a$ :rem creates two random strings
c$=a$&c$ :
End for n

At #1,7,19 : Print #1,b$
At #2,2,7 : Print #2,c$
At #1,9,17 : Print #1,"Press x to quit" :
If s=0 : At #2,0,19 : Print #2,"TICK" :rem print to #1 and #2
If s=1 : At #2,0,19 : Print #2,"TOCK" :

k$=Inkey$(#1,50)
If k$="x" : Exit p :rem exit program

End rep p

rem ---------- End program loop ----------

The code for the sound job is as follows:-

Def_integer p,n

rem +++++ TICKTOCK SOUND FOR CONCURRENCY DEMO +++++

rem ---------- Program loop is endless ----------
rem << use beep by trial and error use as daughter job>>

Rep p
If n=100 : n=150 : Else n=100
Beep 2000,n
Wait 50
End rep p

rem ---------- End program loop ----------

[pjw]

The sound job uses the keyword WAIT because PAUSE opens a channel by default thus damaging the display.

Thats what SMSQ/E's inbuilt keyword SUSJB is for

I don't really know how to send the WAIT code on this forum. The code I have attached were .rts or .cde files. When I tried to attach the files I got an error saying wrong file type,

Only a few filetypes can be uploaded here. Zip is the most common: You need to Zip the file.

I also don't know how to convert an SMS screen image such that I can post it on this forum

On Windows you can use the PrtScr key combination, to copy a screen to the Clipboard. Then use Paint to crop and save the image for uploading. On the Q68 you could use Snip (off Knoware.no) and then convert the PIC to JPG (with QTImage, for example).

The code for the main job is as follows:- Note the rems have all appeared in the wrong place. See rubbish photo for correct layout.

Wrap your code in {code}{/code} tags (using square [ ] brackets!)

I think youll find that CLOCK on its own proves the point: Invoking CLOCK starts a channel-less job, that writes to a channel owned by the job that invoked it.

The only way I can think of doing what you are trying to do, is to have access to the other job's real channel ID and finding a way of sending IO to it. This can only be done using machine code, either via a job (as in CLOCK) or via a toolkit, as in my example, above.

[pjw]

PS: You can see the PrtSc key of your laptop on your photo, above. Just to the right of the middle of the image.

[Tinyfpga]

Thank you pjw, for your tips.

What you mean by "Wrap your code in {code}{/code} tags (using square [ ] brackets!)" are you willing to elaborate?
Does via a toolkit mean via a Knoware toolkit. If so which might it be ? If not, can a general purpose toolkit be written?

pjw and emmbee have given me an idea. Can I compile a program using Qliberator, LRESPR it and then call it whilst passing
a display channel like CLOCK #n ?