Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 20:20 02 May 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 : CMM2: Next steps?

     Page 2 of 8    
Author Message
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3848
Posted: 03:25pm 23 Jun 2020
Copy link to clipboard 
Print this post

  abraxas said  Thank you so much, Mauro...


Ditto from me, that slab of source-code (in a style different from mine) is just what I need as a test example for my BASIC tokenizer. It was a bit of a fight to extract a .rar file though

  abraxas said  Honestly I haven't worked in an interpreted language for 3 decades so my intuitions are probably skewed by me not having to worry about parsing/interpreter costs in most of my developer experience.


I'm in the same boat, and its compounded by the fact that some of the optimisations I have read about for other BASICs make no difference in MMBasic. I have found it is even more important than usual to test the effects of an optimisation before applying it wholesale.

Regards,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
MauroXavier
Guru

Joined: 06/03/2016
Location: Brazil
Posts: 303
Posted: 04:41pm 23 Jun 2020
Copy link to clipboard 
Print this post

Soon I will upload a video with a demoscene, and the more important, with the source relatively well indented and documented. I believe that this can help some users.

About the MMBASIC speed, I would like to say some words about it.

Until now I have some performance problems with Gauntlet, and I have no doubt that it's me making some mistakes and the port from CMM to CMM2 had some bad optimization.

The Gauntlet, for now, is only 2x faster than the version for the original CMM, which doesn't make any sense. Can I blame the MMBASIC for this? Definitively no!

I must optimize more, organize the source code, and turn it in something readable to anyone.

I have no doubt that Gauntlet can reach almost 5x more gameplay performance if compared to the original CMM, and doesn't go beyond this because it's running at the same time some enhancements that don't exist in the CMM version, like the screen with a more colorful palette, playing music and sound effects emulating an SN76489 or playing in a digital format.

As said before, maybe make sense to claim that the performance of a CMM2 is like a C64 using machine language, but without the need to develop in low level, however, when studying more deeply the commands of this implementation of MMBASIC, I believe that soon the community will see that it's possible to create impossible things even for an Amiga 500, Mega Drive or SNES.

Like any console or old computers, it's only a question of time for the community extract the full potential of this marvelous machine.
Edited 2020-06-24 02:45 by MauroXavier
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 04:49pm 23 Jun 2020
Copy link to clipboard 
Print this post

  Quote   matherp said  
 thwill said  
Some way (any way) of being able to configure a set of BASIC programs that can be easily launched at the command line without need to specify RUN, quotes and a path


Sorry, but I just disagree with this one, having a "special case" directory or similar on the disk feels wrong. Typing RUN isn't so hard?


I'm really surprised I can't persuade you of this one, perhaps another example? I am writing a (for the moment minimal) MMBasic preprocessor. Which do you think would be the preferable way to run it:


Here is my final offer, valid for one day only  

I cut F11 and F12 to a maximum of 24 characters.
This allows me to create a new OPTION
OPTION PATH pathname$
example: OPTION PATH "/mydir/"
This has a maximum of 24 characters and must start and end with "/". i.e. it must be an absolute pathname
At the command line you can then type *fred
This will convert to RUN +chr$(34)+pathname$+fred+chr$(34)

i.e. RUN "/mydir/fred"

Note this will only look at the single directory specified in PATH (or the current directory if OPTION path is not set). It will not search the current directory if path is set.

Acceptable?
 
abraxas
Regular Member

Joined: 16/06/2020
Location: Canada
Posts: 99
Posted: 05:08pm 23 Jun 2020
Copy link to clipboard 
Print this post

  MauroXavier said  S

About the MMBASIC speed, I would like to say some words about it.

Until now I have some performance problems with Gauntlet, and I have no doubt that it's me making some mistakes and the port from CMM to CMM2 had some bad optimization.

The Gauntlet, for now, is only 2x faster than the version for the original CMM, which doesn't make any sense. Can I blame the MMBASIC for this? Definitively no!

I must optimize more, organize the source code, and turn it in something readable to anyone.


I have nothing but admiration and kudos and praise for the guys behind CMM1 and CMM2. That said, I think it's not borne by evidence that CMM2 is generally 10x faster than CMM1. For graphics based stuff that's implemented as ASM routines it might be. But general compute in BASIC is likely only about 2x faster as per your experience. There might be good reasons for it. Perhaps not much can be done to get it on a higher level but I doubt you can just tweak your code to get your MMBasic to run 5x faster vs CMM1 unless you do algorithm optimization in which case your code will be faster on CMM1 as well.

I really hope that Geoff might be able to some day give us a BASIC compiler or enhance the interpreter with a JIT so the performance of the CMM2 can get on par with something that would feel more like coding in Pascal or C on a 16 bit machine. In my experience that would be around 10x execution speed vs its speed right now. I think it's probably doable. No idea how challenging that would be. Compiler/JIT development is not a piece of cake.
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3551
Posted: 05:20pm 23 Jun 2020
Copy link to clipboard 
Print this post

  robert.rozee said  my first suggestion: do nothing, take a break. bugs will turn up, they always do, and my personal opinion is that for a while it would be a good idea just to see how it flys, fixing problems/bugs as they turn up. MMbasic has been around for a few years now, with various additions and improvements made over time. any major changes would just create confusion as the language deviated from the version that has already evolved.

cheers,
rob   :-)


I agree with Rob, leaan back !! as soon as the article is printed and people start to play with it, there will be questions that may lead to modifications.
This audience is an educated one, playing with MMbasic for years. The new adopters may have a way of looking at things that needs attention.

I do not have a CMM2, but things I can expect is the incompatibility with RPi hats (since you designed a compatible connector, people may expect it to be fully compatible). Things that need fixing in simple power-up defaults, but maybe more.

Matherp, you delivered a masterpiece, and now it will prove itself...

Volhout
PicomiteVGA PETSCII ROBOTS
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3848
Posted: 05:33pm 23 Jun 2020
Copy link to clipboard 
Print this post

  abraxas said  But general compute in BASIC is likely only about 2x faster as per your experience.


My experience with Z-MIM suggests general BASIC compute is at least 10x faster on the CMM2 over CMM1.

What I'm less convinced by is that general BASIC compute is at least as fast as the same computation in, for example, C-64 6502 assembler.

This isn't to dispute Mauro's assertion about the implementability of most/all 8-bit games on the CMM2 because except in edge cases for games the additional graphics performance should more than outweigh the general compute performance penalty.

Best Regards,

Tom
Edited 2020-06-24 03:33 by thwill
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3848
Posted: 05:35pm 23 Jun 2020
Copy link to clipboard 
Print this post

  Volhout said  I agree with Rob, lean back !! as soon as the article is printed and people start to play with it, there will be questions that may lead to modifications.


I actually concur with this, but Peter opened the door.

Best wishes,

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

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3848
Posted: 05:38pm 23 Jun 2020
Copy link to clipboard 
Print this post

  matherp said  Here is my final offer, valid for one day only   ... Acceptable?


If that is the only offer then I accept (as if I should be the one making the choice), however if you don't mind I'll drop you a PM on the subject once the kids have gone to bed which you can ignore or not as you feel appropriate.

Thanks for listening,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
MauroXavier
Guru

Joined: 06/03/2016
Location: Brazil
Posts: 303
Posted: 06:02pm 23 Jun 2020
Copy link to clipboard 
Print this post

  abraxas said  I think it's not borne by evidence that CMM2 is generally 10x faster than CMM1. For graphics-based stuff that's implemented as ASM routines it might be. But general compute in BASIC is likely only about 2x faster as per your experience.


Gauntlet has intense code optimized for the video capacity of the original CMM with many tweaks to circumvent the missing frame buffer.

I have not ported some parts of the source code, instead of it, I developed a little wrapper, what's more CPU intensive than a good native implementation. At that moment the intention was only to port it as soon as possible.

B-DASH, when fastly ported to CMM2 was impossible to play without an FPS limiter, and in my tests, the game goes beyond 10x faster than the original CMM. I will send a link with this version when I back to my house. If you have both CMM 1 and 2, you may compare it for yourself.
 
abraxas
Regular Member

Joined: 16/06/2020
Location: Canada
Posts: 99
Posted: 06:26pm 23 Jun 2020
Copy link to clipboard 
Print this post

  MauroXavier said  
B-DASH, when fastly ported to CMM2 was impossible to play without an FPS limiter, and in my tests, the game goes beyond 10x faster than the original CMM. I will send a link with this version when I back to my house. If you have both CMM 1 and 2, you may compare it for yourself.


One thing I want to ask about this... I noticed that in the demo version you don't have square monsters, butterflies or slime. So are you computing only what is visible on the screen? Because in a full Boulder Dash game we will have to iterate over the entire map on every game tick because baddies will be flying around, slime will be growing etc. I don't know if there is a way to efficiently eliminate iterating the entire map on every game tick. I mean, in most levels iteration over most tiles will result in a no-op most of the time but you still have to do the iterating over the whole board as bombs, butterflies and other baddies move all the time even when off screen.

