Home  |  Contents 
Microcontroller and PC projects
  Forum Index : Microcontroller and PC projects         Section
Subject Topic: MMBasic for DOS Beta 6 Post ReplyPost New Topic
<< Prev Page of 8 Next >>
Author
Message << Prev Topic | Next Topic >>
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2117
Posted: 29 July 2017 at 8:58am | IP Logged Quote Geoffg

No, it is not a bug. As per the manual MM.ERRNO is only reset to zero by ON ERROR CLEAR. It is also cleared by RUN, NEW, ON ERROR IGNORE and ON ERROR SKIP.

You cannot have it reset to zero on every command that is executed because it might take one or more commands before you are able to test MM.ERRNO and by then it would have been reset. So, you need to clear it yourself in your error handler.

Geoff


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


Joined: 18 July 2016
Location: Australia
Online Status: Offline
Posts: 56
Posted: 29 July 2017 at 9:06am | IP Logged Quote flip

Thanks Geoff! - I misunderstood this point - that's excellent and will mean not needing to save error values, just query and reset wherever needed...brilliant and elegant.

Regards,
Phil
Back to Top View flip's Profile Search for other posts by flip
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2117
Posted: 29 July 2017 at 9:23am | IP Logged Quote Geoffg

robert.rozee wrote:
might have found one of the problems: it looks like chdir$ internally provides quote marks at begining and end of the supplied string, so the string should NOT already have the quote marks present.

chdir$ does not add quotes, it just takes the string as presented (with spaces, etc) and changes to that directory. If you add quotes you are adding illegal characters to the directory path.

panky wrote:
It appears that chdir will only accept quoted text as an argument directly and ONLY non-quoted text when a string variable is the argument. Edit: This appears to be true for all the files related commands eg. FILES etc.

BASIC requires quotes around string constants but they are not part of the string - they just tell the interpreter that the enclosed text is a string. For example A$ = "C:\temp" sets A$ to C:\temp not "C:\temp".

All file related commands use strings without embedded quotes. The following are the same:
CHDIR "C:\temp"
and
A$ = "C:\temp" : CHDIR A$

Geoff
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
KeepIS
Regular Member
Regular Member
Avatar

Joined: 13 October 2014
Location: Australia
Online Status: Offline
Posts: 81
Posted: 29 July 2017 at 9:37am | IP Logged Quote KeepIS

I do have a question about the Serial Port addition.

I've been testing code that runs fine on the E-100, it sends a string 26 bytes long.

I can loop back on a single port and it works fine in MMBasic.

However if I use a Radio link - I get a consistent but totally incorrect response.

On the radio link I can't even get one char to send and receive correctly - it sends the char but the received char is incorrect and always the same incorrect value for a given char.

If I send the same string or char via exactly the same ports and link on a simple Windows .NET application then it's perfect - same ports, same radio link path.

Really strange as cut it back to the simplest code.

Open "COM10: baud=9600" As #1
Print #1, Chr$(&h42);

Works fine in the E-100, Win10 .net program and ONLY in MMbasic If the radio path is removed and using a loop back on the port (which means I modified the code to send and receive over the same port in MMbasic DOS)

Hope this makes sense - it's not important right now but interesting nonetheless.

Almost like a baud rate timing issue? Anyone got any ideas?

I know it's not the easiest thing to test unless you have a couple of link transceivers ready to go. Maybe something for down the track when everything settles down with the new version.



Edited by KeepIS on 29 July 2017 at 9:39am


__________________
It's all too hard.
Back to Top View KeepIS's Profile Search for other posts by KeepIS
 
flip
Regular Member
Regular Member


Joined: 18 July 2016
Location: Australia
Online Status: Offline
Posts: 56
Posted: 29 July 2017 at 9:44am | IP Logged Quote flip

Hi Geoff,
Amazing - talking to the uMite and it works!!

One little thing is the LOC() function doesn't seem to work for serial port...this would be handy to know characters in receive buffer.
...still testing
Regards,
Phil

Edited by flip on 29 July 2017 at 9:55am
Back to Top View flip's Profile Search for other posts by flip
 
KeepIS
Regular Member
Regular Member
Avatar

Joined: 13 October 2014
Location: Australia
Online Status: Offline
Posts: 81
Posted: 29 July 2017 at 10:18am | IP Logged Quote KeepIS

Yes I also noticed LOC() missing for serial, manual seems to indicate that as well.



__________________
It's all too hard.
Back to Top View KeepIS's Profile Search for other posts by KeepIS
 
robert.rozee
Guru
Guru


Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 1140
Posted: 29 July 2017 at 10:22am | IP Logged Quote robert.rozee

Geoffg wrote:

chdir$ does not add quotes, it just takes the string as presented (with spaces, etc) and changes to that directory. If you add quotes you are adding illegal characters to the directory path.


my mistake there, getting confused between all the quote mark rules! for the benefit of others: LFNs (long file names) passed as parameters on the windows commandline require quote marks around them. so at the console prompt you'd need to type:
cd "C:\Program Files"
in order to indicate that you are just passing a single parameter to cd, a parameter that contains a space.

