CodeWalrus

Introduction
For the last year, I have been working on Claw, a development system for embedded devices.
It has a very small RAM footprint and can run on systems with as few as 2 KB of RAM.
The VM's own memory footprint is tiny and most of the RAM remains to be used by the applications.
Claw will probably support multitasking in it's operating system releases and also support CEFS (Claw embedded read-only file system) and FAT32 for loading (and storing) files from and to.
The files are streamed and therefore can be as large as 4 GB (on 32 bit VM's) or 64 KB (per executable) on 16 bit systems. 64 bit is supported as well, though 4 and 8 bit is not.
Claw features and assembly language and an high-level language that will compile to CXE executables that Claw can execute. On any platform, as Claw executables are binary compatible!
So you focus on your code and write and compile it once. Claw will deal with libraries and device specific hardware! But this freedom is of course still limited by hardware factors (e.g. it needs a screen to display graphics, or processor speed and RAM size).

Memory
Claw is entirely stack-based and uses three main stacks. There is a call-stack which stores the source address every time you call another function. As Claw has file system support built-in you can of course call functions from libraries dynamically. Dynamic linking is performed by Claw automatically, so you don't need to worry about library versions. The next stack is the work stack. It stores the function arguments, is used for arithmetic and other instructions and is arbitrarily accessible. The third stack is the array pool which programs use to allocate parts of memory to store data to. New memory can be allocated at any time but as in a stack, only the last array can be deallocated at a time. There cannot be holes in the memory map.

Supported platforms
The architectures and systems that I will port Claw to include but are not limited to 32- and 64-bit Intel and AMD computers running Windows, Linux or BSD; AVR (especially Arduino Uno and Mega); MIPS (routers); ARM and XTensa (ESP8266). Somebody might want to do a port the TI-84+CE and I might do a port to the TI-84+ if I find time.

Online IDE
There is also a planned online IDE that includes an online compiler as well as a standalone, offline compiler and assembler that runs on Windows, Linux, and BSD. The assembler also works for Mac OSX.

Open source
Claw is an open source project and is on GitHub: https://github.com/bmuessig
The chosen license is as permissive as it gets: The "new" / "revised" 3-clause BSD license.
This means Claw can be used free of charge, can be modified and used in closed source and commercial projects, as long as the name is not miss-used and I get credited appropriately.

Development status
I have completed most of the assembler so far and a good part of the VM. The compiler is just a draft so far, but will be started soon.  Most parts of Claw that are not yet made are already documented and planned but just not yet written.

Have fun!

I'm glad this is still alive. I liked the idea and making it multiplatform is great. Try to focus on smaller platforms, so that you don't run into platform limitation issues, then move on to other platforms one at a time :)

Quote from: DJ Omnimaga on May 07, 2016, 07:13:00 PM
I'm glad this is still alive. I liked the idea and making it multiplatform is great. Try to focus on smaller platforms, so that you don't run into platform limitation issues, then move on to other platforms one at a time :)

So size wise, I estimate the core to be about 50 KB when completed and compiled with a settings enabled on the AVR platform. I plan on making a separate TI-83 a TI-84+ version in Axe unless Cumred_Snektron will make one in Assembler. I have already implemented all math, logic and most stack and array pool functions of the C version over the course of the last days.
The CPU is still not yet implemented.

Will you limit speed to make easy cross platform development possible, or will heavy programs not be able to run on slower platforms?

Quote from: aeTIos on May 09, 2016, 04:53:40 PM
Will you limit speed to make easy cross platform development possible, or will heavy programs not be able to run on slower platforms?

Well in theory I can't do anything to make heavy programs work on slow platforms, but the other way round. I plan on providing syncronous timer functions to allow games to run at the same speed everywhere and so that they can frameskip on slower platforms. Graphics will be scaled and you can choose an aspect ratio (not a screen resolution) at the beginning.
Use geometrical functions whereever possible, but of course, bitmaps will be supported aswell (but they will get scaled).

I don't think speed should be limited, but there should be a timer command for people who wants to throttle the speed of their programs. Also glad to see some progress :)

Nice! I can't wait to try it out, will it by chance be compatible with the HP Prime :trollface: ?

Quote from: alexgt on May 10, 2016, 01:50:05 AM
Nice! I can't wait to try it out, will it by chance be compatible with the HP Prime :trollface: ?

I don't think he knows HP PPL. D: Maybe if one day someone ports Linux to the HP Prime or if Jean Baptiste Boric's third-party firmware gets functional enough to run programs made in C/C++?

Quote from: DJ Omnimaga on May 10, 2016, 05:49:56 AM

Quote from: alexgt on May 10, 2016, 01:50:05 AM
Nice! I can't wait to try it out, will it by chance be compatible with the HP Prime :trollface: ?

I don't think he knows HP PPL. D: Maybe if one day someone ports Linux to the HP Prime or if Jean Baptiste Boric's third-party firmware gets functional enough to run programs made in C/C++?

Yes. But claw can easily run as an operating system on bar metal if one likes so. Given just the C API claw could easily replace the old OS (except for actual float math which will be provided via an addon).

Well, a Claw OS can also do the job I guess (except if the user needs his calc for exams and must re-install the original firmware, but maybe dual-booting can be added). But that would probably be better discussed in https://codewalr.us/index.php?topic=973.0 if you ever get to that platform (since the other guy could probably help)

One thing at a time I guess ;)

That would be cool to dual boot but I would want to get another Prime and use Claw on it so I wouldn't possibly damage my current calc.

Yeah same, although if the new firmware thing is deemed safe, then what the authors could do is allow dual-booting. Actually, maybe a bootloader could be done instead that launches on calc startup then allows the user to load any firmware he wants afterwards (until next calc reboot).

Yeah, that would be very useful. Come to think of it I already have a back up calc, my pseudo broken prime :P

Well, if you know how to hook up a custom screen to it then you could definitively use it for testing. But I doubt the HP Connectivity Kit will detect the calculator screen with third-party firmwares so maybe you would be better off using your working calc as a guinea pig to test Claw and the broken one connected to the PC for HP PPL programming. Or someone could take care of it if you ship it and hook a screen to it.

I need my non broken one for programming since I only code on calc. So I will just go to someone that can replace the screen. For now I am loaning the broken one to my friend for math.

I case you are wondering why the development slowed down a little, I am having an internship at CERN (http://home.cern/about) right now.
Though I still managed to find some time reworking the variable pool and fixing and improving certain aspects of the virtual machine.

Good luck with your internship DarkestEx. :) I'm glad there is still some progress being done on Claw, though. By the way, is @Cumred_Snektron  still working on it too? I remember he wanted to make his own language, but I forgot if he merged his project with yours (otherwise it looks like we'll have three community TI-84+CE languages lol).

I've been waiting for more reasons to get the CE.  :P

You can always get one immediately, even if ICE and Claw aren't out yet. In the meantime, you can use TI-BASIC with CE Textlib or Sprites v2 :)

Is there a possibility of Claw being able to target a GBA?

I guess it depends what are the minimum requirements for it. It was originally designed for the Microcat, which had a  128x128 LCD and a small amount of RAM, so that could help. CPU speed isn't a factor I think.

Quote from: Ivoah on May 18, 2016, 01:43:59 AM
Is there a possibility of Claw being able to target a GBA?

That would absolutely work.
Claw needs a minimum of 50KB of FLASH storage and a minimum of 512 bytes of RAM.
It is not at all affiliated with the microcat project anymore and is aimed for many screen sizes.

Nice! that sounds like that would be cool ;)

Quote from: alexgt on May 18, 2016, 12:08:45 PM
Nice! that sounds like that would be cool ;)

Thanks, I hope so too ;)

The size of the TI-84+ version will be a lot, lot less than the C version as it will be a total rewrite that I am planning to do at some point.
Though the other platforms can easily run C programs and therefore just use the official C version I am working on.

When you say 84+, does this now rule out a TI-84+CE version? O.O

There is C support for the CE, that means it will probably run on that with minimal effort

Quote from: DJ Omnimaga on May 18, 2016, 04:10:50 PM
When you say 84+, does this now rule out a TI-84+CE version? O.O

No absolutely not though I can't make it 84+CE version myself. But I will try everything to make it easy for one CE developer to port it. As Cumred said, a it is C, porting is easy anyways. My part will be PC, Arduino, TI-83+ and TI-84+. Also I will do the assembler.

Ah ok good to hear. For some reasons a lot of people seems to ignore the CE or favor the Nspire CX for big projects, even though it's a much more open platform. In most cases though it's because people prefer C++ and want to avoid C at all cost, and the CE lacks C++ support

Quote from: DJ Omnimaga on May 18, 2016, 04:30:10 PM
Ah ok good to hear. For some reasons a lot of people seems to ignore the CE or favor the Nspire CX for big projects, even though it's a much more open platform. In most cases though it's because people prefer C++ and want to avoid C at all cost, and the CE lacks C++ support

Well I hope that it's compatible with both. Claw is pure ANSI C.
I personally avoid the color calcs always as I don't have nor need one but I still love to have compatibility.

Well, it seems like Cumred has a CEmu ROM anyway so that can help, and others can probably test if you can't access a 84+CE yourself. Just focus on the versions you primarily work on and maybe other people can help porting it. In any case, make sure it's functional first lol.

By the way, do you plan to post a list of the commands/instructions in public?

Quote from: DJ Omnimaga on May 22, 2016, 04:14:59 PM
By the way, do you plan to post a list of the commands/instructions in public?

Yes, I I absolutely going to do that at some point.

I have resumed work on Claw and have had a lot of new ideas during the last time that I will be incorporating now.
But there is one thing you guys have to decide:
Is it worth porting it to the monochrome TI-84+ or not?
This would be a full rewrite, but the only Calc platform I own (or am interested in developing on/for).
Ports to the CE, and the Nspire (i think) are relatively straight forward although i will not do any of these for various reasons. Claw's reference implementation is written in C and should run on the latter two without too much changes to the core. Although the hardware specific code would have to be added
Claw is plugin based and features can be added on compilation. the most basic things like file access have to be implemented in any case.

A 84+ port would be nice, but I don't know if the audience is still large enough.

So Claw is making progress. Slowly but I am working on it.
I just started writing the Assembler and will soon push it to GitHub as well.
I will keep you updated :)

Good to see progress. :) Was there a command list and documentation somewhere? I forgot. By the way I think the language should be kept simple, so we don't need to learn 100+ commands, but also high-level so it isn't as cryptic as ASM to BASIC programmers, for example.

Quote from: DJ Omnimaga on July 12, 2016, 04:12:02 AM
Good to see progress. :) Was there a command list and documentation somewhere? I forgot. By the way I think the language should be kept simple, so we don't need to learn 100+ commands, but also high-level so it isn't as cryptic as ASM to BASIC programmers, for example.

I am still developing a command list but most things are already figured out. While there is a very simple assembly language for claw, I will also develop a language that is similar to lua, basic and a little similar to c.
It will be quite easy, don't worry.

Good to hear. Also the ASM could be handy for those who are more versed into that.

Quote from: DJ Omnimaga on July 12, 2016, 05:50:15 AM
Good to hear. Also the ASM could be handy for those who are more versed into that.

Yea, I think so too. Also the assembler I easier to program and I need something quickly so that I can make test programs while developing the actual clawvm.

Bump. So I am now writing the Claw Assembler.
This is how an example file will look like:
+CX:16 ; required, CX = executable, CL = library; 16 = 16 bit executable, 32 bit, 64 bit

; this metadata is optional and will be imported into the executable
#TITLE "Sample program"
#AUTHOR "muessigb"
#COPYRIGHT "(c) 2016 muessigb"

; this metadata is required and has to be present
#VERSION (0,1) ; version expects an array of major and minor version

+sym main ; main function, required
ldc  42 : $MYVAR ; load the constant 42 onto the stack and name it MYVAR
ldc 278 ; load the constant 278 onto the stack
addc 1034 ; add 1034 to the 278
ld $MYVAR
mul

+sym test:1 ; test function
; :0 is optional and specifies the function index but is required for callbacks and libs

What do you think?

Another bump. Any suggestions or thoughts?

+CWX:16 ; required, CWX = executable, CWL = library; 16 = 16 bit executable, 32 bit, 64 bit
; everything's case insensitive

; this metadata is optional and will be imported into the executable
#TITLE "Sample program"
#AUTHOR "muessigb"
#COPYRIGHT "(c) 2016 muessigb"

; this metadata is required and has to be present
#VERSION 0:2 ; version expects an array of major and minor version

+ctv testvar 278 ; this defines a new constant testvar as 278

+sym main ; main function, required
ldc  42 ; load the constant 42 onto the stack and name it MYVAR
ldc $testvar ; load the constant from testvar onto the stack
addc 1034 ; add 1034 to the value of testvar
call test:0 ; call function test, the :0 is optional and specifies the module number

+sym test:1 ; the :1 is optional and specifies the function index but is required for libraries and callbacks
ld 1 ; load the 42 from earlier
mul ; multiplies the sum from earlier with 42
ret ; ret at the end of symbols is totally optional


Bump!
Implemented the tokenizer part of the Claw assembler.
I also did some changes to the syntax where I thought it would be needed.

https://github.com/muessigb/Clawsemble

Wait, in those two code examples, I see stuff that looks like ASM. Will this be the most common Claw syntax? Or will it be just for those who are going for the ASM syntax?

Quote from: DJ Omnimaga on July 14, 2016, 12:03:00 AM
Wait, in those two code examples, I see stuff that looks like ASM. Will this be the most common Claw syntax? Or will it be just for those who are going for the ASM syntax?

That's right :)
This is claw's asm syntax that I am working on currently.
There will be a way easier language too at some point.

Ah ok phew, I was worried that in the end I would have to use the ASM syntax.

I am making lots of progress. Currently I am implementing the preprocessor for the Claw assembler and the expression solver.

I hope that timers are supported, so that it is easier to make our games run at the same speed on multiple platforms. :P

Quote from: DJ Omnimaga on July 20, 2016, 03:36:57 AM
I hope that timers are supported, so that it is easier to make our games run at the same speed on multiple platforms. :P

Yes, as I already suggested. But, i don't know yet, if i will add them as instructions or as modules.

By module, do you mean like a plugin-based language enhancement? I hope it doesn't require the user to download extra dependencies if a Claw game uses such module.

Quote from: DJ Omnimaga on July 20, 2016, 09:47:05 PM
By module, do you mean like a plugin-based language enhancement? I hope it doesn't require the user to download extra dependencies if a Claw game uses such module.

Well Claw can be extended in two ways:

- Embedded modules:
These are modules such as graphics and string manipulation, file system, networking, timing, gpio, spi / i2c, etc. that are hardcoded into the respective Claw port.
These modules can be left out or added when compiling Claw and cannot be added later. Claw will check if all important modules are present before starting and refuse to boot if not.
Modules are often very hardware specific but still use the same functions throughout the different hardware.

- Included libraries:
Claw supports compiling executables as libraries that can be used by games and programs on (any) platform. All hardware specific code is done in the modules
and therefore libraries can be hardware independant.
But again, modules have to be present and the library cannot use more bits per value than the platform it runs on can offer.
These libraries are loaded at run time by calling a special instruction and can even be unloaded.
This way Claw allows launching other games and libraries from others. There are also planned permissions that rely on the hardware modules.

Libraries can be downloaded or are already included with the game. They can be shared between different games and should be as version independant as possible.
They can also be downloaded.
Modules however have to be built right into Claw. Claw is made modular, so adding or porting existing modules is going to be easy. Adding modules requires recompiling Claw.

I am also working on a website for Claw that will be used to download firmware upgrades, learn the language and very likely will offer an online compilation service.

My only concern about an online compiler is that if there is no way to compile your programs offline, then what do we do if your website shuts down in a few years? We lost many TI/non-TI tools in the past because of webmasters moving on in real life with kids and different hobbies, forgetting to renew their domain name and to pay their hosting bills in the process. One prime example is Vidéoway emulation (see the other thread).

So my suggestion would be to make that part of Claw also open-source, with a license that allows anyone to re-host a copy of the tutorials and compiler if the original copy ever disappears completely.

Thanks for explaining modules. Just make sure that it isn't a major hassle to compile Claw programs for multiple platforms at a time (eg not require changing most of the graphics code for each platform)

Quote from: DJ Omnimaga on July 21, 2016, 03:16:59 PM
My only concern about an online compiler is that if there is no way to compile your programs offline, then what do we do if your website shuts down in a few years? We lost many TI/non-TI tools in the past because of webmasters moving on in real life with kids and different hobbies, forgetting to renew their domain name and to pay their hosting bills in the process. One prime example is Vidéoway emulation (see the other thread).

So my suggestion would be to make that part of Claw also open-source, with a license that allows anyone to re-host a copy of the tutorials and compiler if the original copy ever disappears completely.

Thanks for explaining modules. Just make sure that it isn't a major hassle to compile Claw programs for multiple platforms at a time (eg not require changing most of the graphics code for each platform)

Well as said, i am not really sure if I make a web version. If I do it will just be additional to the offline compiler and would be a total rewrite in PHP.
I am probably not going to do it and focus on the offline compiler written in rust.
But, if @Streetwalrus or @Juju would host the Claw online compiler that is going to be written I rust on the CW server, then we will also have an online one too.

Oh ok phew. I feared you wanted to make it online-only. Another thing I didn't think about in my previous post that would have been a second issue is that certain people either don't have any internet access or are behind parental filters that blocks every site.

I guess if an online compiler is done then we could maybe host it. It would just need not to be too demanding resources-wise, as our VPS only has 1 GB of RAM and a single-core CPU (although we're moving to a 2 GB RAM cloud VPS in the near future)

If it's not too much trouble for us to maintain, we'll consider it.

You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

Quote from: DJ Omnimaga on July 22, 2016, 01:14:17 AM
You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

It's not going to be PHP but a compiled linux program. Otherwise I would host it on my site.

Quote from: DJ Omnimaga on July 22, 2016, 01:14:17 AM
You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

If needed, Linux has the necessary facilities to control resource usage and process priorities.

Quote from: Streetwalrus on July 22, 2016, 02:11:35 PM

Quote from: DJ Omnimaga on July 22, 2016, 01:14:17 AM
You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

If needed, Linux has the necessary facilities to control resource usage and process priorities.

Yes, but I was planning to write a PHP wrapper for the linux exectuable. Also all data will be stored on my server.
I was planning to host the online IDE and stuff on my server and on your server there would be the standard compiler executable that is called and processed by a PHP script. The php script gets called by the application on my server and is not accessible to the user. Also the php on the cw server would be password protected and could only be accessed by my server which does rate limiting and everything else so load on your side is going to be low.

You don't need PHP at all. Build your application using some RESTful framework instead.

Quote from: Streetwalrus on July 22, 2016, 10:01:12 PM
You don't need PHP at all. Build your application using some RESTful framework instead.

Well I want to use GET requests to get the bytecode back from your server. I will POST data over to your servers from my PHP backend. I really don't care what runs on your side, but my compiler will be a native application that I would like to run. It would just take the code from stdin and output the errors to stderr and the output code to stdout. There is no temporary storage required on your servers at all, just a little RAM while streaming the data out.
That would be my plan.

Quote from: DarkestEx on July 22, 2016, 05:49:50 AM

Quote from: DJ Omnimaga on July 22, 2016, 01:14:17 AM
You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

It's not going to be PHP but a compiled linux program. Otherwise I would host it on my site.

Ah ok I wasn't sure, because some people tend to release their programs as PHP and require the user to install Apache locally in order to run it or stuff like that, which can be an hassle.

Quote from: DJ Omnimaga on July 23, 2016, 06:11:33 AM

Quote from: DarkestEx on July 22, 2016, 05:49:50 AM

Quote from: DJ Omnimaga on July 22, 2016, 01:14:17 AM
You could always give him a bit of disk space but you would need to make sure the php script cannot hinder the rest of the server's performance if it contains bugs or during extensive use (for example if someone compiles over and over while debugging, which is very common).

It's not going to be PHP but a compiled linux program. Otherwise I would host it on my site.

Ah ok I wasn't sure, because some people tend to release their programs as PHP and require the user to install Apache locally in order to run it or stuff like that, which can be an hassle.

Well my initial idea was to write it entirely in PHP which can be used on a computer very easily without apache or anything similar. There are php downloads for any computer platform so this wouldn't have been a problem.

Weird, I always thought that running PHP scripts locally required installing Apache and other things. At least, that's what I had to do back then IIRC. Hopefully you can find a solution that doesn't require the user to install such thing and allow them to run the script via double-click on their computer, like any exe file.

Quote from: DJ Omnimaga on July 24, 2016, 06:36:30 AM
Weird, I always thought that running PHP scripts locally required installing Apache and other things. At least, that's what I had to do back then IIRC. Hopefully you can find a solution that doesn't require the user to install such thing and allow them to run the script via double-click on their computer, like any exe file.

Well the most user-friendly way will be the web application. Also the offline compiler will also support just dropping the input file onto the compiler. There will not be any windows or graphics gui though.

So kinda like a batch file? That would be fine I guess. It just needs to be quick, as to not turn away most people, especially since the language kinda targets less tech-savy people overall (since the more tech-savy users are more likely to stick to C or x86 ASM).

You cant drag and drop onto a batch file, batch files are just a list of Windows CMD commands that are executed ;)

Quote from: c4ooo on July 24, 2016, 04:22:47 PM
You cant drag and drop onto a batch file, batch files are just a list of Windows CMD commands that are executed ;)

And you are wrong. You can drag onto a batch file and access the path using variables.

Quote from: DJ Omnimaga on July 24, 2016, 04:21:43 PM
So kinda like a batch file? That would be fine I guess. It just needs to be quick, as to not turn away most people, especially since the language kinda targets less tech-savy people overall (since the more tech-savy users are more likely to stick to C or x86 ASM).

Claw compiler will always be a compiled binary. And about easyness, it will not be hard.
Also Claw is targeted at advanced users too. I will use it for remotely updating the firmware in IoT projects and also to allow me to run stuff from sd card. Claw is not made just to be simple. I need it in a number of actual projects.

