 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 : CMM2: Possible to sequentially run a series of programs?
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi folks, I think I know the answer to this question (i.e. "It's not possible"), but I'm hoping I'm wrong. I want to be able to run a series of programs "test1.bas", "test2.bas", "test3.bas", ... in sequence with a single command, or by running a single program that launches them in sequence. Is this possible on the CMM2 / in MMBasic ? or is there just not enough operating system present to handle it unless each of "testX.bas" is written to explicitly launch its successor upon completion using EXECUTE. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Tom, Its easy on MM-DOS, for CMM2, an idea I can think of is to create a file as follows (Assuming size is not a problem, and they all end by 'falling through') Something like INCLUDE "TEST1.BAS" CLEAR INCLUDE "TEST2.BAS" CLEAR INCLUDE "TEST3.BAS" EDIT: There are many other caveats I can think of...Not using Same Procedure names, Labels: (e.g. RESTORE to same label....etc,etc depends how much 'control' you have over the contents of the files. Regards Phil Edited 2020-07-18 19:54 by flip |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi Phil, I suspect there are other issues, but: 1) You can't #Include a .bas file, only a .inc file. 2) If you could include a .bas file and that file used #Include itself then it wouldn't work because only a single-level of hierarchy is supported - though my transpiler (which is what the unit-tests are for) does support/flattent up to 5 levels of #Include. 3) EDIT: Also CLEAR only removes variables so you would need to be sure you didn't have any duplicate sub/function names in the files ... which ultimately kills this as an idea. Thanks, Tom Edited 2020-07-18 20:03 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| MikoKisai Newbie  Joined: 10/07/2020 Location: GermanyPosts: 6 |
If having each program be aware of its successor is too inflexible for you, you could consider having them all be aware of a *single* program that keeps track of how far it got somehow (e.g. by writing an index to a file). Example code I hastily threw together (tested with MM-DOS, several things could be improved on the CMM2): REM List of files you want to run DIM f$(2) = ("a.bas", "b.bas") curIndex = 0 REM Use some file name that doesn't exist before you run this ON ERROR SKIP 3 OPEN "test.txt" FOR INPUT AS 1 INPUT #1, curIndex CLOSE #1 ON ERROR ABORT IF curIndex < 2 THEN nextFile$ = f$(curIndex) curIndex = curIndex + 1 OPEN "test.txt" FOR OUTPUT AS 1 PRINT #1, curIndex CLOSE #1 RUN nextFile$ ENDIF KILL "test.txt" PRINT "Autotesting done." And then each program would look something like this: PRINT "This is program A" RUN "autotest.bas" On the CMM2, you could probably avoid the file I/O by using the RUN command's ability to set the command line and then have each file use a specific argument to tell the main program where it is in the sequence (such as the file name?), but AFAICT that won't work on (the current release of) MM-DOS. You could even send a specific command-line into each test program and check for this to still allow running the programs individually. |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi "MikoKisai", After posting I came up with pretty much an identical scheme that I was going to build into into my unit-testing framework ... though given there is no completely generic way I will probably roll-back on my previous requirement of not having each program being aware of its successor. Instead each program will #Include the same file listing all the test files in the suite and by looking up its own name in the list it will be able to see which file should be executed next. However this then made me worry about the endurance of the onboard Flash; which was already an issue of concern to me. So I've put this on the back-burner whilst we see what magic "matherp" can work. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Maybe Peter's OPTION FLASH / RAM is what you want. John |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Ummm ... Yes John, that's why *I* started that thread  I'm just hoping that Peter can resolve the CSub issue so that we don't have to choose between the two. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I understood you do not use CSubs and so that puzzled me as to why you don't use OPTION RAM? John Edited 2020-07-23 03:22 by JohnS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
That is correct. I guess (1) I've also been otherwise occupied with getting my transpiler to a beta state, and (2) I was also waiting to see whether it was an experimental feature that "sticks" before I invest in a development that depends on it. It would be a real stinker if we have to choose between CSubs and running from RAM or expect users to switch between the two. Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Current status is that CSUBS don't and won't run from RAM. Appears to be a "too big address change" issue for the way the compiler generates instructions for position independent code. The instructions loaded to RAM are identical to the FLASH version except for the start address which is correct in both cases |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi Peter, Is it that the interpreter can't call the CSub in RAM or (as someone suggested earlier) that the CSub can't call back into the routines in the firmware? Either way is the issue that the jump is relative and there is a limit on the size of the offset allowed for a relative jump? Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
No idea and not going to investigate futher. Feel free to explore the myriad GCC compiler options that may impact |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
At least for the moment that is rather above my pay grade, but thanks for the offer If this is the only issue then can we please keep RAM as an option? Would it be possible for the 'terp to produce a friendly error message and exit if it encounters a CSub whilst running from RAM? Can we have a mechanism to determine if we are running in FLASH or RAM ... is that already possible with Mm.Info(Program) ? Thanks for all your efforts, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