the string MM.CmdLine$ potentially contains quote marks at the beginning and end, placed there by windows. if you are doing something with it that involves the SYSTEM command, then these enclosing quote marks usually need to be maintained. if you are using it with a command internal to mmbasic (such as chdir$) then these quote marks need to be stripped out.

in all of the above i am NOT talking about the quote marks used to delimit a string literal. it just happens that both windows and mmbasic use the same character (") as a means of enclosing strings. in the case of windows this is done purely to allow the string to contain space characters without creating confusion.


cheers,
rob :-)
Back to Top View robert.rozee's Profile Search for other posts by robert.rozee
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2117
Posted: 29 July 2017 at 12:08pm | IP Logged Quote Geoffg

KeepIS wrote:
On the radio link I can't even get one char to send and receive correctly

This could be due to the buffering that Windows does. Went you PRINT something to the serial port Windows places it in a buffer to be sent as time permits and then returns immediately so that the program can continue. If your next command is an INPUT$() the string might still be in the process of being sent by the Windows O/S.

Try a PAUSE of a few hundred milliseconds between the PRINT and INPUT$().

flip wrote:
One little thing is the LOC() function doesn't seem to work for serial port...this would be handy to know characters in receive buffer.

LOC() is not implemented for Serial I/O. This info is buried somewhere in the Windows subsystems, I will go exploring and see if I can find it. The last time I wrote code for Windows was years ago and I had forgotten what a complicated and unorganised beast it is!

Geoff
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
flip
Regular Member
Regular Member


Joined: 18 July 2016
Location: Australia
Online Status: Offline
Posts: 56
Posted: 29 July 2017 at 1:11pm | IP Logged Quote flip

Quote:
LOC() is not implemented for Serial I/O
Please don't worry on my account...after tinkering I'm now sorry I mentioned it and thinking about it it's not really needed anyway.. MMBasic for DOS would generally be so much faster than whatever you're connected to, it may be simpler to leave Windows to handle buffering, and we just skim off what we need until its empty (or our program decides it's had enough)

Regards,
Phil
Back to Top View flip's Profile Search for other posts by flip
 
KeepIS
Regular Member
Regular Member
Avatar

Joined: 13 October 2014
Location: Australia
Online Status: Offline
Posts: 81
Posted: 29 July 2017 at 10:45pm | IP Logged Quote KeepIS

Sorry for this longish rambling post:

Geoffg wrote:

Try a PAUSE of a few hundred milliseconds between the PRINT and INPUT$().
Geoff


I had already done that and about everything I could think of.

Now before I posted, I made sure to run simple code of sending only one byte from MMBasic and receiving that one Byte on a separate Windows terminal application.

1: TX 1 Byte from MMBasic over COM8.

2: RX 1 Byte from COM10 using a Win terminal application.

Always the wrong value received.

1: TX 1 Byte from a another Win app over COM8.

2: RX 1 Byte from COM10 using same Win app as with MMbasic test.

Correct data received.

I even rebooted the PC three times over the day trying to fault find.

This morning I RESUME the PC (from last night session).

Press run - the CORRECT char is returned!!! seriously ???

Load the full E-100 code and transmit 32 bytes out one port and receive it over the 2nd port in the same code - no delays and 100% every time. WTH?

This is not user error as everything was as I left it last night - nothing touched, no cables moved - press on button - press run and it worked.

I'm taking up basket weaving.

Edited by KeepIS on 29 July 2017 at 10:46pm


__________________
It's all too hard.
Back to Top View KeepIS's Profile Search for other posts by KeepIS
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2117
Posted: 30 July 2017 at 3:18am | IP Logged Quote Geoffg

Your experience shows why this joke could actually be true...

Quote:
An mechanical engineer, physicist, and computer programmer are in a car driving down a steep mountain when the brakes fail. The careens around bends picking up speed until they finally reach the bottom and the car rolls to a stop.

The engineer hops out of the car and begins inspecting the brakes for the source of the failure. The physicist grabs a pad of paper and starts calculating the maximum angular momentum and friction coefficients.

The computer programmer looks at the car, then at the mountain and says, "let's push it up to the top and see if it happens again."

Geoff
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
KeepIS
Regular Member
Regular Member
Avatar

Joined: 13 October 2014
Location: Australia
Online Status: Offline
Posts: 81
Posted: 30 July 2017 at 4:04am | IP Logged Quote KeepIS

So true, but the good thing is that DOS MMBasic is now working perfectly on the COM ports, I've done everything to try and replicate the fault but to no avail, which irks me on some level.





Edited by KeepIS on 30 July 2017 at 4:17am


__________________
It's all too hard.
Back to Top View KeepIS's Profile Search for other posts by KeepIS
 


<< Prev Page of 8 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.0938 seconds.
Privacy Policy     Process times : 0.02, 0, 0, 0.08