I drag and dropped files into batch files many times. ;) One notable calculator example is TI-Boy SE.

Also regarding advanced users I meant that Claw would also target less advanced users as well, who tend to be turned away by anything that is either tedious or complicated to use.

errrrrrr how does that work?

Quote from: DJ Omnimaga on July 24, 2016, 04:30:37 PM
Also regarding advanced users I meant that Claw would also target less advanced users as well, who tend to be turned away by anything that is either tedious or complicated to use.

Yes, I am not planning to make Claw complicated but it will still be powerful.

Quote from: c4ooo on July 24, 2016, 04:38:17 PM
errrrrrr how does that work?

You can use %0, %1, ... to access the arguments that were passed to be batch file. If you drag a file onto a batch file, argument 0 should be the workdir and argument 1 the dropped file.

Ohh, don't know that :)

Anyways, i think it would be really usefull for some people if you could make a javascript based VM so they can easily run claw programs on their sites :)

Quote from: c4ooo on July 24, 2016, 04:50:23 PM
Ohh, don't know that :)

Anyways, i think it would be really usefull for some people if you could make a javascript based VM so they can easily run claw programs on their sites :)

While this idea sounds nice, the only thing I could offer is emscripten (I think) which turns C code into JavaScript.
This would totally work.

You would probably have to rewrite it then. I doubt the tool will correct convert C drawing calls into canvas drawing calls, fileIO calls into cookies (the only way to save stuff onto the user's computer in javascript) and so on.

Quote from: c4ooo on July 24, 2016, 05:10:19 PM
You would probably have to rewrite it then. I doubt the tool will correct convert C drawing calls into canvas drawing calls, fileIO calls into cookies (the only way to save stuff onto the user's computer in javascript) and so on.

Pretty simple, I won't. I really dislike Javascript as a language and will not rewrite it. About the drawing, that is an external module, not a built-in feature.

I can't imagine how CPU-intensive Claw games converted to Emscripten would be. Just look at Opossum Massage Simulator in the CW Arcade section to see what I mean... O.O


Unless the CPU hog depends of the browser you use?

Quote from: DJ Omnimaga on July 25, 2016, 07:51:26 AM
I can't imagine how CPU-intensive Claw games converted to Emscripten would be. Just look at Opossum Massage Simulator in the CW Arcade section to see what I mean... O.O


Unless the CPU hog depends of the browser you use?

I doubt it'll be too fast, yes. It's probably dead slow but I wasn't really going for it anyways. It's really unlikely that I'll port Claw to javascript but i am sure there is some way to make it work. I I thinking about an offline client that runs on your pc and is connected to the web ide. Maybe even a little webserver that is only accessible on the users pc that takes requests from the web ide and executes the code locally.

Wouldn't an offline client being connected to the web IDE defeat the purpose of being offline? ???

Quote from: DJ Omnimaga on July 25, 2016, 08:05:33 AM
Wouldn't an offline client being connected to the web IDE defeat the purpose of being offline? ???

Well i don't think so. You're running a browser on your computer so why can't you also have a program running in the background that receives the code and compiles and runs it on your own pc.

What if the user has no Internet access at all, though?

Quote from: DJ Omnimaga on July 25, 2016, 08:08:04 AM
What if the user has no Internet access at all, though?

Then he obviously compiles offline entirely.

Ah ok, I thought you required an always-online connection like certain game consoles and games.

Quote from: DJ Omnimaga on July 25, 2016, 08:10:09 AM
Ah ok, I thought you required an always-online connection like certain game consoles and games.

Lol of course not. I am trying to avoid it being online altogether. The web ide wouldn't really offer much compared to an offline one anyways.

Of course Claw itself will get internet functionality on some platforms that support it.

Which kind of Internet functionality would it have on platforms like Android?

Quote from: DJ Omnimaga on July 25, 2016, 05:26:26 PM
Which kind of Internet functionality would it have on platforms like Android?

On the PC, Android and the ESP 8266 it would have full sockets support and a built-in dhcp client.
There might be a webserver too.

UPDATE:

I have just launched the official website to http://claw.muessigb.net/ (http://claw.muessigb.net/)!
While it is still quite light when it comes to content, I will add more soon :)

Quote from: DarkestEx on July 25, 2016, 05:50:19 PM

Quote from: DJ Omnimaga on July 25, 2016, 05:26:26 PM
Which kind of Internet functionality would it have on platforms like Android?

On the PC, Android and the ESP 8266 it would have full sockets support and a built-in dhcp client.
There might be a webserver too.

So online multiplayer or highscore upload possibilities? Also nice site :3=

Quote from: DJ Omnimaga on July 26, 2016, 01:27:54 AM

Quote from: DarkestEx on July 25, 2016, 05:50:19 PM

Quote from: DJ Omnimaga on July 25, 2016, 05:26:26 PM
Which kind of Internet functionality would it have on platforms like Android?

On the PC, Android and the ESP 8266 it would have full sockets support and a built-in dhcp client.
There might be a webserver too.

So online multiplayer or highscore upload possibilities? Also nice site :3=

Thanks :)
And yes, this is absolutely possible ;)

That's nice. I think if such feature is implemented then it should maybe allow people to upload highscores or data on the site they want, using an API or something, though. But that would probably be very hard to implement and not as necessary as the language features itself. So it's better to focus on the non-online features first I guess. :P

Quote from: DJ Omnimaga on July 27, 2016, 08:05:17 AM
That's nice. I think if such feature is implemented then it should maybe allow people to upload highscores or data on the site they want, using an API or something, though. But that would probably be very hard to implement and not as necessary as the language features itself. So it's better to focus on the non-online features first I guess. :P

Well even though I don't plan to include too much functionality into the network module, it should still be quite easy to get something to work.

BUMP.

I am making good progress with the assembler again and might even be able to finish it, before going on vacation.
Currently there aren't many things anymore that need to be finished. Mainly the instructions compiler,
the file builder, the commandline arguments and a small part of the expression evaluator still needs to be done.

Nice. I wish you good luck. Which commands will be included before your vacations?

Quote from: DJ Omnimaga on July 30, 2016, 07:48:18 AM
Nice. I wish you good luck. Which commands will be included before your vacations?

Well the assembler is really easy to finish. I could basically implement all commands before I go, but I am fighting some nasty bugs currently so I don't think I will make it work before I go on vacation, though I will take my laptop with me and work some more on it whenever I find time.

Good luck then and I wish you fun during your vacations. :)

Quote from: DJ Omnimaga on July 31, 2016, 04:11:40 PM
Good luck then and I wish you fun during your vacations. :)

Thanks :)

So I found a bug that bothered me for a few days now and fixed the tokenizer in the assembler.
I am also looking into changing Claw to support 8 bit platforms.

What was the bug and which 8-bits platforms do you mean?

Quote from: DJ Omnimaga on August 05, 2016, 03:57:01 PM
What was the bug and which 8-bits platforms do you mean?

The bug was the tokenizer not recognizing the negative sign and overwriting it instead of adding it to numbers. I also fixed another bug that prevented mathematical expressions from being evaluated correctly.

With 8-bit platforms I mean support for platforms that are truly 8 bit based and which do not have acceleration for 16-bit but still basically support it (comp, add, sub, support).

On a side note, I hope that Claw uses the same sign for negative and substractions, because in TI-BASIC editors on the PC it's annoying when you type - by habit, only to get a Syntax error on the calc because you had to use the other minus sign.

And thanks for the info about 8-bit platforms. I was wondering if that meant the NES, Sega Master System, MSX, Commodore 64 or such platforms would eventually run Claw.

Quote from: DJ Omnimaga on August 05, 2016, 09:48:05 PM
On a side note, I hope that Claw uses the same sign for negative and substractions, because in TI-BASIC editors on the PC it's annoying when you type - by habit, only to get a Syntax error on the calc because you had to use the other minus sign.

And thanks for the info about 8-bit platforms. I was wondering if that meant the NES, Sega Master System, MSX, Commodore 64 or such platforms would eventually run Claw.

First, of course BUT there is a limitation. Negative numbers have to be put in parantheses if they are not the first number in an equation. Just as you know from mathematics.

And yes, I mean these type of platform too to some extent.
But mainly the AVR processor architecture and possibly 6502 and z80.

Ah ok. Yeah my main issue was having to access a special menu or utility just to be able to insert the special minus symbol in my code every single time I needed it.

And I see. I am curious about how well old-school platforms could handle vector graphics, though...

Quote from: DJ Omnimaga on August 06, 2016, 07:02:40 AM
Ah ok. Yeah my main issue was having to access a special menu or utility just to be able to insert the special minus symbol in my code every single time I needed it.

And I see. I am curious about how well old-school platforms could handle vector graphics, though...

If you ask me, quite well actually. Given that one of the first actual game consoles with a 1 MHz CPU actually just used them and also given that I basically just lines and circles, it shouldn't be to bad.

Ah ok. I was wondering, because on Mac computers in college (Cubes) Adobe Illustrator seemed to lag like mad as soon as something becomes remotely complex. If vectors lagged a 450 MHz computer this much, imagine how bad it will be on a 15 MHz calculator. But again, maybe that was because we worked a lot with bezier curves and other effects.

Eh, theorically, vectors shouldn't lag that much on anything, even Bézier curves if you do it right. If you add some fancy stuff, then yeah it might lag.

Here we go for the first test release of Claw Assembler:
http://claw.muessigb.net/dl/clawsemble-16_aug_08-a.zip

Please download and test it, by opening a terminal and typing:
either:
mono ./csm.exe ./Sample01.csm
or on Windows:
csm .\Sample01.csm

Try messing with the #err lines and the #def lines and their equations.

I would be glad if someone broke the arithmetic part so that I can make it even more rock solid ;)

Nice to see a release. I'll see if I can find some time to mess around with it later :)

Also I like your signature :P (I think the Claw logo should be a little darker, though, so it's easier to see on light backgrounds)

Quote from: DJ Omnimaga on August 08, 2016, 07:19:26 AM
Nice to see a release. I'll see if I can find some time to mess around with it later :)

Also I like your signature :P (I think the Claw logo should be a little darker, though, so it's easier to see on light backgrounds)

Thanks :)

I changed the logo's color to black. Does it work better now?

I like it more actually now :)

Quote from: DJ Omnimaga on August 08, 2016, 04:44:23 PM
I like it more actually now :)

Thanks :)

I FINISHED THE PREPROCESSOR! ;D
It can do, expressions, hexadecimal escapes, multiline statements, defines, undefines, nested if's, ifdefs, elseifs, custom errors, file includes and more.
Also the error handling is totally finished and displays nicely formatted errors.
Feel free to test and download the version from here:
http://claw.muessigb.net/dl/clawsemble-16_aug_09-a.zip

Awesome! I'm glad to see this progress smoothly so far. :) Will there be a mini tutorial in the future by the way?

Quote from: DJ Omnimaga on August 09, 2016, 04:06:03 AM
Awesome! I'm glad to see this progress smoothly so far. :) Will there be a mini tutorial in the future by the way?

Absolutely, as soon as I find time, I will write a full one up.
To make it easy for all of us, I kept the entire preprocessor compatible to the C one.

