![]() |
Forum Index : Microcontroller and PC projects : CMM2: Next steps?
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
I'm not wanting (or not wanting) it. I'm happy with all the many other choices. I'm not sure how many people would want an RPi with bare metal MMBasic, bearing in mind the other choices and the RPi limited I/O & power usage. John |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
If HDMI is wanted, plenty of chips do it and have good I/O. I don't offhand recall for sure but I think the Allwinner T2 does. Not really today's issue. John |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4301 |
Sorry John, it was poor forum etiquette to quote you when my comment was directed towards Rob. Regards, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4301 |
Hi Peter, A handful of things to do with #Include that aren't bugs, but nor are they "big ideas" for next steps. 1. Support .inc files #Including other .inc files - I implemented support for this for my preprocessor before realising it was unsupported by MMBasic. 2. You allow a .inc file to be RUN, fair enough, how about allowing a .bas file to be #Included ? - Even if you have to call such behaviour a "bug" it would be a useful bug. 3. Improve error messages from the MMBasic preprocessor: - indicate they are from the preprocessor - include file and line number - I frequently scratch my head at "Error: no closing quote" and "Error: Could not file" before recalling they come from the preprocessor - hopefully remove "Error: Can't import from an import" or if not then you should probably change to "Error: Can't include from an include" Yours hopefully, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4301 |
4. Support absolute paths in #Include, currently you get "Error: The path name format is invalid" EDIT: please ignore the below it is a dang fool idea and is how we end up creating our own version of DLL hell, much simpler/safer to have each program have it's own copies of even common .inc files. I would still like absolute paths though to support my ideas for RUN with dynamic filenames. - I think this is crucial to the idea the community might develop, distribute and reuse a standard library of functions and subroutines to extend the MMBasic built-ins. - otherwise we're likely to end up with multiple copies ... though that may be safer if the "standard library" is volatile. YMMV but in my opinion the algorithm to locate a ".inc" file should be: 1. If absolute then look there and only there. 2. If relative then look relative to the file doing the #Include, 3. but if it can't be found there then look relative to a fixed location, e.g. /include/ Best regards, Tom Edited 2020-06-29 07:44 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
damos Regular Member ![]() Joined: 15/04/2016 Location: AustraliaPosts: 74 |
optional DAC2array%() should contain numbers in the range 0-4095 to suit the 12-bit DACs... Thanks for pointing this out. I have been playing with this and it is brilliant! It does exactly what I need. You give it a buffer and it keeps playing it repeatedly until you tell it to stop. I think the way I need to do it is just assign a large buffer and just keep overwriting the same buffer with new data, making sure not to overwrite the place where it is currently playing from. This can probably handled using timers. For example, if I want to play a decaying modulated waveform, I create the first 100ms worth of data, start playing then every 50ms update the samples that are have already been played. The trick is to minimize latency so new inputs update the waveform as quickly as possible. |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1638 |
This is probably another bad idea of mine and I'm not sure if it's possible, but have you considered the option of using the program to edit itself in memory? If the program contained a line like: You could find that string in memory by PEEKing (if you knew where to look) and POKE the filename etc. into that location before executing it. I don't know the ramifications on the program's running if there are spaces at the end of the line or REM markers (') because I believe they are removed. I'll go back under the bed for now. Bill Keep safe. Live long and prosper. |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4301 |
Self-modifying BASIC code, that's wonderful! I've no idea if it would work and I'm not desperate enough yet to try it, but I love it none the less. Enjoy ... I'm beginning to wonder if my cat is Australian, that's where I always find him. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5030 |
Not that I'm terribly familiar with it, but what do you hope to gain that you wouldn't get running RISC OS on the Pi? That boots almost instantaneously and has a powerful BASIC with O/S level integration a couple of key presses away. It even comes with a community of ardent devotees. Regards, Tom I'm not wanting (or not wanting) it. I'm happy with all the many other choices. I'm not sure how many people would want an RPi with bare metal MMBasic, bearing in mind the other choices and the RPi limited I/O & power usage. John Honestly: I would want one. Although I have used RiscOS pico and RiscOS on the Pi, there are drawbacks (there always are..). 1/ The RiscOS people like their ACORN based UI so much that they are not adapting it to what 99.99% of the world are using. I refer to the special way of operating the UI with mouse wheel press. I cannot get used to it. Make mistakes too often. 2/ Despite the extremely high execution speed of BBC basic V, the commandset of MMBasic is simply better. Especially with graphics and such. MMBasic is simply better !!! And Picromite (matherp did a great job creating it) is not stable in the current Buster / Pi4 platform (at least I cannot get it stable). And (according Peter) that is due to underlying changes in Raspbian. And Raspbian will continue to change (as linux does). Therefore the only way to get MMBasic stable on the Pi is to go bare metal. Yes, I would love to have bare metal MMBasic on the Pi. Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10195 |
re Raspberry Pi (copied from an email to someone asking why not Raspberry Pi) No professional development environment for bare metal and no openly available documentation NDA possibly required for access to some bits Multiple versions which are all different, no guarantee what will be produced going forward or commitment to availability of older version No ADC, limited other peripherals At the end of the day it possibly could be done but I chose to use the ST chip because there is an excellent development environment that I had used before. I had no knowledge of Raspberry Pi H/W, can anyone point you to any serious documentation of the chip and its peripherals – I suspect not. The ST has a 1000 page manual explaining the internals in precise detail and a guaranteed support life. Had I tried to do the development on the Raspberry Pi it would still be ongoing and you wouldn’t have anything to play with Edited 2020-06-29 22:09 by matherp |
||||
Raul Newbie ![]() Joined: 06/05/2020 Location: United KingdomPosts: 11 |
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20RaspberryPi:%20RC5%20RISC%20OS%20Pico |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5030 |
Hi Raul, Did you try it ? I did, and was not very happy with the stability. Especially when going in- and out of the editor, I repeatedly lost changes. Could be me doing things wrong. Everything about RiscOS (also pico) is very different from the world of Windows/Linux. Nothing is intuitive. The command line edit mode works completely different from the editor. It could have been great, but as I read it on their website, it was a one-of release, no maintenance. No good user manual. "Take it or leave it". I only kept it on a SD card because the blazing speed, and, if I want to torture myself writing a basic program of 10 lines, taking over one hour, searching on the internet for tips how to use de damned thing. From reading 1980's BBC basic manuals, to forum tips what function keys do what in RiscOS pico. Maybe for people with a background in Acorn machines it is intuitive... I struggled with it.. Volhout PicomiteVGA PETSCII ROBOTS |
||||
vegipete![]() Guru ![]() Joined: 29/01/2013 Location: CanadaPosts: 1128 |
What is the possibility of the a large chunk of the file manager being turned into a function that is callable from MMBasic? It could be a nice tool to use for selecting files. FUNCTION SelectFile( parameters ) AS STRING parameters: (for example, maybe others would be better) title$ ' title for the top line of the display (File Manager could title itself too.) font ' font to use, maybe just 1 or 2 startpath$ ' initial path to view filter$ ' extra bonus if only specific (but more than one) file types are shown returns: string containing complete pathway of chosen file, or something indicating cancel The converse function, SaveFile, would be amazing too. Now if the above could function in a window smaller than the full screen, (in a clipping region, as in a previous idea... ;-) then that would be icing on a cake that's been dialed up to eleven. Visit Vegipete's *Mite Library for cool programs. |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10195 |
Zero: sorry but the way it is constructed is completely incompatible with being run from a program |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6266 |
Easy enough to do as a Basic user-function. Every user program will want something different so a roll-your-own is better than rigid options of a in-built function. DIR$() is the function to use from within a program. Jim VK7JH MMedit |
||||
abraxas Regular Member ![]() Joined: 16/06/2020 Location: CanadaPosts: 99 |
I would really love MMBasic to support some sort of fast array comprehension syntax. First it would cut down on a lot of code noise in terms of FOR/NEXT loops and second it could likely be implemented in a much more performant way. What I envision is something like this: DIM myArray(10,20) AS STRING = ("foo", "bar" .... ) FOREACH myArray() myCallback SUB myCallback element AS STRING, index1 AS INTEGER, index2 AS INTEGER 'do something with each element of the array END SUB The idea is that the callback receives every element from the array along with the element's index or indexes if the array is multidimensional. I would think this could be efficiently implemented so consuming large arrays would be really fast. |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4301 |
Could you please consider what I've written regarding .lnk files in my latest post on CMM2: RUNning a program named by a variable$ or string-expression Tom Edited 2020-07-01 23:12 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
mkopack73 Senior Member ![]() Joined: 03/07/2020 Location: United StatesPosts: 261 |
It would be nice if there was a way to get a compiler for MMBasic. If you have an interpreter you're already 75% of the way there... It would be nice to be able to take what we make interpreted and convert to compiled code to get even better performance. As far as Math functions - matrix cross and dot product functions - I mean, these could certainly be written as functions in basic and shared, but the performance will be much faster if those were already converted into Assembly as part of the Language - very helpful for 3D and ray tracing type operations. Multiply a matrix * scalar. Matrix * vector. One thing to consider with the Matrix math functions is that performance is usually noticeably faster if you represent an X by Y matrix as a 1 dimensional array rather than a 2D array (even though the 2D array is easier to visualize and understand) as a 2D array takes embedding a 2nd loop to process it properly. To that end it might be good if there were some functions to convert between a 1D representation and 2D and vice versa. Something that could perform an Average across an array of floats might also be useful in some cases (again as a speedup vs doing it with a for loop in Basic.) While we're talking arrays - either an option for SORT to work in descending order, or have a REVERSE(Array) function that swaps the order around. Anyhow, just my thoughts... I just ordered my CMM2 kit yesterday so looking forward to sinking my teeth in and seeing what this thing can do! |
||||
SYM-1 Regular Member ![]() Joined: 18/10/2019 Location: New ZealandPosts: 45 |
On the commodore 64 If I remember correctly if you were in immediate mode you could cursor up to any line on the screen and edit it then run it. Good for learning basic or testing effect of various lines. Persistence is the key |
||||
Sasquatch![]() Guru ![]() Joined: 08/05/2020 Location: United StatesPosts: 377 |
On the CMM2 use the <up-arrow> key at the command prompt to "scroll" through previous commands. You can then edit and press <enter> to execute the command. This is similar to later versions of MS-DOS. See page 5 of the user manual. -Carl |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |