Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Running BASIC text files

22 views
Skip to first unread message

cfe...@freeremoveuk.com.invalid

unread,
Dec 10, 2011, 5:32:29 AM12/10/11
to
You can run BASIC text files - but when they are loaded - they are
renumbered.

Is there anyway of changing BASIC's choice of loading to RENUMBER 1,1?

ie for large files.

Thanks
--
Colin Ferris Cornwall UK

John Kortink

unread,
Dec 10, 2011, 6:27:38 AM12/10/11
to

On Sat, 10 Dec 2011 10:32:29 GMT, cfe...@freeRemoveuk.com.invalid
wrote:

>You can run BASIC text files - but when they are loaded - they are
>renumbered.
>
>Is there anyway of changing BASIC's choice of loading to RENUMBER 1,1?
>
>ie for large files.

Not via 'external' means (I ran into the same problem yonks ago).
You have to change the BASIC module. Then you simply *RMLoad the
changed copy early in your boot sequence.

It's a simple change, although where exactly to apply it, depends
on the module version. E.g. in 1.29 it's at offset 0xC678 (where
MOV R4,#10:MOV R5,#10 becomes MOV R4,#1:MOV R5,#1).


John Kortink

--

Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

cfe...@freeremoveuk.com.invalid

unread,
Dec 11, 2011, 6:11:29 AM12/11/11
to
In message <kpf6e7d2orn4m0u92...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:

>
> On Sat, 10 Dec 2011 10:32:29 GMT, cfe...@freeRemoveuk.com.invalid
> wrote:
>
> >You can run BASIC text files - but when they are loaded - they are
> >renumbered.
> >
> >Is there anyway of changing BASIC's choice of loading to RENUMBER
> >1,1?
> >
> >ie for large files.
>
> Not via 'external' means (I ran into the same problem yonks ago).
> You have to change the BASIC module. Then you simply *RMLoad the
> changed copy early in your boot sequence.
>
> It's a simple change, although where exactly to apply it, depends
> on the module version. E.g. in 1.29 it's at offset 0xC678 (where
> MOV R4,#10:MOV R5,#10 becomes MOV R4,#1:MOV R5,#1).
>

Thanks - Just tried the mod - with one of the RO5 versions of BASIC.

A BASIC_TXT file of just under 1M byte - seemed to run ok.

Is there any reason - for this not to applied to the RO main sources?

Also not sure why BASIC has to print 'renumbering'.

Steve Drain

unread,
Dec 12, 2011, 8:32:15 AM12/12/11
to
There is no need to alter the module and reload it, because that pair of
instructions is unique to the code. Here is a snippet that will make the
changes /in situ/, and remove the 'renumbering' message.

It works with a rom version as well if you have the ROMPatch module. Is
this available for RO 5? The 32-bit version from RO6 does not seem to
allow patches at that high memory, even if it were legal to use it. ;-)

I am not sure that my method for distinguishing between rom and rma, for
all versions of RISC OS, is the best, so suggestions are welcome.

SYS"OS_Module",18,"UtilityModule" TO ,,,r%
SYS"OS_Module",18,"BASIC" TO ,,,a%

FOR i%=a% TO a%+&D800:REM keep inside BASIC module
IF !i%=&E3A0400A THEN:REM MOV R4,#10
IF i%>r% THEN
OSCLI("ROMPatch &"+STR$~(i%+00)+" &E3A0400A &E3A04001")
OSCLI("ROMPatch &"+STR$~(i%+04)+" &E3A0500A &E3A05001")
OSCLI("ROMPatch &"+STR$~(i%+12)+" &E3A00007 &E8BD8000")
ELSE
i%!00=&E3A04001:REM MOV R4,#1
i%!04=&E3A05001:REM MOV R5,#1
i%!12=&E8BD8000:REM STMFD R13!,{PC}
ENDIF
i%=a%+&D800
ENDIF
NEXT i%

Rick Murray

unread,
Dec 12, 2011, 10:35:00 AM12/12/11
to
On 11/12/2011 12:11, cfe...@freeRemoveuk.com.invalid wrote:

> Is there any reason - for this not to applied to the RO main sources?

Just wondering why the file couldn't be loaded into, say, Zap,
renumbered there, and then saved *as* *a* *BASIC* *program*?


> Also not sure why BASIC has to print 'renumbering'.

Probably side effect of not loading a BASIC program. It's a text file
which BASIC is interpreting and tokenising on-the-fly.


Best wishes,

Rick.

Martin

unread,
Dec 12, 2011, 12:01:53 PM12/12/11
to
On 12 Dec, in article <CnnFq.52254$Oz7....@newsfe24.ams2>,
Steve Drain <st...@kappa.me.uk> wrote:
> IF !i%=&E3A0400A THEN:REM MOV R4,#10

I fear that will be treated as a single-line IF..THEN rather than the
start of a multi-line IF..THEN..ENDIF in many cases!

It will always execute the following lines, unless REMs are set to be
removed on loading that code, by having OS variable BASIC$Crunch set and
it being valid for the BASIC version being run.

Martin

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

Steve Drain

unread,
Dec 12, 2011, 12:50:35 PM12/12/11
to
On 12/12/2011 17:01, Martin wrote:
> On 12 Dec, in article<CnnFq.52254$Oz7....@newsfe24.ams2>,
> Steve Drain<st...@kappa.me.uk> wrote:
>> IF !i%=&E3A0400A THEN:REM MOV R4,#10
>
> I fear that will be treated as a single-line IF..THEN rather than the
> start of a multi-line IF..THEN..ENDIF in many cases!
>
> It will always execute the following lines, unless REMs are set to be
> removed on loading that code, by having OS variable BASIC$Crunch set and
> it being valid for the BASIC version being run.

True, but I /always/ have BASIC$Crunch set, and advocate that everyone
else should, too. ;-)

More seriously, the reason for this fudge is buried in the depths of
time and only relates to BASIC V version 1.04. Why it is not set in
!Boot baffles me. BASIC VI removes REMs etc as a matter of course.

BTW Basalt removes REMs if it encounters them.

John Kortink

unread,
Dec 12, 2011, 12:51:33 PM12/12/11
to

On Mon, 12 Dec 2011 16:35:00 +0100, Rick Murray
<heyrickma...@yahoo.co.uk> wrote:

>On 11/12/2011 12:11, cfe...@freeRemoveuk.com.invalid wrote:
>
>> Is there any reason - for this not to applied to the RO main sources?
>
>Just wondering why the file couldn't be loaded into, say, Zap,
>renumbered there, and then saved *as* *a* *BASIC* *program*?

Um, because you don't want to do that after every edit ?
Else what would be the point in editing in text format
in the first place.

And, to answer the next question : because not all editors
in the world know what BBC BASIC is, and automatic pre- or
post-processing is much more convenient in text format.

>> Also not sure why BASIC has to print 'renumbering'.
>
>Probably side effect of not loading a BASIC program. It's a text file
>which BASIC is interpreting and tokenising on-the-fly.

It doesn't tokenise 'on the fly'. It tokenises all of
it in one go, when it loads.

Martin

unread,
Dec 12, 2011, 5:00:54 PM12/12/11
to
On 12 Dec, in article <0arFq.38914$E33....@newsfe23.ams2>,
Steve Drain <st...@kappa.me.uk> wrote:
> On 12/12/2011 17:01, Martin wrote:
> > On 12 Dec, in article<CnnFq.52254$Oz7....@newsfe24.ams2>,
> > Steve Drain<st...@kappa.me.uk> wrote:
> >> IF !i%=&E3A0400A THEN:REM MOV R4,#10
> >
> > I fear that will be treated as a single-line IF..THEN rather than the
> > start of a multi-line IF..THEN..ENDIF in many cases!
> >
> > It will always execute the following lines, unless REMs are set to be
> > removed on loading that code, by having OS variable BASIC$Crunch set
> > and it being valid for the BASIC version being run.

