Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1171 > unrolled thread

Running BASIC text files

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Running BASIC text files cferris@freeRemoveuk.com.invalid - 2011-12-10 10:32 +0000
    Re: Running BASIC text files John Kortink <kortink@inter.nl.net> - 2011-12-10 12:27 +0100
      Re: Running BASIC text files cferris@freeRemoveuk.com.invalid - 2011-12-11 11:11 +0000
        Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-12 13:32 +0000
          Re: Running BASIC text files Martin <News03@avisoft.f9.co.uk> - 2011-12-12 17:01 +0000
            Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-12 17:50 +0000
              Re: Running BASIC text files Martin <News03@avisoft.f9.co.uk> - 2011-12-12 22:00 +0000
                Re: Running BASIC text files Alan Adams <alan@adamshome.org.uk> - 2011-12-18 12:37 +0000
                  Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-18 13:21 +0000
                    Re: Running BASIC text files Alan Adams <alan@adamshome.org.uk> - 2011-12-18 14:20 +0000
                      Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-18 17:17 +0000
                        Re: Running BASIC text files Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-20 05:58 +0100
                          Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-20 15:30 +0000
                            Re: Running BASIC text files Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-21 08:34 +0100
                        Re: Running BASIC text files "Ste (news)" <steve@revi11.plus.com> - 2011-12-20 13:36 +0000
                          Re: Running BASIC text files Steve Drain <steve@kappa.me.uk> - 2011-12-20 15:31 +0000
                            Re: Running BASIC text files "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-12-20 16:39 +0100
                              Re: Running BASIC text files Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-21 08:39 +0100
        Re: Running BASIC text files Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-12 16:35 +0100
          Re: Running BASIC text files John Kortink <kortink@inter.nl.net> - 2011-12-12 18:51 +0100
            Re: Running BASIC text files Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-13 06:31 +0100
              Re: Running BASIC text files Martin Wuerthner <spamtrap@mw-software.com> - 2011-12-13 10:11 +0100
                Re: Running BASIC text files trevj <trevj@cwazy.co.uk> - 2011-12-13 02:36 -0800
                  Re: Running BASIC text files John Kortink <kortink@inter.nl.net> - 2011-12-13 15:20 +0100
                    Re: Running BASIC text files Martin Wuerthner <spamtrap@mw-software.com> - 2011-12-13 15:42 +0100
                Re: Running BASIC text files cferris@freeRemoveuk.com.invalid - 2011-12-13 12:37 +0000
              Re: Running BASIC text files John Kortink <kortink@inter.nl.net> - 2011-12-13 15:38 +0100
    Re: Running BASIC text files  <news@iank.org.uk> - 2011-12-13 16:37 +0000

Page 1 of 2  [1] 2  Next page →

#1171 — Running BASIC text files

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

[toc] | [next] | [standalone]

#1172

On Sat, 10 Dec 2011 10:32:29 GMT, cferris@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    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

[toc] | [prev] | [next] | [standalone]

#1174

In message <kpf6e7d2orn4m0u92nj9t9kukghbdnl32o@4ax.com>
          John Kortink <kortink@inter.nl.net> wrote:

> 
> On Sat, 10 Dec 2011 10:32:29 GMT, cferris@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'.


-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#1176

On 11/12/2011 11:11, cferris@freeRemoveuk.com.invalid wrote:
> In message<kpf6e7d2orn4m0u92nj9t9kukghbdnl32o@4ax.com>
>            John Kortink<kortink@inter.nl.net>  wrote:
>
>>
>> On Sat, 10 Dec 2011 10:32:29 GMT, cferris@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'.

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%

[toc] | [prev] | [next] | [standalone]

#1178

On 12 Dec, in article <CnnFq.52254$Oz7.36638@newsfe24.ams2>,
   Steve Drain <steve@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. 

[toc] | [prev] | [next] | [standalone]

#1179

On 12/12/2011 17:01, Martin wrote:
> On 12 Dec, in article<CnnFq.52254$Oz7.36638@newsfe24.ams2>,
>     Steve Drain<steve@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.

[toc] | [prev] | [next] | [standalone]

#1181

On 12 Dec, in article <0arFq.38914$E33.6964@newsfe23.ams2>,
   Steve Drain <steve@kappa.me.uk> wrote:
> On 12/12/2011 17:01, Martin wrote:
> > On 12 Dec, in article<CnnFq.52254$Oz7.36638@newsfe24.ams2>,
> >     Steve Drain<steve@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!

Martin

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

[toc] | [prev] | [next] | [standalone]

#1194

In message <5240a0e8c7News03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> On 12 Dec, in article <0arFq.38914$E33.6964@newsfe23.ams2>,
>    Steve Drain <steve@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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#1198

On 18/12/2011 12:37, Alan Adams wrote:
> In message<5240a0e8c7News03@avisoft.f9.co.uk>
>            Martin<News03@avisoft.f9.co.uk>  wrote:
>
>> On 12 Dec, in article<0arFq.38914$E33.6964@newsfe23.ams2>,
>>     Steve Drain<steve@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

[toc] | [prev] | [next] | [standalone]

#1199

In message <EOlHq.219145$cr3.198855@newsfe03.ams2>
          Steve Drain <steve@kappa.me.uk> wrote:

> On 18/12/2011 12:37, Alan Adams wrote:
>> In message<5240a0e8c7News03@avisoft.f9.co.uk>
>>            Martin<News03@avisoft.f9.co.uk>  wrote:
>>
>>> On 12 Dec, in article<0arFq.38914$E33.6964@newsfe23.ams2>,
>>>     Steve Drain<steve@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.

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


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

[toc] | [prev] | [next] | [standalone]

#1200

On 18/12/2011 14:20, Alan Adams wrote:
> In message<EOlHq.219145$cr3.198855@newsfe03.ams2>
>            Steve Drain<steve@kappa.me.uk>  wrote:
>
>> On 18/12/2011 12:37, Alan Adams wrote:
>>> In message<5240a0e8c7News03@avisoft.f9.co.uk>
>>>             Martin<News03@avisoft.f9.co.uk>   wrote:
>>>
>>>> On 12 Dec, in article<0arFq.38914$E33.6964@newsfe23.ams2>,
>>>>      Steve Drain<steve@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

[toc] | [prev] | [next] | [standalone]

#1203

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.

[toc] | [prev] | [next] | [standalone]

#1206

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. ;-)

[toc] | [prev] | [next] | [standalone]

#1209

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.

[toc] | [prev] | [next] | [standalone]

#1204

In article <OfpHq.66356$925.51238@newsfe16.ams2>,
   Steve Drain <steve@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.

[toc] | [prev] | [next] | [standalone]

#1207

On 20/12/2011 13:36, Ste (news) wrote:
> In article<OfpHq.66356$925.51238@newsfe16.ams2>,
>     Steve Drain<steve@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

[toc] | [prev] | [next] | [standalone]

#1208

In article <PT1Iq.94546$Rz.93992@newsfe29.ams2>, Steve Drain
<steve@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/

[toc] | [prev] | [next] | [standalone]

#1210

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.

[toc] | [prev] | [next] | [standalone]

#1177

On 11/12/2011 12:11, cferris@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.

[toc] | [prev] | [next] | [standalone]

#1180

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

>On 11/12/2011 12:11, cferris@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.


John Kortink

-- 

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web