 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 4 of 5   |
|||||
| Author | Message | ||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Thanks Phil, that makes sense. I will fix it. Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5905 |
I haven't been able to reproduce the error. I tried rebooting windows with the USB adapter left plugged in and with it plugged in after rebooting. The serial port code worked first time with both scenarios. Windows 10 with a Silicon Labs adapter. I will try with a microbridge next. Jim Edit: No problems talking to a MMX so have trouble blaming the adapter. The code I use for testing is Open "COM6: baud=38400" As #5 Print #5, "print mm.ver" Pause 100 dat$ = Input$(20, #5) Print dat$ Close #5 You need the pause 100 Jim VK7JH MMedit  MMBasic Help |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Thanks Jim! I had thought you'd put some 'magic' in your code...(and was fishing for it  ...but as usual I was off-track - it's finally clicked...When I installed MMEDIT, I had to get my son's permission(!) as he owned the laptop at the time. I have since taken it over from him - at the great expense of providing him a better one  ...but I digress...When I run MMBasic for DOS, it runs as my non-Admin user. When I run MMEDIT (or any program installed as Admin which uses a serial port) as a non-Admin user it seems to permanently set a flip-flop to allow the serial port to work correctly there-afterwards So it's a rights issue over the serial ports (for me at least)...hope this helps someone... May need to go in the 'MMBasic technical reference manual'...which leads me to another point... IF no-one is doing this AND Geoff agrees, I would like (with Geoff's permission /content vet of course) to help compile a public list of features/specs/limitations/design decisions/alternative ways of doing things with examples...(i.e. stuff that would bloat the manual, but is helpful for those head-banging moments)..I was even thinking of a small MMBasic library program to use keywords to drive a large reference database sitting on an SD card or DOS file...may regret this offer but right now it seems like an exciting challenge. Regards, Phil |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Go for it Phil. It does sound like a big job. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Attached is Beta 7 of the DOS version of MMBasic. 2017-08-22_072750_DOS_MMBasic_5.04.05_Beta_7.zip This fixes all reported issues: - The EOF() and LOF() functions now work as expected on serial ports. - The COLOUR command is reinstated and works as it should. - MM.HRES and MM.VRES now report the correct values. - The EDIT, WEDIT, SAVE and LIST commands no longer "eat" empty lines. - The NEW command will cause the current program file name to be "forgotten" . - The EDIT command will prompt for a file name when saving if there is not a current file. - The file name in the title bar of the console windows is now updated correctly. I tried sending the text output to stdout but it got too complicated. The way MMBasic is implemented (with EDIT, the command prompt, etc) it is not a straight scripting language and does not lend itself to redirecting the input or output. I will however have another shot at it later as it would be a handy feature. Another "feature" that I have left for later is using a Windows file selector dialog box for some functions. Finally, I have discovered that Windows is not buffering the serial output (it does buffer input). Therefore LOF() for serial output will always return zero. Buffered output can be implemented but the way that Windows does it is quite complicated and I'm not sure that it is worth the issues that it brings. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
hi geoff, you've produced another great accomplishment  there does seem to be a small problem with the files command: DOS MMBasic Ver 5.04.05 Beta 7 Copyright 2011-2017 Geoff Graham > files "*.z" Volume in drive C is OS Volume Serial Number is 3E75-E877 Directory of C:\Documents and Settings\admin firmware\DOS version File Not Found Error: Error running DIR > i would have thought finding no files should not generate an error message. i've been doing quite a bit of experimenting with using just stdin and stdout, microsoft certainly don't make it easy to do anything interactive without having to go to the console's win32 API. the only elegant solution i've had much success with is creating a separate thread to handle stdin. see the attached example (delphi/pascal source and a compiled .exe) it just echos keypresses back, while at the same time maintaining a 'spinning' cursor: 2017-08-24_080027_test_with_thread.zip after a character is read, the 2nd thread sits in a tight loop until the main thread uses the character (it really should be placed in a queue), then blocks at the next read from stdin until a key is pressed. meanwhile, the main thread freely animates the cursor. just an idea: have you though of a commandline switch, such as "/C" to switch between interactive and console modes? if /C is specified then the editor would be disabled, along with any calls to the console API, leaving just standard reads and writes to deal with. this may make the whole process much easier to achieve. cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
That sounds quite workable. Error messages could go to stderr. Thanks, I will explore in that direction. Geoff Graham - http://geoffg.net |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, Thanks for your great work on this. Just one small issue, on big screens, MM.VRES and MM.HRES report correctly up to 255 but then roll around to 0. Also on this theme, there is a POS command for horizontal position (which does work over 255). Is there or if not would it be easy to provide a function that returns vertical position? It would be nice to save and restore current screen position during a subroutine call. EDIT Another request (may apply to uM?) Can the String$ function be altered to work with any integer 0-255? It currently reports Error: xxx is invalid (valid is 32 to 126) When using an Integer as the second parameter (works fine with a string constant as second parameter) So it can work with data other than Ascii strings. > ? String$(10,255) Error: 255 is invalid (valid is 32 to 126) > ? String$(10,Chr$(255)) > ? String$(10,65) AAAAAAAAAA > Regards, Phil |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Are you talking about the DOS version? That would be a very big screen that is more than 255 characters wide. I will look into a function that returns the current cursor position. Thanks for the note on STRING$() I will fix it in the next version. Geoff Geoff Graham - http://geoffg.net |
||||
darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240 |
Hi Phil , note that character table (32 to 126) are the ascii code we normaky use , over 126 (127 to 255) they are special charracters (1 to 31 too), chr$(under 32 and over 126) clean probably the wrong values (i don't have look the source since ages ;) ) Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, Yes, I tried it on a 4k monitor (ACER UHD4K2K great for programming at $499)- so with standard Windows font (12 pixels wide) it happens. Also, it could be useful if anyone wants to go completely nuts and use small characters (e.g. 4x6) to generate individually coloured pixels (960x360 on UHD) Hi Darthmite, Chr$(0) thru Chr$(255) are all valid string character values. I just think of STRING type as a list of 8-bit bytes, [with a length byte (0-255) in front]...not necessarily used for Ascii purposes...the less restrictions, the more opportunities to create! (or go nuts  )Regards, Phil |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
+1 |
||||
| darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240 |
And another +1 Is just that the character table on Maximite dont go that far. Here the example for US Layout (on stm32 version) ... The 1st generation of PIC32 was not like the one we got now , Geoff probably try to limit the use of the flash to what really was needed at this time // US Layout (QWERTY) { 0, 0, 0, 0, 'a', 'b', 'c', 'd', 'e', 'f', // 0- 9 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', // 10- 19 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', // 20- 29 '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', // 30- 39 ENTER, ESC, BKSP, TAB, ' ', '-', '=', '[', ']', '\\', // 40- 49 0, ';', '\'', 0, ',', '.', '/', 0, F1, F2, // 50- 59 F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, // 60- 69 0, 0, 0, INSERT, HOME, PUP, DEL, END, PDOWN, RIGHT, // 70- 79 LEFT, DOWN, UP, 0, 0, 0, 0, 0, 0, 0, // 80- 89 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 90- 99 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 100-109 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 110-119 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 // 120-129 }, Cheers. Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| Peter63 Newbie  Joined: 28/07/2017 Location: SwedenPosts: 14 |
2017-09-01_213051_MMBasic_DOS_5_4_Quick_Guide.zip I wrote this, a summary of commands and fuctions. Peter |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, Just a little bug when using calculation in the first parameter of the INPUT$ command: Open "~tmp.txt" For Output As #1 Regards Phil Print #1, "Hellothereeveryone" Close #1 strt=6 : fnsh=11 : lngth=fnsh-strt Open "~tmp.txt" For Random As #1 Seek #1, strt Print Input$(lngth, #1) '(prints: there) Seek #1, strt Print Input$(fnsh-strt, #1) Error: Internal fault (sorry) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Good one Phil, your test program was a huge help in finding it - thanks. I will fix it in the next release. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Thanks Rob, that one will be fixed in the next release also. Geoff Geoff Graham - http://geoffg.net |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, all, Still having great fun with this. 1. Geoff wrote: I won't need any more in my programs, so leave it to you whether to pursue. (anyone else who needs it please leap in!!) 2. A really minor thing is that the Windows title bar doesn't restore when returning from a 'System' command.(can be seen in Builder test program attached). This is really only a 'nice-to-have'.[EDIT 15/9: There is the SETTITLE command which gives us more control anyway - I forgot about this - Geoff has the bases covered  ]3. Attached is a Builder demo as part of Character-based GUI/IDE I'm working on. It generates and runs a HELLO.BAS program then returns. Hope it inspires others with what is possible ! 2017-09-13_224727_BuilderH.zip EDIT: Thought about it driving to work and realised this (very basic Builder version)will rely on MMBASIC.EXE being the default program that Windows will run when presented with a '.BAS' file. In all other respects it will build, and you will be able to run the produced HELLO.BAS program separately. EDIT2: Sorry I was too quick...attached version BuilderI.BAS 2017-09-14_053329_BuilderI.zip should work correctly if MMBASIC.EXE is placed in same directory as the unzipped BuilderI attached OR MMBASIC.EXE is in your Windows PATH environment variable. Regards, Phil |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, This bug is very tiny, a SUB or FUNCTION in first line is not recognised by the interpreter. Threw me for a little while when testing updates to my app builder program. Super easy to work-around seems to be just put anything, apostrophe, empty line, whatever on first line of the program. > LIST Sub SayHelloTo(name$) Print "Hello, ";name$ End Sub SayHelloTo "Al" > RUN [4] SayHelloTo "Al" Error: Unknown command > Regards, Phil |
||||
| Peter63 Newbie Joined: 28/07/2017 Location: SwedenPosts: 14 |
Hi Geoffg, all, I missed a way to send in a default string to input -command? s$="default string" input"Default string to be edit or not";s$ print s$ Any trix or fix? |
||||
| Page 4 of 5 |
|||||
 Print this page |
