Page 4 of 9

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sat Jan 15, 2022 11:14 am
by pjw
Tinyfpga wrote:I tried using PEEK_L($1C060) on a Q68 and in SMSQE's command line. It works as Peter describes, but I have two problems.

The first is that Qliberator will not accept $1C060. I have read through the Qlib manual but can't find a reference to this problem.{/quote]
Qlib V3.45+ accepts literal hex floats. Use that!
The second is that I cannot think of a way to halt a program for a certain amount of time using this instruction.

It would be nice to be able to do something like
n=(a delay in 25ns units)
a= PEEK_L($1C060)
STOP_UNTIL (PEEK_L($1C060))-a = n

I suppose this require something running in the background to monitor the time difference. How does the PAUSE instruction work for example?
Im not sure that that kind of timer makes much sense for delaying loops. Yould still need a resource-demanding loop to monitor it. Yes, you can get more accurately timed delays, but unlike PAUSE, SUSJB etc such a timer doesnt let the system get on with other tasks while it waits (apart from normal job scheduling, of course).

On a different track, it might be useful to standardise some kind of timer(s) across platforms. Since the Q68's is already there, and cast in hardware, it would make sense to emulate its capabilities as a minimum. Step 2 would be to add suitable commands to use it into SMSQ/E.

Then, perhaps it wouldnt be too hard for anyone adding an RTC, or any other simple (or complex) piece of hardware to the QL itself to add a Q68-compatible timer too..? Then we could - at last - solve to problem of accurate, asynchronous, timing across the board for anyone who wants it.

Not being a hardware guy, I may be talking through my hat here, but wouldnt it be possible for such a timer (with extra circuitry, perhaps) to generate a hardware interrupt too, at user-specified, case-per-case, intervals? Then more precise wait loops could be implemented without unnecessary time-wasting. Ie, the system would be allowed to get on with other things, and the waiting job be suspended until the timer's release signal arrived..
<>

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sat Jan 15, 2022 2:33 pm
by NormanDunbar
Martin_Head wrote:Use something like
a=PEEK_L(114784)
a=a + (a delay in 25ns units)
REPeat loop
IF PEEK_L(114784) > a THEN EXIT loop
END REPeat loop

This is not perfect. If the hardware timer rolls over (resets) during the loop. It will not end.
Aye, even worse, PEEK_L is signed so anything over $7FFFFFFF will be negative and the calculation will go to buggery! ;) This should work though:

EDITED It was 2^31 that should have been added, not 2^32. Apologies all round. I'm a numpty. (Norm.)

Code: Select all

StartTick = PEEK_L(114784)
if StartTick < 0 then StartTick = StartTick + 2^31

DelayTime = (a delay in 25 ns units)

REPeat Loop
    NowTick = PEEK_L(114784)
    IF NowTick < 0 THEN NowTick = NowTick + 2^31
    IF ABS(NOwTick - StartTick) >= DelayTime THEN EXIT Loop: END IF
END REPeat Loop 
It's simpler if we had unsigned data types in S*BASIC like we do in C/C++! But the above should work.

Cheers,
Norm.

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sat Jan 15, 2022 4:17 pm
by Derek_Stewart
Hi

Why not use the SLUG command, which is present in all versions of SMSQ/E, well on my Q68, QPC2, SMSQmulator.

If the Q68 SMSQ/E manual read:
Q68 SMSQ/E Manual Page 24 wrote: 8.3 Slug The SLUG command can slow the machine down, which might be useful for some games.

Syntax: SLUG how_much where how much is a value between 0 (no slug) and 255 (slowed down to a crawl).

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sat Jan 15, 2022 6:09 pm
by Tinyfpga
I understand the SLUG command as an instruction to slow the processor and not an individual application. Is this correct?

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sat Jan 15, 2022 9:48 pm
by mk79
NormanDunbar wrote:It's simpler if we had unsigned data types in S*BASIC like we do in C/C++! But the above should work.
Well, in reality PEEK_L returns a float, so in principle one could do a PEEK_UL if one wanted.

Cheers, Marcel

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sun Jan 16, 2022 12:50 am
by stevepoole
Hi Folks,

On my QPC2, pkL=PEEK_L(114784) / PRINT pkL gives 1.677722E7 / pk$=pkL / pk=pkL-pk$ / print pk gives -4, the 'lost' internal 'fp' value we need.

But PEEK_L(114784) NEVER changes, so Norman's routine never exits. And, what is PEEK_UL - a comand unrecognised on my QPC2 !!

SLUG cannot be used by Tiny, as it SLOWS processing, but only by 1/50th second units... much too big to be useful for him.

So we are left with wait loops : 100 loops='whatever' : FOR delay=1 to loops: hold=1. (This is simple to use, but is unfortunately system dependant ! )

But wait loops are fine if you are a beginner simply prototyping a bit of Basic code.... Other systems only need a relative performance factor applied to 'whatever'.

Steve.
______________

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sun Jan 16, 2022 9:09 am
by NormanDunbar
I think the PEEK is for Q68.

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sun Jan 16, 2022 9:58 am
by Martin_Head
Here's a quick and dirty Q68WAIT SuperBASIC extension for the Q68.

I've done a quick test, and it seemed OK. Just LRESPR Q68Wait_cde

Using Q68WAIT 40000*1000*5 will give a 5 second delay (40000 = 1mS)

IF used on a non Q68 it should give a 'not found' error

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sun Jan 16, 2022 10:25 am
by pjw
NormanDunbar wrote:I think the PEEK is for Q68.
Theres no such function in SMSQ/E for Q68, unless its in an as yet unreleased version.
I think it was meant more hypothetically, as in:

Code: Select all

DEFine FuNction PEEK_UL(adr)
LOCal v
v = PEEK_L(adr)
IF v < 0: RETurn 2^32 + v
RETurn v
END DEFine PEEK_UL
:

Re: Is SBASIC programming on SMSQE difficult?

Posted: Sun Jan 16, 2022 10:33 am
by XorA
Ah that timer is nicely in the IO space, so would not be hard to emulate that on sQLux using clock_gettime with the MONOTONIC source!