AppBasic

In case the situation with AppBasic doesn’t resolve OK, it may be useful to remind people of DrawGen. This may help for some purposes.

http://jcgl.orpheusweb.co.uk/DrawGen/dgen.html

I don’t know if it works on an RPi, but I just checked and it works on my ARMiniX.

Saying this as I do use it sometimes to generate a drawfile whilst also saving out printed (text/values) results.

Jim

Is there a way of using DrawScript commands within a Basic program?

Why not use !MakeDraw? You can generate a Draw file in memory from BASIC (containing vector graphics, jpegs, sprites and text) and render it on screen using SYS “DrawFile_Render” and save it using the normal ‘save’ menu option. See the programmes !CountDown and !Cat for examples (available from !Store).

!Cat saves the directory contents either as a Draw graphic or as a text file.

There appears to be filetype problems when using DrawScript with StrongED in DrawScript mode. This may depend on the version of StrongED, I have version 4.69f6, a recent version. Try saving a DrawScript file using StrongEd, accepting the given filetype of Drawscri, and then observe the filetype of the saved file. Next, with DrawScript booted, do *show, look at the list of File$type_xxx and spot the only filetype name with more than 8 characters.
Finally, ask yourself the question whether !Drawscript should be included on a Raspberry-Pi distribution, as suggested by a previous poster, in this state.

Finally, ask yourself the question whether !Drawscript should be included on a Raspberry-Pi distribution, as suggested by a previous poster, in this state.

Was DrawScript and/or its filetype allocated? If not, then it’s a definite no.
If it was, as what? “DrawScpt” or something?
The allocations page is quite clear → file types <= 8 characters. Shouldn’t be too hard for the author to fix.

I don’t know the answer to your first question, perhaps someone ‘from ROOL’ will give a rooling on this. :-)
It seems that the filetype name should be DrawScri and if a file is saved using the filetype number, &b9b, it is saved correctly as a DrawScript file with name type, Drawscri. The problem is that StrongED’s save box has DrawScri in the type field, which seems right, but the file gets saved with a different type (I don’t want to spoil the fun for folk to discover the type). If the type field entry is altered to Drawscript (or &b9b of course) then all is well. Some inconsistency it seems.
Since both !DrawScript and !StrongED are free, everyone can download them and have fun finding this out for themselves. I have checked this only with the last versioon of !DrawScript and the very recent v4.69f6 of StrongEd.

If it was, as what? “DrawScpt” or something?

If only! If it was as above there would be no problem, and that suggestion is a possible fix, but :-

%Set File$Type_B9B DrawScript

That’s 10 not 8.

Current StrongEDs now truncate that to 8 and finish up saving the file with a filetype of 000, earlier StrongEDs ignored the excess length.

The full exchange is on the riscository AppBasic mailing list

P.S. It is not a StrongED bug but comes from the use of OS_FSControl,18 and that only two words are allocated for the filetype. From the PRM :-

DIM str% 8
SYS "OS_FSControl",18,,&B9B TO ,,r2%,r3%
str%!0=r2%
str%!4=r3%
str%!8=13
PRINT $str%

The real problem is of course that ‘DrawScript’ is too long as a filetype name but there is an inconsistency in OS_FSControl 18 and 31 that compounds the issue.

Because of that inconsistency the following – which you’d expect to work – fails:

Calling OS_FSControl 18 with filetype &B9B returns ‘DrawScri’

Calling OS_FSControl 31 with ‘DrawScri’ does not return &B9B but an error instead; ‘File type is unrecognised’. You need to pass ‘DrawScript’ to get the hex filetype out.

It looks like OS_FSControl 31 is doing a straight string compare against the value of File$Type_B9B rather than limiting it to the first 8 characters.

Shouldn’t be too hard for the author to fix.

You might recall from earlier in the thread that the author is unwell. IIRC it was also stated that the code was all BASIC…

As Fred has pointed out, as small bug in the application has highlighted a matching bug in the OS.

%Set File$Type_B9B DrawScript

Just out of interest, what happens (to everything) if you change this to “DrawScri” ? Does DrawScript itself still work?

