Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 20:54 27 Apr 2024 Privacy Policy
Jump to

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 4.4 Beta 6

     Page 1 of 2    
Author Message
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 12:00am 25 Jun 2013
Copy link to clipboard 
Print this post

Hi again,

I have added the last of the requests to MMBasic and this needed another beta test version.
It can be downloaded from: http://geoffg.net/Downloads/Maximite/MMBasic_4.4_Beta_6.zip

New in this version is:
- You can now specify a subroutine (without parameters) for any interrupt (SETTICK, SETPIN, etc).
- Added support for Spanish keyboards (CONFIG KEYBOARD ES).
- Fixed a bug with the LENGTH keyword in DIM that sometimes caused MMBasic to crash.
- The SPRITE COPY command now does not require the sprite to be turned OFF. If the sprite is ON the copy command will do the equivalent of SPRITE OFF, then COPY, then ON.

These are in addition to the features in the previous beta (see this post for details).

Please give it a run and let me know if you find anything wrong.

Geoff
Geoff Graham - http://geoffg.net
 
panky

Guru

Joined: 02/10/2012
Location: Australia
Posts: 1094
Posted: 03:15am 25 Jun 2013
Copy link to clipboard 
Print this post

Hi Geoff,

Trying to run some tests on 4.4beta 6 but it is unclear to me how SETTICK can be used as a subroutine? Do you have example code demonstrating the new functions/commands?

Do you have a test suite that could be used?

I have a CGCMM1 and a Duinomite mega that I can test on.

Cheers, Doug.



... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it!
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 04:05am 25 Jun 2013
Copy link to clipboard 
Print this post

The interrupt routine can be a subroutine (not SETTICK itself).

For example:
SETTICK 1000, MySub ' interrupt every second and call MySub

DO : LOOP ' keep MMBasic busy doing nothing

SUB MySub ' this is the interrupt subroutine
PRINT "x";
END SUB

This would print an x on the screen every second.

Geoff
Geoff Graham - http://geoffg.net
 
cwilt
Senior Member

Joined: 20/03/2012
Location: United States
Posts: 147
Posted: 06:27am 25 Jun 2013
Copy link to clipboard 
Print this post

Geoff,

Thanks for adding the use of subs to the interrupts. I will give a whirl shortly.
 
Juri74

Senior Member

Joined: 06/02/2012
Location: Italy
Posts: 162
Posted: 11:00pm 26 Jun 2013
Copy link to clipboard 
Print this post

  Geoffg said   The interrupt routine can be a subroutine (not SETTICK itself).

For example:
SETTICK 1000, MySub ' interrupt every second and call MySub

DO : LOOP ' keep MMBasic busy doing nothing

SUB MySub ' this is the interrupt subroutine
PRINT "x";
END SUB

This would print an x on the screen every second.

Geoff

That's great!
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 12:14am 27 Jun 2013
Copy link to clipboard 
Print this post

Geoff,

With the current addition of calling subroutines from interrupts, which is great, a programmer could now make an entire program event driven.

Using an interrupt when the user presses a key, timers, and hardware interrupts.
A program will setup its variables, interrupts and then 'sleeps'.
Now it is done with:
[code]
DO: LOOP
[/code]

This will keep the MMBasic interpreter doing a lot of work effectively doing nothing, only wait.
Would there be a way to put the Maximite into some kind of sleep mode, only to be woken up when a interrupt (that is setup in the program) is used.
A HALT command?

Stopping a program would still be the same, by a CTRL+C or an END statement in the program.

Microblocks. Build with logic.
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3659
Posted: 12:32am 27 Jun 2013
Copy link to clipboard 
Print this post

But it's bit-banging ports so the interpreter is busy, isn't it?

John
 
kiiid

Guru

Joined: 11/05/2013
Location: United Kingdom
Posts: 671
Posted: 01:01am 27 Jun 2013
Copy link to clipboard 
Print this post

  TZAdvantage said  
Would there be a way to put the Maximite into some kind of sleep mode, only to be woken up when a interrupt (that is setup in the program) is used.
A HALT command?


This is going well in the embedded control direction now
I support the request. Actually had that in my plans, even informed Geoff about that, but in case he likes the idea, it would be great to have it in the standard MMBasic. Low-power is a fashion today.
It may need a bit of work there though and I am not sure is it going to happen in this exact version.
http://rittle.org

--------------
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3659
Posted: 01:45am 27 Jun 2013
Copy link to clipboard 
Print this post

So what about all the things the interpreter does besides executing Basic statements?

John
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 01:56am 27 Jun 2013
Copy link to clipboard 
Print this post

  JohnS said   But it's bit-banging ports so the interpreter is busy, isn't it?

John

Yes it is bitbanging but with a DO: LOOP the interpreter is first interpreting the DO, then the LOOP, then the DO, THEN the LOOP etc... leaving less time and using more power then necessary.
Maybe with newer chips and certainly already with the Mono Maximite there are serial peripherals in use that can work on an interrupt basis.
The color Maximite has less 'power' in that category as so much is used to generate the color VGA. Many embedded solutions work better with a Mono Maximite because of that.