> True, but I /always/ have BASIC$Crunch set, and advocate that everyone
> else should, too. ;-)

Oh yes, so do I. But I have been caught out in the past when others have
run my code who do not have it set!

> More seriously, the reason for this fudge is buried in the depths of
> time and only relates to BASIC V version 1.04. Why it is not set in
> !Boot baffles me.

I agree totally.

> BASIC VI removes REMs etc as a matter of course.
> BTW Basalt removes REMs if it encounters them.

Both good!

Rick Murray

unread,
Dec 13, 2011, 12:31:40 AM12/13/11
to
On 12/12/2011 18:51, John Kortink wrote:

> Um, because you don't want to do that after every edit ?

Hmmm, I wrote code in both !Edit and !Zap, both of which understand (and
tokenise) BASIC.

I wonder what editor is being used that doesn't support BASIC natively? [*]


> It doesn't tokenise 'on the fly'. It tokenises all of
> it in one go, when it loads.

When I wrote "on the fly", I was referring to the act of loading the
text file. As in, it will tokenise during load *every* time the text
file is loaded.


Best wishes,

Rick.

* - I mean, you *could* code in OvationPro, it would just be a pretty
odd thing to do! ;-)

Martin Wuerthner

unread,
Dec 13, 2011, 4:11:41 AM12/13/11
to
In message <4ee6e33b$0$2537$ba4a...@reader.news.orange.fr>
Rick Murray <heyrickma...@yahoo.co.uk> wrote:

> On 12/12/2011 18:51, John Kortink wrote:

>> Um, because you don't want to do that after every edit ?

> Hmmm, I wrote code in both !Edit and !Zap, both of which understand (and
> tokenise) BASIC.

> I wonder what editor is being used that doesn't support BASIC natively? [*]

Editing is not the point. If you want to check the BASIC file into a
version control system, it needs to be plain text, otherwise you lose
most of the benefits of such a system. It is not practicable to
manually convert the file to/from text format all the time, so it is
really best stored in plain text, even more so as BASIC is happy
enough to execute plain text files - provided they do not have too
many lines and cause the line number range to be exceeded when
renumbered with the default renumbering step of 10, which brings us to
the original topic of this thread. I have been using a patched version
of BASIC with a default renumbering step of 1 (as described by John
earlier in this thread) for a long time to be able to run version
controlled plain text BASIC files.

--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

trevj

unread,
Dec 13, 2011, 5:36:20 AM12/13/11
to
For anyone wondering about version control systems/reasoning etc.
check out this ROOL thread... Rob Sprowson has now kindly amended the
renumbering step in RO5:
http://www.riscosopen.org/forum/forums/2/topics/71#posts-9666

cfe...@freeremoveuk.com.invalid

unread,
Dec 13, 2011, 7:37:37 AM12/13/11
to
In message <7252de40...@bach.planiverse.com>
Martin Wuerthner <spam...@mw-software.com> wrote:

> In message <4ee6e33b$0$2537$ba4a...@reader.news.orange.fr>
> Rick Murray <heyrickma...@yahoo.co.uk> wrote:
>
> > On 12/12/2011 18:51, John Kortink wrote:
>
> >> Um, because you don't want to do that after every edit ?
[snip]


> I have been using a patched version of BASIC with a default
> renumbering step of 1 (as described by John earlier in this thread)
> for a long time to be able to run version controlled plain text
> BASIC files.
>

I have just noticed that '!StrongEd' will load and save in &FD1 BasicTxt
format - still displaying BASIC keywords - ie picked out in colour.

(using a 1M byte demo prog)
Saves file quite quick too.

John Kortink

unread,
Dec 13, 2011, 9:20:47 AM12/13/11
to

