 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 : MMBasic for Linux (a possiblity - don't get too excited)
Page 1 of 5   |
|||||
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Hi folks, Just spinning this thread off so as to avoid poluting the PicoMite thread further. I've got a couple of weeks coming up with a laptop but no 'mite hardware so I am going to *try* to port MMBasic (5.05) for DOS/Windows to Linux using the GNU toolchain. 1. Why? a. for the challenge b. because I would like to understand the firmware / MMBasic better. c. because I would like to be able to do MMBasic development on Linux (and Raspberry Pi) without needing a tethered 'mite. In addition I would like to make available programs I've already developed to a friend who doesn't have 'mite hardware (or any inclination to get it). 2. Why such an "old" version of MMBasic ? I've had a look at the available source-code and the DOS version is the smallest (because it doesn't include any of the hardware/microcontroller specific code) and has the simplest existing toolchain. If I can get it to work I would then look at pulling in later developments from the other MMBasic branches with the hope of getting it to and maintaining at something approximating CMM2 compatibility. 3. Why not start with the PicRoMite source-code ? It's significantly larger - probably that's the "troublesome" code to do with using ther GPIO and the Pi as if it were a micro-controller. It also depends on what appears to be an Eclipse toolchain which I personally want to avoid. 4. How will this differ from PicRoMite ? It will hopefully be portable to all Linux' and won't have the GPIO / micro-controller specifics. Perhaps I might look at hardware aspects later if I'm successful with my initial port, but to be honest if Peter with all his hardware/electronics experience can't get it to work I don't see muggins succeeding. 5. What about graphics ? Not initially of interest to me, but I do wonder if something might be done with the SDL, see BBC Basic for SDL. 6. When can I have it ? IF (big IF) I'm successful, or at least get far enough along that I think I will be successful then I will talk to Geoff and Peter about this. Until then it's purely a private project for my own edification. Of course this may all be so much hot air, we will just have to wait and see. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Thanks Peter, I've already made that agreement (months ago) and have access to the source-code (unless there is a later "extra private" version.) My CURRENT plan as detailed above is to start with the "simpler" DOS version without the I/O and Eclipse toolchain. I imagine I will "borrow" from, or at least look at your PicRoMite source-code if I run into difficulties. It's possible that "on contact with the enemy" I may roll-back on this decision and start with the PicRoMite source instead. EDIT: to put it another way, as a personal project I want to have the opportunity to make my own mistakes and as far as possible do it my own way. Again this may all be hot air. Best wishes, Tom Edited 2021-08-12 20:56 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
I wondered when I first came across the Picromite whether it was a version of MMBasic that talked to linux over stdio, so effectively the linux box is the console. I never investigated further as there was no need. I did manage to eventually find the happy combination of bits to let it run on a Pi though. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
hi tom, you might instead consider starting off with the MX170 version of micromite basic. my reasoning: the linux console/terminal includes full VT102 emulation, which means that you will not have to do anything to the editor to make it work. things become super simple, barely an inconvenience. the steps required will be something like: 1. switch the console/terminal to raw i/o with: var tios, SAVEDtios:termios; begin TCGetAttr(0, tios); SAVEDtios:=tios; CFMakeRaw(tios); TCSetAttr(0, TCSANOW, tios); // place console in RAW mode repeat // main loop in here until finished; TCSetAttr(0, TCSANOW, SAVEDtios) end. 2. make sure all calls to console i/o are routed through simple printf, etc statements. i've not looked closely at this part of the source, but this should all be routed through just a couple of points in the code. 3. replace all the hardware-specific calls with empty stubs- this will be a tad tedious. at some future point you can then bring the lost functionality back online (for instance, for a RPi version). 4. write some simple emulation of flash and RAM as arrays, with the 'flash' read from a file on disk at startup and written back to disk on shutdown. later on, you can make the behaviour more sophisticated. the above should give you a solid starting point, and with a bit of luck you can pass the required edits back to geoff so he can incorporate them as conditional compiles into his main repository. that way, you can create a port where upstream changes that geoff makes over time can be rapidly reflected in the linux version. cheers, rob :-) |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3008 |
With DOS MMBasic (or MX170), I would suggest including the longstring commands and functions (as I have done with Geoff's and Peter's permission). Longstring routines PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Thanks Rob, that sounds like good advice. Geoff (or perhaps Peter) if you see this is there a particular version of the source that is considered the base-line or do the DOS, Micromite(+) and CMM2 sources all share the same status ? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
IMHO (based on 8 different ports) this would be the worst starting point. DOS or Picromite is the way to go - both RAM based. Picromite uses STDIO for file handling (can't remember what DOS does). For Linux you can also do console I/O including mouse support with ncurses if you want. NB: PicoMite started with DOS version My approach is always to strip out everything except core MMBasic. Then get command line operation of Basic working. This proves all the main functionality is there - heap handling, variable creation etc. Then add file load and RUN. Then file save and then everything else Edited 2021-08-12 22:14 by matherp |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
guess it is a matter of opinion. with the DOS version, you'll end up having to put back in a whole load of editor functionality that was previously stripped out by geoff. personally, i would avoid ncurses like the plague, it is a rabbit hole that you can disappear down into until then end of days. just switch the console into raw mode, and you can treat it as a bog-standard 80x24 VT102. mouse support is already there, documented in the GFXterm documentation and already used by the MX170/470 editor (with a bit of luck, you won't need to touch the editor code at all). remember: keep things simple, don't add functionality beyond the bare minimum until you have something that is stable. the absolute last thing you want to end up with is something that runs for some users but not others, or is in any way unstable. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
Isn't that inevitable with Linux given all the different flavours? |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
It shouldn't be for a console application like MMBasic. Anyway purely selfishly the only user I care about at the moment is me  .Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
not at all, you just need to make sure to only use core functionality that is shared across all 'flavours'. and there is a great deal of that core functionality, certainly more than enough to get mmbasic up and running. tom should be able to produce something that can compile for linux (32- and 64-bit intel), osX (intel), and RPi (arm). cheers, rob :-) Edited 2021-08-12 22:54 by robert.rozee |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
And if Windows Subsystem for Linux (WSL) becomes standard on Windows (a distinct possibility) it should even be possible to close the loop and have the same source compile back to Windows. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3649 |
Instead of SDL, you might look at Allegro (which doesn't have to be used for games). John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
Exactly, multiple different compilations. OK the source may be the same but you have to compile and distribute multiple versions with multiple different "makes" I assume this is why many Linux programs seem to ship as source that has to be compiled on the users' machine |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3649 |
Most commonly-wanted programs are packaged and available with the most-used distros so don't need any compilation. The less-used or indeed hardly ever used programs are not included pre-packaged, so if someone does want them then they can download and build them. (Typically a trival process along the lines of ./configure ; make ; sudo make install) Of course you can build the other ones if you wish, but most users just install via their distro's package manager. There are so very many programs for Linux each with relatively few users that it wouldn't really make sense to include them packaged in their distro's repository. You've apparently been looking at the latter category. John Edited 2021-08-13 00:31 by JohnS |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
64-bit intel will cover 80% of desktop linux users out there today. 32-bit intel will get this up to perhaps 98%. 2 binaries is hardly a burden. indeed, most users are moving over to 64-bit these days, and in a few years time i'd imagine 32-bit intel will be a thing of the past for the linux community. these sorts of changes are relatively easy and painless with a free/unemcumbered operating system. i actually now have a few virtual machines set up on my desk machine. main operating system is 64-bit linux mint 20.2 XFCE, while the VMs are: 32-bit linux mint 19.3 XFCE 32-bit winXP each VM can then be used to compile and test its own binaries. this allows me to test and compile fpc/lazarus applications for the vast majority of linux desktops, and all windows platforms (as long as win10/11 keeps on supporting win32 applications) i'm looking at adding an osX VM to the collection, this being just marginally more complicated to set up. under linux this is rarely (one might say never) a problem for the end user. the licensing of source does in some rare cases preclude this, as is the case with mmbasic. but, as i say, only a few binaries are needed to cover the vast majority of desktop users, so not really a problem. cheers, rob :-) Edited 2021-08-13 00:39 by robert.rozee |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
This will be meaningless to most, but I need to vent ... what evil minded masochist decided that the signedness of "char" in C would not be standardised as either "signed char" or "unsigned char" ... ... and how have I never noticed this atrocity before? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
In better news: Linux MMBasic Ver 5.05.04 Copyright 2011-2021 Geoff Graham Linux port by Thomas Hugo Williams, 2021 > print 1 print 1 1 > print "Hello World" print "Hello World" Hello World Please ignore the version number and the fact that Peter's name isn't in the copyright, that's just how it is in the DOS version I started from and no reflection on anything else. Details like that will be sorted out with Geoff and Peter if this goes further than a toy project. Lots more work to do. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
Because it's a flippin' 'orrible language. :( Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3649 |
It just reflects what hardware (the CPU) inflicts on (particularly low-level) programmers. Heck, the CPUs inflict other atrocities, such as: 1. character & word size (e.g. 6-bit / 9-bit & 24-bit / 36-bit / 60-bit) 2. big- or little-endian 3. floating point (aarghhhh!!!) I guess you hardly write any C!! BTW C compilers (such as gcc) often allow you to override what the actual CPU provides (but inevitably can generate longer, slower code). John Edited 2021-08-20 23:53 by JohnS |
||||
| Page 1 of 5 |
|||||
 Print this page |
