![]() |
Forum Index : Microcontroller and PC projects : MMBasic for DOS. Ver 5.04 Beta
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
Phil23 Guru ![]() Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Hmmm, Think I know that scenario... That nickname still rolls off a few tongues. Similarly, A younger friend of mine; me 6, him 3 at the time, referred to his Uncle Graham as "Ucle Grum". "Grum" has stuck for almost 50 years now. Phil. |
||||
Paul_L Guru ![]() Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Geoff, did you notice the possible faults I found buried in this thread and another one. http://www.thebackshed.com/forum/forum_posts.asp?TID=9730&PN=1 1. In <PRINT #n> the tic-tac-toe "#" symbol is not optional contrary to what the manual says. <PRINT n%> seems not to work whereas <PRINT #n%> seems good. 2. The DOS interpreter now requires the full file name and the quotes as in <RUN "X.BAS"><enter>. The old one would work just by entering the file name <X><enter>. 3. Will <LOOP WHILE> as tried above work or is it just <LOOP UNTIL>? 4. <LINE INPUT> escaped from the manual leaving <LINE INPUT #n> there by its lonesome. 5. Is the use of a variable for the buffer number kosher in the file operations like PRINT #i% .... INPUT #i% .... OPEN x FOR xxx AS #i% and so forth? Paul in NY |
||||
flip Senior Member ![]() Joined: 18/07/2016 Location: AustraliaPosts: 114 |
yep it's funny how we get names...Geoff...very close...my name in dutch is flip, and a few non-dutch people called me that too when I was an ankle biter... ![]() Thanks for looking at the bugs; just noticed one more in the DOS version. I found key-presses using INKEY$ in QuickBasic very handy when doing text-mode dialogs. In MM when keys are pressed which generate compound codes [e.g. up-arrow CHR$(0) + CHR$(72) ] then the second code is delayed until the subsequent key-press...and so forth..until a key which doesn't generate a compound code is pressed...everything 'catches up'. I seem to recall this may have been an artefact of the environment you're coding the DOS version in. e.g...using following code: DO:a$=INKEY$:IF LEN(a$) THEN ? ASC(a$) ELSE a$=a$:LOOP WHILE a$<>"q" Pressing Generated Char Code ---- ---------- <UP> 0 (should have 72 as well but that appears on next key-press) <UP> 72 and 0 (previous 72 + this 0, missing next 72) <q> 72 and 113 (which is the remainder of the up arrow + q) I am keen on these features as my ultimate goal would be to use the DOS version as a shell task dispatcher / mini database / development environment for all MM-related stuff... All that said I wouldn't want in any way to distract your development work from your 'core' ![]() Regards, Phil |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Thanks, this is a documentation fault. The manual should read: "Except for PRINT, INPUT and LINE INPUT the # in #fnbr is optional and may be omitted" Yes, this was a feature inherited from the Maximite code which was the base for the old DOS version. This version uses the Micromite code base. Having said that, there should be no reason why this feature cannot be ported over... I will look into it. It should (even though it is undocumented). Are you saying that you tried it and it did not work? Thanks, another documentation failure. Yup, that should work. Geoff Geoff Graham - http://geoffg.net |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Yes, that is a bug. The argument to the SYSTEM command should be a string expression (with quotes if it is a string constant). It is fixed in Beta 4 below. Thanks Phil, that is a bad bug which also exists in the Micromite versions. I have fixed it in the DOS version posted below and will also be fixed in the next release for the Micromite. That issue and the other bugs are fixed in the attached version 5.04.05 Beta 4: 2017-07-15_143318_DOS_MMBasic_5.04.05_Beta_4.zip This version generates the following codes for special keys: ![]() The manual has been updated to reflect this and the other errors listed above. Geoff Geoff Graham - http://geoffg.net |
||||
Paul_L Guru ![]() Joined: 03/03/2016 Location: United StatesPosts: 769 |
No Geoff, I did not try it. I will however get around to it eventually. Paul in NY |
||||
flip Senior Member ![]() Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Fantastic!! ![]() Paul, I was a bit curious on those as I just assumed they'd work. The following 2 are the undocumented cases. This one was the only one I tried that never seems to test the condition: DO UNTIL {condition} (but I don't think I've ever thought of using it)... LOOP whereas DO executes the code in loop and works as expected..statements inside the loop will be executed once even if condition was false at the start...I use this one a lot but in any case we can just use NOT in front of an expression if we need to switch between WHILE and UNTIL... LOOP WHILE {condition} Many thanks again Geoff... Regards, Phil |
||||
Paul_L Guru ![]() Joined: 03/03/2016 Location: United StatesPosts: 769 |
Thanks, this is a documentation fault. The manual should read: "Except for PRINT, INPUT and LINE INPUT the # in #fnbr is optional and may be omitted" In other words, the "#" is mandatory in OPEN and CLOSE but optional in PRINT, INPUT, and LINE INPUT. Hmmmmm.... Since you will usually have only one OPEN and one CLOSE command, but many PRINT, INPUT or LINE INPUT commands during an interaction with a file, the optional status of the "#" in the OPEN and CLOSE does not seem to save much code space and makes the code more bumfuzzling. It would be OK if you made the "#" mandatory in all file commands, especially if it will save any space in the interpreter code. Yes, this was a feature inherited from the Maximite code which was the base for the old DOS version. This version uses the Micromite code base. Having said that, there should be no reason why this feature cannot be ported over... I will look into it. This is more important than it appears at first glance. Under the V4.5 interpreter if I wanted to repeatedly test a program named "Q:\somedirectory\Zingblech33_v17.bas" I would temporarily rename it "T", start the old MMBasic.exe in the Q:\somedirectory\ directory, edit the program, save it, <Alt>+<tab> to MMBasic focus and type <t><enter>, and it would run. Now I must repeatedly type <run "T.bas"><enter>, and the interpreter doesn't remember its last command and repeat it with the the old DOS <up arrow><enter> trick. This slows the cycle down a little, esp;eciallyh if youp're finishhing yoau'r eighth decazde and you CAN't TYPE SO GooD ANYMORE. If it doesn't clutter up the executable it would be nice to have <T><enter> back. And another thing .... will you please slow down, I can't keep up with your bug fixxxing cycle! And another thing .... where did you hide the donate button on your site, I don't see it! Paul in NY |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
just had a read of the manual and ran the DOS version. very cool! geoff, a few small notes: 1. page 4 of manual: "Differences to the Maximite Version of MMBasic", should be "Micromite Version". 2. when launched by dropping a .BAS file onto the injterpreter's icon, the SYSTEM command starts in "C:\Documents and Settings\admin". this does not happen if you just run the interpreter by double-clicking on the icon. i am running it under XP. 3. having the micromite's editor available (or some variation thereof) would be incredibly useful in creating an integrated environment. how difficult would this be? i do see that you can run an external DOS editor using the SYSTEM command, this would be a workable solution if the currently loaded program were saved to a temporary file before SYSTEM was called and restored upon return (say use the fixed name of MMBASIC.RAM). you'd then just need to alias EDIT to SYSTEM "my_editor MMBASIC.RAM". bearing in mind that EDIT can never be called from within a program. 4. some sort of extremely simple graphics system would also be a great addition. it need not be compatible with the existing micromite GUI commands. for instance, the following commands would be sufficient: WINDOW #nbr [[, width, height] | CLOSE ] PLOT #nbr, x, y, colour LINE #nbr, x1, y1, x2, y2, colour TEXT #nbr, x, y, colour, text$ where #nbr can specify a number of different popup graphic windows created by WINDOW. all text I/O would still go through the console window. 5. timer interrupts. as always, just some ideas! cheers, rob :-) |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Thanks for the comments Rob. In its present incarnation the DOS MMBasic cannot do graphics or editing due to the limitations of the DOS box which is strictly character mode only with no cursor positioning. If MMBasic opened a proper window then much more would be possible but that is a whole new level of complexity. Brilliant suggestion re using SYSTEM to open Notepad for EDIT. I just tried it and it works perfectly. I will put it into the next version. I'm not sure on timer interrupts. There is no I/O (at this time) so there is little point in implementing that feature. Geoff Geoff Graham - http://geoffg.net |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
the timer interrupts would largely be there to allow code to run with less alterations, although it would also facilitate writing simple games should anyone decide to do so (ie, in an educational environment). a 50mS granuality would be fine. does the DOS box not support VT100 sequences? or ansi escape codes? i'll look into finding some code for popping up windows and doing primative graphics - it is something i've considered in the past for other projects. true to the win32 API i expect it will be relatively simple in terms of the number of lines of code, but require some rather obscure incantations! btw, i'm thinking forwards into the future... imagine someone having a micromite tethered to a PC. they write some simple realtime data acquisition code in basic that runs on the micromite, sending the numeric results back cia the console. on their PC they run another mmbasic program that collects data from the comm port that is attached to the micromite, writes it (in non-realtime) to a file perhaps, and perhaps draws a graph on-screen in a popup window as the data arrives. the arduino IDE has a similar feature, where you can run two pieces of code - one piece on an attached arduino, another (a script) on your PC, with the two interacting. cheers, rob :-) |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Sorry about the duplicate post. Initially I posted this in the wrong thread, this is its proper location... Attached is an updated version: 2017-07-18_095008_DOS_MMBasic_Ver_5.04.05_Beta_5.zip In this version it is possible to edit the program from within MMBasic. The EDIT command will edit the last file supplied on the command line or used in RUN, LOAD or SAVE. When the editor is closed MMBasic will automatically reload the program from the file. If no file has been used MMBasic will create a temporary file and delete it after. By default the editor used is Notepad but another editor can be specified by setting the DOS environment variable MMEDITOR to the path of the alternative editor. Also added to this version is the SAVE command and the FILES command will now take a search specifier (ie, FILES "*.bas"). Geoff Geoff Graham - http://geoffg.net |
||||
cdeagle Senior Member ![]() Joined: 22/06/2014 Location: United StatesPosts: 265 |
Thanks Geoff for the very useful editing feature for the DOS version of MMBASIC. We used to say many years ago "real programmers use DOS and Fortran." We can now say "knowledgeable programmers use DOS and MMBASIC." David |
||||
isochronic Guru ![]() Joined: 21/01/2012 Location: AustraliaPosts: 689 |
That explains the lack of 32-bit integers ![]() ![]() ![]() ![]() ![]() |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
have done a bit of digging - getting VT-100 compatibility is indeed complicated. however, positioning the cursor and changing colour attributes is relatively simple using the win32 API calls SetConsoleCursorPosition(h, xy) and SetConsoleTextAttribute(h, at). the attached demo (source included in delphi/pascal) provides three functions: gotoXY(x, y) colour(attribute) clrscr i reckon these three functions would be a neat addition to the DOS version of mmbasic. there are also console functions in the win32 API to handle keyboard (and possibly mouse) input, but these look a little more involved. see: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx 2017-07-18_153918_project2.zip ![]() cheers, rob :-) |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Interesting. The DOS MMBasic uses the Watcom C compiler so I need to get at the API from that. I will look into it. Geoff Graham - http://geoffg.net |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
An alternative is to run MMBasic in DOSBox (http://www.dosbox.com/wiki/). This would then give you access to graphic modes. In theory it would be possible to use all the GUI/LCD commands with the right LCD driver as now is done for several LCD controllers. The source could then stay very close to the Micromite version with the bonus of being able to develop/develop GUIs on the PC. DOSBox also runs on Linux, MacOSX making available even more platforms. Microblocks. Build with logic. |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
but if the goal is to simply replicate the PIC32 version, would one then not want to also think about putting in stubs to in some way handle all the I/O? i rather like the alternative idea of DOS mmbasic being something that has it's own unique set of festures - running on a PC there are a whole swathe of applications that are out of reach of the PIC32 versions. the below .zip file contains an external program (cursor.exe) that can be called from within mmbasic to provide colour and cursor positioning. there is a demo program (colour demo hack.bas) included to show how to use it. painfully slow, but it does demonstrate the idea. 2017-07-19_060844_cursor.zip note: you can't just drop the 'colour demo hack.bas' file onto the mmbasic icon to run it, as mmbasic will start up in the wrong directory and not be able to find cursor.exe. instead you need to start mmbasic.exe, then type: load "colour demo hack" run cheers, rob :-) |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I would like the DOS version to be as close to the PIC32/and others as possible. Development of GUIs in particular. You will have a much, much faster edit/run cycle. A great addition to a DOS version would be an ability to debug it. Stepping through code is an enormous time saver. As DOSBox is also open source it would indeed be possible to add some I/O simulation, but that is a tall order an dout of the scope i think. Microblocks. Build with logic. |
||||
flip Senior Member ![]() Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Well I've been going like a rocket with this new DOS release. I find it fastest I have ever written code...By firing up MMEdit, then with code file open, and clicking on the DOS icon, it runs instantly...I can test and make corrections at the same time and fire off other instances of MMbasic if need be, whilst working on the one code file in MMEdit. Attached is my latest...including on-screen line editing...try the simple DB...add some records then try editing. Next will be a dynamic test wrapper... Edit this file is better 2017-07-19_110104_DosScreenTests.zip ..unzip to empty directory...not all of it works, but most does This is just too much fun !! Regards Phil |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |