Home  |  Contents 

Microcontroller and PC projects
  Forum Index : Microcontroller and PC projects         Section
Subject Topic: A beginner (almost), woes aplenty Post ReplyPost New Topic
Page of 3 Next >>
Author
Message << Prev Topic | Next Topic >>
plover
Senior Member
Senior Member


Joined: 18 April 2013
Location: Australia
Online Status: Offline
Posts: 239
Posted: 10 July 2018 at 8:45pm | IP Logged Quote plover

Well, how hard can it be I did learn and use basic decades ago albeit. I am not sure but I seem have stuck in my brain that Geoff Graham may have made a comment like, something about getting a BASIC interpreter up and running in 6 months or was it less, how hard could it be, the plan was laid out.

When I saw the thought of ordinary BASIC could be used in real life, Wooow, I had just started looking at these free software development environment, really only some 500 plus MB and I should be able to do something, well there was something about C language and compiling, perhaps wait a little longer.

I take heart in that he persevered, the result is history. I have enjoyed following the development immensely. A number of times decided that now I will do it. So far a box full of parts, including a couple of Mick boards actually working (bought them assembled). Do have MMBasic on those boards working using Linux, not to forget Jim's editor, with syntax colouring.

You can't let that stay in the box. So while I am doing some AutoTrax crash learning I relax (distract my brain) with running MMBasic in the terminal on Win 7.

Running the Basic and having the manual in front of me, cheating by copying the "exercises" from the pdf to the terminal, which has been augmented with some capability in my beloved text editor.

Ok, I got to page 9 in the manual, discovered that there was a mistake but found out my manual was too old. It had been corrected in the latest (checked it today) That was good enough for session 1.

Started session 2 page 10, Random File IO, which has always bothered me, don't really know why. Here it did become interesting as I had to do some thinking. Well up and running.

DOS MMBasic Ver 5.04.08
Copyright 2011-2017 Geoff Graham

> OPEN "filename" FOR RANDOM AS #1
Error: No such file or directory
>
>


What? checking back on page 9, naaah fair enough there is no file. Let me put something in the file, saw print statement earlier:

>
> close 1
>
> OPEN "filename.txt" FOR OUTPUT AS #1
>
> PRINT #1, "The quick brown Fox jumped over the fence in Daylight to the chookh
ouse, but the cockerel would have none of that"
>
> close 1


Soon found out that I had forgotten that #1 now was open, therefore the CLOSE 1. To my satisfaction and delight I survived the next line, no error message. Quickly a CLOSE 1 just to be sure that would not hit me next with an error.

Now of course I have strayed from the manual, but how hard can it be to read something in that file?. Starting to look like cat and mouse, with the mouse laughing

