Topics

Disc i/o

R.E.
 

 Hi this is a fine product.  I have written my first program in almost 20+ years Using BBC Basic.  I love it.
One problem. I wrote a little prog and used DATA statements to acces the 100 odd strings I needed.
 I have all the routines functioning as I wanted and expected but........
  As soon as wrote in the Disc access routines, the screen Print layout went to......pieces.
  So I assume that there is a CHR$ 13 appended to all the data now that it's coming from the disc file.
  Is that it?   How do I get rid of all the carriage returns that seem to be imbeded now?  Any ideas?
Is that what it is? can I just use LEN and subtract the last (unseen) character?
Any help would sure be appreciated.
-Steve Hatch
DEWEY AZ
No more C for me. It's back to basics.

Marcello
 

Hi, 
This is the function I normally use to solve the problem you mention.

      DEF FN_RecClean$(Z$)
      REM Gets rid of format charaters.
  REM Keeps everithing following "§"
      REM Removes everithing following "!" (used as comment lines)
      LOCAL I%, A$, C%
      FOR I%=1 TO LEN(Z$)
        C%=ASC(MID$(Z$,I%,1))
        IF C%=ASC("§") THEN A$+=RIGHT$(Z$,LEN(Z$)-I%) : =A$
        IF C%=ASC("!") THEN =A$
        IF (C%>=&21) AND (C%<=&7D) THEN A$+=CHR$(C%)
      NEXT I%
      =A$

When you get a record from file:

Record$=FN_RecClean$(GET$# FileNr%))


Best regards

Marcello


On Sat, Mar 24, 2018 at 4:39 AM, R.E. <hatch@...> wrote:
 Hi this is a fine product.  I have written my first program in almost 20+ years Using BBC Basic.  I love it.
One problem. I wrote a little prog and used DATA statements to acces the 100 odd strings I needed.
 I have all the routines functioning as I wanted and expected but........
  As soon as wrote in the Disc access routines, the screen Print layout went to......pieces.
  So I assume that there is a CHR$ 13 appended to all the data now that it's coming from the disc file.
  Is that it?   How do I get rid of all the carriage returns that seem to be imbeded now?  Any ideas?
Is that what it is? can I just use LEN and subtract the last (unseen) character?
Any help would sure be appreciated.
-Steve Hatch
DEWEY AZ
No more C for me. It's back to basics.


Richard Russell
 

On Fri, Mar 23, 2018 at 08:39 pm, R.E. wrote:
So I assume that there is a CHR$ 13 appended to all the data now that it's coming from the disc file.
No.  So long as you use the correct pair of statements there will not be any appended characters.  So if you write to disk using PRINT# and read back from disk using INPUT# you will not get any characters appended to strings, and if you write with BPUT# and read using GET$# again you won't get any characters appended to strings.  When you may get unwanted effects of that sort is if you mismatch the pairs of statements, so for example if you write using BPUT# and read using INPUT# you can expect odd results, as you can if you write using PRINT# and read using GET$#.

You definitely should not be removing the last character of the string or anything like that (and if you did want to do that, using LEN is very long-winded since BBC BASIC has a built-in function for removing the last character of  a string!).  You can easily confirm that this is the case using a simple test program:

      file% = OPENOUT(@tmp$ + "test.dat")
      PRINT #file%, "Hello", "world!"
      PTR#file% = 0
      INPUT #file%, hello$, world$
      CLOSE #file%
      PRINT hello$, LEN(hello$)
      PRINT world$, LEN(world$)

No characters added, no characters removed!  Note that I have assumed that your strings themselves do not contain 'control characters' (such as LF - CHR$10 - or CHR$13 - CR); if they do you may need to take special precautions.

Marcello's reply is addressing a different issue and I don't think it is relevant to your situation at all.

Richard.

Richard Russell
 

Just as a further note, I assume that you are not attempting to read a file created by a program other than BBC BASIC (e.g. a text editor program).  In that situation different considerations apply, and you would need to use code such as that listed at the Wiki under Reading and writing plain text files.  BBC BASIC does not have, and never has had, any built-in statements or functions that will read a plain-text file such as would be created by a program like Notepad or Wordpad (in Windows).  To do that you need to use additional code, for example the FNreadline function listed in that Wiki article.

Richard.

R.E.
 

  Well Thank You.  I'm sure I can fix it now.  The problem was I was inputing a file created by wordpad.
  It was a splendid blended mess of control characters just like you said.
 HA Ha ha stupid me....
   By the way I really do love your program.   I'm writing all the little programs that only I need and it's
just as easy as I could imagine.  I did some C+ programming back in the late 80's but haven't since.
  It always seemed too cumbersome since it would be weeks or even months between writings
But here is 'good ol basic' back out of my sub-conscious after all these years. (learned on a Tandy model1)
  Just a few words to learn since yours are just a bit different, but not bad at all.
  So again let ,me say thank you.... I sincerely mean it.  You've got an old man thinking again (and having fun)
Stephen Hatch
Dewey AZ USA.

Richard Russell
 

On Sat, Mar 24, 2018 at 10:26 am, R.E. wrote:
By the way I really do love your program.   I'm writing all the little programs that only I need and it's
just as easy as I could imagine.
BBC BASIC is not perfect; hindsight always identifies a few things that could have been done better, and file handling is probably one of them.  But in general it meets the objective of being simple enough for a complete beginner yet powerful enough to cope with the demands of complex programs.  It can be criticised for not being as 'tailored' to Windows as some other BASICs, but it's this very property that has made it possible to develop versions for Linux, Mac OS, Android, iOS etc. largely without sacrificing compatibility.

Richard.

Dagfinn
 

Re: Back to Basic

 

Actually the «Richard Russell» BBC Basic, continuing the tradition of the BBC Micro, has quite a lot of C-like functionality – in particular the combination of high level and low level features -  so in a way you get the best of both worlds, the C-like world and the Basic-like world 😊

 

Dagfinn

 

Sendt fra E-post for Windows 10

 

R.E.
 
Edited

Here is what I wrote to strip the LF off the word processor file.
  Thanks you for the help. This works just the way I wanted it to.


      :                      REM strip chrs10 (line feed)from each car string
      FOR x=1 TO fc   : REM    fc is the number of entries from the car file
        cr$=""
        cr$= LEFT$(car$(x),1)
        IF ASC(cr$)=10 THEN d$=MID$(car$(x),2):car$(x)=d$:        REM check for a 10
      NEXT x
      :                      REM collect chars starting at 2nd char in d4

Stephen Hatch

Richard Russell
 

On Sun, Mar 25, 2018 at 09:35 am, R.E. wrote:
Here is what I wrote to strip the LF off the word processor file.
It's a somewhat long-winded version of the code listed in the Wiki article to which I linked earlier, here rewritten using your variable names:

      IF ASC(car$(x))=10 car$(x)=MID$(car$(x),2)

If you compare this with yours you'll see that you have quite a lot of unnecessary code: initialising cr$ to "" (not needed), setting cr$ to the first character of car$(x) (not needed: ASC returns the first character anyway), using a temporary string d$ (not needed).

If you've previously been used to programming in C such overheads are insignificant (and indeed the compiler can probably spot them and strip them out anyway) but a slow, interpreted, language like BBC BASIC benefits from some 'manual optimisation'.  Even if the speed improvement is of no value in this particular case, it might be on another occasion.

Richard.

samr6791@...
 

The simple test program shown in post #22486 was tried:
"No such variable" was reported at the first line.
The PC has Windows Vista, with BBC BASIC for Windows version 5.50b.
Attempts to upgrade to version 6.12a have failed.
(When "Run as administrator' is used with "upgrade.exe" there is no response).
If anyone could suggest why this simple test routine fails it would be much appreciated.

      file% = OPENOUT(@tmp$ + "test.dat")
      PRINT #file%, "Hello", "world!"
      PTR#file% = 0
      INPUT #file%, hello$, world$
      CLOSE #file%
      PRINT hello$, LEN(hello$)
      PRINT world$, LEN(world$)

Richard Russell
 

On Sun, Jan 6, 2019 at 09:01 PM, <samr6791@...> wrote:
If anyone could suggest why this simple test routine fails it would be much appreciated.
It's because v5.50b is ancient (released around twelve years ago, almost to the day) so will have many bugs, some features not yet implemented (e.g. @tmp$ did not yet exist, hence the error) and won't be compatible with modern versions of Windows.  You need to upgrade to v6.12a: there's no reason why you would not be able to, I've tested it on Windows 95, Windows 2000, Windows XP, Windows 7 and Windows 10.

So repeat the upgrade.  If you have a virus scanner, disable it first since that's a likely cause of any issues.  Also make sure that the 'upgrade.exe' you downloaded is not corrupted: html downloads aren't reliable.  For example check that the file length is exactly 5,028,440 bytes.

You could also consider using 'BBC BASIC for SDL 2.0' (BBCSDL).  It should run in Windows Vista (although admittedly I've not tried it) and is free!  Unlike 'BBC BASIC for Windows', it is being actively developed.

samr6791@...
 

Following advice from Richard Russell the v5.50b version of BB4W has been upgraded, and the simple test given in this discussion works perfectly now.