Hacking Design Your Own Menu: Community Challenge!

  • Thread starter Thread starter BassAceGold
  • Start date Start date
  • Views Views 29,008
  • Replies Replies 224
  • Likes Likes 5

How many games do you store per folder?

  • ~5

    Votes: 6 9.1%
  • ~10

    Votes: 9 13.6%
  • ~20

    Votes: 15 22.7%
  • ~30

    Votes: 5 7.6%
  • ~40

    Votes: 12 18.2%
  • 50+

    Votes: 27 40.9%

  • Total voters
    66
I vote to just let everything be free. I get a rather large feeling that nobody is going to plot the demise of nameless person. If anything, people should be checking that sort of stuff themselves before mindlessly putting it on their flashcart.
 
Could be possible from the menu to choose the scripts that want to use or it must be doing from external files?
 
Could be possible from the menu to choose the scripts that want to use or it must be doing from external files?

The scripts can be loaded from the file browser:
2013-02-23_171743.png


And there will be a file containing a list of scripts to launch on boot.
 
I've always found the DSTwo's navigation of games a little weird, since I couldn't get a 1D list with icons.

So perhaps a 1D list (icons and no icons), a 2D grid with normal-sized icons, and also a 2D grid with double-size icons?

This kinda' sounds like other flash cart menus now that I think about it more (minus the double-size menus items).
Me too
 
The scripts can be loaded from the file browser:
2013-02-23_171743.png


And there will be a file containing a list of scripts to launch on boot.
Ok, I looked through your BAGASM R1 thread and figured things out a bit.
I'm just wondering how easy/difficult it will be for regular Joes to write BAGASM scripts or will you provide BAGASM scripts on request or will I have to frown so hard I poop my pants and hope my knobheaded scripting attempts will work?
 
Ok, I looked through your BAGASM R1 thread and figured things out a bit.
I'm just wondering how easy/difficult it will be for regular Joes to write BAGASM scripts or will you provide BAGASM scripts on request or will I have to frown so hard I poop my pants and hope my knobheaded scripting attempts will work?

It shouldn't be overly difficult. I have a wiki started for it so there is a reference to learn from. Getting used to how it does logic is probably going to be the tricky part. Its a bit of a mix between a low level language with high level operations. Your script will fairly long because only one operation can be done per line, so any equations with multiple steps will span multiple lines.

As for the release of this menu, it will come with default scripts for a basic interface, so you won't be completely abandoned with a bare-bones menu while waiting for other scripts to be made.

Here is a pixel fixer script (flashes the screen red, green and blue)

Code:
;DS2 settings
[Flip Mode 2]
[CPU_freq 13]
 
;disable the console on NDS
[Console 0]
 
;start of the program
_start:
    ;clear the top screen (for DS)
    CLRSCRN #1
    FLIP #1
 
    ;set up some colors to flash
    ;red
    RGB $R0,#31,#0,#0
    ;STARY $R0,COLORS,#0
    SET COLORS[0],$R0
    ;green
    RGB $R0,#0,#31,#0
    ;STARY $R0,COLORS,#1
    SET COLORS[4],$R0
    ;blue
    RGB $R0,#0,#0,#31
    ;STARY $R0,COLORS,#2
    SET COLORS[8],$R0
 
    ;store the screen number in register 15
    SET $R15,#0
 
    ;pick a random color to use
    FLASH_LOOP SET $R0,#0
        LOOPTO #0,$R0,#3,#1
            LDARY $R2,COLORS,$R0
            SETSCRNCOL $R15,$R2
            FLIP $R15
            JUMP CHECK_INPUT
            DONE_INPUT_CHECK VSYNC
        LOOPBACK #0
    JUMP FLASH_LOOP
 
HALT
;array of colors to use
COLORS ARRAY #3
 
CHECK_INPUT GETKEY $R10
    ;check if R is pressed
    CHKKEY $R10,#256
    JMPP R_PRESSED
 
    ;check if start is pressed
    CHKKEY $R10,#8
    JMPP START_PRESSED
 
    ;otherwise exit this check
    JUMP EXIT_INPUT
 
