Assembler for SmileBasic Virtual Machine

READ HERE FIRST The project is live. The assembler works, everything you need in order to use it is here: https://www.dropbox.com/s/eii36mktsmgqojz/SmileBasic%20VM%20tools.zip?dl=0 If you have any questions or need any help using it please message me here on this thread. I will help. The KEY to the VM is also posted on the site already. For those who don't have the VIRTUAL MACHINE Key that runs in SmileBasic here it is:

4RQ3X483

PLEASE NOTE The assembler is for PC. The Virtual Machine runs inside SMILEBASIC. The project is DONE and ready for more. If you want to contribute to the project or help work on it please let me know. I'm willing to accept ideas or help! Let's make SmileBasic amazing! Everything below this is old and outdated now. At the current moment I am just starting to plug away at the assembler which will convert the assembly language the virtual machine I created in SmileBasic uses. This means it'll be feasible to actually write programs for it (finally). Of course, it's understandable this has taken such a long amount of time. I intend to port the assembler from C# directly into SmileBasic, as well. I also intend to port the Virtual Machine from SmileBasic to as many platforms as I can. At the moment the virtual machine itself is still very open because I didn't want to use the base-foundation version of it. I wanted to create a fork instead (So I always have the original). I'm going to create a fantasy emulator that works more like the nes / gameboy once I finish the assembler. It will be forked from the Virtual Machine that already works in SmileBasic. The virtual machine doesn't come with any graphics/sprite stuff by default. That's up to the end user, but... the game console I'm creating will literally be a old fashioned game emulator. I'm pushing to see just how much is possible with emulation on SmileBasic but it seems like atleast something the level of GameBoy. Now, with the assembler it'll be possible to actually create machine code out of assembly. Assembly language is still not as easy to use. But, once the assembler is working. Someone could easily create a program to say-- translate from C to assembly. Translating from C to assembly is a lot easier than say, translating from C directly to machine code. I still like the idea of writing in assembly though, for a virtual machine. It's pretty cool. (and in efficient). Once the asembler is done I'll be setting up file hosting or something and sharing it. The assembler won't be done for probably a few days if not a week from now. Please keep an eye out for my work, because I'm not stopping and I'm going to crank out a massive volume of stuff in the coming weeks, I'm going as fast at it as my life allows. Hopefully I can create something a bit more powerful than the gameboy, and make it possible for others to make games in it on their pc. It will also work in SmileBasic. (The fun part is that since it would work within SmileBasic, as well as on PC you can choose how you make the game, but it ends up working the same on all systems anyway) That's the dream anyway. To have something a bit simpler than game maker that lets you literally create the games on pc and then boom drop them into SmileBasic. I think games will pop up alot faster once this series of tools is done. I may even consider making Monster Tamer within this emulation system instead of making it properly for SmileBasic. We, Will. See. The first tech demos that use graphics for the virtual machine will be ready in less than a month. I am going fairly fast here.

So I'm using an enumerator in C# to identify the opcode parameters. I've read / heard about using things like this before. I suppose it's a kind of logic that I'm not used to. So , here we are. The start of an assembler for my virtual machine first with a very hand-written list of every valid opcode, and it's properties.

Update I have the assembler identifying user-inputted opcodes now. This is important because not only is it identifying them, but it is checking to see if they are valid and if not it is (at the moment) throwing NOP opcodes. (which is actually fine and better than it breaking but i'd rather it have me tell me there's no match lol) Anywho here's a screenshot of the Assembler at work identifying the input. It's actually smarter than me I tried to do LD16 REGISTER $REGISTER as a test but then I checked my OWN documentation and found out that there is no such command. HAH. Joke's on me. (why didn't I allow a 16 bit value to be loaded from ram? or maybe I'm a derp... anyhow..) It is working. I think! Below, now with error-catching. It can tell you the expected parameters of any assembly input. I work so fast it scares me now. :P :D Basically this is only a few steps away from being able to load an external, convert it to machine code. and boom. But sleeptime is coming then i'll be busy all day tommorow with life stuff. so yeah. two days from now maybe? I also have another task, I'm going to be trying to import the VM to pc, as well as improve it in smilebasic. The advent of a comiler that actually builds something for smilebasic is HUUUUGE. (I mean something on pc that can cross-compile to SB )

Update The assembler is getting ready to go. At this point I cannot confirm or deny if it properly writes bytecode (the main concern would be the formatting of the opcodes and the byte syntax but it does appear to match the intended bytecode language.) Here's a juicy screenshot of the VM doing it's thing and interpreting the correct bytes. notice how it converts the value 1000 into four bytes? By tommorow I should be able to feed it a text file and have it spit out some vauge bytecode I can them dump into smilebasic and have it run.

Update So after hilariously realizing I hadn't included "REGISTER11" in the set of valid REGISTERS, and nearly an hour of debugging before realizing it. Here we are at the pre-compile confirmation. Here's what the assembler can do now. It is infact, generating bytecode. It is also putting this bytecode into an array of bytes. Which I later plan to review and ensure is correct. So far, it seems correct. Next step ->Writing to a file then using bin2dat to transfer said file to SmileBasic using SBFM. Linking input of the controls to ram addresses, and then writing a program that wraps into the ram values which allows reading from ram to indirectly (and through the assembly program itself) control a sprite on the screen.

UPDATE the compiler fully compiles That's right, I transferred compiled code from the PC compiler into a DAT file and the code fully compiled!!! I will post the project assets on the top post.

Is this some sort of C# to SmileBASIC compiler or vise versa? I don't know what you mean by "virtual machine", but I assume it's an emulator of some sort.

Is this some sort of C# to SmileBASIC compiler or vise versa? I don't know what you mean by "virtual machine", but I assume it's an emulator of some sort.

It runs it's own bytecode. You can write a program for it in assembly and then hook into the ram using normal smilebasic functions (so you essentially have a processor that can run assembly programs) It's only good for math and the like right now, or checking conditions. It's basically a simple assembly runtime. EDIT: TL;DR, Write Assembly code on your computer, run my assembler. Put your text file with your assembly code in the bin folder of the download provided, (or just modify the compilethis.txt file) then Run the exe and type the filename you want to assemble. It will spit out a compiled .bin file. Take this and run it through bin2dat, using the instructions provided. Once you've done that you can transfer it to SmileBasic. if you still don't understand it, then i'll be more clear on what it can do: It runs code inside smilebasic but not smilebasic code. You can still run smilebasic code alongside it by adding function calls into the main loop of the VM source code that runs inside SmileBasic. To be even clearer, you can't control sprites or smilebasic features directly with the vm but what you can do is write obfuscated code almost no one will understand so your smilebasic programs are cooler. Also since it uses virtual ram you can easily implement freeze-states too. (instant loading and saving of program state fully). If you want help figuring out any of how to use this let me know I'm more than happy to help.