Little Clawsemble preprocessor overview:

Let's start with the conditionals.
They can be nested as much as desired and each if can have an unlimited amount of elseif's/elseifdef's and elseifndef's.
There can only be one else which is optional and has to be the last element in the if block.
#if (expression)    is used to only process the enclosed code if the condition is met, or the number or string inside the parantheses is non-zero
#ifdef defininition    is similar to the above but the condition is met, if a variable with the name is defined
#ifndef definition    as above, but condition is met, if the variable is not defined
#elseif (expression)    is used to provide an alternative, if the previous condition(s) is/are not met
#elseifdef definition    as above, but the condition is if a variable with that name is defined
#elseifndef definition    as above, but the if the variable is not defined
#else    if the condition is not met and the elseif's don't met their conditions either
#endif    is used to close the if-block

Expressions are simple.
All C arithmetic operators are supported and are using the same symbol, except for modulo, which is // now.
Numbers can be written with +/- prefix to show whether they are positive or negative. Negative numbers do
not need to be enclosed in parantheses. You can easily write something like: (-1 + -2 -3 - -4) and you can
even omit the spaces and Clawsemble will still be able to deal with it correctly.
Using the negative sign to negate an expression is NOT supported though. Use *-1 to do so instead.
Expressions should always be enclosed in one set of parantheses ()
Hexadecimal numbers are prefixed with an $ABAB, characters are written like this %d.

Multiple files work too.
Just use #include "filename.csm", to include other source files. They are just inserted into your main program at the position
of the #include statement and have access to the same #defines as your main program.

You can define variables.
Use #define MY_VAR 1234, #define YOUR_VAR %d, #define HEXVAR $DEADBEEF or #define ANOTHER_VAR (123 + $1242 * 123) to define your own variables
that you can check later on with the #if statement and it's companions. #undefine is used to delete a variable from memory again.
Variables can also be redefined at any point by simply calling #define again.
Be careful with the names, as they are case-sensitive. Also, all exact word-occurences of the variable name in the program are
automatically replaced by the value that the variable has at that point of time. If it changes later on in the assemblation,
the value won't change again.

Custom errors are easy to use.
Let's say, you have some conditions that have to be met for a program to be assembled correctly and you would like to prevent
the user from such accidents then you can simply use the #error statement to abort the further assemblation of the program.
You can even display an error message, the result of an expression or the contents of a variable by passing it after the #error statement:
e.g.: #error ("The architecture " + ARCH + " is unfortunately not supported at the moment!")

Make it short.
Many shorthand forms are available to save you typing:
#error, #err
#define, #def
#include, #inc
#elseif, #elif
#elseifdef, #elifdef
#elseifndef, #elifndef

Comment your code.
You can use the ; character to comment out lines if you don't want them to be parsed.
Everything after the start of a comment until a newline character is ignored and will not be processed.
You can put the comment at the beginning or the end of a line. Multiline comments are not supported.
Comments can be disabled by putting a \ in front of the comment. Like this:    \;
The \ character can also be used to break single line codes into multiple ones:
e.g.: #define MY_COMPLEX_EXPRESSION \
(123 + 124 + 23230 + 12040 + ONE_OF_MY_VARS + 12332 * 124224 - 20 + \
1402 + $BEEF)


This tutorial will be finished later on, when more of the assembler is done and ready for primetime.

Update:

I have finished the instruction list. A lot was already there but I have finally completed it.
Can you PLEASE have a look if I am missing anything and maybe suggest some improvements?

Here is the full instruction list:
https://docs.google.com/spreadsheets/d/1Tfi8z7maQLM3RUHfQpnS50gAkGyfiizkQ54TTZGl9e4/edit?usp=sharing

I can't check all commands now due to limited time, but wouldn't it be easier for programmers to not have to press Shift+# or Alt gr+#  every three second when coding?

Quote from: DJ Omnimaga on August 10, 2016, 01:34:15 PM
I can't check all commands now due to limited time, but wouldn't it be easier for programmers to not have to press Shift+# or Alt gr+#  every three second when coding?

What  ???
Well, first, C and many other languages use # for preprocessor directives and second, I think on most keyboards it's quite simple to reach the # symbol.
For me it's a separate key.
I primarily wanted to keep it compatible with existing things, so I choose the most common method. I doubt you will ever use the Assembler as I assume you don't get along with assembly and I can't complain if you can't; it's still not so easy. But don't worry, Cumred's high level compiler with mostly Basic/Lua syntax is on it's way ;)

Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

Quote from: DJ Omnimaga on August 10, 2016, 04:02:26 PM
Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

Thanks :D

You usually don't need to use these statements as they are executed on the compiler PC and not the device. Clawsemble has own instructions for it which are just written as a word.

I have finally finished Claw's instruction set :)

You can find a list with all the instructions and their descriptions and parameters here:
https://github.com/muessigb/Clawsemble/wiki/Instruction-set

Quote from: DJ Omnimaga on August 10, 2016, 04:02:26 PM
Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

No keyboard has a first level '#'.
If you can't be bothered to press the shift button you could get the hash-tag keyboard :trollface: http://thehashkey.com/kickstarter

Quote from: c4ooo on August 22, 2016, 08:50:08 AM

Quote from: DJ Omnimaga on August 10, 2016, 04:02:26 PM
Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

No keyboard has a first level '#'.
If you can't be bothered to press the shift button you could get the hash-tag keyboard :trollface: http://thehashkey.com/kickstarter

