 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 3 of 5   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 5768 |
The Picromite failed because the RPi version of linux and the GPIO interfacing kept changing with every release. *If* they finally settled down to just keeping up with just the official Debian stable releases then it might be ok, but they don't do that. They have to be bleeding edge all the time. That's not much of a problem for the intended market, or most of those who never use Raspbian, but it's not a stable platform. You *can* "freeze" versions of Rasbian and a GPIO interface and only develop for those, but you can never update the Pi with anything newer if you do that as it's liable to break something (as has been proven). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
the Raspberry Pi runs Linux. any application that is written following a few simple guidelines will work on just about any distribution of Linux. i have done this, it works. many other people have been doing the same thing for decades without issue. for example, GFXterm compiles for (and runs on) both Linux Mint and Raspbian, without any change to the source code. serial ports are accessible to any application once you enter the following incantation (exactly as show) at the command prompt: sudo adduser $USER dialout the above is a once-off thing that you never need to enter ever again. your application can even do this for you, but it is rarely built in as it requires the user entering their password when prompted. talking to the serial ports is no more difficult than it is under windows. things get a little more interesting when trying to access the I/O pins on the RPi, however if you use the API provided by pigpio and don't try anything too esoteric things will work fine. for sound, you talk to alsa, a software layer that provides a simple API that sits between your application and the sound hardware. you feed it a mono or stereo digital stream and it plays it. just about every desktop distribution of Linux supports alsa, including the RPi Linux distribution. none of it is rocket science - or brain surgery! https://www.youtube.com/watch?v=THNPmhBl-8I cheers, rob :-) Edited 2021-08-26 04:38 by robert.rozee |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3586 |
It sounds simple. Except that I have been involved in Puppy Linux for some 15 years. And despite the senior devs there, it takes time and adaptatios every roll of the kernell, every change in gcc, every library update, every change in python, lua, and whatever scripting language. Maybe they where not as senior..? And maybe peter gave up because he experienced something similar. A change in the priority handler in linux I remember as result of a kernell change. It will become different now anyway, since 32bit is becomming less supported in the linux world. Appart from pi4, all pi's are 32bit I recall. So you will have to compile the whole shebang. Or rely on Raspbian packages...and these change as Peter experienced. PicomiteVGA PETSCII ROBOTS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Don't tell them that Rob, I was going to use my (touch wood) success on this project as a reason to remove the "Not a Guru" banner from my avatar  . The project is "MMBasic for Linux" c.f. "MMBasic for DOS". The RPi runs Linux so assuming no assumptions about the size of pointers have slipped into the source-code (fortunately x86 and ARM, at least by default, are both little-endian) then it should be trivial to compile the source for both x86_64 and ARM32 - it's not as if the core MMBasic has any dependencies to speak of. Serial comms (OK, I know the DOS version has it) will not be in my initial feature set, and GPIO may never be - sorry. I try to be flexible. At my electronics desk (more of a cubby-hole) my computer is a Pi3 attached to the VESA mounting on the back of a small LG TV/monitor. In my office I have a high-spec 2019 vintage ThinkPad running Win10 with CentOS 7 and Ubuntu 20 Linux VMs. The ThinkPad came on holiday with me so I am doing initial development under Ubuntu 20. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3677 |
Generally, it is. I'm not sure why they're having such issues. The way you describe it, they should not have them. Maybe you've simplified or they're doing something extra (I have no idea what or why!). (Well, the kernel itself is bound to be some fun as is every OS, but they're trying to cope with the many weird hassles and nightmares of actual hardware.) I think he mentioned a combination of things but the big issue (which does not apply to the list you stated) is that MMBasic, dealing in its particular ways with I/O and hardware, is far from an ordinary Linux program. John Edited 2021-08-26 08:19 by JohnS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3586 |
I guess the difference between my experience, and yours, is that I was involved with people that are building the distribution, you are using it. PicomiteVGA PETSCII ROBOTS |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3677 |
Sure - that's very different to what nearly all programmers (let alone users) do with Linux. Unlike Windows (as an example), Linux keeps APIs across updates so programs go on working. Linus (Torvalds) insists on binary compatibility at the kernel API level. Windows does not do that, sadly (and stupidly). Picromite/MMBasic isn't a distro so shouldn't be impacted in the same ways (self-chosen when you decide to make a distro - something most people don't do). However, MMBasic is close to the hardware (unlike almost every other program) so can expect some grief. Peter very generously donates his time & effort and got fed up with (something/some things). It happens. Probably it could be overcome but would need someone to devote time & effort. John |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5768 |
Compatibility across linuxes is pretty good generally - providing you aren't making any demands on anything other than the standard API. Also remember that linux runs as a multi-user system and you have to use special techniques if you need time-critical routines. Remember that it was designed to run time-sliced text-based programs. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Hi folks, I now have a reasonable approximation of non-blocking console I/O, Peek, Poke and Memory Copy/Set implemented - at least enough to get "Yellow River Kingdom" running: https://www.youtube.com/watch?v=1C_27NmpoV0 Ironically it craps out at the end due to a BASIC bug ... not sure when that crept in there, but it suggests none of you downloaded and played it for more than 30 seconds .Having compared my keyboard code with that for the PicRoMite I have a suspicion that mine is too simplistic and won't necessarily survive contact with the enemy. For anyone wondering why I don't just lift vast swathes of the PicRoMite code the answer is that I won't learn as much that way, and also if I write (or at least type in) the code myself I will find it easier to maintain, also NIH  .Next up getting #INCLUDE working so that I can start to bring up my MMBasic unit-tests. Best wishes, Tom Edited 2021-08-26 23:56 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Latest update: It's been a bit of a fight but I now have #INCLUDE and 95% of the rest of the CMM2's pre-processor code working for my Linux port - unfortunately this doesn't produce anything I can show a worthwhile video of. Note that if anyone is interested the CMM2 has an undocumented command "LIST FLASH" which will list the pre-processed code stored in the flash as opposed to the vanilla "LIST" command which just spools the current program file from the disk to the console. Still plenty of holes to plug and rough edges to file off before there is anything to release though. Best wishes, Tom Edited 2021-09-02 23:00 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5768 |
Oh, you've gone and done it now, Tom. Peter will remove it on the next update. ;) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3586 |
Not when we put the command in the user manual .... PicomiteVGA PETSCII ROBOTS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Well I've got my unit-tests working which (I think/hope) means a very significant part of the non-graphical and non-hardware I/O aspects of MMBasic are now running on Linux (x86_64) including program loading and "chaining": https://www.youtube.com/watch?v=zunbYsv7BUs It's all a bit of a "dog's breakfast" but I'm confident I can iron that out with usage. I guess it's time to talk to Geoff and Peter about a version number and how they want the alpha "published". Best wishes, Tom Edited 2021-09-05 01:08 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Question: Are there any defacto standard tests that have been used to validate MMBasic releases in the past? Can someone provide links? IIRC as a minimum there is some sort of performance benchmark that is occasionally posted. Best wishes, Tom Edited 2021-09-05 04:38 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3027 |
The 5 benchmarks I ran on the picomite are zipped below, along with the tain.txt file which Paul_L's ta benchmark needs. bench.zip The most commonly run bench.bas has had these numbers posted: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 ABC 800 single precision 0.9 1.8 6.0 5.9 6.3 11.6 19.6 2.9 ABC 800 double precision 1.2 2.2 10.0 10.6 11.0 17.8 26.4 14.4 IBM PC 1.5 5.2 12.1 12.6 13.6 23.5 37.4 3.5 Apple III 1.7 7.2 13.5 14.5 16.0 27.0 42.5 7.5 VIC-20 1.4 8.3 15.5 17.1 18.3 27.2 42.7 9.9 ZX81 in "fast mode" 4.5 6.9 16.4 15.8 18.6 49.7 68.5 22.9 Maximite 0.016 0.144 0.196 0.205 0.354 0.512 0.721 0.310 Maximite with line Nos 0.016 0.131 0.193 0.194 0.245 0.393 0.582 0.241 Maximite without line Nos 0.016 0.111 0.173 0.173 0.192 0.336 0.525 0.220 MicroMite 40MHz 0.028 0.18 0.285 0.289 0.644 0.892 1.346 0.376 MicroMite 48MHz 0.023 0.15 0.237 0.24 0.536 0.744 1.121 0.313 Picromite Pi Zero 0.014 0.058 0.093 0.102 0.184 0.298 0.354 0.127 Armmite STM32H7 0.003 0.023 0.038 0.042 0.067 0.098 0.146 0.065 C-Language (code see above): Arduino UNO 0.010 0.010 0.058 0.043 0.043 0.043 0.045 0.284 Arduino DUE 0.003 0.003 0.006 0.007 0.007 0.007 0.106 0.014 [/code] Edited 2021-09-05 05:09 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 328 |
One benchmark that's used for both low-end computers and high-end calculators is Thimet Calculator Performance Index There's a table on there that compares many different machines. Here is their benchmark that I converted from their C version and runs on MMBASIC: timer=0 loops=20000 ' Adjust # of loops so runtime is at least 5 seconds. for i=0 to loops-1 r0=10 do x=r0 x=x+1 x=x-4.567e-4 x=x+70 x=x-69 x=x*7 x=x/11 r0=r0-1 loop while r0>0 x=log(x) x=sin(x) x=sqr(x) x=sqr(x) next print x t=timer/1000 print format$(t,"Time:% 3.3f seconds") print format$(34/t*loops,"Index:% 4.2f") Edited 2021-09-05 05:15 by toml_12953 |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3027 |
Bench.bas for MMBasic DOS (100,000 iterations): MMBASIC DOS 0.0002 0.0017 0.0028 0.0028 0.0073 0.0092 0.0117 0.0058 (Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz) ArmMite F4 0.011 0.079 0.14 0.149 0.249 0.354 0.528 0.257 ~ Edited 2021-09-05 05:34 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 328 |
Where can we find it? Is that the one in the previous post? Edited 2021-09-05 07:38 by toml_12953 |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3863 |
Not that it's particularly meaningful ... Linux x86_64 build running Ubuntu 20 in a VirtualBox VM on an Intel(R) Core(TM) i7-950H @ 2.60 GHz 0.0000 0.0020 0.0040 0.0040 0.0080 0.0130 0.0190 0.0070 This is with CMake's default Release settings so probably not at the highest level of optimisation. Also my Linux build is based off the DOS code and doesn't have the hashed variable/function/sub optimisation of the latest CMM2 firmware. And if I'm honest I want to look at the TIMER code again as I saw Z-MIM produce a -ve execution time on one occasion .What's the FLASH RUN 1 statement at the end of each of these benchmarks supposed to be doing ? Best wishes, Tom Edited 2021-09-05 08:28 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3027 |
Yes, it's bench.bas, one of the 5 in the zip file. More starting in 2012 here. It's at least meaningful in that it ran, and also that results are comparable to MMBasic DOS. That was part of chaining all 5 benchmarks on the Picomite as shown here: Picomite benchmarks. ~ Edited 2021-09-05 08:39 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Page 3 of 5 |
|||||
 Print this page |