As Fred has pointed out, as small bug in the application has highlighted a matching bug in the OS.

I disagree. It is a deficiency in the OS, for certain. However, for the OS to misbehave over an invalid input does not make a wrong (or even inconsistent) behaviour a bug.

Now, should we change the File$Type setting to clip to eight characters, or should we change OS_FSControl 31 to clip its input? Which is preferable?

I think tweaking OS_FSControl is easier. It already discounts trailing spaces in the string and uses an unterminated (length-is-given-instead) string comparison, therefore…

Change this:

        ADD      r5, r5, #1             ; r5 -> end of string (space or CtrlCh)
        SUB      r5, r5, r1             ; r5 = length of bit to compare
 [ debugcontrol]
 DREG r5, "length of source string "
 ]

to this:

        ADD      r5, r5, #1             ; r5 -> end of string (space or CtrlCh)
        SUB      r5, r5, r1             ; r5 = length of bit to compare
        CMP      r5, #8                 ; is it too long?
        MOVGT    r5, #8                 ; if so, clip it to maximum allowed
 [ debugcontrol]
 DREG r5, "length of source string "
 ]

Given the time (10pm), I’m not going to build and install a new ROM image just to see if that works as expected… ;-)

I’m not going to build and install a new ROM image just to see if that works as expected… ;-)

It will fix the case where the input string is longer than the File$Type_xxx value but it won’t fix the issue I highlighted. For that you’d need to clip the comparison string (in the same way as you’ve clipped the input string).

If this were to be implemented as a fix then it’d be best to clip both input string and comparison strings.

Awww dammit. Clipped the wrong one. That’s what you get when somebody is juggling two keyboards and a big bowl of pasta.

Well, the other one is the same sort of thing, just a few lines further down. ;-)

[footnote: got to get up in seven hours…why can’t I fall asleep already?]

MOVGT r5, #8 ; if so, clip it to maximum allowed

Noooo, please don’t used signed conditions when using unsigned numbers, use “MOVHI” instead.

That’s what you get when somebody is juggling two keyboards and a big bowl of pasta.

So it’s not Alphabetti Spaghetti then?

As regards the DrawScript Filetype problem, I suggest that we use DrwScrpt for the filetype. Of course, anything with no more than 8 characters will do, but just removing the two vowels would seem simplest. I have just re-visited DrawScript after a long time and needed to sort this out as saving files was a pain. I have changed the line
“Set File$Type_B9B DrawScript” to “Set File$Type_B9B DrwScrpt”.
So far, saving files has worked in the usual way and there have been no problems.

I am using DrawScript on a Pandaboard running RISC OS v5.23 dated 18/02/17 and it is throwing up a lot of zero page errors. The error log mentions BASIC, but not DrawScript.

Just discovered, after the filetype problem returned, that there were two more instances of the line “Set File$Type_B9B DrawScript” in the run and RunM files, as well as in the boot file (in previous post). So, changed those as well – I hope that’s it.

Hello Gavin Wraith. Do you have any updates about the situation with Joe Taylor?
If he is still alive can you ask him to release the sources for AppBasic?
It would be sad it will be lost.
In worse case can you ask his family?

I spoke to Joe in January. His affliction, trigeminal neuralgia, has not really changed in a decade, except that COVID is an added complication. His children are grown up and live elsewhere. His computers are still unreachable, but, even if they were not, he has not been in a state to sort them out, and I do not think anybody else can. I feel it would be tasteless to press the matter and I am reluctant to do so. I too very much regret this situation.

Thanks Gavin for quick reply. Yes sad news for him more than for us. No need to torture him if he is not feeling well.
We still can use his nice layouts for a future IDE but it would be for C++ then.

His affliction, trigeminal neuralgia,

The causative issue I won’t enquire about, some are not good.

I feel it would be tasteless to press the matter and I am reluctant to do so. I too very much regret this situation.

An offer to assist in updating for recent technologies might be a tactful route. Covid-19 isolation is a boon to the introvert, with limits. For everyone else, it’s a total pain, especially when communication with another soul is restricted and the depression slide begins.