Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#15 pretty cool stuff


just some ideas for further improvement:

- add some basic syntax highlighting
- possibly some realtime error checking
- provide tooltip popups for syntax that is used
- integrate manual directly into editor, so that it can be easily viewed

thanks, I already love using it!

PS: maybe some way to access the PC speaker would also be neat?


  • Logged In: NO

    Another thing that would be useful and very intuitive would be numbering the dimensions of the output areas, that is provide line numbers for the text output window and coordinate info (x*y) for the graphic window.

    also a way to parametrize the online help (tooltip popups) that would do something along the lines of:

    circle 150,150,5 -> "draws a circle at position (x:150,y:150) with a radius of 5"

  • Logged In: NO

    sorry, just browsed the older requests and noticed that the majority of my ideas have already been suggested and in fact even been implemented in svn.


  • Logged In: NO

    what would however be useful, would be support for functions and not only procedures (functions without return values), likewise having the option to pass parameters to functions would also be useful to illustrate more complex concepts.

  • Logged In: NO

    another thing that might be useful to easily allow users to look at the source quickly, would be providing standard background colors for control flow statements such as if, for, goto, gosub, return - so that blocks of code that belong together are indented properly and have some special background color, depending on the statement:

    for i=1 to 10 step 2
    print i
    next i

    where the rectangular area for this block would get a background color matching "for" loops

  • drblast

    • status: open --> pending
  • drblast

    Logged In: YES
    Originator: NO

    Thanks for the ideas, I'm glad you're enjoying the program.

    Syntax highlighting will be in the next release, which will be out either today or tomorrow.

    A SOUND command is being planned, that will play a .wav or .mp3 file.

    The current documentation will be integrated into the editor before the 1.0 release. If you haven't found the documentation, it's included with the Windows version in an easy to use HTML format that will load in any browser that supports frames.

    And I'll look into the tooltip popups.

    In reference to the follow-up comments, functions will likely not be implemented, as they're beyond the scope of what BASIC-256 tries to do. I'd rather encourage kids who have advanced to that point to learn Python or Scheme.

    It might be possible to easily change the background in order to highlight loops, but this wouldn't work for nested loops, and might end up being more confusing than helpful.

    • status: pending --> open
  • Logged In: NO

    wrt sound/speaker support, how about simply providing something along the lines of:

    beep frequency, duration

    where frequency could be specified in hertz and duration ms?

    concerning the implementation of functions and return values, I agree that this might become unnecessarily complex, on the other hand, one could probably easily and very intutively emulate support for this sort of stuff by simply providing commands for a basic stack (inspired by assembly), i.e. something like:

    push_var 10 REM push a 10 onto the stack
    gosub exec_loop call the sub

    push_var 100
    push_var 20
    gosub multiply REM: actually call the subroutine
    pop_var result REM: store the result in a local variable


    REM implementation of a function that accepts one parameter
    pop_var num REM pop stack argument and save into variable "num"
    for i=1 to num
    print "hello world!"
    next i

    REM implementation of a function that accepts parameters and returns a result
    pop_var x
    pop_var y
    result = x*y
    push_var result

    This would not only be very intutive, but would also have the added advantage of illustrating low-level concepts, too.

    What do you think?

  • Logged In: NO

    > It might be possible to easily change the background in order to highlight
    > loops, but this wouldn't work for nested loops, and might end up being more
    > confusing than helpful.

    agreed, that's a good point, on the other hand, optionally allowing users to enable some sort of automatic syntax-aware indentation might still be helpful.

  • Logged In: NO

    a simple push/pop should be sufficient, no need to append a suffix like "arg" or "var"-would only confuse some people

  • Logged In: NO

    a simple push/pop instruction should be sufficient, no need to append a suffix like "arg" or "var"-I'm sure, it would only confuse some people

  • drblast

    • status: open --> closed
  • drblast

    Logged In: YES
    Originator: NO

    • status: closed --> open
  • Logged In: NO

    WRT to what exactly?

  • Logged In: NO

    I have no idea how that empty comment got there.

    No "NO" was intended.


  • Logged In: NO

    concerning the idea to visually honor nested constructs (loops, conditions), I agree that this might become confusing if implemented using the editor control itself, however there could be source-code specific symbols for such constructs, pretty much the way pcGRASP implements them.
    regarding the proposal to add a basic stack, I actually like the idea for the aforementioned reasons (illustrating low-level concepts), but also because it would encourage more controlled use of global variables that may affect other sub routines.

  • Bob Kazooie
    Bob Kazooie

    Logged In: YES
    Originator: NO

    I am bit sorry if I haven't understood all the comments too troughout, due to my inability to write code. However I'd still like to comment, as a learner, that I like all of the ideas proposed, however I'd rather add few more to the list as well:

    -Yes, typos tend to be the worst enemy of a programmer; one typo in 3867 lines might ruin the whole program. So with such lines that have a clear syntax error, it would be rather small effort to have i.e. red background highlight. The C64 basic didn't have it, but I see no reason why 256-Basic shouldn't have it, since it is not neccessary to have the fun with the sprites.

    -would be useful for a starting programmes such as me, even tough as I understood, it might cause bit of complications, so such highlighting should be optional, or "check"able (meaning that if it is intentional loop or similair, it could be checked as intentional. However this is the part I didn't quite understand, so this part of the comment is ignorable.

    -I recon this means that one could achieve information of the purpose and usage of a command, merely clicking (rather than overlapping) the command, it would be useful for learning (for this would be invert possibility of finding a command that does action x, and would help people to 'read' the language of the code), even tough there might also be the possibility to turn this feature off, for people who folow different ways of learning. However I remember this being suggested already.

    -The manual would be rahter great, if not even necessity, expecially when checking the commands to use, and what do they do, even if they are listed in the web page for two reasons:
    Firstly, web pages don't work with 100% probability and are not allways aivable for people using i.e. laptop computer outside the home (I know one could download, but since it might be aivable on the internet, why bother... until the day they're not aivable).
    Secondly, I, for example, am not too interested to read stuff from the net (requires bookmarking and the tab and the browser open) when it could have been so much handier to click the "help" -> "command list". (sorry, I am lazy whiner on the matter, but I believe I'm not the only one).

    -In addition I'd add also the tutorials in either help or pdf -file, for they appeal far more pleasant to read for some reason (as some people still prefer to read their news on newspaper). I believe there is not too much programming to learn in "finding tutorials over the internet".

    As I recall it being said of the manuals, that they are in the internet, but I'd like to stress out, that one thing that gets me to drop off the learning, is to complicate things unneccessarily. And I am such a "gramps", that I hate online-help links (nothing is more irritating, than that, when one is in a need of quick help; forums are for online help). Ofcourse, I am only one opinion, so might it be possiple to create a version (package) with, and version (package) without, integrated help and command list.

    -Also the possibility of translate the final program could be neat; it is far more different feeling to realize that you have created a program that would work, and to first time run the executeable file succesfully.

    -And regarding to the PC speaker, I remember the ol' Q-Basic being able to play PC speaker (aka. PC Beeper) sounds in different frequences, and in such way to play a simple tune. This is something bit different than just merely playing a file.

    As said, I am not a programmer, and know as much as dipsallad of programming. But am more than interested to learn, therefore I would also offer my self as bit different beta tester of the program, than fully learned programmer is able to be (for I, even not a kid, am more or less the target audience of this project), as I am intending to learn programming meanwhile.

  • syntax validation could very intuitively be implemented by simply showing a red cross or stop sign on the left (right) side of each line that wasn't recognized (couldn't be processed) by the parser.

  • regarding this idea about visualizing syntax recognition with a red stop sign, this seems pretty good and intuitve, but probably a simple smiley would also be nice, something thats "green and happy" if the code is syntactically correct, which turns "red and sad" (nice rhyme!) when there are syntax errors in the code buffer. Similarly, such code lines could be highlighted in red or marked with a red cross next to the text buffer.

    Also, whenever there's a recognized keyword typed in, there could be a tooltip shown illustrating its use and parameters.

  • a documentaton viewer would ideally be implemented as a tab widget, so that it can be shown instead of the output area (text/graphics), which are likely to be mostly irrelevant when programming. So that there would be one tab reading "Documentation" and another one "Output", the latter one should probably become active automatically once a program is run

  • Just to add, I am also all for adding an integrated help widget, to clarify: I found kidbasic by reading stackoverflow.com, where someone mentioned that he is using it for aptitude testing of software programmer/developer applicants by giving them a language reference and assignments with varying complexity, up to implementing complex 3D scene drawing (with rotating spheres and such). And I think in this sense, kidbasic might actually be a viable platform because it is easy to get started, but there is nothing that keeps you from visualizing and implementing even complex stuff