TheBackShed.com

Forum Index : Microcontroller and PC projects : Any interest in MMBasic for Windows with full Graphics?

Page 3 of 5

Author

Message

toml_12953
Guru

Joined: 13/02/2015
Location: United States
Posts: 328

Posted: 02:31am 21 Jan 2022

Copy link to clipboard

Print this post

matherp said It is still cold and miserable in the UK so outside pursuits are on hold and I need a new project.

I have the germ of an idea for how to program a windows graphics version of MMBasic. The idea is that, like the CMM2, it would use a mouse to control the GUI controls and it would support the full set of MMbasic drawing commands. It wouldn't and couldn't replicate any specific existing version of MMbasic so, for example, you couldn't take Mauro's CMM2 programs and run them unchanged but it could eventually support things like true sprites using the graphics card rather than the processor to render them.

This is a big project and takes me outside my "embedded" comfort zone so I only want to start it if there is real interest from a significant user-base.

For those interested in the base technology I'm thinking of using google "one load coder pixelgameengine"

Thoughts?

I'd certainly run it! One use would be to debug programs for the CMM2.

LeoNicolas

Guru

Joined: 07/10/2020
Location: Canada
Posts: 450

Posted: 06:34am 21 Jan 2022

Copy link to clipboard

Print this post

It will be a great feature running graphics on the MMBasic DOS / Linux.

KD5ZXG
Regular Member

Joined: 21/01/2022
Location: United States
Posts: 53

Posted: 06:53am 21 Jan 2022

Copy link to clipboard

Print this post

Definitely want MMBASIC w. graphics for Windows or DOS/VESA.
But also want simple remote control of USB attached Picos.
PC isn't exactly bristling with native GPIO.

Not Windows, but what about running quad SPI connected Picos
to offload VGA and maybe other burdens from the interpreter?

$4 could afford one for each color, maybe going too far...
Two Picos could hide in a PS/2 keyboard as easily as one.
Edited 2022-01-21 16:58 by KD5ZXG

Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3589

Posted: 11:32am 21 Jan 2022

Copy link to clipboard

Print this post

tgerbic said Took a few minutes to think about this and provide a slightly different set of ideas. Any BASIC running on a modern PC should have some relatively easy way to provide a GUI function for programs.

I would think it would be useful to have a version of PC MMBasic that contained graphics, at least to the level of that in the Explore 100, with similar functioning commands. This code base could use a standard graphics library which would allow it to be compiled to Linux and Windows. This provides a compatible direction for a useful graphics support, cross platform.

Something I miss from the days of the ISA based PCs, S100 or my Apple II, for example, is the ability to have the PC BASIC easily drive hardware pins directly.

A possible and useful extension would be to define a set of IO port addresses defining a standard set of IO ports. For example sixteen 8-bit IO, eight 16-bit IO addresses, eight I2C ports, eight SPI ports, sixteen A2D ports and sixteen D2A ports, etc. These could be coded into MMBasic to be used with existing MMBasic microprocessor nomenclature. MMBasic could then have compatible PC and PIC (or other microprocessor) hardware to code against.

In the case of microprocessors running MMBasic, BASIC would directly access the microprocessor hardware, as it does today.

In the case of PCs running MMBasic, the PC MMBasic versions could direct the IO out a USB connection to one or more hardware adapter boards.

For simplicity let's look at one example. Let's say we had a firmware that would work on a PIC, Arduino or other microprocessor that would take commands from the PC MMBasic to provide IO requests to the remote microprocessor hardware. From within the PC BASIC program you could configure a pin by defining it like you would for hardware (SETPIN) but BASIC would send the config to a port on the remote hardware board. You could then do a PIN(6) = 1 and BASIC will send a 1 to the configured port on the remote hardware board changing pin 6 to a 1. Could also define pins so you could use the PRINT "Temperature: " DS18B20(15) command, LCD 1, 2, "Hello World" or I2C READ.

Since there is a bit of hardware and serial communication between the BASIC program and the remote hardware board, IO would be a bit slower but in many cases acceptable. You might not be able to use a rotary encoder on the remote hardware but that function might be in the GUI on the PC instead. I see the external IO more as drivers for SPI, I2C, parallel bits, temp sensors, A/D or D/A, that you would want to control from a PC BASIC application.

Not everything is covered by this idea but it is a place to start thinking about this kind of functionality. It would make a PC based MMBasic appear to have access to hardware pins, consistent with MMBasic running on an actual microprocessor. In a sense, this would be like a virtual ~1024-pin microprocessor running MMBasic with a graphical PC as the console.

This is probably a wild set of ideas but in my case it would help solve the loss of direct IO we had with earlier PCs. Some basic GUI support would allow PC MMBasic to be used in places that now requires us to switch to other variants of BASIC to draw a user interface. To be honest, I would like to be able to use only MMBasic for PC and microprocessor projects. I would like to make it easier to develop microprocessor BASIC programs on my PC with some ability to access IO connected devices. I would also like to easily be able to use a PC running BASIC to drive equipment and experiments on my electronics bench.

Regards

This is what I do in almost all of my test setups.
I have an Arduino (tinybasic) or MX170 (MMBasic) attached through USB as a COM device. In Teraterm Scripting Language(windows) or Expect Scripting(linux) scripting I send sets of commands to the commandline of the Arduino/MX170 and read the response. In some cases, where speed is more of an issue, this can include loading (through the same commanline interface) a basic program, executing it, reading the response, killing the program, and continue on the commandline.

