 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 : Pushing the limits of MMBasic
Page 1 of 3   |
|||||
| Author | Message | ||||
epsilon Senior Member  Joined: 30/07/2020 Location: BelgiumPosts: 255 |
This is a continuation of the thread on MMBasic's namespace limits, as suggested by Tom: https://www.thebackshed.com/forum/ViewTopic.php?TID=13459&P=8#169096 It's perfectly possible to create a CSUB that does variable look-up for you. You call it with a string containing the variable to look up, the CSUB does a hash lookup, and returns what it found. But then you need to handle assignments too, and allocation, and arrays, integers, floats and strings, and before you know it you're recreating a Basic in a CSUB  This approach can work, but I don't think it improves the quality of the code. The preprocessor/transpiler approach also works I think, and it does improve the quality of the code, especially if it can be extended, e.g. to support macros with arguments. Thank you very much Peter! That certainly gives me enough space to make it to the release I had in mind (assuming I can resolve the performance issues I'm still facing). After that first release however, I think I'm going to take a good look at Tom's transpiler. If I can understand that tool to the point that I can make changes to it myself, I think I may switch over to that approach for pre-processing. I'll essentially get access to a whole meta-layer on top of MMBasic, which can be very powerful. Exactly, and when I start throwing 3-letter-acronyms around, I should clarify them. My bad. Epsilon CMM2 projects |
||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
If you do get to that point then be sure to give me a buzz as I'm sure we'd be better off with one "public" transpiler with two maintainers instead of two private projects each with only a single maintainer. The reasons I stopped work on it: 1) I'd solved my original problem which was being able to have a single set of source-code for Z-MIM for both CMM1 and CMM2. 2) Nobody else seemed terribly interested. 3) I began to have doubts about my choice of parser design - it's still a basically good recursive descent parser but it uses too many global variables for my liking. 4) Peter added #DEFINE to MMBasic and I wondered if this was the beginning of a wider scope of enhancements to the MMBasic preprocessing step which might make my efforts superflous. Aside: The book "Software Tools" by Kernighan & Plauger has some ideas about macro processing, and indeed much, that with time might be used to build a more fully featured operating system environment atop of MMBasic / the firmware. Yeah, sorry about that, I'm still wedded to my serial terminal. Perhaps one day I may write a VI clone ... and then learn how to use VI properly  Yes, when I get back to working on SPFORTH (crosses fingers) which is basically just one humongous CSUB I will need to petition for more C access to the API; I'm going to want MMBasic free access to the file-system if nothing else. HOWEVER I want to get to that point first so I can prove a need as it's unfair to ask Peter for enhancements, especially "controversial/edge" ones without a use-case ready to go - as I did with block comment support, though you managed to make use of that. Best wishes, Tom Edited 2021-05-20 19:44 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
Yes, of course! I prefer emacs, but it's OK, we can still be friends  If it's OK to be respectfully controversial, I think the CMM2 FW is a bit too monolithic. It would be better to have a more modular design: - An MMBasic run-time: just the language proper and a thin adaptation layer to platform services, such as console and filesystem, provided by a Kernel. - A language agnostic Kernel implementing the platform services (file system, graphics...). We already have the beginnings of this in the ARMCfunctions.h jump table. - Optional/loadable middleware components (CSUB/CFUNCTION libraries) such as 3D-engine, MATH, etc. - A pre-processor. ...Design of the C64? I have no idea what you're talking about... Edited 2021-05-20 20:15 by epsilon Epsilon CMM2 projects |
||||
jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
I have right now problem with limit of the recursion. It looks like 100 levels of recursion depth is maximum and I need hundreds up to thousands  So when I finally converted part of the algorithm from obfuscated JS, I will still need to remove recursion (probably own stack + loop)  Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Because I don't think that is likely to be a fruitful discussion I'm not going to get into that beyond asserting that the BBC Micro has a much more flexibly designed operating system than the C64 - and I'm not asserting either machine was overall "better" just commenting on the OS design. I'm hopeful with a bit of careful use-case supported persuasion and a lot of graft we *might* be able to reach a state where the CMM2 can host a good BASIC preprocessor, FORTH, assembler and maybe even some manner of "C" compiler, but I wouldn't hold out much hope of Python or Java. Anyone for LISP ? Of course it's also possible that nobody cares that much as there is a large niche of BASIC hackers and LED flashers (no disrespect intended, I know the hardware possibilities go much beyon LED flashing) that the CMM2 already serves and perhaps that is enough. Best wishes, Tom Edited 2021-05-20 20:52 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
TEGAN: Of course, if we had an index file, we could look it up in the index file under index file! What am I saying. I'm talking nonsense. NYSSA: Recursion isn't nonsense. TEGAN: Eh? NYSSA: That's and example of recursion. When procedures fall back on themselves. If you had an index file, you could look it up in the index file. TEGAN: If.....my dad used to say that "IF" was the most powerful word in the English language. NYSSA: Recursion is a powerful mathematic concept. But I don't see how it can help us now. TEGAN: "IF"... I-F! Stands for Index File! - Doctor Who, Castrovalva, Episode One. Smoke makes things work. When the smoke gets out, it stops! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
This is, indeed, pushing the CMM2 - a box designed to be a more modern version of a 1980's home computer. Is it the right approach? The SOC simply isn't designed to run a games engine, compiler, or even MMBasic for that matter. It's basically only a high-end mobile phone device. It can only drive VGA by mis-using it's on-board LCD driver. MMBasic wasn't originally designed to even approach the standard of BBC Basic either. I don't think we should be too surprised when we hit limitations. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
And this is one of the reasons I love our Kiwi and Aussie cousins, we all watched the same "bad" telly in the 80's. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Absolutely. Though given most mobile phones are running a Linux derivative I don't think the hardware is the limiting factor. A couple of blokes in sheds cannot be expected to produce a fully commercial quality computer operating system as a hobby, however what they have achieved is remarkable. Anyway, it is what it is, we have fun with it, the limitations make it interesting, so Bonzer! Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I think MMBasic is probably better than BBC Basic in many ways. However the latter sits atop of Acorn MOS which is a well thought out 8-bit operating system designed by a couple of people whom I guess were relative specialists in the field whereas I am under the impression that MMBasic doesn't really have an equivalent layer of separation between it and the hardware, or if it does it is rather more cobbled together. Anyway, it's all pretty amazing and it's not my intention to be critical or downplay the achievements of the CMM2, MMBasic, or those involved in their creation. Best wishes, Tom Edited 2021-05-20 21:17 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
From my point of view, I would like just inline assembler. Acorn Archimedes BBC Basic combined with inline ARM assembler was perfect tool. CSUB in current state are nice, but to have inline assembler, which can translate during MMBasic preprocessing ARM code of code into CSUB would be super useful. You can then use easy to use BASIC with super fast assembler and not need half-way C... I like many other languages (Forth, Python), but I think strength of CMM2 is MMBasic and not the HW. SW written in MMBasic has (at least for me) the advantage you can see/edit/reuse the source code (and the inline assembler will keep it), but already CSUB has currently disadvantage of not kept C-source (when you don't put it into comment). Also you need tool on Mac/PC side and one of main advantages (for me) is CMM2 is self containing Also more languages for CMM2 will be splitting the programmers into more ways, what I see also as disadvantage. Of course, you can then get some people who don't like the BASIC, but for me it will loose some appeal... Just my 5 cents. Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I think you mean much too low end to be in a phone :) Or can you think of a phone with this (STM32H743) chip? John Edited 2021-05-20 22:56 by JohnS |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
In the meantime, I got a chance to try this out. I get the following error when starting my program: Not enough String memory I currently have 49 #defines defined. If I replace one of the 49 #defines back to a CONST, the program works. With the previous FW revision, the program is working fine with the 49 #defines. Epsilon CMM2 projects |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
So, if someone would have a FW patch ready-to-go that would present a language agnostic platform API to the user, would it be rejected by the commmunity, and by Peter and Geoff, because the MMBASIC centricity is seen as key to the whole CMM2 experience? Btw, with kernel I don't mean an OS kernel like Linux, but a passive set of services (gfx, file system...) presented as a jump table at a fixed position in memory. Epsilon CMM2 projects |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I guess the "community" wouldn't care if the experience remained the same, i.e. boot to BASIC and existing MMBasic programs continue to run. If that wasn't the case I would suggest this is a non-starter. For Peter and Geoff, it could, if nothing else represent a maintenance headache as unless ported over it would represent a further divergence between the CMM2 firmware and that of the Armmite and Micromite series - though they seem to be pretty diverged anyway. That's still a piece of an OS kernel. On the Beeb there would be a further layer of indirection so the user could replace those services. Best wishes, Tom Edited 2021-05-21 01:44 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
@ thwill: Thanks.  Yes, I had nothing really relevant to add, but every time I hear the word 'Recursion', I always think of that Dr. Who scene! @ johns: CMM2 chip in mobile-phone - yes, I wondered that too. Never heard of a cellphone with one of those chips in it, but anything is possible I guess. @ epsilon: I don't think Geoff or Peter care what you do with the source YOURSELF, so if you wanted to rewrite MMBASIC source to support the features you wanted, I think they would be fine with that - just don't call it MMBASIC, as it would not be a supported port of the original source. As for Geoff or Peter adding that feature set, I don't see them doing that for precisely the reason that thwill stated in the post above.(maintenance headache) Not saying that they would NEVER entertain the idea, but I don't expect they would see that kind of feature as something that many others would use, and that it would deviate away from the concept of the CMM2 as being a SIMPLE retro-type computer(that stuff you're talking about is complex). We'll see if Peter or Geoff comment here on that idea, but knowing those chaps as I do, I think I can confidently say that won't happen. You'd need to make a port of MMBASIC and include that functionality yourself if you wanted it that badly. Happy to be proven wrong though.Smoke makes things work. When the smoke gets out, it stops! |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
Actually the source code license does not allow such modifications to be released. I'm allowed to make changes as long as I keep them to myself. Geoff has good reasons to do this: https://geoffg.net/OpenSource.html It allows for more complexity, but does not require it. It's an extension that was also provided by the original 80s home computers. One project I have in mind, besides a game/game-engine, is creating a programming language (even if I end up being the only user of that language). It would be so much fun to be able to do that on the CMM2, and post my progress on TBS, but if the language would have to funnel through an MMBasic layer to get to the machine, that whole idea is a non-starter. I can certainly understand that Peter or Geoff would turn down the proposal because they want the CMM2 to remain an MMBasic-only device. It would be a shame though if it gets dismissed because of practicalities such as maintenance overhead. I'd be happy to do my part, also on the FW side. Epsilon CMM2 projects |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
TBH I don't know (and care even less) what SOCs go into phones. I guessed at an overall similar standard of complexity. :) I think it's safe to say that no-one would be bothered if the system was customised. However, if it meant changes to the way that MMBasic works then it wouldn't be a CMM2 any more. IMHO much of MMBasic is largely at the "support" stage now so fundamental changes won't be made. There's too much risk of breaking earlier work now. There's no problem in adding to MMBasic by producing CSUBs, of course, that's what they are for. I've never looked at the MMBasic source. Is there an API? Edited 2021-05-21 17:52 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I'm in favour of @epsilon's suggestions, because I suspect that for SPFORTH to be anything more than a proof of concept I will ultimately need more access to the firmware service layer than the C API (ARMCFunctions.h) currently provides. There are two ways of doing this, either piecemeal by appealing to Peter as and when (which is fine, it's what I was planning on) or by seeing whether that service layer can be more formalised. Either would have to be achieved without disrupting the existing MMBasic. I also think having more people poking around in the firmware (subject to Geoff's license conditions) can only lead to a more sustainable future for the 'mite platform. Personally I don't see having language options other than MMBasic to be in conflict with the CMM2's 80's computer concept. A majority (?) of the 8-bit computers had a FORTH implementation, some had a BASIC compiler and the BBC Micro at least had two (?) implementations of Pascal, and that's without considering what was available on CP/M. I also wouldn't agree that having more languages would fragment the developer base, in my judgement a significant number of those developers who are likely to be interested in other languages on the CMM2 are the same people who in the absence of those languages would be likely to lose interest and drop off the community to pursue something else anyway. Note that I'm also working from the assumption that in the short/medium term any language other than MMBasic will be hosted by MMBasic, it will either compile to a humungous CSUB or it will be interpreted by a humungous CSUB as the firmware has no provision for direct execution of a binary. It would be good to know if there is a known practical limit to the size of a CSUB beyond the limitations of program memory. Perhaps Peter or Geoff might comment on this even if they prefer to stay schtum on the rest of this conversation ? And finally I thought I'd mention that despite working on an implementation I'm not a FORTH evangelist, I've only been looking at it for 3 months and I can't program in it for toffee. My interest in bringing it to the CMM2 is: 1) I know enough history to know it is 80's era appropriate. 2) As languages go it's easy to implement. 3) It's a high(ish) level language with the potential to be faster than MMBasic. 4) It's sufficiently different from BASIC to be an interesting alternative. Best wishes, Tom Edited 2021-05-21 19:05 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Maybe use one of the existing "byte code" or the like virtual machines to make a CSUB. Any of LLVM, Dalvik (or its successor) or, well there are soooo many to choose from. Perhaps the binary (well, hex sort of) CSUB could be released without infringing Geoff's / Peter's copyrights. (I'm trying to figure a way to avoid restructuring MMBasic itself to have an OS layer, which seems unlikely to be allowed by Geoff/Peter.) John |
||||
| Page 1 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
