I wanted to see if I could run Spasm in a web browser. Turns out I can, with some hacks.

http://media.taricorp.net/spasm/spasm.html

Hacks are disabling app generation (because building GMP in is too much work) and writing my own main() because emscripten decided to be helpful and replace the contents of main() with nothing, so I ripped out the important bits and made my own emscripten_main().

Potential uses:
  • With jsTIfied, have runnable samples in 83pa28d.
  • From KermM, support assembly in sourcecoder.
  • Other stuff
That's pretty neat!
I've now added some default includes (ti83plus, ti84pcse, dcs7, dcse8) to the package, so you can use those without mucking with the FS manually.

Source is also up on Bitbucket now, so you can look at my hacks.
Fewer hacks required now. Apparently most of main() was getting optimized out because it was invoking undefined behavior.

It also captures output from running the assembler in a more useful fashion now (though emscripten doesn't appear to give me a way to get the return value from main, so I'll have to hack something in to capture it).
Now it displays the include files available, and lets you use your own. There's also an easter egg which I added at Jonimus' request. Here's a screenshot of things in action.



(TRIPLE POST)
Nice ! Assembly support in SourceCoder would be so amazing.
Awesome. I got my TI-Basic tokenizer working in Emscripten, and I seem to recall that functions can also be optimized out if you don't call them from anywhere and didn't add them to the list of functions that should be exposed to the JS api.
It's such a great idea, and would be great to add to the community assembly guide, but I'm doubting KermM will be so willing to leave Brass.
DrDnar wrote:
It's such a great idea, and would be great to add to the community assembly guide, but I'm doubting KermM will be so willing to leave Brass.
If the alternative was being able to copy-and-paste Assembly code directly into SourceCoder and being able to assemble and upload to an in-browser emulator in one click, I think I can live with promoting a second assembler as well. Wink I'm very excited about this for SourceCoder and plan to add ASM support ASAP.
At one point I had constructed a version of dcs6.inc with the macros rewritten to be SPASM-friendly, I suspect it could be updated with relatively little trouble for DCS7/DCSE. This would make it even more painless.
Runer pointed out that Spasm hangs when you give it too many labels. I found that the magic number appears to be 7919 because of a bad hash table implementation that gets stuck in an infinite loop when all possible values collide due to the table being too small.

I guess I've become the unofficial maintainer of spasm now? I opened an issue on codeplex for this as well, but am not convinced it'll see any action there.
Tari, since calc84 has created a fork called SPASM-ng that adds ez80 support, how difficult would it be to apply your techniques to his fork? I'd like to start seriously working on ASM support in SourceCoder 3.
Yes, it works. I had to make approximately the same changes to make it work correctly as I did to plain old spasm.

Lazy way to build the javascripty version of spasm-ng is just to overwrite the src directory in the spasm-emscripten repository with the code in my emscripten branch of spasm-ng.

Here's a pre-built version (with no changes other than building spasm-ng).
http://media.taricorp.net/spasm-ng/spasm.html
The bitmap.cpp hunks could be upstreamed.

Rather than patching out makeapp(), siggen() and the call to makeapp(), in order to compile them out, you could either leverage Emscripten's built-in predefined macros (if any), or have it predefine a macro through the command line.
This way, the code changes for supporting Emscripten would be so small that everything could be upstreamed.
I also remember having to fiddle with the makeapp and signing code recently in order to deal with CSE apps. Not sure if your branch has that deficiency, but I was working on the one distributed with WabbitCode. It's pretty trivial to hack in, or I can make a pull request, if you're interested.
Wow, i just saw this. This is a really cool idea!
chickendude wrote:
Wow, i just saw this. This is a really cool idea!

Indeed! I just tried it out; and it worked quite nicely! It made it really easy to see the listing code as well. Smile
Lionel Debroux wrote:
The bitmap.cpp hunks could be upstreamed.

Rather than patching out makeapp(), siggen() and the call to makeapp(), in order to compile them out, you could either leverage Emscripten's built-in predefined macros (if any), or have it predefine a macro through the command line.
This way, the code changes for supporting Emscripten would be so small that everything could be upstreamed.
Good points. I've been treating this as more of a toy than anything so I'm not real concerned with upstreaming my changes, but I've added issues in the repo to remind me at some point.

elfprince13 wrote:
I also remember having to fiddle with the makeapp and signing code recently in order to deal with CSE apps. Not sure if your branch has that deficiency, but I was working on the one distributed with WabbitCode. It's pretty trivial to hack in, or I can make a pull request, if you're interested.
If anything, send a PR to the spasm-ng repo. I'd end up pulling it in from there at some point and am not sufficiently interested to figure out what needs changing myself. Smile
Thank you so much for your help on this today! For the uninitiated, Tari added minification, then exports, then wrapped everything in the SPASM namespace to prevent overwriting $ (also used by jQuery) in the global namespace. This allowed me to throw together a prototype of ASM support in SourceCoder. I noticed that there's at least one missing export: emscripten'd SPASM-ng seems to have a hard-coded path for inc.data, the current directory. Is there a function that can be exposed to load the inc.data from a specified directory? I also notice you have a very clever method of uploading user-specified include files to the emscripten file system; is there a similar system to make it look in the website's filesystem? I noticed it was loading a Cemetech 404 page at one point, so I believe this is possible.

Edit: ... perhaps I should try the -I flag.
The Synchronous Virtual XHR-Backed File System should work nicely for your purposes. Alternately or in addition, set Module.filePackagePrefixURL.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement