matherp said  

just a typo in the order of strings in overlaid_functions[] in functions.c compared to the enum in configuration.h

Thanks. I compared your current repo state to the last pull I had and I see what you're talking about.

I might not be able to learn from my own mistakes, but I can at least learn from other's. ;)
Edited 2025-06-06 01:53 by jkdelauney

Alternatively, allow the same x, y, x, y, w, h parameters in the Framebuffer copy? which already has the background option.
Edited 2025-06-06 02:20 by Bleep

  toml_12953 said  

When I run prog1, I get

[LIBRARY] const true=-1
Error : true variable already declared

I do have TRUE declared in my library but why is CHAIN trying to rerun the library commands?

Peter,
What do you think about the CHAIN command not running the normal code in the library. All other resources in the library (SUBs,FUNCTIONs,FONTs CSUBs) are still available to the chained program just the normal code it not run. The FLASH CHAIN command does not run the normal code. i.e. comment this line in do_chain()



Gerry

  Quote  

What do you think about the CHAIN command not running the normal code in the library.

This discussion stems from, IMHO, incorrect use of the library. It should be a repository of subroutines and functions that are , in effect extending the language. Again, IMHO, it should never contain executable main program code and definitely should not be declaring global variables without ON SKIP protection.
Disabling the library would mean that anything in the library would be inaccessible in the chained program. FLASH CHAIN is very different as it runs a pre-tokenised image. CHAIN loads from source and has to tokenise which means it rebuilds the subroutine tables.
In any event, unless any critical bugs are found in the next few days, the release is completely closed and I have already sent the binaries to Geoff ready for release.

I can't understand why you would even consider having executable code in the Library, especially trying to Chain to it as the Library routines (like all well-behaved subroutines and functions) should all be using their own local variables so there's no need for them to access the variables area of the previous program. The only reason to try that I can see is to see if it breaks. :)

  Mixtel90 said  

I can't understand why you would even consider having executable code in the Library, especially trying to Chain to it as the Library routines (like all well-behaved subroutines and functions) should all be using their own local variables so there's no need for them to access the variables area of the previous program. The only reason to try that I can see is to see if it breaks. :)

I like to initialize constants to be used in every program such as TRUE=-1, FALSE=0, etc. I also like to set OPTION BASE 1, OPTION ESCAPE and other temporary options.
The only problem is declaring the constants but now I get around it by doing this:

  Quote  

I like to initialize constants to be used in every program such as TRUE=-1, FALSE=0, etc. I also like to set OPTION BASE 1, OPTION ESCAPE and other temporary options.

Much better, in my view, to have a template that you use to create any new program and put these in the template rather than the library. No need for ON ERROR then. I seem to remember MMEDIT supports such a template?

If you don't use MMEDIT then it's easy enough to LOAD "template.bas" from SD card before you start programming.

Hello, I think I found a bug...

can anyone confirm this? I was trying the Keypad feature, see for yourself:












I tried also tried a different syntax, always the same. I am using as you can see a 128x64 LCD...
Because of the "display error" in Putty I also tried to do something like:



Problem persists. I have a 2 row by 3 column keypad.. I don't know what I am doing wrong.

row1 is: GP20
row2 is: GP21
col1 is: GP22
col2 is: GP19
col3 is: GP18

Greetings
Daniel

Obviously the error isn't right but manual page 55

  Quote  

The PicoMite firmware supports either a 4x3 keypad or a 4x4 keypad

Hello Peter,

thank you a lot for your reply! Ahh this is my bad. My PCB is already designed for an 2 by 3 row Keypad... Hm.. Ok. Then I have to do a redesign. I assumed, that it would be no problem to allow a smaller keypad. Sorry my bad  

Or is there a work-around possible?








I have some pins left, that I initially wanted to use for GPIO...


Greetings
Daniel
Edited 2025-06-07 01:34 by Amnesie

If you have two unassigned pins then just include these in the keypad command and your PCB will work fine. Otherwise just run the scan in a timed Basic interrupt
Edited 2025-06-07 01:36 by matherp

  matherp said  

If you have two unassigned pins then just include these in the keypad command and your PCB will work fine. Otherwise just run the scan in a timed Basic interrupt

Ah, thanks, good Idea! I know that a 2 by 3 keypad seems a bid odd, but I am saving one single pin at least   .. Hey there are projects in which every single Pin counts... so I thought, it would work with the built-in keypad function. But you gave me a good hint! Thanks!

Greetings
Daniel

Of course, in some cases you can get several buttons on a single ADC input by switching resistors. You can save a lot of pins like that. In practice you can probably get 4 or 5 buttons easily, more if your resistor tolerances are good.

Having trouble with BYVAL in latest RC. According to the manual changing the value in this test Sub should leave the original value unchanged. Or have I got it wrong?
If that is the case an example in the manual would make it clearer.

Edited 2025-06-07 12:05 by phil99

  phil99 said  

Having trouble with BYVAL in latest RC. According to the manual changing the value in this test Sub should leave the original value unchanged. Or have I got it wrong?
If that is the case an example in the manual would make it clearer.

> LIST
' Test prog 1
Dim integer a=5
 Print "a =";a
test

Sub test(BYVAL a As integer)
 If a = 5 Then
  a = 10
  Print "In Sub a =";a
 EndIf
End Sub

Print "After Sub a =";a
End
>
>
> RUN
a = 5
In Sub a = 10
After Sub a = 10
>

You're not using a as a parameter when you call test. Change test to test a.
If a isn't a parameter, it's global unless you define it as local in the sub.

Yes, me thick!

An example always help dimwits like me.
Edited 2025-06-07 13:23 by phil99

  phil99 said  

Yes, me thick!

An example always help dimwits like me.

Take some solace in knowing that most BASICs would give you an error for trying to call a SUB that takes parameters without supplying them. MMBasic assumes you'll just do it right. That makes it a lot harder to debug a large program when integers can get out of range without an error and SUBs can be called with missing parameters, among other non-existent checks.

  Quote  

Take some solace in knowing that most BASICs would give you an error for trying to call a SUB that takes parameters without supplying them. MMBasic assumes you'll just do it right. That makes it a lot harder to debug a large program when integers can get out of range without an error and SUBs can be called with missing parameters, among other non-existent checks.

MMBASIC must be better than "most BASICs"

  Quote  

When calling a subroutine you can supply less than the required number of values and in that case the missing values will be assumed to be either zero or an empty string.

Edited 2025-06-07 14:52 by TassyJim