On Tue, 13 Dec 2011 02:36:20 -0800 (PST), trevj <tr...@cwazy.co.uk>
wrote:
I'm not sure I will ever use one of those cheerfully and
colourfully patched up BASICs, but while they're at it,
they should also fix another annoying quirk (which I've
patched myself years ago), which is faulting zero shifts
in assembly as 'Bad shift', unless it's LSL. All other
zero shifts (LSR#0, ASR#0, ASL#0) can be silently turned
into LSL#0 without generating an error.

John Kortink

unread,
Dec 13, 2011, 9:38:39 AM12/13/11
to

On Tue, 13 Dec 2011 06:31:40 +0100, Rick Murray
<heyrickma...@yahoo.co.uk> wrote:

>On 12/12/2011 18:51, John Kortink wrote:
>
>> Um, because you don't want to do that after every edit ?
>
>Hmmm, I wrote code in both !Edit and !Zap, both of which understand (and
>tokenise) BASIC.
>
>I wonder what editor is being used that doesn't support BASIC natively? [*]

Vim, for one.

>> It doesn't tokenise 'on the fly'. It tokenises all of
>> it in one go, when it loads.
>
>When I wrote "on the fly", I was referring to the act of loading the
>text file. As in, it will tokenise during load *every* time the text
>file is loaded.

Well, then don't mention interpretation and tokenisation
in the same sentence. They don't happen at the same time,
and only the former can be described as being done 'on
the fly' (i.e. while running) ...

Martin Wuerthner

unread,
Dec 13, 2011, 9:42:14 AM12/13/11
to
In message <jvmee713orb99gmrv...@4ax.com>
John Kortink <kor...@inter.nl.net> wrote:


> On Tue, 13 Dec 2011 02:36:20 -0800 (PST), trevj <tr...@cwazy.co.uk>
> wrote:

>>For anyone wondering about version control systems/reasoning etc.
>>check out this ROOL thread... Rob Sprowson has now kindly amended the
>>renumbering step in RO5:
>>http://www.riscosopen.org/forum/forums/2/topics/71#posts-9666

> I'm not sure I will ever use one of those cheerfully and
> colourfully patched up BASICs, but while they're at it,
> they should also fix another annoying quirk (which I've
> patched myself years ago), which is faulting zero shifts
> in assembly as 'Bad shift', unless it's LSL. All other
> zero shifts (LSR#0, ASR#0, ASL#0) can be silently turned
> into LSL#0 without generating an error.

Ah yes, good point. I have run into that problem in the past.
Obviously, it is not a problem to avoid a literal ASR#0 in the code,
but when assembling parameterized code there are often shift
statements like ASR#(BitsPerComponent - 2).

ne...@iank.org.uk

unread,
Dec 13, 2011, 11:37:58 AM12/13/11
to
In article <e4355a3f5...@cferris.freeuk.com>,
<cfe...@freeRemoveuk.com.invalid> wrote:
> You can run BASIC text files - but when they are loaded - they are
> renumbered.

> Is there anyway of changing BASIC's choice of loading to RENUMBER 1,1?

> ie for large files.

> Thanks

Have you tried 'Bastext' http://erikgrnh.home.xs4all.nl/riscos/bastext.html
I have been using this with some very large basic programmes with no
problems. You can just call it in the run file of the programme you are
working on and it will convert the programme to tokenised and renumber it
to your specifications each time you run it. It's pretty quick too.

Regards
Ian K

Alan Adams

unread,
Dec 18, 2011, 7:37:56 AM12/18/11
to
In message <5240a0e8...@avisoft.f9.co.uk>
Martin <New...@avisoft.f9.co.uk> wrote:

> On 12 Dec, in article <0arFq.38914$E33....@newsfe23.ams2>,
> Steve Drain <st...@kappa.me.uk> wrote:

<snip>

>> True, but I /always/ have BASIC$Crunch set, and advocate that everyone
>> else should, too. ;-)

So what IS Basic$crunch? It doesn't appear in the index to the PRMs.
It doesn't appear in the index of the Basic VI reference manual
*help basic$crunch says "nothing found".

<snip>

--
Alan Adams, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/

Steve Drain

unread,
Dec 18, 2011, 8:21:32 AM12/18/11
to
On 18/12/2011 12:37, Alan Adams wrote:
> In message<5240a0e8...@avisoft.f9.co.uk>
> Martin<New...@avisoft.f9.co.uk> wrote:
>
>> On 12 Dec, in article<0arFq.38914$E33....@newsfe23.ams2>,
>> Steve Drain<st...@kappa.me.uk> wrote:
>
> <snip>
>
>>> True, but I /always/ have BASIC$Crunch set, and advocate that everyone
>>> else should, too. ;-)
>
> So what IS Basic$crunch? It doesn't appear in the index to the PRMs.
> It doesn't appear in the index of the Basic VI reference manual
> *help basic$crunch says "nothing found".

