Maybe a thread regarding MMBasic issues ?. In most cases quoting the version you’re running would be a good idea…
I’ll start… On startup the default drive is A: how do we change that to B: permanently so it survives power cycles ?
You could put it in a .bas file, store it in flash, and set it to autorun. There’s an example mentioned on this thread, and @rlauzon used it in his collection of code examples, explained here in this text file.
That will work for most stuff, though there are exceptions. Some of the OPTION commands can’t be put in a .bas file, for instance, like CPUSPEED. Setting the default drive works though.
Also worth mentioning – it might not survive if you flash an updated firmware. That said, I have actually seen it persist across (maybe just minor?) updates to PicoMite. The only time I know I’ve seen it get lost is when I flashed an entirely different firmware (like MicroPython) and then returned to a PicoMite firmware.
1 Like
Yes that already crossed my mind as a workaround but hoped for something within the option settings, maybe in a future release…
1 Like
You could put it in your library. Both in SUB MM.STARTUP and by itself. That way, it’s run at startup and every time you run a program.
SUB MM.STARTUP
B:
END SUB
B:
2 Likes
Issue 1 working well 
. Odd how I’ve noticed some programs kill the colourcode option, insert/overwrite etc…
Next issue… controlling the keyboard and screen backlights from MMBasic ?. Surely only needs the spi address of the STM32 and correct codes to pass over…
I don’t think the line for controlling the screen backlight is connected in the PicoCalc. I hope I’m wrong!
if you recently did a keyboard firmware update (now called BIOS) then you should be able to set both display and kb backlight through i2c.
1 Like
I’m a little bit lost, where is the keyboard firmware update ?
A work in progress but folk are getting closer !. The latest ‘official’ release is v1.1. NOTE THIS INVOLVES A SLIGHTLY DIFFERENT METHOD TO INSTALL as flashes the ondoard STM32 microcontroller not your core modules flash !
Look in the ‘bin’ folder here for 1.1… note a 1.2 is in the works !
And have a butchers at this thread…
1 Like
Interesting one…
Sub keyboard
If inkey$<>“” then
Run “m.bas”
Endif
End sub
Just exits back to the command prompt even if no key is pressed ?
Picomite MMBasic RP2350A Edition V6.00.0 RC23. STM32 V1.2
Seems like you might have to put it in a loop?
The manual indicates that inkey$ returns immediately if the input buffer is empty, so if no key had been pressed, then your conditional will fail (since inkey$ == “”) and the run command won’t happen.
Sure I’ve used this before in this exact form and worked fine. ‘If inkey$ doesnt equal nothing’
Edit… loop until inkey$<>“” in another program working perfectly…
Edit2… replacing the gosub with ‘if inkey$<>“” then goto finish’ works every time !?
Maybe this is an issue exiting subroutines.
@DigitalDreams if I am understanding you problem report correctly then I think the issue is that the input buffer isn’t empty on entry, i.e. there is some stray key press already in it from earlier so it is finding that and returning immediately.
To deal with this I frequently write this construct:
Do While Inkey$ <> "" : Loop ' Clear existing input.
Do While Inkey$ = "" : Loop ' Wait for a new key to be pressed.
YMMV,
Tom
1 Like
You might think that but never had the issue with Inkey$ before, works fine outside a subroutine !. Checking inkeys$ now after every section of my program and ‘goto finish’, works every time…
Another difference here is the INPUT$() function.
According to the PicoMite manual, This will read up to X characters from a serial port or input buffer, but if there’s no data there, it will return an empty string.
However, the TRS-80 Model 100 manual (which documents that version of Microsoft BASIC), says that it will wait until the user has entered X characters.
I haven’t tested this yet, so I’m not sure if this matches the PicoMite manual (I’ve found other discrepancies already). But INPUT$ was intended to be similar to INKEY$, but will WAIT for input rather than return empty string and continue.
So, in theory, you could do
A$=INPUT$(1,#0); REM Read key from the keyboard
And the program would stop at this statement until 1 key is pressed.
Tested this. Ya, it works like the PicoMite manual says.
So
PRINT “INPUT”
A$=INPUT$(1,0)
PRINT “=”;a$;“=”
prints
INPUT
==
And does not wait for me to input something.
Which does not work like Microsoft BASIC (MS-DOS 2.1):
So…
function inputString$(len)
local result$, a$
result$=""
do
do while a$=""
a$=inkey$
loop
result$=result$+a$
a$=""
loop until len(result$) = len
inputString$ = result$
end function
This function will wait until len keystrokes are input before returning.
This probably needs some tweaking for the extra keystrokes generated by the shift, ctrl and alt keys.
The most recent release (RC23) no longer sends extra keystrokes for shift and ctrl. I left the extra keystroke in for alt, because it seemed like that was expected based on some programs I’d seen. (I guess because it was unlikely yo be typed when entering string input, unlike shift, and also because it may he used for navigating menus and maybe highlighting them when pressed.) Shift and ctrl never appeared in mainline PicoMite and they no longer appear as separate keypresses in the PicoCalc version either. That was a probkem in the way the PicoCalc reported keys.
1 Like
Also, if the differences between PicoMite/MMBasic and Microsoft BASIC are unintentional, then that would be best brought up on TheBackShed as a bug. Otherwise the PicoMite developer won’t see it if it’s posted here. And I don’t really know what the goals of PicoMite actually are, so this could actually be intentional behavior, especially since it seems to match the PicoMite documentation (though that could be a bug too, I guess?)