The Sinclair QL Forum

No problem Steve, I just thought you might find CSM helpful. At least t=you have something that works.

I'm interested though, which character didn't work?

Cheers,
Norm.

Hi Norm,

Thanks again for the CSM docs.

It is CHR$(10) - ENTER, which is troublesome.... (if you try to PRINT it as a hash char) ... but the code transfers OK.

Regards,

Steve.

Morning Stephen,

I thought it would be CHR$(10)!

I wonder if repeated use of INKEY$ would be "better" to read strings containing that character, rather than attempting to peek and poke a whole string? Just a thought, it will most likely be slower, by a lot.


Cheers,
Norm.

Hi Norm,

Here is a screen shot of five jobs running together. As you see, I only need to transmi keys 1 2 3 4 5 or a b c d e . This needed ten-char POKE$ and PEEK$, using a pseudo-binary string '12345abcde', where INKEY$="" are represented by zeros. So job1, say, only tests for '1' or 'a' ....

With PIPES, only the last job gets inkey$, and has to pass it back down the inversed call sequence to each job.

The KEYHOLE method can turn any job off, with keys a to e, without the whole lot coming crashing down !
Keys 1 to 5 just tempoarily 'puts the job to sleep', by not outputting the screen waves.
And you can tailor your peeking and poking to your exact needs... as long as you respect the buffer length.

Steve.

Hi everybody,

The multitasking program, (in the last posting), runs OK under qpc2, but fails under Qemulator.

First, Qemulator refuses to EX several SMSQ/E programs_bas. It will EXEC Qlib compiled programs though.

Also, there seems to be a Qemu problem with ALCHP() : A Boot program reserves some memory, then Lruns a second program which also reserves memory, but then Peek$ & Poke$ corrupt the name table, if the first base adress is used ... (OK under QPC2).

Does Qemu do a CLCHP when it does a NEW for LRUN ?

Regards,
Steve.

stevepoole wrote: Does Qemu do a CLCHP when it does a NEW for LRUN ?

Memory reserved by ALCHP is indirectly cleared by NEW, CLEAR, LOAD and LRUN - On all platforms - with QPC2, you've probably just been lucky.

If you want allocated memory to survive killing the S*BASIC program, you need to revert to another toolkit, like BTools ALCHP, for example.

Tobias

stevepoole wrote:Hi everybody,

The multitasking program, (in the last posting), runs OK under qpc2, but fails under Qemulator.

First, Qemulator refuses to EX several SMSQ/E programs_bas. It will EXEC Qlib compiled programs though.

EXing SBASICs should work on any system running SMSQ/E. Are you sure you loaded SMSQ/E and not Qdos? Theres also something called MBASIC on Minerva which works in a similar way.

Also, there seems to be a Qemu problem with ALCHP() : A Boot program reserves some memory, then Lruns a second program which also reserves memory, but then Peek$ & Poke$ corrupt the name table, if the first base adress is used ... (OK under QPC2).

Does Qemu do a CLCHP when it does a NEW for LRUN ?

You were just "lucky" that SMSQ/E hadnt used your memory for anything else. Thats how you could still apparently access it after a NEW, LRUN, etc. If you want to reserve memory that survives a NEW etc, you could try RESPR instead of ALCHP in your boot program.

Good morning Tobias! You beat me to it - again

Hi Tofro & per,

Thanks for your comments. Yes, I was very lucky using QPC2 : Otherwise I doubt if I would have suceeded at all ....

I took your advice abot RESR() etc, and now have even a safe QDOS working program version. ! Tested and beta-tested.

Just a few quirks to eliminate, as we are working with four platforms, and with dos5_, win, ram & flp versions (in _bas & _task).
So it is oh so easy to get files mixed up !

The KEYHOLE method does indeed work well using all versions.

Regards,
Steve.

Morning Steve,

I'm impressed by your method of working. Nicely done. I like the way you solved it using only the standard tools. Always a bonus.

I'm slightly puzzled by an earlier reply when I asked if you had tried the CSM thing and you said that you had considered it but "it required a thing to be installed" - is your plan to have the process work without additional software, as you have done, or do you have an aversion to things in general? Just wondering.

While SMSQ is fine, I know that the BBQL needs the Thing system loaded - but it's small and shouldn't use up too much memory, but I think this process of sharing memory might be a prime candidate for things. (Not that I know much about them!)

I imagine that a chunk of memory could be allocated and stored as a pointer with perhaps a name, in the thing. Then any jobs or SuperBASIC/SBASIC that needs a particular memory area could get the address from the thing, using the name as a parameter. Maybe the RAM could be allocated by the Thing itself, as opposed to using ALCHP or RESPR and this a usage count kept and the RAM not RECHP'd (in the case of ALCHP) until the count is zero.

Just thinking - it came to me at about 2AM when I was, for some unknown reason, wide awake!

If I get a chance, I might even use this as something for the next edition of the somewhat irregular eComic on Assembly Language.


Cheers,
Norm.