;R_PRESSED===============================================================
    ;switch the screen if R is newly pressed
    R_PRESSED SUB $R1,#0
    ;R is still on its last press
    JMPP DONE_INPUT_CHECK
    ;set R to its new press
    INCR $R1
 
    ;clear current screen before switching
    CLRSCRN $R15
    FLIP $R15
 
    ;now to switch the screen
    INCR $R15
    ;check if its greater than 2
    SET $R5,$R15
    SUB $R5,#2
    JMPN DONE_INPUT_CHECK
    ;if it is, then set to 0
    SET $R15,#0
    JUMP DONE_INPUT_CHECK
 
;START_PRESSED===========================================================
    ;exit program when start is pressed
    START_PRESSED HALT
 
;EXIT_INPUT==============================================================
    ;$R1 is used to ensure that the R key is detected as a new press
    EXIT_INPUT SET $R1,#0
        JUMP DONE_INPUT_CHECK

Once you're familiar with what operations do what, its not too terrible. The trickiest part of this script is trying to detect if a button is newly pressed rather than just held in general (As you can see with the R button). So you can bet I will be adding a new operation to make that consume less lines.
 
More progress to report with bars to show!

While you may have already seen screen shots of the menu with progress bars and such in them, the new ones are now rendered using the built script interpreter!
There is no text displaying the percentage though since I have yet to add that kind of text support in BAGASMI. So now that I have gotten this kind of concept working, perhaps other menu functions can be moved to scripts for almost complete customization of the menu.

2013-03-02_200123.png