And just the iteration over a 40x20 map takes at least 30ms in MMBasic on CMM2 (unless I really goofed in my test code). So a Boulder Dash remake with a big map (say 200x100) would spend 750ms just iterating the tiles. In which case that would likely make it unplayable. A map with half of the tile count (e.g. 10,000 tiles) might juuust work acceptably with 350ms per game tick.

In summary, is a Boulder Dash clone with levels by Peter Liepa doable on CMM2? Very likely. Is one that has a map an order of magnitude bigger also dobale? I'm not so sure. Not without dropping to ASM to improve the performance of the game loop.
 
MauroXavier
Guru

Joined: 06/03/2016
Location: Brazil
Posts: 303
Posted: 07:25pm 23 Jun 2020
Copy link to clipboard 
Print this post

  abraxas said  One thing I want to ask about this... I noticed that in the demo version you don't have square monsters, butterflies or slime. So are you computing only what is visible on the screen? Because in a full Boulder Dash game we will have to iterate over the entire map on every game tick because baddies will be flying around, slime will be growing etc. I don't know if there is a way to efficiently eliminate iterating the entire map on every game tick. I mean, in most levels iteration over most tiles will result in a no-op most of the time but you still have to do the iterating over the whole board as bombs, butterflies and other baddies move all the time even when off-screen.


I haven't implemented any monster, but in the same manner that I did to the diamonds and rocks, all things out of screen are processed too (wait for the falling rock on stage 2), but in a different way of the original code.

As you said, in the original implementation of the Bounder Dash it scans the entire map, but in my implementation, only the things that have movement are processed.

For example, in a map with a size of 40x40, you have 1600 blocks to be scanned, but let's imagine this same 40x40 map with 80 rocks, 15 monsters, and 50 diamonds, you have only 145 entities to be processed instead 1600.

In the cases of maps with the monsters that change to diamonds or maps with a huge quantity of entities we still have much less processed entities.

This is only a little trick, but for sure it's possible to use other optimizations to do exactly the same things as the original code.

Obviously this doesn't solve a map with 1000x1000, not because it is a huge map, but because probably it would have an immense quantity of entities to be processed.
 
cdeagle
Senior Member

Joined: 22/06/2014
Location: United States
Posts: 261
Posted: 07:27pm 23 Jun 2020
Copy link to clipboard 
Print this post

I would like the ability to pass the name of a MMBASIC function to a MMBASIC subroutine by way of the parameter list.

Implicit numerical calculations would also be handy and hopefully faster. For example

Vector2 = Matrix1 * Vector1

where Vector2 is a 3-element vector, Matrix1 is a 3-by-3 square matrix and Vector1 is a 3-element vector, for example.
 
MauroXavier
Guru

Joined: 06/03/2016
Location: Brazil
Posts: 303
Posted: 07:50pm 23 Jun 2020
Copy link to clipboard 
Print this post

  abraxas said  And just the iteration over a 40x20 map takes at least 30ms in MMBasic on CMM2 (unless I really goofed in my test code). So a Boulder Dash remake with a big map (say 200x100) would spend 750ms just iterating the tiles. In which case that would likely make it unplayable. A map with half of the tile count (e.g. 10,000 tiles) might juuust work acceptably with 350ms per game tick.

In summary, is a Boulder Dash clone with levels by Peter Liepa doable on CMM2? Very likely. Is one that has a map an order of magnitude bigger also dobale? I'm not so sure. Not without dropping to ASM to improve the performance of the game loop.


If you are not in a hurry and can wait to me finish four programs (Demo X, Dungeon Crawler, Final Fight, and Gauntlet), I accept this challenge.

What do you think about a playable Boulder Dash with a 200x200 map (yes, 40.000 tiles!), with a stage editor and other enhancements?

We can create a topic here when we start this project and open to all join and help too. Let's do it together?

I believe many people can learn some good tricks with a project like this.
 
Sasquatch

Senior Member

Joined: 08/05/2020
Location: United States
Posts: 296
Posted: 08:55pm 23 Jun 2020
Copy link to clipboard 
Print this post

I'll put in my vote for native Wii Classic Controller support!

Note that with the cable and PCB from an inexpensive Wii Classic Controller it should be possible to interface most any type of retro joystick/controller or even build a proper arcade style console with arcade style microswitch joystick and buttons.  I do agree that we should come up with some kind of "standard" connections so that every game does not need to be tweaked for inputs.

-Carl
-Carl
 
abraxas
Regular Member

Joined: 16/06/2020
Location: Canada
Posts: 99
Posted: 09:45pm 23 Jun 2020
Copy link to clipboard 
Print this post

  MauroXavier said  [
We can create a topic here when we start this project and open to all join and help too. Let's do it together?


I messaged you in private about this, Mauro. I didn't want to pollute this thread any more. But in short, yeah I'm up for it with the caveats that I mentioned in the PM. In case you're also aboard start a new top level thread about it!
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1082
Posted: 10:23pm 23 Jun 2020
Copy link to clipboard 
Print this post

May I put in a request for clipping regions?

Let me explain...

If I enter
LINE 50,-100,200,700
I get the line I expect. (Well, mostly. It shows the same off-screen error I found with BOX and CIRCLE.)
The line has been clipped to the screen.

Now suppose I wish the confine my drawing to just a section of the screen, perhaps called a window?  ;-)
If my window is, for example, defined by [BOX 100,75,250,200], then I only want that portion of the above line that is inside the box. Yes, I could write a mess of code to figure out the (possible) intersection points of the line and the box and then draw my line segment inside the box.

But when I expand that to circles (0,2,4,6,and 8 possible intersections), boxes, triangles, polygons and add fill, drawing becomes rather unmanageable.

A bit of thinking outside the box (or in this case, the page) suggests an easy solution: draw on a different page and then just blit the window region to the desired drawing page.

However, this leaves one command out in the cold, so to speak. The PRINT statement. Ideally, the PRINT statement should respect the clipping region too. Printing stuff while the clipping region is active should result in text wrapping and scrolling only in the region. (Thwill might appreciate this with his Z-MIM project because then he could easily display different interpreter output in different windows.) The TEXT command would obey clipping the same as it does now with full screen clipping.

I expect deep in the firmware, the drawing routines call a DrawPixel function that compares the requested pixel x and y coordinates to [0,MM.HRES] and [0,MM.VRES] and if it's within that range, the pixel can be plotted. Perhaps a clipping region could be easily implemented by allowing those plotting limits to be reduced as desired:
CLIPREGION x,y,w,h
CLIPREGION OFF
A slight unknown is what behaviour should be expected with printing in a clipping region that is partially off screen. We know from using our big computers that text happily scrolls in a window that is partially off screen and the off screen part is there, just not visible. It did not wrap at the edge of the visible screen. But that might be asking too much. The simple case is that the clipping region can only shrink the 'virtual' edge of the screen inwards. (This also means that CLIPREGION 0,0,MM.HREX,MM.VRES would have no effect.)

Another feature is that creative use of clipping regions would allow the drawing of arc sections of ellipses, something not easily possible now given that the arc command does not include an aspect ratio parameter.

Thank you for the opportunity the offer suggestions.
Visit Vegipete's *Mite Library for cool programs.
 
damos
Regular Member

Joined: 15/04/2016
Location: Australia
Posts: 56
Posted: 12:12am 24 Jun 2020
Copy link to clipboard 
Print this post

I would kill for better data capabilities. Being used to .Net and super powerful LINQ capabilities, it can be limiting. Now there is so much space, there is potential to write really big programs and the limiting factor will be how data is handled.

I accept that a jump to object oriented is too big a step, but basic JSON support would be seriously helpful. Particularly the ability to serialize and deserialize. For example, person = JSON.Deserialize("{Name:'Fred', Age:21, Address: 'Evergreen Tce'}") could produce an individual string with the name person.Name="Fred", integer person.Age=21 and person.Address = "Evergreen Tce". Even at this level it is really useful as it allows setting to be saved or retrieved from files.

An enhancement to that would allow the Deserializing of arrays. person[5].Age when there is an array in the Json data. This is becoming object oriented, so it may be easier to return separate arrays: person.Name[], person.Age[], etc.

I think it is fine to only go one level deep. person.Address could be retrieved as the string {Street: "Evergreen Tce", Town: "Springfield", Zip: 90210}. If we need the values inside person.Address, we just Deserialize again.

The reverse is serializing. In this case string json = JSON.Serialize(person) will take all variables the start with "person." and serialize them into a JSON string.

These are just 2 new functions and make no underlying changes to the structure of the language.
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2794
Posted: 12:24am 24 Jun 2020
Copy link to clipboard 
Print this post

Duplicate post
Edited 2020-06-24 10:27 by WhiteWizzard
For everything Micromite visit micromite.org

Direct Email: whitewizzard@micromite.o
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 04:56pm 24 Jun 2020
Copy link to clipboard 
Print this post