Then you benefit is
a/ simple direct commands
b/ option to run basic programs that do some fast stuff.
c/ enjoy the functionality that is inside basic (just imagine you have a simple bit based IO only and have to write all the SPI functionality, I2C functionality, ADC reads, string handling, yourself. The script would be immense.

In essence: everything you need already exists. You just have to use what is there.
And if you use scripting languages, or MMBasic with COM port support that is free to you. Reason I use scripting in Expect, is that it allows me to use ethernet devices also using telnet or ssh (it is not limitted to serial ports only) where as MMBasic does not support that yet.

Volhout
Edited 2022-01-21 21:35 by Volhout

PicomiteVGA PETSCII ROBOTS

Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646

Posted: 03:38pm 21 Jan 2022

Copy link to clipboard

Print this post

bigfix said It would make sense if it supports some minimum I/O to the outside world
Serial & I2C would be nice, syntax similar to current MMbasic for portability

Eventually it could support an USB to I2C adapter, allowing to connect the GP I2C I/O box, which was just designed in another thread

There is also the IOIO-OTG which originally was Android only but now is PC compatible.

The cool thing about the IOIO on Android is that; unlike most OTG devices, it can charge the device.

Not very hobbyist-friendly in terms of pricing but I believe it is open source.
Edited 2022-01-22 01:39 by Tinine

thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3865

Posted: 03:56pm 21 Jan 2022

Copy link to clipboard

Print this post

Tinine said There is also the IOIO-OTG which originally was Android only but now is PC compatible.

The cool thing about the IOIO on Android is that; unlike most OTG devices, it can charge the device.

Not very hobbyist-friendly in terms of pricing but I believe it is open source.

And now I've had to buy an OTG adapter (a normal one, not that piece of gold-plated unobtanium) to see if MMB4L running on my Android phone can talk serial to an attached 'mite.

Best wishes,

Tom

Game*Mite, CMM2 Welcome Tape, Creaky old text adventures

Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646

Posted: 04:28pm 21 Jan 2022

Copy link to clipboard

Print this post

thwill said

And now I've had to buy an OTG adapter (a normal one, not that piece of gold-plated unobtanium) to see if MMB4L running on my Android phone can talk serial to an attached 'mite.

Best wishes,

Tom

This is also quite exciting....looking forward to the results

Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646

Posted: 04:32pm 21 Jan 2022

Copy link to clipboard

Print this post

@thwill

Does this mean that we could be looking at MMBasic on the Odroid or similar?

Cheers,

Craig

KD5ZXG
Regular Member

Joined: 21/01/2022
Location: United States
Posts: 53

Posted: 05:52pm 21 Jan 2022

Copy link to clipboard

Print this post

GPIO over USB isn't completely daft, as proven in BASIC at least once before.
Anyone ever fool with FUZE Basic? Could control pins of connected Arduinos.
I could never get Arduino pin I/O to work when Pi3 ran the FUZE interpreter.
Which was a nuisance, at the time I needed 5V GPIO my Pi3 couldn't do.
But a PC running specific obsolete version (I forget exactly which) could...
Maybe was fuzebasic64v3'9'1 with fuzeBasicArduino.ino both vintage 2017?

Found this silly demo I once wrote (for PC) to read two pots (via Arduino).
Point trying to make that FUZE treated external GPIO as-if part of the PC.
Maybe could connect more than one? Never actually tried more than one.
NEEDS LINE NUMBERSssssss. Hate how FUZE stripped line numbers
and shoveled unwanted structure over my glorious numeral spaghetti.

rem *** 360 degrees in a circle ***
DEG
rem *** Arduino ***
setDevice (0)
rem *** setup button between pins 10 and 12 ***
pinMode (12, 2)
pinMode (10, 1)
digitalWrite (10, 0)
rem *** setup button between pins 7 and 9 ***
pinMode (9, 2)
pinMode (7, 1)
digitalWrite (7, 0)
rem *** setup built-in red LED on Arduino ***
pinmode (13,1)
rem *** setup a sprite for Knob AO to turn ***
knoba = newSprite (1)
loadSprite ("fighter.png", knoba, 0)
spriteCentre (knoba)
rem *** setup a sprite for Knob A1 to turn ***
knobb = newSprite (1)
loadSprite ("fighter.png", knobb, 0)
spriteCentre (knobb)
CLS
UNTIL digitalRead (12) + digitalRead (9) = 2 LOOP
printAt (0, 0); analogRead (0); " "
printAt (10, 0); analogRead (1); " "
printAt (0, 1); digitalRead (12); " "
printAt (10, 1); digitalRead (9); " "
rem *** echo D9 button to RED LED D13 ***
digitalWrite(13,digitalRead(9))
setSpriteAngle (knoba, 30 + (analogRead (0) * 300 / 1024))
setSpriteAngle (knobb, 30 + (analogRead (1) * 300 / 1024))
plotSprite (knoba, 150, 150, 0)
plotSprite (knobb, 650, 150, 0)
UPDATE
REPEAT
hideSprite (knoba)
hideSprite (knobb)
PRINT "exiting, both buttons pressed."
WAIT (2)
END

So, a half dozen Picos dangling from a PC might be awesome...

Why spend $41 the for IOIO_OTG when a Pico is $4?
Not sure which direction you meant about Android OTG?
https://shop.pimoroni.com/products/pico-lipo-shim
Even with the shim, Pico is cheaper than IOIO_OTG.
Edited 2022-01-22 04:42 by KD5ZXG

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8605

Posted: 07:22pm 21 Jan 2022

Copy link to clipboard

Print this post

Quick progress report

Based on responses and some feasibility testing I've been doing the project is a GO.

I've got the framework running with three threads
One handles the Display, keyboard and mouse. This uses the olcPixelGameEngine which gives pixel level access to a display window

The second thread will run the main MMbasic loop

The third thread will run a millisecond timer that can be used for all the various timeouts and provide data to the clock/timer commands etc.

The keyboard input and screen output are all up and running and the screen will be completely recognisable using your favourite MMBasic fonts - none of this windows font rubbish.

It all seems to be going together OK although mixing C and C++ is proving a bit of a pain. The screen and keyboard handling are controlled though a class and its methods and are totally event controlled whereas MMbasic is fully procedural C sitting in a tight loop. What doesn't help is my total lack of competence in C++

Speed is impressive

Hopefully MMbasic will be running to the extent of executing at the command line in the next couple of days or so.
Edited 2022-01-22 05:26 by matherp

Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 5771

Posted: 08:14pm 21 Jan 2022

Copy link to clipboard

Print this post

Erm... yeah... it is a bit. :)