Do a bit of research before claiming something:
(https://upload.wikimedia.org/wikipedia/commons/thumb/a/a3/German-Keyboard-Layout-T2-Version2-large.png/550px-German-Keyboard-Layout-T2-Version2-large.png)
This is the german keyboard layout which has a first level # key right left to the return key.
Unfortunately the same layout makes it cumbersome to access the curly and sharp braces, as they need a modifier key to work.

Sorry for breaking the previous instruction set, but I forgot some really important instructions.
Here is the updated list:

#	Mnemonic	Description	Operands	Static operand
0x0	NOP	Do nothing.
0x1	VNFO	Pushes the configuration flags of the virtual machine such as features and processor details.
0x2	STSZ	Pushes the current instance's allocated stack size followed by the usage.
0x3	CASZ	Pushes the current instance's allocated call stack size followed by the usage.
0x4	PLSZ	Pushes the system's allocated array pool size followed by the usage.
0x5	RICK	Rickrolls the user. This will result in the program not behaving as expected. Use with care!
0x6	HCF	Kills the current instance of the virtual machine. Displays an error message from the constant table. Use -1 to skip the message.		TABLE_ENTRY (S)
0x7	EOP	Ends the current program. Performs a normal exit.
0x8	BRK	Creates a breakpoint. Takes a constant breakpoint ID.		BREAKPOINT_ID (B)
0x9	DBPS	Prints a string from the constant table to the debug console.		TABLE_ENTRY (S)
0xa	DBDA	Dumps the contents of the current array to the debug console.
0xb	DBDV	Pops the last stack value and prints it to the debug console.	VALUE ($0)
0xc	MDP	Pushes whether the optional module is present and loaded. Takes an constant entry that contains the module name.		TABLE_ENTRY  (S)
0xd	MDL	Loads a module into the extended instruction area. Takes a constant index of the module.		MODULE_INDEX (B)
0xe	MDV	Pushes the minor, the the major version of the module onto the stack. Takes a constant index of the module.		MODULE_INDEX (B)
0xf	LRL	Loads a library/binary from a string handle. Takes the handle from the referenced constant table entry. Pushes whether the load was successful.	SLOT ($0)	TABLE_ENTRY (S)
0x10	LRD	Loads a library/binary from a string handle. Takes the handle from the currently loaded string. Pushes whether the load was successful.	SLOT ($0)
0x11	LRU	Unloads a library/binary that was previously loaded. Does not crash if the slot was empty.	SLOT ($0)
0x12	FEX	Pushes whether a function exists. Using -1 as the slot will check for a local function.	SLOT ($0), FUNCTION_INDEX ($0)
0x14	LC	Loads a numeric constant and pushes it onto the stack.		VALUE (N)
0x15	LD	Copies a lower stack value onto the top of the stack. Uses a constant relative offset.		REL_STK_OFFSET (B)
0x16	LDD	Copies a lower stack value onto the top of the stack. Uses a dynamic absolute offset.	ABS_STK_OFFSET ($0)
0x17	DV	Drops the last value from the stack.	VALUE ($0)
0x18	DP	Duplicates the uppermost value on the stack.	VALUE ($0)
0x19	SW	Swaps the two uppermost values on the stack.	VALUE ($0)
0x1a	LX	Pushes a value from an array to the stack. Uses a constant address (aligned at the numeric type).		ADDRESS (N)
0x1b	LXD	Pushes a value from an array to the stack. Uses a dynamic address (aligned at the numeric type).	ADDRESS ($0)
0x1c	LXB	Pushes a byte value from an array to the stack. Uses a constant address (aligned at the byte type).		ADDRESS (N)
0x1d	LXBD	Pushes a byte value from an array to the stack. Uses a dynamic address (aligned at the byte type).	ADDRESS ($0)
0x1e	PX	Pushes a value from the stack to the array. Uses a constant address (aligned to the numeric type).	VALUE ($0)	ADDRESS (N)
0x1f	PXD	Pushes a value from the stack to the array. Uses a dynamic address (aligned to the numeric type).	VALUE ($1), ADDRESS ($0)
0x20	PXB	Pushes a byte value from the stack to the array. Uses a constant address (aligned to the byte type).	VALUE ($0)	ADDRESS (N)
0x21	PXBD	Pushes a byte value from the stack to the array. Uses a dynamic address (aligned to the byte type).	VALUE ($1), ADDRESS ($0)
0x22	XC	Creates a new numeric array. Uses a constant size in elements. Selects the array afterwards.		SIZE (N)
0x23	XCB	Creates a new byte array. Uses a constant size in bytes. Selects the array afterwards.		SIZE (N)
0x24	XCD	Creates a new numeric array. Size in bytes is taken from the stack. Selects the array afterwards.	SIZE ($0)
0x25	XCI	Creates a new array and initializes it's contents and size with a constantly selected constant value from the constant table. Selects the array afterwards.		TABLE_ENTRY (A)
0x26	XS	Selects the current array used to share data with. Uses a constant relative offset within the current instance.		REL_ARR_OFFSET (B)
0x27	XSD	Selects the current array used to share data with. Uses a dynamic absolute identifier.	ABS_ARR_OFFSET ($0)
0x28	XSR	Selects the current array as the array assigned to the calling executable.
0x29	XAR	Sets the current array as the array assigned to the calling executable.
0x2a	XR	Resizes the currently selected array. Uses a dynamic size in elements. On some platforms only the last created array can be resized.	SIZE ($0)
0x2b	XRB	Resizes the currently selected array. Uses a dynamic size in bytes. On some platforms only the last created array can be resized.	SIZE ($0)
0x2c	XRL	Resizes the last created array. Uses a dynamic size in elements. This is guaranteed to work on any platform.	SIZE ($0)
0x2d	XRLB	Resizes the last created array. Uses a dynamic size in bytes. This is guaranteed to work on any platform.	SIZE ($0)
0x2e	XD	Drops the currently selected array. On some platforms only the last created array can be dropped.
0x2f	XDL	Drops the last created array. This is guaranteed to work on any platform.
0x30	XPO	Pushes the relative offset of the currently selected array to the stack.
0x31	XPI	Pushes the absolute index of the currently selected array to the stack.		REL_ARR_OFFSET (B)
0x32	XPS	Pushes the size in bytes of the currently selected array to the stack.
0x33	XPSB	Pushes the size in bytes of the currently selected array to the stack.
0x34	XCS	Pushes the size in bytes of the dynamically selected constant table entry. Pushes 0 if the entry does not exist.	TABLE_ENTRY ($0)
0x35	XFN	Fills the array with a value. Takes the number, the length in elements and the offset in elements from the stack.	LENGTH ($2), TAR_OFFSET ($1), VALUE ($0)
0x36	XFC	Fills the array with a constant value. Takes length in bytes and offset in bytes from the stack.	LENGTH ($1), TAR_OFFSET ($0)	VALUE (B)
0x37	XMN	Copies from the current array to another one. Takes length in elements and offset in elements from the stack. Takes a constant relative array offset.	LENGTH ($2), TAR_OFFSET ($1), SRC_OFFSET ($0)	REL_ARR_OFFSET (B)
0x38	XMB	Copies from the current array to another one. Takes length in bytes and offset in bytes from the stack. Takes a constant relative array offset.	LENGTH ($2), TAR_OFFSET ($1), SRC_OFFSET ($0)	REL_ARR_OFFSET (B)
0x39	XMD	Copies from the current array to another one. Takes length, offset and absolute offset to target from the stack.	LENGTH ($3), TAR_OFFSET ($2), SRC_OFFSET ($1), ABS_ARR_OFFSET ($0)
0x3a	XMCN	Copies a constant from the constant table to the array. Uses a constant table entry as source. Clips the constant, if it's longer than the size. Length and offset in elements.	LENGTH ($2), TAR_OFFSET ($1), SRC_OFFSET ($0)	TABLE_ENTRY (A)
0x3b	XMCB	Copies a constant from the constant table to the array. Uses a constant table entry as source. Clips the constant, if it's longer than the size. Length and offset in bytes.	LENGTH ($2), TAR_OFFSET ($1), SRC_OFFSET ($0)	TABLE_ENTRY (A)
0x3c	XMCD	Copies a constant from the constant table to the array. Uses a dynamic table entry. Clips the constant, if it's longer than the size. Length and offset in bytes.	LENGTH ($2), TARGET_OFFSET  ($1), TABLE_ENTRY ($0)
0x3d	CNB	Converts the number in elements on the stack to the equivalent number of bytes.	ELEMENTS ($0)
0x3e	CNC	Converts the constant number in elements to the equivalent number of bytes and pushes it.		ELEMENTS (N)
0x3f	CBN	Converts the number in bytes on the stack to the next equivalent number of elements.	BYTES ($0)
0x41	JP	Performs a relative jump. Takes a constant offset to the target.		OFFSET (L)
0x42	JPD	Performs a relative jump. Takes a dynamic offset to the target.	OFFSET ($0)
0x43	JPZ	Performs a relative jump, if the popped stack entry is <= 0.	DISCRIMINATOR ($0)	OFFSET (L)
0x44	JPP	Performs a relative jump, if the popped stack entry is > 0.	DISCRIMINATOR ($0)	OFFSET (L)
0x45	JPPD	Performs a relative jump to the dynamic offset, if the popped stack entry is > 0.	DISCRIMINATOR ($1), OFFSET ($0)
0x46	JS	Performs a short jump ahead if popped stack entry is > 0.	DISCRIMINATOR ($0)	OFFSET (SL)
0x47	JSB	Performs a short jump back if popped stack entry is > 0.	DISCRIMINATOR ($0)	OFFSET (SL)
0x48	CA	Calls a local function. Takes a constant function index.		FUNCTION_INDEX (F)
0x49	CAD	Calls a local function. Takes a dynamic function index.	FUNCTION_INDEX ($0)
0x4a	CL	Calls a library function. Takes a constant function index.	SLOT ($0)	FUNCTION_INDEX (F)
0x4b	CLD	Calls a library function. Takes a dynamic function index.	SLOT ($1), FUNCTION_INDEX ($0)
0x4c	RET	Returns from a function early.
0x4e	ADD	Pops $0 and $1. Pushes $1 + $0.	$0, $1
0x4f	SUB	Pops $0 and $1. Pushes $1 - $0.	$0, $1
0x50	MUL	Pops $0 and $1. Pushes $1 * $0.	$0, $1
0x51	DIV	Pops $0 and $1. Pushes $1 / $0. This is a signed division.	$0, $1
0x52	MOD	Pops $0 and $1. Pushes $1 % $0. This is a signed division.	$0, $1
0x53	POW	Pops $0 and $1. Pushes $0 to the power of $1.	$0, $1
0x54	MAX	Pops $0 and $1. Pushes the larger of both.	$0, $1
0x55	MIN	Pops $0 and $1. Pushes the smaller of both.	$0, $1
0x56	AND	Pops $0 and $1. Pushes $1 & $0. This is a bitwise function.	$0, $1
0x57	OR	Pops $0 and $1. Pushes $1 | $0. This is a bitwise function.	$0, $1
0x58	XOR	Pops $0 and $1. Pushes $1 ^ $0. This is a bitwise function.	$0, $1
0x59	BSL	Pops $0 and $1. Pushes $1 << $0. This is a bitwise function.	$0, $1
0x5a	BSR	Pops $0 and $1. Pushes $1 >> $0. This is a bitwise function.	$0, $1
0x5b	ADDC	Pops $0. Pushes $0 + c.	$0	C (N)
0x5c	SUBC	Pops $0. Pushes $0 - c.	$0	C (N)
0x5d	MULC	Pops $0. Pushes $0 * c.	$0	C (N)
0x5e	DIVC	Pops $0. Pushes $0 / c. This is a signed division.	$0	C (N)
0x5f	MODC	Pops $0. Pushes $0 % c. This is a signed division.	$0	C (N)
0x60	ANDC	Pops $0. Pushes $0 & c. This is a bitwise function.	$0	C (N)
0x61	ORC	Pops $0. Pushes $0 | c. This is a bitwise function.	$0	C (N)
0x62	XORC	Pops $0. Pushes $0 ^ c. This is a bitwise function.	$0	C (N)
0x63	BSLC	Pops $0. Pushes $0 << places. This is a bitwise function.	$0	PLACES (B)
0x64	BSRC	Pops $0. Pushes $0 >> places. This is a bitwise function.	$0	PLACES (B)
0x65	ICR	Pops $0. Pushes $0 + 1.	$0
0x66	DCR	Pops $0. Pushes $0 - 1.	$0
0x67	ABS	Pops $0. Pushes abs($0).	$0
0x68	RND	Pops $0. Pushes rand() % $0.	$0
0x69	SQRT	Pops $0. Pushes sqrt($0).	$0
0x6a	LOG2	Pops $0. Pushes log2($0).	$0
0x6b	IPW2	Pops $0. Pushes a logic true, if $0 is a power of 2 and a logic false otherwise. This is a logical function.	$0
0x6c	NEG	Pops $0. Pushes -$0.	$0
0x6d	NOT	Pops $0. Pushes ~$0. This is a bitwise function.	$0
0x6e	REV	Pops $0. Reverses the bits of $0 and pushes them. This is a bitwise function.	$0
0x6f	CBS	Pops $0. Pushes the number of active bits in $0. This is a bitwise function.	$0
0x70	CBZ	Pops $0. Pushes the number of trailing zero bits in $0. This is a bitwise function.	$0
0x71	LAND	Pops $0 and $1. Pushes $0 && $1. This is a logical function.	$0, $1
0x72	LOR	Pops $0 and $1. Pushes $0 || $1. This is a logical function.	$0, $1
0x73	LNOT	Pops $0. Pushes !$0. This is a logical function.	$0
0x74	EQ	Pops $0 and $1. Pushes $0 == $1. This is a logical function.	$0, $1
0x75	NEQ	Pops $0 and $1. Pushes $0 != $1. This is a logical function.	$0, $1
0x76	LT	Pops $0 and $1. Pushes $0 < $1. This is a logical function.	$0, $1
0x77	LTEQ	Pops $0 and $1. Pushes $0 <= $1. This is a logical function.	$0, $1
0x78	GT	Pops $0 and $1. Pushes $0 > $1. This is a logical function.	$0, $1
0x79	GTEQ	Pops $0 and $1. Pushes $0 >= $1. This is a logical function.	$0, $1	C (N)
0x7a	EQC	Pops $0. Pushes $0 == c. This is a logical function.	$0	C (N)
0x7b	NEQC	Pops $0. Pushes $0 != c. This is a logical function.	$0	C (N)
0x7c	LTC	Pops $0. Pushes $0 < c. This is a logical function.	$0	C (N)
0x7d	LTEQC	Pops $0. Pushes $0 <= c. This is a logical function.	$0	C (N)
0x7e	GTC	Pops $0. Pushes $0 > c. This is a logical function.	$0	C (N)
0x7f	GTEQC	Pops $0. Pushes $0 >= c. This is a logical function.	$0

Uuuuh, an evil doublepost  O.O Should better call the site Editors to fix that ;)

Btw you should also update the spoilered list in your old post :)
Aaand it really looks nice  :thumbsup:

Quote from: p2 on August 22, 2016, 01:53:58 PM
Uuuuh, an evil doublepost  O.O Should better call the site Editors to fix that ;)

Btw you should also update the spoilered list in your old post :)
Aaand it really looks nice  :thumbsup:

Haha, double posts are alright to promote big updates which this absolutely is ;)

I will and thanks :)

Thanks for the instructions update. Also I'm glad this is coming along nicely. I'm still curious about how fast vector graphics will render on lower-end platforms, especially if many vector graphics are present on the screen at the same time (such as Ikaruga or Touhou shooters)

Quote from: DarkestEx on August 22, 2016, 12:06:52 PM

Quote from: c4ooo on August 22, 2016, 08:50:08 AM

Quote from: DJ Omnimaga on August 10, 2016, 04:02:26 PM
Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

No keyboard has a first level '#'.
If you can't be bothered to press the shift button you could get the hash-tag keyboard :trollface: http://thehashkey.com/kickstarter

Do a bit of research before claiming something:
-snip-
This is the german keyboard layout which has a first level # key right left to the return key.
Unfortunately the same layout makes it cumbersome to access the curly and sharp braces, as they need a modifier key to work.

Given that the population of Germany makes up 1.1% of the world population, these keyboards are still a minority ;) However, i would presume there are other      keyboard layouts with a first level '#', and one should also consider that computer use is not equally distributed across countries., however it seems that english keyboards with no first level '#' are still the blatant majority.

Quote from: c4ooo on August 23, 2016, 09:10:25 AM

Quote from: DarkestEx on August 22, 2016, 12:06:52 PM

Quote from: c4ooo on August 22, 2016, 08:50:08 AM