Any step, small as it seems, to optimize the working of MMBasic is worthwhile because it will leave more processing time and cost less power and heat. As long as it is possible of course because sometimes changes look simple but can be very difficult to implement.


Edited by TZAdvantage 2013-06-28
Microblocks. Build with logic.
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 04:11am 27 Jun 2013
Copy link to clipboard 
Print this post

As has been pointed out, MMBasic is doing a lot of work while apparently "doing nothing" executing an empty DO : LOOP.

On an associated topic, I recently attempted implementing a sleep mode and had to discard it. The problem is that to effectively reduce power consumption during the sleep period the firmware had to shut down the peripherals (SPI, DMA, timers, etc) and then, when the processor came out of sleep, reconfigure them to their exact state before the shutdown. This was not easy and had all sorts of unwanted side effects.

Geoff
Geoff Graham - http://geoffg.net
 
cwilt
Senior Member

Joined: 20/03/2012
Location: United States
Posts: 147
Posted: 04:40am 27 Jun 2013
Copy link to clipboard 
Print this post

I wrote a binary clock display which does exactly that last night. The module is loaded, a subroutine is called which sets the interrupt and then a DO: LOOP is all that is left. Once I clean up the code I will copy it here.
  TZAdvantage said   Geoff,

With the current addition of calling subroutines from interrupts, which is great, a programmer could now make an entire program event driven.

Using an interrupt when the user presses a key, timers, and hardware interrupts.
A program will setup its variables, interrupts and then 'sleeps'.
Now it is done with:
[code]
DO: LOOP
[/code]

This will keep the MMBasic interpreter doing a lot of work effectively doing nothing, only wait.
Would there be a way to put the Maximite into some kind of sleep mode, only to be woken up when a interrupt (that is setup in the program) is used.
A HALT command?

Stopping a program would still be the same, by a CTRL+C or an END statement in the program.
 
Dylan
Regular Member

Joined: 17/06/2013
Location: Netherlands
Posts: 81
Posted: 07:52am 27 Jun 2013
Copy link to clipboard 
Print this post

  Geoffg said   As has been pointed out, MMBasic is doing a lot of work while apparently "doing nothing" executing an empty DO : LOOP.

On an associated topic, I recently attempted implementing a sleep mode and had to discard it. The problem is that to effectively reduce power consumption during the sleep period the firmware had to shut down the peripherals (SPI, DMA, timers, etc) and then, when the processor came out of sleep, reconfigure them to their exact state before the shutdown. This was not easy and had all sorts of unwanted side effects.


Geoff, on the ZX81 there were "FAST" and "SLOW" modes. Back then generating video effectively reduced the 4MHz Z80 to a quarter of that, and DMA video on an 80Mhz PIC32 only costs 3% or so performance.

Wouldn't it make more sense to "invalidate" all peripherals once slow mode is entered? Excluding interrupts to reawake the device, of course.

I've only compiled 2.7, so there might be big changes, but it starts off at $BFC0: and then immediately jumps twice (i.e. redundantly) using the free (GCC) compiler. How much the reason for restart is looked at I can't yet judge.
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 08:55am 27 Jun 2013
Copy link to clipboard 
Print this post

  Geoffg said   As has been pointed out, MMBasic is doing a lot of work while apparently "doing nothing" executing an empty DO : LOOP.

On an associated topic, I recently attempted implementing a sleep mode and had to discard it. The problem is that to effectively reduce power consumption during the sleep period the firmware had to shut down the peripherals (SPI, DMA, timers, etc) and then, when the processor came out of sleep, reconfigure them to their exact state before the shutdown. This was not easy and had all sorts of unwanted side effects.

Geoff

The HALT command on a Basic Programming level is a good command to let the interpreter know that the Basic program is not executing statements.
That time can be used by the underlying interpreter/firmware for other tasks.
What is useful in the basic language is that the programmer actively makes the choice to do 'nothing' until an interrupt occurs.
There is no more program 'flow'. Only events (interrupts) from that moment on can make the program respond.

Basically now you have two choices. a DO: LOOP and then the program can only be stopped with a CTRL+C or variations of
[code]
WaitLoop:
DO
A$=INKEY$
LOOP UNTIL A$<> ""

IF A$ = "Q" then END 'Or go somewhere to close down the program orderly.
' Handle other keyboard input.

goto WaitLoop
[/code]

With a HALT you get a third choice, and i think the most 'clean' one that separates functionality very nice.
[code]
BackgroundColor = 0

ON KEY OnKeyEvent
SETTICK 1000, ShowTime
SETPIN 20,6, onPin20High
SETPIN 20,7, onPin20Low
HALT

SUB OnKeyEvent
A$=INKEY$
IF A$ = "Q" then END 'Or go somewhere to close down the program orderly.
' Handle other keyboard input.
END SUB

SUB ShowTime
COLOR 7, BackgroundColor
CLS
PRINT TIME$
END SUB

SUB OnPin20High
BackgroundColor = 1
END SUB

SUB OnPin20Low
BackgroundColor = 0
END SUB