One script is used to generate both bars (the individual file's progress and the over all progress), and the script is executed twice to draw each bar.

Here is the code of the progress bar script so you can kind of get a feel for it.
Code:
;=======================================================
;    BAGMenu Progress Bar
;        Script
;
;    Written by BassAceGold
;
;Renders a progress bar on screen
;based on the following arguments.
;
;
;ARGV arguments
;    $R0 = screen to render to
;    $R1 = x position to draw bar at
;    $R2 = y position to draw bar at
;    $R3 = width of progress bar
;    $R4 = height of progress bar
;    $R5 = progress bar outline color
;    $R6 = progress bar fill color
;    $R7 = current progress
;    $R8 = total progress
;
;
;The calculation used for generating a percent is:
;    percent = (current progress * 100) / total progress
;
;
;
;=======================================================
 
;interpreter pragma
[Script]
 
 
;misc regs uses
;$R10 = calculated x2 position
;$R11 = calculated y2 position
;$R15 = final percentage filled
;$R16 = progress bar width
;$R17 = check if boarder color is transparent
;$R18 = storage of the transparent color
 
 
;program start
_start:
 
;first, collecting the values passed
;through argv.
 
;grab the screen number
ATOI $R0,$ARGV0
;x position
ATOI $R1,$ARGV1
;y position
ATOI $R2,$ARGV2
;width
ATOI $R3,$ARGV3
;height
ATOI $R4,$ARGV4
;boarder color
ATOI $R5,$ARGV5
;interior color
ATOI $R6,$ARGV6
;current progress
ATOI $R7,$ARGV7
;total progress
ATOI $R8,$ARGV8
 
;then some misc calculations that'll help later on
;add width to x position to get x2 position
SET $R10,$R1
ADD $R10,$R3
 
;add height to y position to get y2 position
SET $R11,$R2
ADD $R11,$R4
 
 
;Now to draw progress bar outline
;If the outline color is set to magenta
;we'll consider that as transparent.
 
;So lets check if the boarder color is transparent
;Color - Magenta should = exactly zero if a match
SET $R17,$R5
SUB $R17,#64543
 
;if it is transparent (color - magenta == 0), skip boarder drawing
JMPZ no_boarder
 
    ;otherwise, continue drawing outline
 
    ;top line
    ;screen, x1, y1, x2, y2, color, size
    DRWLINE $R0,$R1,$R2,$R10,$R2,$R5,#1
 
    ;bottom line
    DRWLINE $R0,$R1,$R11,$R10,$R11,$R5,#1
 
    ;left line
    ;x2 is the same as x1
    DRWLINE $R0,$R1,$R2,$R1,$R11,$R5,#1
 
    ;right line
    ;x1 is the same as x2
    DRWLINE $R0,$R10,$R2,$R10,$R11,$R5,#1
 
 
 
;no boarder here
;now we calculate how much to draw inside the box
;first we need to do a check to make sure we aren't going
;to divide by 0
 
;check if the current progress is 0
no_boarder SUB $R7,#0
    JMPP not_zero
    ;if the current progress is 0, set it to 1
    SET $R7,#1
 
 
    ;now calculate a percentage
    ;percent($R15) = (current progress($R7) * 100)/total progress($R8)
    not_zero SET $R15,$R7
        MUL $R15,#100
        DIV $R15,$R8
 
        ;now using the percentage, we'll determine how much of the
        ;progress bar to fill
        ;(bar width = percentage * bar width) / 100
        SET $R16,$R15
        MUL $R16,$R3
        DIV $R16,#100
 
 
        ;finally we can draw the interior of the progress bar
        ;we are going to leave a 1 pixel boarder around the interior
        ;so lets calculate the bar position
        ;x + 1
        ADD $R1,#1
        ;y + 1
        ADD $R2,#1
        ;y2 - 1
        SUB $R11,#1
        ;x2 = x + width
        SET $R10,$R1
        ADD $R10,$R16
 
        ;then draw the rectangle
        ;screen, x1, y1, x2, y2, color
        DRWRECT $R0,$R1,$R2,$R10,$R11,$R6
 
        ;update the screen
        FLIP $R0
 
HALT
 
  • Like
Reactions: Boriar
So, can your menu pass values to BAGASM to use in scripts?

That's the plan. It can right now since the progress bar needs values passed to it to properly display things, but eventually you should be able to put scripts as the executable binary in arg files.

So lets say you wanted to make a text reader script, the user could just use the standard menu to browse text files, and then pass the text file they want to read to your script using .arg files.
 
  • Like
Reactions: Boriar
That's the plan. It can right now since the progress bar needs values passed to it to properly display things, but eventually you should be able to put scripts as the executable binary in arg files.

So lets say you wanted to make a text reader script, the user could just use the standard menu to browse text files, and then pass the text file they want to read to your script using .arg files.

Wow!!!
It's more than i can expect from a menu :yaynds:
 
Been a while since the last update.

What I've done so far is mostly under the hood stuff regarding script handling. Some notable things to mention:

-You can now use script files as the binary in .arg files to pass files to them; as suggested in my previous post
-You can now specify scripts to run on boot using the bootScripts.txt file in the user files folder

The format of the bootScripts.txt file is relatively simple, here is my current file:
//List scripts here to start on boot.

//Scripts with a & on the end of the line are cached.
//Cached scripts run like normal scripts, except when they
//end due to a HALT operation, the script is restarted back
//to its original first run conditions while preserving any
//changes to the ram in its previous runs. These scripts are
//not unloaded and reloded each time, they stay in ram.

//Scripts with * are protected scripts. These scripts can
//not be stopped by the user.

//Scripts with % are executed regardless of program state.
//This means the script will run while the system menus
//are in use.

main *%
circlesNewLoop

Basically, with your scripts in /menufolder/scripts, you just need to specify a script name and its run mode. If no extension is used for loading scripts, it automatically searches for the compile script (.basm) first and then the regular script file (.asm) second. Compiled scripts should load faster since its essentially a dump of the already converted (.asm) file.

Some ideas I am going to work on:
-Calling other scripts within scripts. BAGASMI scripts are limited to what they can do individually, but chaining a bunch of small programs to make a large program would be possible. Kind of following the UNIX philosophy of making individual scripts that do one thing and do it well.

-Returning data in scripts.This will make calling scripts within scripts more useful. Perhaps you make a script for formatting string data, you could grab the processed string back from the called script in the parent script for further usage.

-Hook more menu functions into scripts. Mostly file browsing related functions so scripts can operate on whats currently shown in the system menus.

-Add more graphic functions to scripts. Need transparency, frames, animations, fancy text with fonts, and tiled fonts.

-Add audio functions to scripts. This combined with the file browsing functions could make for simple media player script.

-Add keyboard input functions to scripts. This with a tile font system could make for a small text editor script.

Once all those are in place, I can start working on interface scripts and crank out a first release! With the first release out, people can figure out the scripting language and suggest other features or improvements they'd like to see added.
 
  • Like
Reactions: mike1
I guess one could argue that it has the components of a pretty basic high level operating system.

-It has a kernel, which allows access to video, input, audio and filesystem features from the Supercard SDK and my own libraries.
-Supporting programs (scripts) can be created and run (with their own virtual memory) and use the kernel provided features.

Perhaps BAGOS is a suitable name for this menu?

However, I'm not sure I would want to go ahead and actually call it an operating system.
 
  • Like
Reactions: Boriar
I guess one could argue that it has the components of a pretty basic high level operating system.

-It has a kernel, which allows access to video, input, audio and filesystem features from the Supercard SDK and my own libraries.
-Supporting programs (scripts) can be created and run (with their own virtual memory) and use the kernel provided features.

Perhaps BAGOS is a suitable name for this menu?

However, I'm not sure I would want to go ahead and actually call it an operating system.
:lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol:

Try to translate "Vagos" or better "Vago" from spanish. I know about "B" instead of "V" but in spanish both sound the same.
I like the joke but i think it not representing all the efforts you have put on it.

Why don't you think it's an OS? Only support for external hardware is missing but... can you add support for 3in1 directly from the menu?
I suggest BAG-DoS, you know D and S stand for DS, and you have O and S for OS.
Do you like it?

In other hand, have you improved BAGASM for use with the menu?

BTW GREEAATT work
 
:lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol::lol:

Try to translate "Vagos" or better "Vago" from spanish. I know about "B" instead of "V" but in spanish both sound the same.
I like the joke but i think it not representing all the efforts you have put on it.

Why don't you think it's an OS? Only support for external hardware is missing but... can you add support for 3in1 directly from the menu?
I suggest BAG-DoS, you know D and S stand for DS, and you have O and S for OS.
Do you like it?

In other hand, have you improved BAGASM for use with the menu?

BTW GREEAATT work
I think BAGOS is a good name despite the Spanish weirdness.
And BAG-DOS sounds even weirder as people would associate it with DOS (disk operating system).
BAGMenu could be an alternative if you don't like the sound of OS, but hey supercard called their menu an OS so why shouldn't you.
And if you want to add DS to it may I suggest D-BAGS. :P
 
I'm sad to see this on the second page. What kind of progress has been made since your last update?
 
Honestly, pretty much none since I've been busy with exams. Progress will be pretty slow at this point since I'm essentially working on two projects at once (this and BAGASMI for scripting).

In the list I've mentioned above, I'm currently thinking about how to implement:

Returning data in scripts.This will make calling scripts within scripts more useful. Perhaps you make a script for formatting string data, you could grab the processed string back from the called script in the parent script for further usage.

As that will be key in linking multiple scripts together. Things I need to consider for this are: what data types will be returned, where the data is stored, how to access the return data within scripts, and when it should cleaned up (and how).

The rest on the list, isn't so much hard to implement, but rather time consuming.
 
I'm slowly starting to get back into coding things. Most of the work so far has been on the interpreter. I've added a few new logic operations to the interpreter, as well as modifying the math operators to potentially improve performance (combining storage with the math operator into one). I've also been working on the BAGASMI wiki.

I'm thinking that I might release what I've got of the menu so far, so people can play around with the scripting. The interpreter isn't as tightly tied to the menu yet (see the previous posts as to whats missing), however, you can pass files directly to the script much like passing roms to their respective emulators.

My hope is to just get some feedback on the stuff and prioritize some features or requests based on the scriptwriter's needs/wishes.

For those who aren't interested in this scripting stuff, the menu is perfectly useable for loading things. However, the menu is very bare-bones since many features are planned to be added through scripts in the future.
 

Site & Scene News

Popular threads in this forum