Quote from: DJ Omnimaga on August 10, 2016, 04:02:26 PM
Oh I meant how commands are #elseif instead of elseif for example. On my French Canadian keyboard the # has no 1st level key assigned. I am ok with #, but commands will take longer to type.

Keep up the good work though :3=

No keyboard has a first level '#'.
If you can't be bothered to press the shift button you could get the hash-tag keyboard :trollface: http://thehashkey.com/kickstarter

Do a bit of research before claiming something:
-snip-
This is the german keyboard layout which has a first level # key right left to the return key.
Unfortunately the same layout makes it cumbersome to access the curly and sharp braces, as they need a modifier key to work.

Given that the population of Germany makes up 1.1% of the world population, these keyboards are still a minority ;) However, i would presume there are other      keyboard layouts with a first level '#', and one should also consider that computer use is not equally distributed across countries., however it seems that english keyboards with no first level '#' are still the blatant majority.

Haha yes, but I was still right :P

Also I am just following standards. C, C# and most assemblers use # for preprocessor instructions so I really don't feel bad for using it.

So I would say the instruction set is now finally done :)
I have moved stuff around and tweaked others.

Great. There is only one concern I have about that instruction set, though, and it's that there seems to be many for an ASM-like instruction set. Are all ASM languages like that? Because I kept hearing ASM programmers saying they found ASM easier than higher-level languages because there are very few instructions to learn compared to other languages.

Quote from: DJ Omnimaga on August 25, 2016, 05:36:20 AM
Great. There is only one concern I have about that instruction set, though, and it's that there seems to be many for an ASM-like instruction set. Are all ASM languages like that? Because I kept hearing ASM programmers saying they found ASM easier than higher-level languages because there are very few instructions to learn compared to other languages.

Well after all this is a fraction of all total Z80 instructions ;)
And most of them do high level things such as working with arrays.

Really? I thought Z80 only had like 8 instructions O.O

Quote from: DJ Omnimaga on August 25, 2016, 03:48:57 PM
Really? I thought Z80 only had like 8 instructions O.O

Here you go, DJ:
http://clrhome.org/table/

Thanks for the link @DarkestEx , I didn't realize there were that many.

Also what happened to your avatar and signature banner? Both images are 404 links O.O

both his avatar and signature banner are working? ^^ no 404s for me :)
(pictures weren't cached, could download them)

Edit: Looks like I checked right after he had fixed them ^^

Quote from: DJ Omnimaga on August 25, 2016, 11:46:59 PM
Thanks for the link @DarkestEx , I didn't realize there were that many.

Also what happened to your avatar and signature banner? Both images are 404 links O.O

Yes, Z80 is huge O.O

I just fixed the images. Thanks for telling me :)

Yay! Yeah at first I thought your host went belly up or something

I started working on Claw as an operating system. This will be a separate project and will allow booting into Claw with a normal computer.
Unlike the embedded Claw, this will be closed source.
Here's a screenshot of it booting:
(http://img.codewalr.us/Claw86_01.PNG)

Nice. I hope the startup times remain fast, unlike the TI-Nspire OS  and most Windows OSes :)

Quote from: DJ Omnimaga on September 07, 2016, 05:20:01 AM
Nice. I hope the startup times remain fast, unlike the TI-Nspire OS  and most Windows OSes :)

It's starting in just a few seconds (under 5 secs).

Btw, I have made a step by step walktrough through a sample program I made.
It is also available on my GitHub Wiki: https://github.com/bmuessig/Clawsemble/wiki/Step-by-step-example-program



.CWX:16  ;16 bit executable

#define num_values 3  ; number of values is 3
.dbs values {10,5,2}  ; constant short array with the values

.sym main:0  ; main entry point, you can name it whatever you want as long as you set its id to 0
        xci values  ; create a new buffer filled with the constant "values" from above
        lc 0  ; load the sum start number 0 onto the stack
        dp  ; load the counter start number 0 onto the stack by duplicating the last zero
    .lbl forloop_bgn  ; new label (start of for-loop)
        dp  ; duplicate the uppermost value to save it
        ltc num_values  ; check if counter is less than 5
        jpn forloop_end  ; if last comparision was false end the for-loop
        sw  ; swaps the counter with the sum
        ld 1  ; copies the counter ontop of the stack
        lxbd  ; load value in the values array at the counter position
        add  ; add the value from the array to the sum
        sw  ; swap to the counter again
        icr  ; increment the counter
        jp forloop_bgn  ; jump to the begin of the for-loop again
    .lbl forloop_end  ; end of the for loop
        dv  ; drop the counter
        divc num_values  ; divide the sum by the number of values
        dbdv  ; print the result to the debug console
        eop  ; optional end of program statement


.CWX:16
This statement basically just tells the assembler to make an executable, no library.
The executable shall use 16 bit constants.

#define num_values 3
This tells the preprocessor to load the number 3 into the preprocessor constant "num_values"

.dbs values {10,5,2}
This tells the compiler stage 2 to add an entry to the constant database with the name "values"

.sym main:0
This tells the compiler stage 2 to add a new symbol (aka function) that is named "main" and has the function id 0. Later the operating system / vm searches for function 0 when it launches the program. Function 0 is always the entry point for executables.

xci values
This creates a new array on the stack and makes its size and element equal to the one of the "values" constant.

lc 0
This loads the constant 16-bit number 0 onto the stack:
(Top of stack) 0 (Bottom of stack)

dp
This duplicates the top entry of the stack:
0 (Counter) (Top of stack)
0 (Sum) (Bottom of stack)

.lbl forloop_bgn
This saves a label (only valid to the current symbol) with the name "forloop_bgn".
This tells the compiler to note this address down for later use.

dp
This duplicates the counter as it will otherwise get lost in the next instruction:
0 (Copy of Counter) (Top)
0 (Counter)
0 (Sum)

ltc num_values
If the uppermost stack value that is popped is less than num_values (3), push 1. Otherwise push 0:
1 (Result of check) (Top)
0 (Counter)
0 (Sum)

jpn forloop_end
If the uppermost stack value that is popped is zero or smaller than zero, jump to "forloop_end":
0 (Counter) (Top)
0 (Sum)

sw
Swaps the Counter with the Sum:
0 (Sum) (Top)
0 (Counter)

ld 1
Copies the counter to the top of the stack:
0 (Copy of Counter) (Top)
0 (Sum)
0 (Counter)

lxbd
Loads the byte number at the array index of the uppermost stack entry to the stack:
10 (Value from array) (Top)
0 (Sum)
0 (Counter)

add
Adds the Value from the array to the sum and pushes the result:
10 (Sum) (Top)
0 (Counter)

sw
Swap to the counter again:
0 (Counter) (Top)
10 (Sum)

icr
Increment the counter by one:
1 (Counter) (Top)
10 (Sum)

jp forloop_bgn
Jumps back to the beginning of the loop.

(We go back to the beginning of the loop)
dp
This duplicates the counter as it will otherwise get lost in the next instruction:
1 (Copy of Counter) (Top)
1 (Counter)
10 (Sum)

ltc num_values
If the uppermost stack value that is popped is less than num_values (3), push 1. Otherwise push 0:
1 (Result of check) (Top)
1 (Counter)
10 (Sum)

jpn forloop_end
If the uppermost stack value that is popped is zero or smaller than zero, jump to "forloop_end":
1 (Counter) (Top)
10 (Sum)

sw
Swaps the Counter with the Sum:
10 (Sum) (Top)
1 (Counter)

ld 1
Copies the counter to the top of the stack:
1 (Copy of Counter) (Top)
10 (Sum)
1 (Counter)

lxbd
Loads the byte number at the array index of the uppermost stack entry to the stack:
5 (Value from array) (Top)
10 (Sum)
1 (Counter)

add
Adds the Value from the array to the sum and pushes the result:
15 (Sum) (Top)
1 (Counter)

sw
Swap to the counter again:
1 (Counter) (Top)
15 (Sum)

icr
Increment the counter by one:
2 (Counter) (Top)
15 (Sum)

jp forloop_bgn
Jumps back to the beginning of the loop.

(We go back to the beginning of the loop)
dp
This duplicates the counter as it will otherwise get lost in the next instruction:
2 (Copy of Counter) (Top)
2 (Counter)
15 (Sum)

ltc num_values
If the uppermost stack value that is popped is less than num_values (3), push 1. Otherwise push 0:
1 (Result of check) (Top)
2 (Counter)
15 (Sum)

jpn forloop_end
If the uppermost stack value that is popped is zero or smaller than zero, jump to "forloop_end":
2 (Counter) (Top)
15 (Sum)

sw
Swaps the Counter with the Sum:
15 (Sum) (Top)
2 (Counter)

ld 1
Copies the counter to the top of the stack:
2 (Copy of Counter) (Top)
15 (Sum)
2 (Counter)

lxbd
Loads the byte number at the array index of the uppermost stack entry to the stack:
2 (Value from array) (Top)
15 (Sum)
2 (Counter)

add
Adds the Value from the array to the sum and pushes the result:
17 (Sum) (Top)
2 (Counter)

sw
Swap to the counter again:
2 (Counter) (Top)
17 (Sum)

icr
Increment the counter by one:
3 (Counter) (Top)
17 (Sum)

jp forloop_bgn
Jumps back to the beginning of the loop.

(We go back to the beginning of the loop)
dp
This duplicates the counter as it will otherwise get lost in the next instruction:
3 (Copy of Counter) (Top)
3 (Counter)
17 (Sum)

ltc num_values
If the uppermost stack value that is popped is less than num_values (3), push 1. Otherwise push 0:
0 (Result of check) (Top)
3 (Counter)
17 (Sum)

jpn forloop_end
If the uppermost stack value that is popped is zero or smaller than zero, jump to "forloop_end":
3 (Counter) (Top)
17 (Sum)

(We jump to the end of the loop)
dv
Drops the uppermost stack value (the counter):
17 (Sum) (Top)

divc num_values
Integer-divides the Sum by the number of values (3):
6 (Result) (Top)

dbdv
Prints the result to the debug console: 6
The stack is now empty.

eop
Ends the program. This is optional.

I really hope this helps understanding how Claw works. Making this step by step listing took quite a while :)

Alright, I have all the hex and their names copied.
Since I don't have the organization for the menus, I have started on the compiler.
All I have is convert number in program to 16bit number.
I hope to have the source code compatible so all it now needs is a compiler.

Quote from: E37 on September 07, 2016, 03:33:52 PM
Alright, I have all the hex and their names copied.
Since I don't have the organization for the menus, I have started on the compiler.
All I have is convert number in program to 16bit number.
I hope to have the source code compatible so all it now needs is a compiler.

Awesome ;D
Just to confirm you got the right instruction set from https://github.com/bmuessig/Clawsemble/wiki/Instruction-set
Instruction 0x19 should be called SWF, is that correct?

EDIT:
In case you need an easier to edit or copy version, there is a JSON representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=json
a C# representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=cs-class
and a C representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=c-header

Quote from: DarkestEx on September 07, 2016, 04:41:25 PM

Quote from: E37 on September 07, 2016, 03:33:52 PM
Alright, I have all the hex and their names copied.
Since I don't have the organization for the menus, I have started on the compiler.
All I have is convert number in program to 16bit number.
I hope to have the source code compatible so all it now needs is a compiler.

Awesome ;D
Just to confirm you got the right instruction set from https://github.com/bmuessig/Clawsemble/wiki/Instruction-set
Instruction 0x19 should be called SWF, is that correct?
EDIT:
In case you need an easier to edit or copy version, there is a JSON representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=json
a C# representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=cs-class
and a C representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=c-header

I fixed it!
The IDE is ready whenever you have the sorted menus done!
(I did notice that 0x4D is empty)
All Claw commands begin with the byte 0xBB and the command byte follows.

Quote from: E37 on September 07, 2016, 06:29:35 PM

Quote from: DarkestEx on September 07, 2016, 04:41:25 PM

Quote from: E37 on September 07, 2016, 03:33:52 PM
Alright, I have all the hex and their names copied.
Since I don't have the organization for the menus, I have started on the compiler.
All I have is convert number in program to 16bit number.
I hope to have the source code compatible so all it now needs is a compiler.

Awesome ;D
Just to confirm you got the right instruction set from https://github.com/bmuessig/Clawsemble/wiki/Instruction-set
Instruction 0x19 should be called SWF, is that correct?
EDIT:
In case you need an easier to edit or copy version, there is a JSON representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=json
a C# representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=cs-class
and a C representation here:
http://dev.claw.bmuessig.eu/bytecode/?view&output=c-header

I fixed it!
The IDE is ready whenever you have the sorted menus done!
(I did notice that 0x4D is empty)
All Claw commands begin with the byte 0xBB and the command byte follows.

Nice :)
One question, do you mean the compiled version or the IDE editable version?
In the compiled version you would just need to use one single byte for one instruction. The single number arguments that follow are either a single byte or a single 16 bit word.
Strings are put into a constant table in the header of the compiled program.

How about some screenies?

Quote from: E37 on September 07, 2016, 07:09:29 PM
How about some screenies?

Looks really awesome :)

I will make you a list of the menus today. I guess there will be "Maths", "Logic", "Bitmanipulation", "Jumps", "VM", "Debug", "Arrays", "Stack" , "Extend", and "Misc", but I will see if I missed anything :)

Quote from: DarkestEx on September 07, 2016, 07:12:18 PM

Quote from: E37 on September 07, 2016, 07:09:29 PM
How about some screenies?

Looks really awesome :)

I will make you a list of the menus today. I guess there will be "Maths", "Logic", "Bitmanipulation", "Jumps", "VM", "Debug", "Arrays", "Stack" , "Extend", and "Misc", but I will see if I missed anything :)

Make sure to tell me if you want any keys replaced.
Like replacing sto with LD
Note than the menus won't have title.
I can make as many as you want! Almost to the point of having a key to a command! Wait it only supports up to 200 menus... That should be good.

Quote from: DarkestEx on September 05, 2016, 07:40:00 PM
I started working on Claw as an operating system. This will be a separate project and will allow booting into Claw with a normal computer.
Unlike the embedded Claw, this will be closed source.
Here's a screenshot of it booting:
snip

What's the benefit of this over Forth? Forth has the benefit that once you've got the base words set up for a system it's an OS for free (compare to a Lisp machine's OS, where it's just a shell, but that's enough).

Quote from: E37 on September 07, 2016, 07:27:31 PM

Quote from: DarkestEx on September 07, 2016, 07:12:18 PM

Quote from: E37 on September 07, 2016, 07:09:29 PM
How about some screenies?

Looks really awesome :)

I will make you a list of the menus today. I guess there will be "Maths", "Logic", "Bitmanipulation", "Jumps", "VM", "Debug", "Arrays", "Stack" , "Extend", and "Misc", but I will see if I missed anything :)

Make sure to tell me if you want any keys replaced.
Like replacing sto with LD
Note than the menus won't have title.
I can make as many as you want! Almost to the point of having a key to a command! Wait it only supports up to 200 menus... That should be good.

Hmm maybe there can be a store menu on the arrow key?
Pressing it could open the stack menu. Pressing the ln key could open the Array menu.

Quote from: bb010g on September 07, 2016, 07:34:54 PM

Quote from: DarkestEx on September 05, 2016, 07:40:00 PM
I started working on Claw as an operating system. This will be a separate project and will allow booting into Claw with a normal computer.
Unlike the embedded Claw, this will be closed source.
Here's a screenshot of it booting:
snip

What's the benefit of this over Forth? Forth has the benefit that once you've got the base words set up for a system it's an OS for free (compare to a Lisp machine's OS, where it's just a shell, but that's enough).

Just for fun. There is no actual use of Claw as an operating system on a PC. Claw will be available as a seriously meant operating system for Xtensa LX, ARM and AVR CPUs.
The PC version is more of a fun proof-of-concept project :)

Wait, so there will be an on-calc compiler, after all? That would be cool, since some people still asks if it's possible to program in ASM or C on-calc on newer models, so maybe some TI-84+ users would like to do the same with Claw in the future.

Quote from: DJ Omnimaga on September 11, 2016, 04:13:04 PM
Wait, so there will be an on-calc compiler, after all? That would be cool, since some people still asks if it's possible to program in ASM or C on-calc on newer models, so maybe some TI-84+ users would like to do the same with Claw in the future.

There will be!

Quote from: DJ Omnimaga on September 11, 2016, 04:13:04 PM
Wait, so there will be an on-calc compiler, after all? That would be cool, since some people still asks if it's possible to program in ASM or C on-calc on newer models, so maybe some TI-84+ users would like to do the same with Claw in the future.

As E37 mentioned, will there be one indeed :)
He makes good progress and it looks really nice from what I have seen so far ;D

There won't be one for the color calculators though. Programs for these have to be done on a PC or a monochrome calculator. If i ever find time I might do a color port but that is not yet planned. The assembler however is making lots of progress. Today I implemented custom instructions and multiline instructions.

Yeah it looks pretty nice so far. I was surprised at how fast he progressed O.O

Quote from: DJ Omnimaga on September 12, 2016, 05:41:26 AM
Yeah it looks pretty nice so far. I was surprised at how fast he progressed O.O

Often I muck around and work slowly. When I have something specific to work towards, I can be quite quick.
General update on the IDE:
The core will be done in a day or two. I'll be moving on to the addons soon.

Quote from: E37 on September 12, 2016, 04:44:10 PM

Quote from: DJ Omnimaga on September 12, 2016, 05:41:26 AM
Yeah it looks pretty nice so far. I was surprised at how fast he progressed O.O

Often I muck around and work slowly. When I have something specific to work towards, I can be quite quick.
General update on the IDE:
The core will be done in a day or two. I'll be moving on to the addons soon.

That sounds really awesome :)

I am making progress too on the PC assembler. It is heavy work and the codebase is growing significantly, but I am getting there :)
https://github.com/bmuessig/Clawsemble

Quote from: DarkestEx on September 12, 2016, 05:13:56 PM

Quote from: E37 on September 12, 2016, 04:44:10 PM

Quote from: DJ Omnimaga on September 12, 2016, 05:41:26 AM
Yeah it looks pretty nice so far. I was surprised at how fast he progressed O.O

Often I muck around and work slowly. When I have something specific to work towards, I can be quite quick.
General update on the IDE:
The core will be done in a day or two. I'll be moving on to the addons soon.

That sounds really awesome :)

I am making progress too on the PC assembler. It is heavy work and the codebase is growing significantly, but I am getting there :)
https://github.com/bmuessig/Clawsemble

I hope you aren't too far into it! I need to make some more file type changes...
Will you add an on-calc compiler?
That would probably increase its use a lot.

Here is a nice update on the resource editor!
(it took me about 3 hours)

Quote from: E37 on September 13, 2016, 07:16:54 PM
Here is a nice update on the resource editor!
(it took me about 3 hours)

Looks really awesome ;D
I am sure this makes it really easy to work with constants :)

EDIT:
@E37 Sorry but unfortunately there is another thing that would need to be added:
Modules

Basically there is one screen where you have a list of the modules that the calculator supports. You can select up to 16 entries from this list (when selected maybe highlight them).
This is used for the module table. I don't know if it's possible, but each of the selected modules has their own additional commands. Can you add them to a menu based on your selection?

I will add constants to the table only for the user. All numbers will be in 2b format (NOT a number on the constant table list)
I need to know more about modules to add them.

Quote from: E37 on September 14, 2016, 12:55:17 PM
I will add constants to the table only for the user. All numbers will be in 2b format (NOT a number on the constant table list)
I need to know more about modules to add them.

The constant table is for arrays only. No empty arrays are permitted ;)
There need to be 8 and 16-bit constant arrays (this is essential to Claw as types would otherwise not work).
About immediate arguments (these are the numbers after the commands), these can be either 8 or 16-bit depending on the instruction.
They can't be all 16-bit nor all be 8-bit as this would break the VM.

Modules are basically ways to extend the command set of Claw. There are 16 slots for Modules. Each slot that is used is filled by a string representing the module,
e.g. "STR" for string manipulation, "SCR" for screen manipulation, "GFX" for graphics, etc.
I am not yet sure what all of the strings will be. Maybe you can just display a list of all these modules and allow the user to select up to 16 of these.
They will later be added to the header of the executable.
Depending on what modules are loaded will there be more commands available (e.g. for string manipulation). So there needs to be one menu for the extended instructions.
It would contain a sub-menu for the module name and that one would contain all the commands that are supported.

How big is the calculator program so far, by the way?

Quote from: DJ Omnimaga on September 15, 2016, 05:56:03 AM
How big is the calculator program so far, by the way?

That's what's worrying me. It is 12000b so far and continuing to grow. Parts may need to be included as an appv. (It will be an app which is limited to 16384b)
I am looking into ways around that. I could make a second app for data... But having an app that didn't do anything is annoying for the user. If it is an appv, that uses ram and limits the max size of the program. I may archive the program and make a pass over it so I can use its ram and unarchive after it is (kind of) compiled.

Update:
I am still working on the project, just haven't had the time recently to make as much progress as I would like.

Quote from: E37 on September 22, 2016, 05:41:32 PM
Update:
I am still working on the project, just haven't had the time recently to make as much progress as I would like.

Nice, that you are still working on it :)

I finished the Assembler and I will now look into the VM again :)

Glad to hear the assembler is finished :)

I guess I'm lagging a little behind.  :P
The base of the IDE is done. (you can create programs and the custom tokens are done, but not much else)
I snazzed up the look a little (in my opinion)
I've attached a download of the executable if anyone wants to see it. It is separate from the resource editor!

What do you think?

Quote from: E37 on September 28, 2016, 07:59:50 PM
I guess I'm lagging a little behind.  :P
The base of the IDE is done. (you can create programs and the custom tokens are done, but not much else)
I snazzed up the look a little (in my opinion)
I've attached a download of the executable if anyone wants to see it. It is separate from the resource editor!

What do you think?

Looks awesome :)
I can't wait to give it a test on my real 84+ ;)

I like how it looks like. What is that animated icon thing by the way?

Quote from: DJ Omnimaga on September 29, 2016, 04:31:43 PM
I like how it looks like. What is that animated icon thing by the way?