re: comments from cdeagle

  Quote  I would like the ability to pass the name of a MMBASIC function to a MMBASIC subroutine by way of the parameter list.


The first can already be done using the eval function e.g.

cls
subtorun$="atan2"
? topsub(4,5,subtorun$)
subtorun$="MYSUB1"
? topsub(4,5,subtorun$)
end
'
function topsub(a,b, c$)
local d$=c$+"("+str$(a)+","+str$(b)+")"
print d$
pause 2000
topsub=eval(d$)
end function
'
function mysub1(x,y)
mysub1=x+y
end function


Note: in 5.05.03 user functions passed to eval must be all capitals. This is fixed in 5.05.04b1c

  Quote  Implicit numerical calculations would also be handy and hopefully faster. For example

Vector2 = Matrix1 * Vector1

where Vector2 is a 3-element vector, Matrix1 is a 3-by-3 square matrix and Vector1 is a 3-element vector, for example.


This one interests me a lot. My thinking is to have a single top level command MATH with multiple subcommands e.g. MATH MATRIX_MUL
However, I will need help to:
Define the most common and useful functionality
Establish sensible syntax for the various subcommands
Provide sample code for the actual math (Basic or C)
Test the results.
NB: This will be a set of commands rather than functions as MMbasic doesn't support arrays as function returns. However, all variable passing in MMbasic is by reference so results can be returned in one of the supplied variables.

Example:

MATH VECTOR_MUL vector1!(), matrix!(), vector2!()

cdeagle, if you want to pursue this further PM me and then I'll send my email address rather than doing everything on the forum
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5910
Posted: 05:42am 25 Jun 2020
Copy link to clipboard 
Print this post

Extend the GPS passer to handle $GNxxx messages.
My GPS (Ublox) puts out $GNGGA headers instead of $GPGGA so the passer is not happy.
The message is identical, just the ID that signifies a common message for a variety of GPS systems.
Similar for $GNRMC instead of $GPRMC

I think those are the only two you use.

Sample output form a UBlox 8M

$GNGGA,044608.00,4107.56684,S,14554.47713,E,1,07,1.72,252.6,M,-8.5,M,,*4D
$GNGSA,A,3,09,04,16,05,,,,,,,,,2.70,1.72,2.07*17
$GNGSA,A,3,72,73,65,,,,,,,,,,2.70,1.72,2.07*1A
$GPGSV,3,1,09,03,00,012,10,04,46,063,16,05,13,220,29,07,62,250,25*78
$GPGSV,3,2,09,08,21,063,,09,85,101,14,16,30,134,34,27,23,098,20*7C
$GPGSV,3,3,09,30,32,274,*43
$GLGSV,2,1,08,65,31,215,29,71,45,021,,72,77,243,19,73,48,148,33*6B
$GLGSV,2,2,08,74,74,235,21,75,25,302,,82,05,155,,83,02,112,*6B
$GNGLL,4107.56684,S,14554.47713,E,044608.00,A,A*68
$GNRMC,044609.00,A,4107.56704,S,14554.47716,E,0.908,228.89,250620,,,A*69
$GNVTG,228.89,T,,M,0.908,N,1.682,K,A*26
$GNGGA,044609.00,4107.56704,S,14554.47716,E,1,07,1.72,252.6,M,-8.5,M,,*40
$GNGSA,A,3,09,04,16,05,,,,,,,,,2.70,1.72,2.07*17
$GNGSA,A,3,72,73,65,,,,,,,,,,2.70,1.72,2.07*1A
$GPGSV,3,1,09,03,00,012,10,04,46,063,15,05,13,220,29,07,62,250,25*7B
$GPGSV,3,2,09,08,21,063,,09,85,101,12,16,30,134,34,27,23,098,20*7A
$GPGSV,3,3,09,30,32,274,*43
$GLGSV,2,1,08,65,31,215,29,71,45,021,,72,77,243,18,73,48,148,33*6A
$GLGSV,2,2,08,74,74,235,20,75,25,302,,82,05,155,,83,02,112,*6A
$GNGLL,4107.56704,S,14554.47716,E,044609.00,A,A*65
$GNRMC,044610.00,A,4107.56677,S,14554.47710,E,0.148,,250620,,,A*79
$GNVTG,,T,,M,0.148,N,0.274,K,A*31
$GNGGA,044610.00,4107.56677,S,14554.47710,E,1,07,1.72,252.5,M,-8.5,M,,*48


Jim
VK7JH
MMedit   MMBasic Help
 
     Page 2 of 8    
Print this page
© JAQ Software 2024