BAGASM R1

Discussion in 'Supercard' started by BassAceGold, Jan 14, 2012.

Jan 14, 2012

BAGASM R1 by BassAceGold at 2:25 AM (2,756 Views / 1 Likes) 18 replies

  1. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    So after furiously straining for weeks (since late December), my BAGASM is finally coming out at full force!

    "What is BAGASM?" you might ask. Well I can tell you what it's not! It's not a sandwhich, or an amazing massage. No, it is merely an interpreter for a language I have created similar to the general syntax that Assembly languages may follow.

    What does this allow? Well for one, you don't have to setup and deal with the finicky development environment,the DSTwo SDK, to create content for the DSTwo! All you need is a regular text editor and the PC or DS2 version of the interpreter to get started.

    PC Interpreter you say? Yes that's right! Due to the nature of the language, I was easily able to create a PC version of the same interpreter that runs on the DSTwo. This allows for the easy and fast testing of your amazing creations without the need of constantly transfering files to your DSTwo. Take a gander below at the screenshot for yourself.
    [​IMG]

    At this point, you're all probably thinking, "Wow, this is too good to be true!". I'd be inclined to agree with you on that part my good man/woman/dinosaur! As awesome as this may sound, there are limits to keep in mind:
    -You can only load 16 sprites (subject to change in future)
    -Currently there is no support for animations, sprite transparency or alpha blending (subject to change in future)
    -No support for stylus input (again subject to change in future)
    -source files can not have blank lines or tabs => white space sensitive (this will be fixed in the future)

    However, these are merely limits I am imposing on said programs. Here are some limits in which I lack the control over!
    -DS2 process is slower than a PC, thus your program may or may not perform as well on the DSTwo as it does in the PC interpreter
    -Language interpreting is always much slower than native code so high performance applications are not recommended
    -The syntax of ASM is very confusing and not easy to read ( i guess i could have used a different syntax, but that would cost speed!)

    So with that all out of the way, if your slightly degraded enthusiasm hasn't already sent you in a spiral of depression, you're probably curious as to how it works?
    Well it is quite simple.
    -First you type up your code, lets say we wanted to create a hello world program. It would start out something like this:
    Code:
    ;Any line with ; as the first character is a comment, yay!
    ;This debug text flag is only good for the PC interpreter,
    ;Debug text slows the DS2 interpreter down a lot/
    ;[Debug Text]
    ;Here we are setting the DS2 CPU speed to its highest value
    [CPU_freq 13]
    ;_start: marks the start of the program, this is where white space
    ;matters
    _start:
    ;this will output Hello World! to the console (top screen on DS)
    PRINT "Hello World!"
    ;finally this will end the program
    HALT
    
    -Then you'd save the code as Hello World.asm where you plan on launching it
    -Finally, you run the interpreter which will then run Hello World.asm

    The interpreter parses the source file and converts it to a more optimized format for super fast parsing. You can actually dump this optimized format as its own binary and run it on its own (cuts down loading times, and obfuscates code if that's your thing) simply by adding the [Compile] flag to the top of your code (more info on this to come in tutorials).

    Are you still here? Excellent! You've got balls to continue reading this far. Now we get to the fun part, Documentation!
    Well currently I do not have any tutorials or examples made up, but I will update this section with a few after I have finished eating my delicious lasagna dinner. This section will contain a list of all the possible operations, what they do, how they work etc, and general tips on programming this eye gouging-ly, monolithic-ally sphincter clenching beast of a language.

    The ginormous list of operations!
    Code:
    Input detection!
    GETKEY X - stores current input in X
    CHKKEY X;Y - checks the key value for a specified key press
    eg. to check for Y button;
    GETKEY $R5
    CHKKEY $R5;#2048
    Key values:
    A = 0
    B = 2
    X = 1024
    Y = 2048
    L = 512
    R = 256
    START = 8
    SELECT = 4
    LEFT = 32
    RIGHT = 16
    UP = 64
    DOWN = 128
    
    Variables
    Note! All variables must be loaded to a register to perform operations on the stored values
    DATA - used to define a variable
    eg. SMALL DATA '0 -creates a variable called SMALL with an initial value of 0 as a 8 bit byte value(')
    PENIS DATA #0 -creates a variable called PENIS with an initial value of 0 as a 32 bit integer(#)
    LOAD X;Y - loads integer variable Y to X register
    eg. LOAD $R0;GIRAFFE -loads value of GIRAFFE to register 0
    LOADC X;Y - loads byte variable Y to X register
    STORE X;Y - stores value of register X to variable Y
    eg. STORE $R0;SHOOP - stores value of register 0 to variable SHOOP
    Math Operations!
    ADD X;Y - adds Y to X
    SUB X;Y - subtracts Y from X
    AND X;Y - bitwise and Y to X
    DECR X - decreases the value of X by 1
    INCR X - increases the value of X by 1
    DIV X;Y - divides X by Y
    MUL X;Y - multiplies X by Y
    RANDM X;Y - X becomes a random number with a max possible value Y
    REM X;Y - get the remainder of X divided by Y
    SHL X;Y - bitshift value X by Y left
    eg. SHL $R0;#1 - multiply by 2
    SHR X;Y - bitshift value X by Y right
    Logic stuff!
    All bits are updated after a math operation is called.
    JMPC LABEL - jumps program to LABEL when collision bit is set (CHKCOL)
    JMPN LABEL - jumps program to LABEL when negative bit is set
    JMPP LABEL - jumps program to LABEL when positive bit is set
    JMPZ LABEL - jumps program to LABEL when zero bit is set
    JUMP LABEL - jumps without condition to LABEL
    
    Output!
    OUT X - outputs the integer value of X to the console
    OUTC X - outputs the ascii character of value X to console
    PRINT "x" - prints string X to console
    LDSPR X;S - loads a sprite to slot X(0-15) with file name S
    DRWSPR X;Y - draws a sprite to screen X (0 = bottom, 1 == top), from sprite slot Y(0 - 15)
    FLIP X - updates screen X (0 = bottom, 1 = top)
    VSYNC - locks program to 60 FPS
    CHKCOL X;Y - checks collision between two sprites X and Y, sprites defined by their sprite number (0 - 15)
    eg. CHKCOL #0;#1
    Misc Operations!
    HALT - ends the program immediately
    NOP - no operation to be performed on line
    SET X;Y - set value X to value Y
    
    Code:
    [b][u]A quick guide for getting started.[/u][/b]
    
    [b][u]Registers:[/u][/b]
    $R(Z) = register value with Z as a value between 0 and 15 (16 registers total) eg. $R4, $R14
    All math operations must use a register to store the computed value.
    
    [u][b]Screen buffer:[/b][/u]
    $VX(Z) = x pixel position of screen buffer to edit, Z is the screen to modify the X pointer to (0 = bottom, 1 = top)
    $VY(Z) = y pixel position of screen buffer to edit, Z is the screen to modify the Y pointer to (0 = bottom, 1 = top)
    $VM(Z) = screen buffer access with Z the screen to access (0 = bottom, 1 = top)
    
    To draw a white pixel to the bottom screen at 64,128:
    SET $VX0;#64
    SET $VY0;#128
    SET $VM0;#65535
    
    [u][b]Sprites:[/b][/u]
    $SX(Z) = x pixel position to draw sprite number Z (0 - 15, 16 sprites total)
    $SY(Z) = y pixel position to draw sprite number Z (0 - 15, 16 sprites total)
    
    To draw a sprite loaded to slot 5 on the bottom screen at 52,76
    LDSPR #5;SpiteName.bmp
    SET $SX5;#52
    SET $SY5;#76
    DRWSPR #0;#5
    Note: Root path for files are set to the same directory where the program is launched at
    
    [b][u]Jumps:[/u][/b]
    Jump lables can be placed on any line and must have an operation following it.
    eg.
    
    HELLO_LOOP PRINT "HELLO!"
    JUMP HELLO_LOOP
    
    Note: Jumps occur immediately as they are called. The line after a jump call is not executed (Thanks to spiritofcat for bringing that up!)
    
    or for an easier read you can follow the jump label with the NOP keyword  (no operation)
    HELLO_LOOP NOP
    PRINT "HELLO!"
    JUMP HELLO_LOOP
    
    [u][b]Printing:[/b][/u]
    You can print on a newline using the command:
    OUTC '10
    which prints the ascii value for \n to the console. This can be used to print other special characters.
    
    [b][u]Variable declarations:[/u][/b]
    There are two types of variables supported, integers (32bit signed) and bytes (8 bit signed). A variable can be declared as such:
    VAR_NAME DATA #0
    This initializes a variable called VAR_NAME as an integer (#) assigned the initial value of 0. A byte can be declared using a ' symbol instead of #.
    Variables can be declared at any point within the source, but are converted to NOP operations before run time, thus it is recommended to declare them initially or at the end after your final halt statement for best performance.
    
    At last we have reached the end! However, I think you'd like to look at the awesomeness I have masterfully created some more!
    [​IMG]This however isn't possible in the current version cause I fixed the glitch.

    Finally, the DOWNLOAD (PROJECT PAGE)!
    This link contains the latest source code, binaries, and test programs.
    The DS2 interpreter loads files via ARGV so a menu such as Imenu or BAGPlug are required to load the .asm and .basm files.
    To run the DS2 version on BAGPlug, simply:
    -copy the two .arg files in the DS folder to /_bagui/ext,
    -then copy BAGASM.plg to your sd card
    -edit the two .arg files to match the program location to your current path of BAGASM.plg
    -Then browse to your .asm or .basm files and click them!
    The PC interpreter can be launched by the ASM.bat file, with the asm file specified as the first argument

    And with that, I bid you guys good luck on your creations.
     
    1 person likes this.
  2. Crimsonclaw111

    Member Crimsonclaw111 GBAtemp Fan

    Joined:
    Apr 7, 2010
    Messages:
    387
    Country:
    United States
    Clever name; appreciate the work, wish I could do something useful with this :P
     
  3. Chaosruler

    Member Chaosruler GBAtemp Fan

    Joined:
    Jun 5, 2009
    Messages:
    491
    Location:
    Tekoa
    Country:
    Israel
    This is amazing, actually because of the nature of the DSTwo, I bet it's amazing enough for a dingo port
     
  4. spiritofcat

    Member spiritofcat GBAtemp Advanced Fan

    Joined:
    Dec 20, 2007
    Messages:
    577
    Country:
    Australia
    Very interesting!
    I've had some small experience in writing assembly code before.
    I didn't see anything about it in your documentation so I thought I should ask, your JUMP operations, do they work like in other Assembly languages, where the line after the jump command still gets executed before jumping to the specified label?
     
  5. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    The line after a jump call is not called before jumping. I'll add this to the quick guide in the first post -- good question!

    It wouldn't be hard to port it to any system. It uses standard C code with only video and input obviously being platform independent.
     
  6. The Real Jdbye

    Member The Real Jdbye D:

    Joined:
    Mar 17, 2010
    Messages:
    8,582
    Location:
    Doing your mom
    Country:
    Norway
    This is interesting, but being an interpreter it doesn't seem like it'll be very useful. Interpreted languages are inherently slow, and the end result might not even run any faster than compiled code would on the DS itself, so it would be requiring a DSTWO for no real reason.
    Even though you're not recommending to use it for high performance applications, that's the main use of the DSTWO CPU since it's way more powerful than the DS...
    And while I haven't tried the "finicky" DSTwo SDK, I find it hard to believe that it's harder to use than ASM.
     
  7. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    This interpreter is definitely not a replacement for using the SDK, it is merely something fun to play around with if it interests one to do so. The SDK isn't hard to use itself, but it seems to be the setup that confuses most people who wish to begin working on it. Chances are that the people who can't figure out the setup, or who won't spend the time to create the environment, probably don't have any intentions (or maybe skill/knowledge?) to put the extra power to good use anyway.

    In then end, I hope to release the source for people to include this as a form of scripting for their own projects if they need the performance of a light scripting language.
     
  8. jimmyemunoz

    Member jimmyemunoz GBAtemp Advanced Maniac

    Joined:
    Feb 23, 2009
    Messages:
    1,958
    Location:
    Louisiana
    Country:
    United States
    Nice work, I'm glad to see you giving your time to the DSTwo homebrew scene B.A.G. :)
     
    1 person likes this.
  9. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    Just a small update on the progress here; I have been heavily optimizing the interpreter over the past couple weeks and have achieved some amazing results.

    My test program, containing 843 441 operations, in this current release completes in a total around 1.5 seconds. In this new release I am working on, I have managed to get the time down to 0.58 seconds for the exact same program.

    This program just went from a rough theoretical speed of 550 000 operations per second to a hypothetical unprecise whopping 1.45 million operations per second(tested on DS2), from which i'm informed is somewhat close to the performance of the super nintendo's processing speed.

    Of course these are all estimated values and most certainly do not reflect real world performance for all programs. It is however still a huge improvement.
     
    1 person likes this.
  10. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    New release! I have entered it in the neoflash competition here:
    http://www.neoflash.com/forum/index.php/topic,7443.msg53010.html#msg53010
    The source code, and binaries are provided in the post.
     
    1 person likes this.
  11. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    Sorry for triple posting, however this is pretty cool.

    I've started a port of BAGASM to run on the DS (any flashcard or nds emulator now). It only runs the one built in program (PROGRAM CODE HERE) and the performance isn't too bad.
    [​IMG]

    This version of BAGASM is the R3 beta, and is currently unreleased for the other supported platforms.

    You can download the test binary here.
    To run:
    -copy nds file to card, anywhere is fine
    -use a launcher that supports argv, nitroFS is used for storing the internal program
    -once in the program, you can use the stylus on the bottom screen to move the circle around and redraw from blank

    Also, if anyone has the ability to run homebrew in DSi mode, please give me a shout, and I'll give you a binary with the benchmark program to get some times :D
     
  12. Snailface

    Member Snailface My frothing demand for 3ds homebrew is increasing

    Joined:
    Sep 20, 2010
    Messages:
    4,324
    Location:
    Engine Room with Cyan, watching him learn.
    Country:
    Antarctica
    You rang? :P

    I have a SudokuHaxed DSiXL fired up and ready to go!
    (my experiments with devkitpro homebrew show an almost exact 2x increase in speed (with math calculations)-- just fyi)
     
  13. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    Excellent!
    Well here is the benchmark program:
    http://www.qfpost.com/file/d?g=zEZPnz4EP

    Its not a whole lot or very benchmarky, but I've been using it for testing since the programs creation, so I might as well stay consistant.
    Heres what it looks like on an emulator:
    [​IMG]
    and the time is of course listed next to the "Program completed in: " line.
     
  14. Snailface

    Member Snailface My frothing demand for 3ds homebrew is increasing

    Joined:
    Sep 20, 2010
    Messages:
    4,324
    Location:
    Engine Room with Cyan, watching him learn.
    Country:
    Antarctica
    [​IMG]

    Awesome, better than twice the speed. ^_^
    Edit: ran it on a DS lite too -- 1.237 s
     
  15. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    The current benchmark results for each system from slowest to fastest:
    DS @ 66mhz = 1.237-1.238 seconds(confirmed by Snailface on hardware)
    DSi @ 133mhz = 0.620 seconds
    DS2 @ 396mhz = 0.192 seconds
    PC = no point in measuring

    Some statistics of the benchmark program:
    -In its total run time, 403 166 actual lines of code are processed (in all the loops and stuff)
    -This benchmark is an optimized version of one the DS2 was running at the beginning. The original went through 843 441lines.
    Just by moving 2 lines of code from the inner loop to the outer loop, the number of processed lines was cut almost to half of the first mentioned value.
    -Without the optimizations, simply replacing all the NOP operations after a jump label name with the next following operation, it processed 756 082 lines.
    So watch your operation usages in loops!


    Thanks for the results Snailface!
     
    1 person likes this.
  16. Snailface

    Member Snailface My frothing demand for 3ds homebrew is increasing

    Joined:
    Sep 20, 2010
    Messages:
    4,324
    Location:
    Engine Room with Cyan, watching him learn.
    Country:
    Antarctica
    I wonder why your DS was slower than mine -- strange.
    I will test a 3ds in a minute just for fun. (they're usually a hair faster).
    Edit: 1.238 , slower than dslite 1.237
    what good are those arm11s for :P
     
  17. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    I just ran the test on an emulator because I'm lazy. It's probably swaying the results to the lower performance end of the spectrum, no clue by how much though.
     
  18. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    Alright, so after a quite a bit of optimization in the interpreter, I managed to bring down the benchmark time on the NDS to 0.973423 seconds. I have also optimized the benchmark script some more, theoretically it should be in its most optimized form to grab more acurate readings of what the hardware can do. After these script optimizations, combined with the interpreter optimizations, the NDS now runs the benchmark in 0.698542 (43.5% faster since the initial port) seconds on hardware :D

    Apart from optimizations, I have added some file system functions like FATOPEN, FATREAD, FATCLOSE and FATSEEK. It's now possible to read data to variables and arrays in BAGASM!

    Code:
    _start:
    PRINT "opening test.txt"
    OUTC '10
    FATOPEN #0,"/test.txt","rb"
    JMPZ FAILED
    PRINT "file opened!"
    OUTC '10
    ;read "Hello World!" from the file
    FATREAD #0,TEST_STRING,#1,#13
    ;print the data to screen
    PRINTS TEST_STRING
    
    JUMP END
    FAILED PRINT "Couldn't open file"
    OUTC '10
    END HALT
    ;an array of 16 bytes(')
    TEST_STRING ARRAY '16
    
    Also I have updated the first post with the link to the github page for this project. You can download the latest compiled binaries from the Binary folder, and all the test programs from the Program folder.

    Here is the link so you don't have to go back: https://github.com/BassAceGold/BAGASM
     
  19. BassAceGold
    OP

    Member BassAceGold Testicles

    Joined:
    Aug 14, 2006
    Messages:
    494
    Country:
    Canada
    Some more benchmark stuff:
    [​IMG]

    As you can see, the DS2 version runs close to 40x (I say around 40 due to code differences between output and no output) slower with text output. This really shows the magnitude of the slow NDS slot transfer.

    Code:
    [Console 1]
    _start:
    PRINT "entering loop(5000x)"
    OUTC '10
    LOOPTO #0,$R1,#5000,#1
    LOOPBACK #0
    OUTC '10
    PRINT "Done!"
    HALT
    
    DS2 version
    [CPU_freq 13]
    _start:
    LOOPTO #0,$R1,#5000,#1
    LOOPBACK #0
    HALT
    
     
    1 person likes this.

Share This Page