That peskey 256 byte limit
Ian K (N)
I am in the process on converting a Free Basic programme to BBC Basic.
Unfortunately I have run into BBC Basic's 256 character string limit which
Free Basic doesn't have. Does anyone have any clever tips or useful tools
to ease my frustration. Unfortunately the variable causing the problem is
extensively used so a quick tweak is out of the question.
Regards
Ian K
Ste (news)
Your only real option if you want to stick with BASIC is to use the $
indirection operator and handle the string that way. You'll have to
implement some string handling functions, too.
There's probably a library out there which already does this type of thing.
For example, !Routines has the string.ctrl library which does some of that
sort of thing.
http://www.7thsoftware.com/software.htm
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Rob Kendrick
"Ian K (N)" <ne...@iank.org.uk> wrote:
Steve's suggestion is the only sensible one if you wish to stick to BBC
Basic. However, there are Microsoft Basic-compatible compiler clones
out there that target C, and thus they might be another option to
investigate.
B.
Richard Russell
> I am in the process on converting a Free Basic programme to BBC Basic.
> Unfortunately I have run into BBC Basic's 256 character string limit which
> Free Basic doesn't have. Does anyone have any clever tips or useful tools
> to ease my frustration.
Could you use Brandy? Its strings can be up to 65535 characters.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
chris...@bigfoot.com
I wrote a simple BASIC library a decade ago which addresses this
problem. The syntax is pretty hideous (as you might imagine), but it
served my purpose at the time:
http://www.starfighter.acornarcade.com/mysite/programming.htm#longstr
The main weakness is the lack of garbage-collection, because BASIC
isn't aware that an integer variable going out of scope may refer
opaquely to a long string that ought to be deallocated. Maybe I ought
to have used a stack-based implementation...
--
Christopher Bazley
Jonathan Graham Harston
> Unfortunately I have run into BBC Basic's 256 character string limit which
> Free Basic doesn't have. Does anyone have any clever tips or useful tools
> to ease my frustration. Unfortunately the variable causing the problem is
> extensively used so a quick tweak is out of the question.
"strings" longer than 255 characters is to stop thinking of them as
strings, and treat them as text blocks.
If it has subcomponents within it terminated with <cr> that are all
shorter than 256 characters you'll be able to access it with the $
operator. Inserting and removing characters may end up a bit slow
as you end up shuffling characters up and down in memory.
I'm sure somebody out there wrote a long string library, but a few
minutes searching for "BBC BASIC long string library" doesn't turn
anything up.
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
The most perfect world is an imperfect world as the imperfections
give people a reason to strive to change it.
Gazza
Yeah... I'm stuck with the same problem with a project I'm doing at
the moment.. The solution I've come up with is to convert everything
to ASCII codes and operate on it byte at a time using blk%?offset%.
The sort of thing I'm doing adapts itself to this method anyhow.
Going through a corrupted MS Word/Generic DTP file extracting the text
component and putting it through a dictionary to filter out the
garbage is the exact task, but as I've seen someone here point out.
Stopping thinking of it as a string and treatng it as a block of bytes
seems to be the best way of going about it.
Maybe now that ROOL has the BBC BASIC source available, somebody might
be able to figure out a RAM loadable version of the module that
addresses these limitations. Long strings, LOCAL var%:DIM var% <space>
memory leaks and native loading/saving of blocks of memory come to
mind straight away. Possibly bringing th ARM version in line with
BB4W. I know it's probably a BIG ask, but we can still dream.
Gavin Wraith
Gazza <use...@garethlock.com> wrote:
> Going through a corrupted MS Word/Generic DTP file extracting the text
> component and putting it through a dictionary to filter out the
> garbage is the exact task, but as I've seen someone here point out.
> Stopping thinking of it as a string and treating it as a block of bytes
> seems to be the best way of going about it.
>
> Maybe now that ROOL has the BBC BASIC source available, somebody might
> be able to figure out a RAM loadable version of the module that
> addresses these limitations. Long strings, LOCAL var%:DIM var% <space>
> memory leaks and native loading/saving of blocks of memory come to
> mind straight away. Possibly bringing th ARM version in line with
> BB4W. I know it's probably a BIG ask, but we can still dream.
I know I am probably missing the point here, but why not just use
RiscLua? Strings can then be megabytes in size. The 'string' and 'lpeg'
libraries provide highly optimized extraction and filtering functions.
Why keep reinventing the wheel?
--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
Derek Haslam
j...@arcade.demon.co.uk (Jonathan Graham Harston) wrote:
> iank wrote:
>> Unfortunately I have run into BBC Basic's 256 character string limit which
>> Free Basic doesn't have. Does anyone have any clever tips or useful tools
>> to ease my frustration. Unfortunately the variable causing the problem is
>> extensively used so a quick tweak is out of the question.
> My standard recommendation when people start trying to deal with
> "strings" longer than 255 characters is to stop thinking of them as
> strings, and treat them as text blocks.
> If it has subcomponents within it terminated with <cr> that are all
> shorter than 256 characters you'll be able to access it with the $
> operator. Inserting and removing characters may end up a bit slow
> as you end up shuffling characters up and down in memory.
Not really a problem if you use Wimp_TransferBlock. Although
originally intended for transferring blocks of memory between tasks it
also works when the blocks are in the same task and even when their
address ranges overlap.
> I'm sure somebody out there wrote a long string library, but a few
> minutes searching for "BBC BASIC long string library" doesn't turn
> anything up.
Derek Haslam
--
Mastery of the rules is a prerequisite for breaking them creatively.
Steve Drain
> On Jan 5, 11:13 pm, "Ian K (N)" <n...@iank.org.uk> wrote:
>> Hello all and a Happy New Year
>>
>> I am in the process on converting a Free Basic programme to BBC Basic.
>> Unfortunately I have run into BBC Basic's 256 character string limit which
>> Free Basic doesn't have. Does anyone have any clever tips or useful tools
>> to ease my frustration. Unfortunately the variable causing the problem is
>> extensively used so a quick tweak is out of the question.
How is the variable used, please?
> Maybe now that ROOL has the BBC BASIC source available, somebody might
> be able to figure out a RAM loadable version of the module that
> addresses these limitations. Long strings, LOCAL var%:DIM var% <space>
> memory leaks and native loading/saving of blocks of memory come to
> mind straight away. Possibly bringing th ARM version in line with
> BB4W. I know it's probably a BIG ask, but we can still dream.
Local DIM LOCAL *is* in the ROOL BASIC, and you can have it with Basalt.
Long strings are tricky. The available version of Basalt has them, but
there are only a few things you can do with them. If you are really
enthusiastic for them let me know that would use them if I did more
work. Likewise LOAD and SAVE blocks. I knocked those up in an hour or
two, but they will not see the light of day unless I think they will
really be used. Meanwhile, here is the syntax for your comments:
SAVE filename$,address%,size%[OF filetype%]
LOAD filename$,address%[,available%][OF filetype%[,filetype%]^]
address%=LOAD(filename$[OF filetype%[,filetype%]^])
The optional available% prevents loading a file into too small a block.
The optional filetype% lists allow only specified files to be loaded.
The function form of LOAD loads the file into a block claimed for it.
Steve
Jonathan Graham Harston
> really be used. Meanwhile, here is the syntax for your comments:
>
> SAVE filename$,address%,size%[OF filetype%]
> LOAD filename$,address%[,available%][OF filetype%[,filetype%]^]
> address%=LOAD(filename$[OF filetype%[,filetype%]^])
bits. That looks useful, and I'll probably add it in when I'm next
playing with it.
(http://mdfs.net/pics/2009/09/img_0070.htm)There are three food groups: brown, green and ice cream.