 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MMBasic for DOS Beta 6
Page 1 of 5   |
|||||
| Author | Message | ||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I have a new beta version of MMBasic for DOS: 2017-07-28_133706_DOS_MMBasic_5.04.05_Beta_6.zip I thought it worth starting a new thread because there has been so many changes since the previous beta. A lot of them come from Rob's research showing how you can get to the Windows API from the Watcom compiler (thanks Rob). In summary the new features are: • The CURSOR command allows you to move the cursor around the screen. • With the COLOUR command you can select the foreground and background colours. • The read only variables MM.VRES and MM.HRES will return the size of the window (in characters). You can drag the window boundaries and these will dynamically update. • The EDIT command will now run the MMBasic editor (same as on the Micromite). This has colour coded output and you can customise the colours. • You can still use an external Windows editor - the command is now WEDIT. • To keep Rob happy you can set the starting directory for MMBasic by setting the DOS environment variable MMDIR to the directory you want to use. • The command SETTITLE can be used to change the title in the console window's title bar. • The read only variable MM.CMDLINE$ will return the DOS command line used to start MMBasic. • If MMBasic is started without a program on the command line it will attempt to load a file called autoexec.bas in the startup directory or the root of the C: drive. And last but not least, you can access serial COM ports on the PC including virtual ports created by USB/serial converters. The syntax is almost the same as the Micromite. For example: OPEN "COM12: baud=38400" AS #5 ‘ open COM12 with a speed of 38400 baud PRINT #5, "Hello" ‘ send the string "Hello" out of the serial port dat$ = INPUT$(20, #5) ‘ get up to 20 characters from the serial port CLOSE #5 ‘ close the serial port I have used this to remotely control a Micromite and it works well. The only hiccup is that a few times I needed to access the port using Tera Term first - I will be interested on the experience of others. The manual has been extensively updated so it would be worth another read through. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
the following should work, but alas does not: S$=MM.CmdLine$ Print S$ If S$<>"" Then Do found = (Right$(S$,1)="\") Or (Right$(S$,1)=":") S$=Left$(S$,Len(S$)-1) Loop Until found Or S$="" If Left$(S$,1)=Chr$(34) Then S$=S$+Chr$(34) Print S$ If found Then Chdir S$ EndIf > > run C:\Documents and Settings\admin "C:\Documents and Settings\admin\My Documents\Downloads\MMbasic\5.x firmware\DOS version\test2.bas" "C:\Documents and Settings\admin\My Documents\Downloads\MMbasic\5.x firmware\DOS version" [14] If found Then Chdir S$ Error: No such file or directory > > the above code is intended to fix the startup directory being set wrong. looks like the problem is chdir does not accept long filenames. also (and somewhat worse) the internal editor saves to the wrong place too! PLEASE, PLEASE, PLEASE, add the simple bit of code i posted to set the current directory to always be the location of the .bas file upon starting mmbasic. AND, also please ensure that once started the internal editor ignores changes to the current directory setting when loading and saving! if i run the above program by dropping it onto mmbasic, then type save "test" the file is saved to "C:\Documents and Settings\admin\test.bas". this is entirely confusing and bizarre behaviour. the mmbasic IDE should maintain it's own load/save location independently to the current directory set by a running program. cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
From a quick glance it appears that you have spaces in the directory path and I bet that is the problem. This is something internal to Windows and I am not sure there is an answer. Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5918 |
Rob, Try adding quotes around the path. If found Then Chdir CHR$(34)+S$+CHR$(34) Jim VK7JH MMedit  MMBasic Help |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
there are already quotes there, see the lines printed out from the above: "C:\Documents and Settings\admin\My Documents\Downloads\MMbasic\5.x firmware\DOS version\test2.bas" "C:\Documents and Settings\admin\My Documents\Downloads\MMbasic\5.x firmware\DOS version" geoff: how are you implementing chdir? the function SetCurrentDirectory supports long file names, all i can guess is that you're using a library supplied by the watcom C compiler that uses the older pre-LFN API calls. the likes of SetCurrentDirectory are supported from XP onwards, which does break win2K and 95/98. if you wanted to support win2K and 95/98 you'd need to detect the OS version and adapt accordingly - probably not worth the effort these days. have you considered changing over to using minGW? this is what i used for pic32prog. there is also the deeper philosophical issue of separating the behaviour of the IDE from the behaviour of the running mmbasic program - this is a problem unique to the win32 and RPi versions of mmbasic. as a scripting language i strongly feel that while the IDE and user program should start out operating in the same current directories, changes by the user program should not affect where the IDE loads/saves from. cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Rob, Beta 6 has no problem with spaces or long paths:  MMBasic is a programming language. So if there is to be a conflict with the "IDE" the programming aspect will take precedence. Neither should it act differently for different commands or at the command prompt. Geoff Geoff Graham - http://geoffg.net |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5918 |
Rob, Apologies for posting before reading (and thinking). Have you tried 'removing' the quotes? If Left$(S$,1)=Chr$(34) Then S$=MID$(S$,2) I don't have XP to test it with but works on W10 Jim VK7JH MMedit  MMBasic Help |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
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. the following code now appears to work, and should be placed at the start of all programs that access files in order to ensure the current directory is set correctly at program startup - ie, is set to the same location as your .bas file: S$=MM.CmdLine$ If S$<>"" Then ' S$=ExpandFileName(S$) ' needed to make bulletproof Do found = (Right$(S$,1)="\") Or (Right$(S$,1)=":") S$=Left$(S$,Len(S$)-1) Loop Until found Or S$="" If Left$(S$,1)=Chr$(34) Then S$=Mid$(S$,2) If found Then Chdir S$ EndIf the windows version of mmbasic is now an IDE as well as just a programming language, and so without providing a clear line between the two functions users will get tripped up, and people will ask "what happened to the program i just saved, it just disappeared?". i'm afraid the environment variable MMDIR is a patch that just adds another layer of confusion, while the basic solution above is an inelegant hack. for the moment i'll stick to using drop here.exe and avoid chdir$ et al like the plague. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
the problem (well, part of the problem) is not specific to any version of windows, but specific to how any version of windows has been set up. when you drop a file onto an (executable) icon, the shell goes through a series of steps to determine how to proceed, the route taken depending (as far as i can tell) upon the permissions and security settings currently in force. so two machines running the exact same versions of windows may behave differently. it is a right mess, but very few folks encounter the problem as programmers code around the issue when it affects their program. cheers, rob :-) |
||||
KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1392 |
Geoff - A BIG thank you for the additions and changes, most are exactly what I had been hoping for. Mike. It's all too hard. Mike. |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1099 |
Rob/Geoff, The issue appears to be with the quotes when using chdir with a string variable as the argument. The following code runs correctly on my Win 7 Pro machine with 5.04.05 beta 6 S$=MM.CmdLine$ Print S$ If S$<>"" Then Do found = (Right$(S$,1)="\" Or Right$(S$,1)=":") S$=Left$(S$,Len(S$)-1) Loop Until found Or S$="" ' Comment out add quote to end and strip quotes from front and back ' If Left$(S$,1)=Chr$(34) Then S$=S$+Chr$(34) If Left$(S$,1)=Chr$(34) Then S$=Right$(S$,Len(S$)-1) If Right$(S$,1)=Chr$(34) Then S$=Left$(S$,1),Len(S$)-1) Print S$ If found Then Chdir S$ EndIf EndIf 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. Doug. Edit: This appears to be true for all the files related commands eg. FILES etc. D. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi all All looking very promising! and I'm eager to get into it !! Geoff, with beta 6 I am still getting the same failure (as per my post on previous MM DOS thread - perhaps missed or I didn't write it up very well)......I thought I'd write an exhaustive bit of code, that would show the bug better (my previous post would not have generated the error unless run twice  )...anyway can someone test/confirm/discuss/otherwise whether the following is a bug? (refer quote above for a description of the suspected bug)[EDIT: I am running Windows 10][Edit: code below updated 18:41 AEST DIM AS STRING Test_File="~~..ZXZ.~~" DIM AS INTEGER iMMERR DIM AS STRING sMMERR DIM i% DIM q$ ? " Test of Error codes MM.ERRNO and MM.ERRMSG$ failing to be reset to 0" ? " after a successful command" ? " Bug apparent in 5.04.05 Beta 5 & Beta 6" ? " Bug not present in previous versions." ? ' Following section is just to guarantee the test is safe and repeatable ON ERROR SKIP SYSTEM "DIR "+ Test_File IF MM.ERRNO=0 THEN ? "program assumes the file exists...About to delete ";Test_File; INPUT "...continue?? (Y/N)";q$ IF UCASE$(q$)<>"Y" THEN ? "Can't proceed with this bug test" END ENDIF ENDIF ON ERROR SKIP KILL Test_File ? ? "Nothing above this line is relating to the Error codes not being reset" ? FOR i%=1 to 2 ON ERROR SKIP 2 CLOSE #1 OPEN Test_File FOR RANDOM AS #1 iMMERR=MM.ERRNO:sMMERR=MM.ERRMSG$ SELECT CASE iMMERR CASE 0: ? "opened OK..."; CASE 1: ? "Creating New file..."; CASE ELSE: ? "Failed to open ";Test_File;": ";sMMERR;"(Err#";iMMERR;")" ? "This message never happens for MM DOS versions 5.04.05 beta 4 or less" ? " NOTE the error is to do with the CLOSE command, not the OPEN command" END END SELECT ON ERROR SKIP CLOSE #1 ? " ...and closed" NEXT i% ON ERROR SKIP KILL Test_File ? " ...and deleted Test_File";Test_File Regards, Phil |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
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 Geoff Graham - http://geoffg.net |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
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 |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
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. 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 Geoff Graham - http://geoffg.net |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1392 |
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. It's all too hard. Mike. |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
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 |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1392 |
Yes I also noticed LOC() missing for serial, manual seems to indicate that as well. It's all too hard. Mike. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
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 :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
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$(). 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 Geoff Graham - http://geoffg.net |
||||
| Page 1 of 5 |
|||||
 Print this page |