You mean on the side?
That is a counter. I initially put it in to see if the screen froze, but I liked the look so much that I left it in.
It starts at 0 and counts (in binary) all the way to 65535 before resting to 0. It is completely pointless (I guess it could show framerate)

Oh I see. I actually like it too so even if it's just to display data, then maybe you should keep it. Actually I should maybe do that if I ever make another Axe game or if Ice compiler allows doing that. Having parts of the HUD designed this way would look cool.

@E37, could you please remove the function of most of the keys that are not used, including tan sin cos log ln sto . x-1 x2 X,T,O,n
You might also want to drop the jump list based approach to save memory. Apart from that, the editor is really awsome :thumbsup:

Quote from: DarkestEx on September 29, 2016, 09:18:57 PM
@E37, could you please remove the function of most of the keys that are not used, including tan sin cos log ln sto . x-1 x2 X,T,O,n
You might also want to drop the jump list based approach to save memory. Apart from that, the editor is really awsome :thumbsup:

I'm still working on it and hope to make it better!
unless claw uses 1/8 of the keys then the jump approach is still smaller and faster.
Glad you like it!

More things!  :w00t:
I'm going to slowly port the IDE to assembly (for my own benefit!)
I hope that I can use some of the assembly to optimize the Axe version.
Don't worry! It won't slow down the development of the Axe version.

I am working on trying to fix an out-of-nowhere-unexplainable-unfixable-bug-of-death right now. It won't die! :banghead:

Quote from: E37 on October 01, 2016, 11:22:02 PM
More things!  :w00t:
I'm going to slowly port the IDE to assembly (for my own benefit!)
I hope that I can use some of the assembly to optimize the Axe version.
Don't worry! It won't slow down the development of the Axe version.

I am working on trying to fix an out-of-nowhere-unexplainable-unfixable-bug-of-death right now. It won't die! :banghead:

Sounds great :D

Good luck finding the bug ;)

I was working on the assembly version when I was struck by the obvious! I realized that I was using assembler (no duh genius!) and could create multi-page apps! So what? Let's see what hacky things I can do!  ;D First off, I can compile programs with Axe as an app. Then, I can send it to my pc. There I can open it to get at the hex inside. I can paste in the app as data in spasm. (removing the checksums) That will run the data in my 'new' app.  :w00t: Then I can create the second page separately in axe, and paste the second 'page' app in as the second page of the app! Now, this is incredibly hacky (and there is a good chance that I can't paste the code like that) But it's worth a shot! If it works it will kill so many problems at once! (And I will have sooooo many bragging rights that I will go crazy  >:D)
I'm basically waiting for someone to scream, "Wait Jacob, that's a HORRIBLE IDEA!!!"

(If nothing else works, pure assembly version to the rescue!)  (-_(//));

Huh, well it doubt it will work. You'll have a call and jp issue  :P There won't point to the right adress in the code and it will most likely crash. You can always try though ...

Quote from: TheMachine02 on October 04, 2016, 06:43:59 AM
Huh, well it doubt it will work. You'll have a call and jp issue  :P There won't point to the right adress in the code and it will most likely crash. You can always try though ...

That's why I'll copy it from when it is already compiled. Since the app takes up the whole page, could I just .org 0 ? (I'm not sure how to fake that out in Axe though...)

Well an there is no .org equivalent in axe langage. Since it is taking a whole page, any cross boundary call won't work ... and that may be a problem too. Anyway, I don't know much about multipage app, so don't take my word as pure gold  :P

The assembly port, after some crazy setbacks, is coming along well!
I hope to have a working interface (basically you can scroll around with the cursor but not add/delete) done in a couple of days.

Glad to see the ASM port going well. I hope to see a new screenshot soon :)

Quote from: E37 on October 04, 2016, 01:04:27 AM
I was working on the assembly version when I was struck by the obvious! I realized that I was using assembler (no duh genius!) and could create multi-page apps! So what? Let's see what hacky things I can do!  ;D First off, I can compile programs with Axe as an app. Then, I can send it to my pc. There I can open it to get at the hex inside. I can paste in the app as data in spasm. (removing the checksums) That will run the data in my 'new' app.  :w00t: Then I can create the second page separately in axe, and paste the second 'page' app in as the second page of the app! Now, this is incredibly hacky (and there is a good chance that I can't paste the code like that) But it's worth a shot! If it works it will kill so many problems at once! (And I will have sooooo many bragging rights that I will go crazy  >:D)
I'm basically waiting for someone to scream, "Wait Jacob, that's a HORRIBLE IDEA!!!"

(If nothing else works, pure assembly version to the rescue!)  (-_(//));

(http://mrwgifs.com/wp-content/uploads/2013/05/Why-Would-You-Do-That-To-Catbug.gif)

That seems kinda like a weird idea lol, although it would be interesting if it worked. I guess for people who can't learn ASM it can be worth a shot if it's less effort, but you definitively have to watch out about safe RAM conflicts or other things that might be setup before any Axe program is launched.

Also that idea reminds me of how persalteas managed to release an Axe game for the TI-82 Stats/83. Axe is not available for the TI-82 Stats/83, so basically he grabbed the hexadecimal after disassembling the game then modified what's necessary to become compatible with the older calculator, then he was set.

That's it.
I've seen it all.
All the possible types of RAM memory corruptions. All of them.

I've switched back to developing in Axe for the moment. Assembly is taking too long. It would be really nice to do, but it is too slow.
I am completely rewriting the previous resource manager. So far, it is 1000b less, can add and remove entries, rename them, but can't edit their data.
And the memory corruption.
Just to name a few examples: Just crashing, writing to 'incorrect' areas etc.
Those are ok. The infuriating ones are the ones that aren't clear. The memory menu looks fine. Everything acts normally. but when I open the data file to check if everything is ok in it... it looks fine. I continue scrolling, continue... Until I realize that the output file shows up in the memory menu as 50 bytes.  But only until several thousand bytes later does it finally stop. I can even quit the program without it crashing if I haven't scrolled too far. (It crashes If I scroll past the 50 bytes)

Anyway... (some) progress is being made.

Use an emulator to help debug the errors ;)

ASM can definitively be quite a PITA when it comes to debugging, from what I heard >.<

Quote from: c4ooo on October 27, 2016, 11:56:21 PM
Use an emulator to help debug the errors ;)

I am. Wabbitemu has helped some (besides eliminating the need to send an app for every trial)

@DarkestEx
>:D
Here is a screenshot of the latest version!
(Note there is a glitch with the cursor in it)

I've been working on more updates!
No screen shot this time.
What's done: (since last time)
The strings in the constant table can be edited.
Pictures in the constant table can be edited.
A fancy title screen.
The ability to create programs. (and name them!)
Archive/unarchive programs. It can open and edit archived programs anyway.
The program list shows if the code is archived.
Various bugfixes.
What's left:
Make the editors for both 1 byte and 2 byte lists.
Sort the menus.
Add a pass for the compiler.
Fix any bugs that appear.

Quote from: DJ Omnimaga on October 27, 2016, 07:05:22 PM
Also that idea reminds me of how persalteas managed to release an Axe game for the TI-82 Stats/83. Axe is not available for the TI-82 Stats/83, so basically he grabbed the hexadecimal after disassembling the game then modified what's necessary to become compatible with the older calculator, then he was set.

Hum ... that was me :P and that was Jetpack 8x+ too.

@E37 you might want to take a look at my PageSwap axiom. It should be somewhere on Omnimaga.

Quote from: E37 on November 03, 2016, 07:01:02 PM
I've been working on more updates!
No screen shot this time.
What's done: (since last time)
The strings in the constant table can be edited.
Pictures in the constant table can be edited.
A fancy title screen.
The ability to create programs. (and name them!)
Archive/unarchive programs. It can open and edit archived programs anyway.
The program list shows if the code is archived.
Various bugfixes.
What's left:
Make the editors for both 1 byte and 2 byte lists.
Sort the menus.
Add a pass for the compiler.
Fix any bugs that appear.

Sounds great :thumbsup:

Quote from: matrefeytontias on November 04, 2016, 12:10:55 AM

Quote from: DJ Omnimaga on October 27, 2016, 07:05:22 PM
Also that idea reminds me of how persalteas managed to release an Axe game for the TI-82 Stats/83. Axe is not available for the TI-82 Stats/83, so basically he grabbed the hexadecimal after disassembling the game then modified what's necessary to become compatible with the older calculator, then he was set.

Hum ... that was me :P and that was Jetpack 8x+ too.

@E37 you might want to take a look at my PageSwap axiom. It should be somewhere on Omnimaga.

I know about pageswap. I actually recently pointed (ben_g?) to it. If I am going to make a two page app, it will be all one app.
Thanks though! (it is a cool axiom though)

I have some more updates! (but for some reason or another, no screenie  :'()
What's been added:
Just about everything - the constant table is complete!
The IDE now checks if the program is the same before archiving to save wear on the flash chip! If you just open an archived program to look, it won't archive it since there weren't any changes!
Added a quit without saving - if the program is archived, you can quit without saving and it will revert to the last archived copy (how it was before you opened it)
In progress:
Bug fixes...
Experimental way to display tokens: if it works, it could grant a 10% speed boost!

All versions of the IDE (past - present - future) run at 6MHz (slow speed mode) so it will work the same on the 83+

It appears to be drawing to a close... I'd say 90% done.

I have cleaned up some more bugs. @DarkestEx
The option to jump to labels is now included! (under the window key)

Just for fun, here is a list of all my fails and brain farts along the way!
[spoiler]
There were many times when I was sure I had fixed a bug, only to recompile it and find out that I only made it worse.
X-Y = Y-X right?
Let's spend 1 hour making a feature, 5 mins optimizing, and another hour trying to find the problems the 'optimized' code creates! (That one happened dozens of times)
Who needs to recompile? Let's just test already!
Forgetting to call the subroutine is its fault. It should have known when to call its self.
I know! I'll use the same memory location that I used to store all my variables in to store a copy of the screen! That'll save so much space!
Updating the fake "variable-2" data will make the actual variable change size.
I can compare all the data for equality in a possibly odd numbered data section in groups of 2 bytes!

[/spoiler]

I did it. I first offered to make an IDE for Claw 75 days ago for @DarkestEx .
Now it is done.
Sure there may be bugs to fix.
But it is done.
Here is the download for the couple of people who want to mess with it.


What's next?


[spoiler=stuff added/changed]
I added a debugging menu. Can you find it?
Pressing window lets you jump to a label. Labels are defined the same way as in assembly.
I managed to hide E37 in the IDE somewhere.
[/spoiler]

Awesome!  I will probably check it out to see how it's like

Lookin nice, lookin nice... Will it work on an 83+ SE?

Quote from: E37 on November 20, 2016, 01:26:36 AM

What's next?

Is that an aura? :trollface:

@E37
WOW I am totally stunned!
Such an incredibly awesome job!  :thumbsup:

I will certainly go and build a proper VM soon so we can start making programs ;D

As I have holldays now, I will give the VM another go. Hope I can finish it soon :)

Quote from: DarkestEx on January 03, 2017, 07:57:22 PM
As I have holldays now, I will give the VM another go. Hope I can finish it soon :)

Sounds awesome!