Looking good so far, Peter, and excellent news about the fonts. :)

Mick

Zilog Inside! nascom.info for Nascom & Gemini
Preliminary MMBasic docs & my PCB designs

Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646

Posted: 09:02pm 21 Jan 2022

Copy link to clipboard

Print this post

I almost posted earlier that @matherp has gone quiet so watch out

IanT
Regular Member

Joined: 29/11/2016
Location: United Kingdom
Posts: 84

Posted: 10:45pm 21 Jan 2022

Copy link to clipboard

Print this post

Just seen the demo on YT Peter - fantastic - thank you, looking forward to trying it.

Regards

JoOngle
Regular Member

Joined: 25/07/2020
Location: Sweden
Posts: 82

Posted: 12:31am 22 Jan 2022

Copy link to clipboard

Print this post

To the original Question: YES!

And as everyone in here is onto: this is GREAT for learning MMBASIC for the CMM2. I gotta admit my CMM2 has been gathering dust for the last 6 months since I don't really have the time to switch between the CMM2 and my work computer+home computer on my TV.

If you in the future could support Sprites Natively (and for example use the 3D graphics cards polygons as sprites and bitplanes and screens) that would be OUT OF THIS WORLD cool.

HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78

Posted: 06:23am 22 Jan 2022

Copy link to clipboard

Print this post

The best thing about MMBasic is how close it is to real world. It allows the development of complex Programmable Logic Controllers that integrate with anything with a SPI, I2C interface or just a GPIO. That's the most powerful ability of MMBasic embedded in a chip.

Using it to make graphical games that no one will play seems OK for learning a bit of Basic Programming, but it goes nowhere.

Just my silly thoughts considering I use to write silly graphical games on my VZ200 35 years ago.

Just know enough to get me in trouble, but not quite enough to get me out.

Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 5771

Posted: 07:31am 22 Jan 2022

Copy link to clipboard

Print this post

^^^ This ^^^

Agreed. Without hardware IO capability MMBasic is stripped of it's whole purpose. Even linking the IO over USB is a compromise and adds a whole new layer of complexity that can go wrong.

Games writing has better tools available, even FreeBasic is probably better as it's compiled.

I'm not knocking this project by any means, but I stick by what I said earlier - I hope Peter is seeing this as something for his own enjoyment. I don't see the PC as a good platform for MMBasic but it's an interesting exercise.

Mick

Zilog Inside! nascom.info for Nascom & Gemini
Preliminary MMBasic docs & my PCB designs

Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646

Posted: 12:36pm 22 Jan 2022

Copy link to clipboard

Print this post

OTOH, there is Windows Embedded, now renamed to Windows IoT.

I evaluated XPE many years ago and it was granular.

Not everyone is a hobbyist and if Pete is planning on being able to support DLLs, this could be HUGE for industrial control.

Craig

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8605

Posted: 12:44pm 22 Jan 2022

Copy link to clipboard

Print this post

Quote Without hardware IO capability MMBasic is stripped of it's whole purpose.

In your view but not of lots of the posters above. I use the DOS version quite frequently for simple utility programs. The CSUB generator is written in it.

flasherror
Senior Member

Joined: 07/01/2019
Location: United States
Posts: 159

Posted: 12:55pm 22 Jan 2022

Copy link to clipboard

Print this post

Since this project is going ahead, a few ideas for "down the road"

TCP/IP client/server and MQTT support, with the intent of being a "server" for connected nodes
Some kind of database support (SQLite should be fine)
Basic audio support (play .WAVs, .MP3s etc) for user notification.
Since this is running on a PC with way more resources than embedded systems, could there be some way to have multiple MMBasic interpreters running in parallel allowing each one's basic code to run independently and pass data between running instances?

JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3678

Posted: 01:06pm 22 Jan 2022

Copy link to clipboard

Print this post

flasherror said could there be some way to have multiple MMBasic interpreters running in parallel allowing each one's basic code to run independently and pass data between running instances?

Likely to "just work".

Worst case, use files to pass data.

John

Page 3 of 5

Print this page