 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 2 of 3   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
The traditional way to load special programs in the 80s was to load a little BASIC program and one or more machine code blocks. RUN then transferred to the machine code. That would fit in with the ethics of the current system nicely. lol It would be useful to have access to the keyboard, screen and storage drivers though. There is a problem with the display system in that it's probably heavily optimised for speed now and parts of it might be in a state of flux! There may not be any fixed addresses for the routines yet. Many moons ago "proper" computers usually had a monitor program in ROM that would handle basic keyboard and text screen access as well as a serial port for tape save/load. After the Camputers Lynx I don't think any home computer had one, which is rather sad really. They were the forerunner of the OS, but much smaller. 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 may be talking bo**ocks but I believe from previous discussion that this is impossible for the CMM2 as it has a Harvard-like memory architecture instead of the more typical von-Neumann architecture. Basically you can only execute code from the Program memory (the "Flash", though it can be RAM) and not from the Variable memory. To put it another way if you could compile machine code and store it in Variable RAM (e.g. in a big array like on actual 8-bit computers) you couldn't transfer the program counter to it. I don't know if this is a limitation of using a SOC micro-controller, a limitation of the firmware, or a limitation of imagination. Best wishes, Tom Edited 2021-05-21 20:02 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
For me this is the most important point. Until I still have MMBasic waiting for me after CMM2 start, I don't have any issue with some extensions/more languages... Maybe can be enough just to have one more MMBasic command: CALL arm_subroutine_address% (reg1, reg2...regN) Then will be enough to translate any your wish into Thumb/2 code, load it with MMBasic and the run it. This could be also more interesting than CSUBs - you can just compile Thumb/2 on the web, save is as binary and the use it inside MMBasic. Without overhead of C (compiler need and speed decrease)... Still, it's about Pushing the limits of MMBasic, not the CMM2. And for same reason, as I don't use writing my programs on the Mac+transfer it to NC/Term/whatever, but built-in editor, I like to have MMBasic as main language there and not for example some compiled one. I can develop on Mac/Linux/PC (and I need still do it for living, at least partially), but the main appeal of CMM2 for me is: 1. fast start with fast BASIC ready 2. REPL 3. access to I/O 4. no multitask, full screen apps I don't need any language that's faster then MMBasic (but I'm looking forward to any speed increase and extension of it  ) and I think when somebody need it, he/she can either use different HW or write own FW and use it on own CMM2 (or make own fan base for it). Nobody is limited to MMBasic, but for me is enough...Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Pardon, Jiri, but what is "2. REPL"? Perhaps something has been lost in translation. By the way, I agree with you about the (much more than) satisfactory utility of MMBasic, but would also like for there to be able to be a "hook" (e.g. before each MMBasic statement is executed) which would allow, for instance, a debugger to be called if a flag were set. I have this working to a significant degree in DOS MMBasic (debugger), but the project has slipped to the far back burner for now. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
It's a python thing read eval print loop (Well, I met it with python, could have been LISP for all I recall.) John Edited 2021-05-21 21:47 by JohnS |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
REPL is exactly as John said. And it works usually for every interpreted language. The main advantage is, you can test every command/statement in command line. This is for me most exciting tool, which is missing in compiled languages. You write function and can it test from command line!. In C? Write test program, compile it, test it... This is mostly replace the need for debugger. Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
epsilon Senior Member  Joined: 30/07/2020 Location: BelgiumPosts: 255 |
I'm sure you're aware of this, but CSUBs aren't necessarily for C code only. It's just ARM executable binary code, hex encoded. For instance: This: void CFUNC_RAM_initEntry(long long *entry, long long *entryIndexp) { CFuncRam[*entryIndexp] = (int)entry; } Compiles to: 00000000 <CFUNC_RAM_initEntry>: 0: 4b02 ldr r3, [pc, #8] ; (c <CFUNC_RAM_initEntry+0xc>) 2: 680a ldr r2, [r1, #0] 4: 681b ldr r3, [r3, #0] 6: f843 0022 str.w r0, [r3, r2, lsl #2] a: 4770 bx lr c: 0800031c .word 0x0800031c And if you look at the hex codes on the left, and compare this with the CSUB, you'll see it's the same: CSUB CFUNC_RAM_initEntry 00000000 680A4B02 F843681B 47700022 0800031C End CSUB So creating an assembler on CMM2 that generates CSUBs is perfectly do-able. If we roll this into this magical pre-processor that Tom and I are going to build, it can even be inline assembly  Whether actually writing ARM assembly code for the Cortex M7 is doable, I'm not so sure. It has a 6-stage superscalar pipeline. If you would write straightforward assembly for it, without understanding the pipeline, you may find that the gcc compiler generates more efficient code. Epsilon CMM2 projects |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
something OT: @Tom What does schtum mean? Kind regards Michael A typo maybe? Edited 2021-05-21 22:51 by twofingers causality ≠ correlation ≠ coincidence |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I'm glad to hear it's going to be *magical*, I thought we might have to do some actual work ;-) I just want to say that I don't think either @epsilon or I are talking about taking anything away from the core CMM2 boot to BASIC experience we're just exploring avenues for adding some other bells & whistles ontop of it for the more adventurous to explore. In addition I don't think us going off and creating our own hardware / firmware (even if we could, and perhaps @epsilon can) is better for the CMM2 than us sticking around here. Sure I might be playing with FORTH but that doesn't mean I'm not exercising / finding bugs in MMBasic, developing tools useful to MMBasic users or buying hardware from CMM2 vendors all of which adds to the health of the CMM2 ecosystem. 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 |
It means to "keep silent", it's a Yiddish word apparently coming from a German word meaning 'silent' ... though the fact that you are German (or at least in Germany) and asked the question makes me wonder about the latter ? Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I don't think that's right. It can be set up that way (and it would make sense for many applications, very likely the default for MMBasic) but I think it's just a case of how the various areas are mapped. There may well be some gotchas, like needing to make sure caches are flushed... (I've never needed to check, as executing data isn't something I do a lot!) John Edited 2021-05-21 22:58 by JohnS |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
Yes Ruben, I'm aware of it, but I was not able (at least with this or this ) to create CSUB directly from assembler or disassemble it back (at least not every time). It's right, that from my point of view is Thumb/2 crippled ARM, I have programmed on ARM250 and it was very nice... And superscalar pipeline are good exactly for this thing: you are writing normally and CPU is much faster... Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
See Peter's answer here https://www.thebackshed.com/forum/ViewTopic.php?TID=13471&PID=164167#164167, it lacks in detail but seems reasonably clear. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
If it didn't work it's not because it inherently won't but just something went wrong (as with any tool things can). Maybe a lack of understanding of the CPU. You're not forced to stick to thumb2 AFAIK. But you will have to understand the CPU even better. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Yes but I think it's wrong. (It may not have been wrong in its context but taken widely I think it's wrong.) E.g. it's perfectly possible to load a program off an SD card into RAM and run it. John Edited 2021-05-21 23:05 by JohnS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I'm not qualified to argue, and nor do I have a particular problem, at least not yet, with the limitation of packaging machine-code as CSUBs. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
@Tom It is very similar to the German word "Stumm". That was why I was so amazed! Thanks for the clarification!  causality ≠ correlation ≠ coincidence |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Not in the CMM2 its not - for performance reasons the memory management controller is set to block execution in the SDRAM. This is changed when OPTION RAM is set for the program space but not the variable space and is one of the reasons programs run slower in RAM Re the wider discussion: the CMM2 firmware is basically complete other than bug fixes. There will be no major structural changes and if you look at the code you will see that much of what has been discussed entails a complete re-write Edited 2021-05-21 23:14 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I don't know whether it's in general English usage, but my family has a penchant for some of the outer-reaches of the language and I think Yiddish has some particuarly nice turns of phrase, "Oy Gevalt" being my favourite. Best wishes, Tom Edited 2021-05-21 23:14 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
I'm not going to kidnap this thread any further.  I didn't know "Oy Gevalt" either! Very interesting. I think knowing other languages and cultures makes the mind widen. causality ≠ correlation ≠ coincidence |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