The primary reference is under the entry for CRUNCH in the manual you
mention, but not in the earlier one. It is also in the entry for *BASIC,
but not so obvious.

Steve

Alan Adams

unread,
Dec 18, 2011, 9:20:13 AM12/18/11
to
In message <EOlHq.219145$cr3.1...@newsfe03.ams2>
Thje manual describes flag setttings for crunch, but not what
Basic$Crunch - presumably a variable - does.

Reading between the lines of the previous posts, I am guessing that it
crunches the program as it loads, without altering the source. That is
NOT apparent from the very limited descriptions, which have always
suggested to me that the source would be crunched - the last thing I
want.

Alan

Steve Drain

unread,
Dec 18, 2011, 12:17:14 PM12/18/11
to
On 18/12/2011 14:20, Alan Adams wrote:
> In message<EOlHq.219145$cr3.1...@newsfe03.ams2>
> Steve Drain<st...@kappa.me.uk> wrote:
>
>> On 18/12/2011 12:37, Alan Adams wrote:
>>> In message<5240a0e8...@avisoft.f9.co.uk>
>>> Martin<New...@avisoft.f9.co.uk> wrote:
>>>
>>>> On 12 Dec, in article<0arFq.38914$E33....@newsfe23.ams2>,
>>>> Steve Drain<st...@kappa.me.uk> wrote:
>>>
>>> <snip>
>>>
>>>>> True, but I /always/ have BASIC$Crunch set, and advocate that everyone
>>>>> else should, too. ;-)
>>>
>>> So what IS Basic$crunch? It doesn't appear in the index to the PRMs.
>>> It doesn't appear in the index of the Basic VI reference manual
>>> *help basic$crunch says "nothing found".
>
>> The primary reference is under the entry for CRUNCH in the manual you
>> mention, but not in the earlier one. It is also in the entry for *BASIC,
>> but not so obvious.
>
> The manual describes flag settings for crunch, but not what
> Basic$Crunch - presumably a variable - does.

"In BASIC VI, programs with -quit set will CRUNCH %1111 [...]. BASIC V
will do this if the variable BASIC$Crunch exists."

The standard RunType for BASIC files is with -quit set, so this applies.

The system variable BASIC$Crunch only has to exist for BASIC V to crunch
the file as it loads. So, somewhere in the Boot sequence arrange for the
line '*Set BASIC$Crunch 1' to be executed. Martin and I think this
should be done anyway.

> Reading between the lines of the previous posts, I am guessing that it
> crunches the program as it loads, without altering the source.

That is correct.

Steve

Rick Murray

unread,
Dec 19, 2011, 11:58:37 PM12/19/11
to
On 18/12/2011 18:17, Steve Drain wrote:

> "In BASIC VI, programs with -quit set will CRUNCH %1111 [...]. BASIC V
> will do this if the variable BASIC$Crunch exists."

As said, Basic$Crunch need only exist as a variable for crunching to be
engaged.

Manually:

bit 0 : Remove leading spaces
bit 1 : Remove spaces in statements
bit 2 : Remove REMs (except first)
bit 3 : Remove empty statements
bit 4 : Remove empty lines

While it is advocated to use crunching, I think something like StrongBS
to make a "release copy" would be a better approach due to the
optimisations possible.

[
Is Mohsen Alshayef still around? The latest StrongBS is from 2009:
http://sites.google.com/site/strongbsnow/
]

Not to mention, some "clever" (in scare quotes) code really seriously
objects to being crunched. Thankfully there isn't much if it around.


Best wishes,

Rick.

Ste (news)

unread,
Dec 20, 2011, 8:36:10 AM12/20/11
to
In article <OfpHq.66356$925....@newsfe16.ams2>,
Steve Drain <st...@kappa.me.uk> wrote:
> The system variable BASIC$Crunch only has to exist for BASIC V to crunch
> the file as it loads. So, somewhere in the Boot sequence arrange for the
> line '*Set BASIC$Crunch 1' to be executed. Martin and I think this
> should be done anyway.

I thought BASIC$Crunch took flags (although I've not looked at the source)
so it should be set to -1 rather than 1.

Ta,

Steve

--
Steve Revill @ Home
Note: All opinions expressed herein are my own.

Steve Drain

unread,
Dec 20, 2011, 10:30:51 AM12/20/11
to
On 20/12/2011 04:58, Rick Murray wrote:
> While it is advocated to use crunching, I think something like StrongBS
> to make a "release copy" would be a better approach due to the
> optimisations possible.

I use BasCrunch, a much milder cruncher. StrongBS is a tour-de-force,
but rather over the top for me. I would rather eliminate inefficient
algorithms myself than hope for a quick fix.

> Not to mention, some "clever" (in scare quotes) code really seriously
> objects to being crunched. Thankfully there isn't much if it around.

I think Basalt comes into that category. ;-)

I do not advise crunching a program to be used with it, but it can be
done with the use of exceptions. Perhaps the speed gained by using new
keywords to replace BASIC routines might compensate. ;-)

Steve Drain

unread,
Dec 20, 2011, 10:31:14 AM12/20/11
to
On 20/12/2011 13:36, Ste (news) wrote:
> In article<OfpHq.66356$925....@newsfe16.ams2>,
> Steve Drain<st...@kappa.me.uk> wrote:
>> The system variable BASIC$Crunch only has to exist for BASIC V to crunch
>> the file as it loads. So, somewhere in the Boot sequence arrange for the
>> line '*Set BASIC$Crunch 1' to be executed. Martin and I think this
>> should be done anyway.
>
> I thought BASIC$Crunch took flags (although I've not looked at the source)
> so it should be set to -1 rather than 1.

No. It just has to exist; any value will do. I have just checked the source.

If it were to have a numeric value you would have to use SetEval, I
think. ;-)

Steve

John Williams (News)

unread,
Dec 20, 2011, 10:39:49 AM12/20/11
to
In article <PT1Iq.94546$Rz.9...@newsfe29.ams2>, Steve Drain
<st...@kappa.me.uk> wrote:

> No. It just has to exist; any value will do. I have just checked the
> source.

> If it were to have a numeric value you would have to use SetEval, I
> think. ;-)

Or TRUE? Which would correspond to Ste's -1, wouldn't it?

John

--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

Rick Murray

unread,
Dec 21, 2011, 2:34:32 AM12/21/11
to
On 20/12/2011 16:30, Steve Drain wrote:

> StrongBS is a tour-de-force,

Indeed it is.


> but rather over the top for me.

Ditto. I turned off some things as it was breaking intermingled
assembler, and some stuff I wasn't entire sure I wanted done. No
examples, I last looked at the options back in, like, 1995 and just
created a config file and used it over and over. ;-)


Best wishes,

Rick.

Rick Murray

unread,
Dec 21, 2011, 2:39:10 AM12/21/11
to
On 20/12/2011 16:39, John Williams (News) wrote:

>> If it were to have a numeric value you would have to use SetEval, I
>> think. ;-)
> Or TRUE? Which would correspond to Ste's -1, wouldn't it?

This is a *Set thing. I don't think the command line understands "TRUE"
and "FALSE".


Best wishes,

Rick.
0 new messages