[/code]
The ON keyword is a perfect reserved word for defining interrupt. It would be very clean if all interrupt generating capabilities can be used from the ON keyword.
ON KEY target
ON PIN pin, HIGH|LOW|CHANGE, target
ON TIMER 1|2|3|4, period, target
etc..

Maybe future:
ON COM 1|2|3|4, READ|WRITE, length, target
ON USB....
ON MOUSE....

Edited by TZAdvantage 2013-06-28
Microblocks. Build with logic.
 
kiiid

Guru

Joined: 11/05/2013
Location: United Kingdom
Posts: 671
Posted: 01:11pm 27 Jun 2013
Copy link to clipboard 
Print this post

  Geoffg said   As has been pointed out, MMBasic is doing a lot of work while apparently "doing nothing" executing an empty DO : LOOP.

On an associated topic, I recently attempted implementing a sleep mode and had to discard it. The problem is that to effectively reduce power consumption during the sleep period the firmware had to shut down the peripherals (SPI, DMA, timers, etc) and then, when the processor came out of sleep, reconfigure them to their exact state before the shutdown. This was not easy and had all sorts of unwanted side effects.

Geoff


Geoff, actually it may not be very hard if we change the point of view slightly. A SLEEP (or HALT as TZA calls it) command would not have any particular usage in the MM when used as a desktop computer system. Such command is most helpful when used in battery-operated systems in order to reduce the power consumption. But those systems often are completely closed to the outside world and rarely require any interaction with the end user.
So, I think it would be much easier if the SLEEP command just stop all the peripheral systems (such as SPI, timers, etc) until the desired event happen. This obviously means there won't be any video, PS2, sound and similar things during the sleep, but that is alright as it does exactly what a sleep command should do - reduce power.
Probably the only notable "wakeup" events to be monitored in this case are USB activity, change on port pin and expired time.
Then the main loop in MMBasic could continue from the sleep point onwards and simply re-initialise most of the hardware (such as video, DMA, etc) except for the very few things which are directly used in the code execution.



http://rittle.org

--------------
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 01:31pm 27 Jun 2013
Copy link to clipboard 
Print this post

After thinking about it for a while it think HALT and SLEEP should have different meanings.

HALT just stops executing and wait for events (interrupts) happening on the ON KEY, SETTICK, SETPIN commands settings defined by the program. No peripherals switched off or anything to reduce power usage. Just a command to instruct Basic that instead of going to the ready/edit mode stay in running mode, without having statements to run.

SLEEP puts the system in sleep mode to conserve power.
Very useful when battery/solar operated. And all the points Kiiid made.
Microblocks. Build with logic.
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 05:33pm 27 Jun 2013
Copy link to clipboard 
Print this post

  kiiid said  Then the main loop in MMBasic could continue from the sleep point onwards and simply re-initialise most of the hardware (such as video, DMA, etc) except for the very few things which are directly used in the code execution.

That was my point, it was not a case of "simply re-initialise".

  TZAdvantage said  HALT just stops executing and wait for events (interrupts) happening on the ON KEY, SETTICK, SETPIN commands settings defined by the program. No peripherals switched off or anything to reduce power usage. Just a command to instruct Basic that instead of going to the ready/edit mode stay in running mode, without having statements to run.

Why not just use an empty DO : LOOP ? If something goes into the language it must deliver real value to a lot of people.

Geoff Graham - http://geoffg.net
 
kiiid

Guru

Joined: 11/05/2013
Location: United Kingdom
Posts: 671
Posted: 06:22pm 27 Jun 2013
Copy link to clipboard 
Print this post

  Geoffg said  That was my point, it was not a case of "simply re-initialise".


Can you be more specific? Where exactly is the problem?
There are a lot of people around who are willing to help and a few minds might come to a solution otherwise invisible to one.
http://rittle.org

--------------
 
MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209
Posted: 11:30pm 27 Jun 2013
Copy link to clipboard 
Print this post

  Geoff said  
Why not just use an empty DO : LOOP ? If something goes into the language it must deliver real value to a lot of people.

Opinions and experience differ so real value is different for everyone.
I like a language to use keywords to do a certain task.
It is much more easy to read and program.
An empty DO:LOOP is a hack because of a missing HALT or similar statement.

When interrupt handling is used in a program, HALT is one of the things that is missing.
The implementation in the firmware can be easy, like an indefinite PAUSE and if the need arise be extended to free up processor time and more difficult things like powering down, etc.
As such it is also a placeholder for future improvements.

I have given examples in my post on 28 June 2013 at 1:55am.


Microblocks. Build with logic.
 
Juri74

Senior Member

Joined: 06/02/2012
Location: Italy
Posts: 162
Posted: 01:32am 28 Jun 2013
Copy link to clipboard 
Print this post

hello! i think i found a bug.. please try this little program

Mode 4
Dim a(10000)


run it, it should run fine.. after program is finished you will remain in MODE 4
now, at command prompt issue a "MODE 3" command..

you will be placed in an "UNDOCUMENTED" graphic mode, a mix up of mode 4 and (i presume) mode 3...

fascinating!

graphics will corrupt if you go under the bottom of the screen and let it scroll up!

Juri
 
     Page 1 of 2    
Print this page
© JAQ Software 2024