>
> OPEN "filename.txt" FOR RANDOM AS #1
> dat$ = INPUT$(64, #1)
>
> print dat$
>
>
> close 1


To me it seems it did not work, to me it looks like that integer variable dat$ should have had some content, if it does where is it and if not why not. I think I missed something vital about "records" perhaps some declaration might have been smarter?

Help please?

Oh I see further down the page here comes help.

>
> close 1
>
> RecLen = 64
> OPEN "test.dat" FOR RANDOM AS #1
Error: No such file or directory
> DO
Error: No matching LOOP
> abort: PRINT

> PRINT "Number of records in the file =" LOF(#1)/RecLen
Number of records in the file = 0
> INPUT "Command (r = read,w = write, a = append, q = quit): ", cmd$
Command (r = read,w = write, a = append, q = quit): IF cmd$ = "q" THEN CLOSE #1
: END
> IF cmd$ = "a" THEN
Error: No matching ENDIF
> SEEK #1, LOF(#1) + 1
> ELSE
Error: No matching ENDIF
> INPUT "Record Number: ", nbr
Record Number: IF nbr < 1 or nbr > LOF(#1)/RecLen THEN PRINT "Invalid record" :
GOTO abort
> SEEK #1, RecLen * (nbr - 1) + 1
Error: Invalid seek position
> ENDIF
> IF cmd$ = "r" THEN
Error: No matching ENDIF
> PRINT "The record = " INPUT$(RecLen, #1)
The record =
> ELSE
Error: No matching ENDIF
> LINE INPUT "Enter the data to be written: ", dat$
Enter the data to be written: PRINT #1,dat$ + SPACE$(RecLen - LEN(dat$));
> ENDIF
> LOOP
Error: LOOP without a matching DO
>


I think it is time for another day, it is getting worse and emails are waiting for answers.


Back to Top View plover's Profile Search for other posts by plover
 
JohnS
Guru
Guru


Joined: 18 November 2011
Location: United Kingdom
Online Status: Offline
Posts: 1698
Posted: 10 July 2018 at 9:56pm | IP Logged Quote JohnS

Maybe use the newer V5.04.09

John
Back to Top View JohnS's Profile Search for other posts by JohnS
 
panky
Guru
Guru
Avatar

Joined: 02 October 2012
Location: Australia
Online Status: Offline
Posts: 563
Posted: 10 July 2018 at 11:18pm | IP Logged Quote panky

@plover,

Looking at your post above, you appear to be entering commands at the MMBasic prompt? For quite a number of the commands you have tried, it makes no sense to enter them at the command prompt and all you will get will be error messages.

It might be an idea to download a copy of Geoff's "Getting Started with MMBasic" from his web site and work through the examples in there.

Perhaps start with simple 5 or 10 line programs to do things like INPUT to a variable and then output to the console.

There are plenty of examples in the manual referenced above.

panky

__________________
DonTSM1,Duinomite,CGCMM1,CGCMM2,2xDimitech,3xWWuMites,MicksMuP,Grogster1A,4xPeterMuM+,Zonker DIP-600,3xCGuKits,CGuBoard2,SnadPic100,SCBP64 & Exp100,PMMZ144,PMMZ100 .. and loving it![:D
Back to Top View panky's Profile Search for other posts by panky
 
plover
Senior Member
Senior Member


Joined: 18 April 2013
Location: Australia
Online Status: Offline
Posts: 239
Posted: 11 July 2018 at 12:00am | IP Logged Quote plover


JohnS

thanks, very good point, will have to laught here as I went and downloaded today but I only checked the manual. Never occurred to me it would be prudent to just check the
version number as well.

For some reason my instinct tells me this is not my problem, but my instinct I also often ignore to my peril. Will check in the morning some time.



Panky

Thanks for replying
Quote:
Ok, I got to page 9 in the manual, discovered that there was a mistake but found out my manual was too old. It had been corrected in the latest (checked it today) That was good enough for session 1.


I did not mention very specificly what manual, but it is inferred that I am diligently going through the manual, page by page.

Well I am stepping through the program one line at the time, I did with the examples on p.. 9 and that worked fine???

I may certainly have misunderstood the manual but it seemed logical to me, step through and check it all works?

Quote:
...it makes no sense to enter them at the command prompt and all you will get will be error messages.


Is it not valid statements?
Back to Top View plover's Profile Search for other posts by plover
 
Grogster
Guru
Guru
Avatar

Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 6227
Posted: 11 July 2018 at 8:49am | IP Logged Quote Grogster

Hey there.

Most commands CAN be run at the command-prompt in immediate mode, but there are several that CANNOT.

Any multi-line command, such as IF/THEN/ELSE will NOT work at the command prompt, unless the interpreter can evaluate the command in one single line.

The reason you are getting errors, is that when you press ENTER on your IF/THEN experiments, the interpreter IMMEDIATELY attempts to run that line of code. It does not work, as you are missing the rest of the multi-line statements, and the interpreter has nothing to execute after the THEN keyword, so it falls over with the error about no matching ENDIF.

Commands like those ones MUST be run as part of a program code, and they simply can't be run at the command-prompt in immediate mode.

EDIT: Well, technically, you CAN do it by separating out the commands using colons. You are still limited to one line of code, but you can do it along the lines of:

IF X=1 THEN:PRINT "TRUE":ELSE:PRINT "FALSE":ENDIF

That would probably work. Not tested, but it should.

EDIT: Just tried it, yes that does work. You really, REALLY need to be entering in the commands using the built-in editor(type EDIT at the command-prompt), so that you can run the code and experiment around. Typing the commands at the prompt like that is a waste of effort too, as the code you are typing will be totally forgotten once the interpreter has executed that line - so you are typing all that code, to have MMBASIC NOT remember it.

I know where you are coming from - entering in the BASIC at the command-prompt. The Atari 800XL I used to have years ago did it that way. Each line was entered at the command prompt, and saved as part of the program. MMBASIC does NOT do it like that. You have to use the built-in editor to write your code, and then use F1 to save it to memory.

Edited by Grogster on 11 July 2018 at 9:06am


__________________
Smoke makes things work. When the smoke gets out, it stops!
Back to Top View Grogster's Profile Search for other posts by Grogster Visit Grogster's Homepage
 
plover
Senior Member
Senior Member


Joined: 18 April 2013
Location: Australia
Online Status: Offline
Posts: 239
Posted: 11 July 2018 at 11:39pm | IP Logged Quote plover

Grogster
Thanks for posting and I like the explanation. I had to try it that way.

When I saw the section of code nicely laid out with indents etc, I did think I had better make a file from that and run?

In the manual page 6

AUTORUN.BAS is described.
Quote:
If a valid program file name is not provided on the command line MMBasic will attempt to load a program
called AUTORUN.BAS and run it. It will first look for this file in the default directory provided by the
Windows operating system and if it was not found there it will look for it in the root directory of the C: drive.


Ah, as the previous little exercise by running individual lines turned out to be a big flop. What about copy and paste the "failing" code to the Autorun.bat?

In my case simple, I have a file p10-record.bas containing the code ready to test so will make a copy and rename this AUTORUN.BAT

Then start up MMBasic.exe from same directory.



The following code is next in the manual, reading text in file in reverse order


OPEN "file.txt" FOR RANDOM AS #1
FOR i = LOF(#1) TO 1 STEP -1
SEEK #1, i
PRINT INPUT$(1, #1);
NEXT i
CLOSE #1


I can use this to test the file I thought I had made with the Fox and over the fence to the chook house. That exercise ended up with me wondering if there was anything in the file. Named the code file "rev-file.bas" and my code:

' Page 10 in the manual for the MMBasic DOS version
' the file called "rev-file.bas"
'OPEN "file.txt" FOR RANDOM AS #1
'Close #1        'just in case it was open
Open "filename.txt" For RANDOM As #1
For i = Lof(#1) To 1 Step -1
Seek #1, i
Print Input$(1, #1);
Next i
Close #1


To get the code into the MMBasic



To run the program, F2


[4] Close #1        'just in case it was open
Error: File number is not open
>


Oh, but the filenumber could have been open? How would I know if it is open or not, I tried to outfox the "already open" error. Hmm.

EDIT an make the CLOSE #1 line a comment then use F2 key, that is quick and easy


taht fo enon evah dluow lerekcoc eht tub ,esuohkoohc eht ot thgilyaD ni ecnef eh
t revo depmuj xoF nworb kciuq ehT
>


Now that was nice, I had managed to fill in some characters in the file, and the new little bit of code also worked.

This took a lot longer for me then what I had expected. ZZZzzz.... here
Back to Top View plover's Profile Search for other posts by plover
 
Grogster
Guru
Guru
Avatar

Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 6227
Posted: 12 July 2018 at 8:48am | IP Logged Quote Grogster

I have had that open/close issue myself. IE: How do you know it is open or closed at a certain point. The simplest solution that others on the forums suggested to me at the time, was a flag. I used a variable such as FOF(file open flag), and just tested that before doing any closing of the port.


If FOF then
  Close #1
  FOF=0 'Clear flag
Endif
Open "FILENAME.TXT" for RANDOM as #1
FOF=1 'Set flag for next time


This way, as soon as you try to open or close the file, it will first check to find out if the file is already open. If it is, it will close the file first, then re-open it. That kind of thing seems to get around the error that can pop-up when you try to close a file that is not open, or open one that is already opened.


__________________
Smoke makes things work. When the smoke gets out, it stops!
Back to Top View Grogster's Profile Search for other posts by Grogster Visit Grogster's Homepage
 
TassyJim
Guru
Guru
Avatar

Joined: 07 August 2011
Location: Australia
Online Status: Offline
Posts: 2711
Posted: 12 July 2018 at 9:37am | IP Logged Quote TassyJim

Don't use AUTORUN until you are sure the code is working.
It can be difficult to escape from rouge programs (and we have them sometimes).

Jim

__________________
It all started with the ZX81....
VK7JH
http://www.c-com.com.au/MMedit.htm
Back to Top View TassyJim's Profile Search for other posts by TassyJim Visit TassyJim's Homepage
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2427
Posted: 12 July 2018 at 11:15am | IP Logged Quote Geoffg

Grogster wrote:
I have had that open/close issue myself. IE: How do you know it is open or closed at a certain point. The simplest solution that others on the forums suggested to me at the time, was a flag. I used a variable such as FOF(file open flag), and just tested that before doing any closing of the port.


Or you can use ON ERROR SKIP

On Error Skip
Close #1

Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
Bill7300
Senior Member
Senior Member


Joined: 05 August 2014
Location: Australia
Online Status: Offline
Posts: 131
Posted: 12 July 2018 at 11:22am | IP Logged Quote Bill7300

Rouge programs, Jim? I usually find it is actually the programmer who ends up with the red face, rather than the program :)
Bill
Back to Top View Bill7300's Profile Search for other posts by Bill7300
 
plover
Senior Member
Senior Member


Joined: 18 April 2013
Location: Australia
Online Status: Offline
Posts: 239
Posted: 12 July 2018 at 12:07pm | IP Logged Quote plover

I like the idea of a single line test, can it be made one line such as

On Error Skip : Close #1


TassyJim:
thanks for the tip about making sure the program runs first. Had not thought about this.

Grogster:
Later I might just try your flag test out, as a single liner.

General:
In a big program I assume then that there is no way of knowing how many file numbers are in use. The follow on then is that make sure you keep tight control over what the file numbers up to, be diligent if used make sure they get closed quickly?

Edited by plover on 12 July 2018 at 12:11pm
Back to Top View plover's Profile Search for other posts by plover
 
rave
Newbie
Newbie


Joined: 24 February 2018
Location: United States
Online Status: Offline
Posts: 28
Posted: 13 July 2018 at 4:19am | IP Logged Quote rave

Geoffg wrote:
Grogster wrote:
I have had that open/close issue myself. IE: How do you know it is open or closed at a certain point. The simplest solution that others on the forums suggested to me at the time, was a flag. I used a variable such as FOF(file open flag), and just tested that before doing any closing of the port.


Or you can use ON ERROR SKIP

On Error Skip
Close #1



Makes a lot of sense. When the program terminates normally (or abnormally) you would want the file/stream to be closed and that can be easily resolved by checking the program's state depending on the program logic (e.g. using a global flag) which is better than ignoring all IO errors just to do a CLOSE #1.

Maybe I'm dumb to understand, but I don't see why one needs a CLOSE #1 before an OPEN #1. The BASIC dialects that I am familiar with close the file/stream before opening a new file/stream with the same number.

For example, SuperBASIC (used with my 2 Sinclair QLs, now collecting dust) says: "The OPEN command will close a channel which is already open with the same channel number prior to opening the new channel" http://superbasic-manual.readthedocs.io/en/latest/KeywordsO.clean.html#open

So there should not be a need to CLOSE #1 before an OPEN #1 when there is any doubt whether or not #1 is still open. Why would this be any different in MMBASIC?

- Rob
Back to Top View rave's Profile Search for other posts by rave
 


Page of 3 Next >>
In the news...
 
Post ReplyPost New Topic
Printable version Printable version
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.8
Copyright ©2001-2004 Web Wiz Guide

This page was generated in 0.1563 seconds.
Privacy Policy     Process times : 0, 0.02, 0, 0.14