 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 1 of 8   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8566 |
I know I'm going to regret starting this thread but.......  I'm interested in views on how or if to take the CMM2 forward. I'm not talking about changes to the concept, major structural changes to the language, or changes to the H/W design - these are fixed, but about things that may make it better both from the perspectives of its educational use and its enjoyment as a "retro" style computer. Ideas can can range from the simple: e.g. implement a BLIT ARRAY sub-command to output to the screen directly from an array (could be useful for ray-tracing) to the more complex: implement a MATH command with multiple subcommands for things like matrix manipulation, complex arithmetic, scaling vectors (ray tracing again) etc. What I can't do is increase the number of commands or functions significantly so ideas have to use and extend existing syntax rather than changing or adding to it. For a number of reasons I'm currently ruling out CFunctions or embedded assembler so think about where you might want a CFunction and if that functionality could be incorporated into the language (e.g. the MATH concept) In general interpreted Basic is most inefficient when the ratio of the effort to parse a command is significantly greater than the processing needed to execute. So, for example, in the case of many of the graphics commands coding entirely in C would have almost no advantage as the parsing overhead is trivial compared to the work to execute, whereas A=A/B is entirely dominated by the effort of parsing as is evidenced by the limited speed advantage of using integers even on MM without floating point processors. Support for additional sensors or external devices should only be suggested if there is something about a device that means it can't be coded in Basic. For example, The BME280 is a bit complex to interface but there is nothing that can't be done in Basic and once a BME280 I/F subroutine is available then it can be shared as an INCLUDE file. Contrast this to the (already supported) WS2812 which simply can't be coded in Basic as the timings are too fast and specific. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Peter, Something to make the File Manager (FM) more ‘user friendly’ when viewing an image file: Select image file using up/down/enter (as current) and display the image. Upon pressing any key in keyboard, return to the FM in the same position (ie highlighting the image file you just viewed). This allows the user to preview multiple images (one after another) rather than having to re-enter the FM and scroll down each time). I will keep thinking of other stuff!!! For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5880 |
You are a sucker for punishment. OPTION AUTORUN filename$ To always run a fixed program on startup. (or bring back autorun.bas) Recently I wanted to transfer a program from micromite to the F4 but the program used BITBANGER CSUB. I could use the DAC function but it means using the DAC pins. The same would happen with the CMM2. Doable in Basic but better if able to use any pin. Useful for controlling remote power switches etc. The ability to set an alarm would be nice as an extension to TIME$ TIME$ = some-ungodly-hour$, ALARM1,loudMusicSub Jim VK7JH MMedit  MMBasic Help |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 425 |
hi peter Hello I come back with my old fantasy, that of adding a structured data type, as in VB6 for example TYPE article code as string * 5 name as string * 30 you have integer price as float END TYPE dim tmarticle (20) as article dim nbarticle as integer and in programs we can write dim tot as float tot = 0 for i = 1 to nbarticle tot = tot + tmarticle(i).qte * tmarticle(i).price next i print tot |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8566 |
Edited 2020-06-23 19:13 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
You'll probably hate this one and maybe it's just because of my work on Z-MIM, Short form syntax for peeking/poking bytes into arrays e.g. a = ?b ' equivalent to: a = Peek(Var b, 0) a = ?(b+5) ' equivalent to: a = Peek(Var b, 5) ?b = a ' equivalent to: Poke Var b, 0, a ?(b + 5) = a ' equivalent to: Poke Var b, 5, a Yes this is BBC micro syntax  Regards, Tom Edited 2020-06-23 19:29 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
This was my first post, which somehow went astray. You are a brave man Peter, OPTION SHIFT F<num> string$ Allow the user to define strings to be generated by shifted function keys and/or allow all the unshifted functions keys to be defined and provide an option to return them to their defaults. Is there a (quite short) limit on how long OPTION F11/F12 allows the generated strings to be? #ifdef, #ifndef, #else, #endif, #define I'm not proposing the full C++ preprocessor support, i.e. macros, etc. Just enough to support conditional inclusion or exclusion of sections of code in what is eventually executed. I know we can do control flow with BASIC commands but we then have to pay the cost of parsing those branches/switches. 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 e.g. *find <file>, *sort <file>, *zmim A common interface for the ubiquitous USB game pads This requires specification of a standard piece of hardware to plugin to the GPIO containing connectors for 2 or 4 USB gamepads and a standard way of reading them ... might need another command/function  or perhaps NUNCHUK can be extended.Can NUNCHUK have an alias without using up a precious command slot. Regards, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Actually I didn't get it quite right, but there's no need to fuss the details correct if the whole idea is a non-starter. Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
An additional syntax to IMAGE ROTATE and IMAGE RESIZE commands to turn off the interpolation to speed up things. With this, I can slice parts of a video page and zoom in to help with textures with perspective (a raycaster with texture, for example). With the current implementation, the software interpolation turns it impossible to use it in real-time. An example: IMAGE ROTATE x, y, width, height, new_x, new_y, angle, [page_number], [interpolation flag] Now I know that I will ask to a complex (and probably slow) thing... With a BLIT READ or BLIT ARRAY you could use it as a texture in a polygon: POLYGON N%(), X%(), Y%(), LC%(), FC%(), #1 But in this case, the polygon must have 4 vertexes else will give an error. Edited 2020-06-23 21:24 by MauroXavier |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8566 |
Done - watch for the next beta release, will even play a mp3 while showing an animated gif and return to the filemanager as if nothing has happened  The battery backed registers in the RTC domain I use for storing options are full so these aren't possible. I don't want to go back to writing options to flash for various reasons. A simple version of this may be possible. How about just: #debug #nodebug, #ifdebug #endifdebug Check out LGETBYTE in the manual - you need the latest version off Geoff's site Could also add LONGSTRING SETBYTE n,byte% Remember commands and functions are tokenised to a single byte so there is no issue with the Basic statement looking wordy and no advantage to cryptic syntax 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? This is a major H/W development and nothing to do with the CMM2 specifically. What is possible is adding support for the Wii Classic Controller which uses the same connector as the Nunchuk and is also controlled over I2C I don't know how you could do a rotate without interpolation - can you point me at any code? Even resize with pixel binning is likely to look terrible. I'm thinking about how MMbasic could optimise raytracing so you can write a Wolfenstein and we could discuss this off line. |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1325 |
Peter you are definitely a glutton for punishment, but we can't help loving you for it  !I note your comment at the bottom of your opening post re the BME280. The BME280 certainly can be coded in basic as you posted for us all a couple of years ago, but given the work you did to achieve that and the comments you made about the complexity of it at the time, I'm sure I couldn't have done it! Back on 10th May I posted some Micromite+ code plotting wireless Digoo and BME280 data here. About half of those several hundred lines were your code to access the BME280 data. The bit manipulation going on there is way beyond me and makes a lot of the code pretty unreadable. If it were put in an INCLUDE file that would do the job but it's not 'neat'.  Ducking in anticipation: Greg |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Hi Peter, Dang! Better than nothing, but I would prefer a "bit" more flexibility rather than a binary choice. Note that even with your minimal version I think you also need a #else and/or #ifnodebug LSETBYTE perhaps, otherwise it doesn't seem to offer any advantages over POKE. Didn't know this. So when we RUN you are more than "crunching it", you are actually sending a tokenised version to the flash for execution? I appreciate brevity, but accept YMMV. 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: RUN "/tools/mmpp/mmpp.bas" "myfile.bas" or: *mmpp "myfile.bas" and if it makes a difference imagine that you had a couple of dozen such tools. The fact that we are limited to two user-defined Fn keys exacerbates the issue. Rather than a special-case directory we would probably be better off with a special top-level file that contains (name -> path/command-line) mappings. OK. I just think that whilst many of TBS denziens can no doubt wire up all manner of weird and wonderful input devices to the GPIO and write software to use them, unless you and/or Geoff define a standard (supporting at least 2 controllers) with a proper connector then there is nothing (other than a single Nunchuck) for game developers to work with and less hardware orientated potential users will be put-off. Regards, Tom Edited 2020-06-23 23:39 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| abraxas Regular Member  Joined: 16/06/2020 Location: CanadaPosts: 99 |
I hate to be "that guy" but unfortunately last night I realized that MMBasic might just be too slow without the ability to drop to ASM or interface with C. Would it be possible to add a C compiler to the OS or a BASIC compiler to speed up the program's execution? Yeah, I know it's a BASIC driven machine and it's not supposed to be able to squeeze every last bit of performance out of the hardware... The problem is that the interpretation penalty might be too high even for trying to develop certain compute intensive 8-bit style games. Last night I sat down to start on a "Boulder Dash" clone and started by thinking "hey with all this power maybe it will go beyond classic Peter Liepa levels and I'll add an adventure mode spanning hundreds of tiles horizontally and vertically..." RUDE AWAKENING! I wrote a simple routine to iterate an array simulating computation of a BDash game loop and was in for a surprise. MMBasic interpretation costs dwarfed everything else. At the end of the post I posted my test program and its timing results. As you will see in there it takes over 35ms to iterate once over an array of 40x24 characters (without doing any real game computation) . After adding all the game logic I expect this number to grow 5-10x once all the different tile types are handled in their own SUBs and their interactions with adjacent tiles are computed. That will put the compute logic at 350ms per game tick and that's just with Peter Liepa sized levels. Gone are my dreams of much larger tilemaps for new types of gameplay. With the way things are now we have super fast drawing routines and very slow general compute and my worry is that CMM2 will end up with game titles that are very visually appealing but not terribly interesting to play. There might not be enough time to compute complex logic unless we can drop to ASM or add C routines for processing the innermost loops or have the ability to simply compile our BASIC programs to gain an extra performance boost. Anyway here's my test code and its output using my CMM2 (400MHz version FWIW): DIM level$(24) LENGTH 40 level$(0) = "W.WWWWWWwWWWWWWWWWWWwwWWWWWWWWWWWWWWWWWW" level$(1) = "w...W........W.....wwwwwwww............x" level$(2) = "w...Wxx..x..........X.......W........W.." level$(3) = "w...W........W.....wwwwwwww............x" level$(4) = "w...Wxx..x..........X.......W........W.." level$(5) = "w...W........W.....wwwwwwww............x" level$(6) = "w...Wxx..x..........X.......W........W.." level$(7) = "w...W........W.....wwwwwwww............x" level$(8) = "w...Wxx..x..........X.......W........W.." level$(9) = "w...W........W.....wwwwwwww............x" level$(10) = "w...Wxx..x..........X.......W........W.." level$(11) = "w...W........W.....wwwwwwww............x" level$(12) = "w...Wxx..x..........X.......W........W.." level$(13) = "w...W........W.....wwwwwwww............x" level$(14) = "w...Wxx..x..........X.......W........W.." level$(15) = "w...W........W.....wwwwwwww............x" level$(16) = "w...Wxx..x..........X.......W........W.." level$(17) = "w...W........W.....wwwwwwww............x" level$(18) = "w...Wxx..x..........X.......W........W.." level$(19) = "w...W........W.....wwwwwwww............x" level$(20) = "w...Wxx..x..........X.......W........W.." level$(21) = "w...Wxx..x..........X.......W........W.." level$(22) = "w...Wxx..x..........X.......W........W.." level$(23) = "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" PRINT "STRING DEREF TEST" reps = 1000 foo = 0 dummy = 0 start% = TIMER FOR c = 1 TO reps FOR n = 0 TO 23 myText$ = level$(n) FOR m = 1 TO 40 slice$ = MID$(myText$,m,1) IF slice$ = "." THEN dummy = dummy + 1 ELSEIF slice$ = "x" THEN dummy = dummy + 2 : foo = 1 ELSEIF slice$ = "W" THEN dummy = dummy + 3 : foo = 2 ELSEIF slice$ = "w" THEN dummy = dummy + 4 : foo = 3 ENDIF NEXT m NEXT n NEXT c PRINT "ELAPSED: ", TIMER-start% PRINT "CHECKSUM ", dummy DIM nlevel(24*40) 'copy ascii data to 2 dimensional array index = 0 FOR n = 0 TO 23 myText$ = level$(n) FOR m = 1 TO 40 slice$ = MID$(myText$,m,1) nlevel(index) = ASC(slice$) index = index + 1 NEXT m NEXT n PRINT "ARRAY DEREF TEST" dotCode = ASC(".") xCode = ASC("x") wCode = ASC("w") WCODE = ASC("W") foo = 0 dummy = 0 start% = TIMER FOR c = 1 TO reps FOR n = 0 TO 959 cell = nlevel(n) IF cell = dotCode THEN dummy = dummy + 1 : foo = 1 ELSEIF cell = xCode THEN dummy = dummy + 2 : foo = 2 ELSEIF cell = WCode THEN dummy = dummy + 3 : foo = 3 ELSEIF cell = wCode THEN dummy = dummy + 4 : foo = 4 ENDIF NEXT n NEXT c PRINT "ELAPSED: ", TIMER-start% PRINT "CHECKSUM ", dummy PRINT "DO NOTHING TEST" cell = dotCode dummy = 0 start% = TIMER FOR c = 1 TO reps FOR n = 1 TO 960 IF cell = dotCode THEN dummy = dummy + 1 NEXT n NEXT c PRINT "ELAPSED: ", TIMER-start% PRINT "CHECKSUM ", dummy Program output: STRING DEREF TEST ELAPSED: 37424.065 CHECKSUM 665000 ARRAY DEREF TEST ELAPSED: 35574.416 CHECKSUM 665000 DO NOTHING TEST ELAPSED: 23116.743 CHECKSUM 960000 Edited 2020-06-24 00:26 by abraxas |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
No, "I'm Spartacus" I suspect there is some optimisation possible in your code, but I agree with the take home message. Z-MIM which is basically nothing but byte crunching with no graphics is (anecdotally) only 50-75% the speed of a Z-Machine implementation on the C-64 (6502 assembler.) Obviously we need more measurement points, but as much as I like the CMM2, it does appear we have 3/4 the (machine code) byte crunching performance of an 8-bit machine coupled with the graphics capability of a 16+ bit machine. EDIT: also on the plus side we do have basically unlimited memory and storage. Regards, Tom Edited 2020-06-24 00:36 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99 |
Without access to the source code of MMBasic it's hard to say what can be done easily... but it strikes me that with 400MHz we _ought_ to be able to get better performance. Maybe add a simple JIT that at runtime compiles most frequently used lines of MMBasic into their own ASTs (Abstract Syntax Trees) in order to avoid parsing/tokenizing those lines on every access? A simple "least recently used" buffer of the "hottest" 500 lines would likely make a world of difference... That would probably speed things up 10x easily for most programs. I dunno I'm no compiler/JIT expert but there has got to be an easily obtained "win" that gets us at least somewhere between a C64 and Amiga level performance inside vanilla MMBasic. Thoughts? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
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. as far as functionality further down the track, perhaps MUCH further down the track... 1. i'd like to see some changes to how the editors work - that is, the VGA editor and the console editor. (a) for the VGA editor: allow selecting different fonts. to the current 100x50 (8x12 character cell), add 80x40 (10x15 cell), 80x24 (10x25 cell), and 50x24 (16x25 cell) for example. this caters for smaller screens and weaker eyes. (b) for the console editor: allow terminal sizes of 80x24 and 80x36 the two editors do not need to match in numbers of columns and rows, as the CMM2 has enough flash space and computrons to have one editor operate as a sliding-window into the other, the only proviso that the cursor on both must be sitting over the same character in the file being edited. 2. there are around 2 dozen 'spare' pins on the H7. select two or three of these and define them as hardware configuration pins, with internal weak pullups enabled. this (first) step will have no effect on the current hardware design. now (remember: further down the track, and could even be a feature that is never made use of) allow for reading these configuration pins at startup, and based upon the value read in configure the CMM2 in a completely different way. for instance, with 3 configuration pins you might have: 7 - standard CMM2 (the default with weak internal pullups and pins o/c) 3 - disable VGA output, turning the freed up pins into GPIOs 5 - configure for HDMI/DVI-D output with external HW as required 6 - direct drive 800x600 parallel-interface panel this allows for ONE version of H7 MMbasic to drive a number of very different maximites/micromites. cheers, rob :-) Edited 2020-06-24 00:54 by robert.rozee |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3830 |
Speaking from almost complete ignorance I doubt that is the case without a significant rewrite of MMBasic. My understanding is that what we have on the CMM2 is effectively the same code that is optimised to fit on the smaller, more resource constrained 'mites. What you are talking about is basically branching off a CMM2 specific version and adding optimisations that will trade size (of firmware and workspace memory) for speed. Looking forward to hear from the cognoscenti, Tom Edited 2020-06-24 00:50 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
the very core of MMbasic is extremely old, and i believe it would be impractical to significantly modify it. the smallest hardware it fits on is the MX170, with 256k of flash memory and 64k of RAM. but, remember, the original IBM PC only had this order of resources available - and far less computrons - while the 8-bit machines of olde had even less. the CMM2 is essentially a C64 without the need to drop to machine code. we do need to accept that it is what it is, all in a neat little 2-chip (H7 + 8mb RAM chip) package. how about the following (only suggested) compromise: add a single command CALL address that allows a jump to any address in RAM. then the user can just write their game is H7 position-independant machine code, load this code into a convenient array sitting in RAM, and jump straight to it. who would like to write the assembler? cheers, rob :-) Edited 2020-06-24 01:08 by robert.rozee |
||||
| MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
Hi, abraxas! Please, don't understand me wrong I'm not criticized you, but in any BASIC interpreted that I had developed since my childhood, you must make some sacrifices and tricks to get the wanted performance. I think that with the Colour Maximite 2 is not different. This is a Boulder Dash prototype that I made in 2016 for the original Colour Maximite, remembering that is ten times slower than the CMM2 (sorry for the bad quality video): Maximite B-Dash v0.1a Please, close the eyes, the source code is not unoptimized and is not an array reader like the original Boulder Dash (this is the tricks that I mentioned): B-Dash Source Then think with me, if the original CMM can do it, why the CMM2, with some tricks and optimizations, can't do it? Please, again, don't understand me wrong, I do not want to appears arrogant, but for sure there is no one single game from NES or Master System that I cannot develop it in the CMM2 (ok, Summer Carnival'92: Recca from NES maybe is a good challenge). If you want to develop a Boulder Dash remake, I can help you with some tips for sure. Count on me! |
||||
| abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99 |
Thank you so much, Mauro. I'll definitely need some tips to understand how to get the most out of this language. Of course I'm very new here and I'm sure my initial ideas are naive and there are tricks of the trade to get MMBasic to perform much better. But is it going to be 10x faster so that it could support larger maps (say 10x the size of Peter Liepa levels)? Right now I'm just exploring of what's easily possible, mostly possible and what requires wizardry in terms of performance. 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. Again, thanks Mauro for the code, I'll read it tonight and I'll ask questions once I get a better idea on what expert level code looks like in MMBasic. |
||||
| Page 1 of 8 |
|||||
 Print this page |
