If you could use any programming language to program add-ons, what would you use? I’m working on a thing to make WebAssembly work on them with a tool called w2c2 and I’d like some inspiration, ideally ones that are on https://github.com/appcypher/awesome-wasm-langs because it needs to compile to WebAssembly
(I have AssemblyScript somewhat working so far)
C.
C.
No one would want to even try something like Rust or Go or Zig or AssemblyScript? I guess I should find a different project then
Hi,
if you have no better idea, you can make compiler for the CASIO basic, running on the calculator. Lot of people know this language, the editor is already there and some speedup would be very benefical. Smile
I would like to choose C, or Hitachi Assembly.
I don't own any CASIO Prizm yet but I do have CASIO fx-9750GII/9860GII and tried some C for them. I hope the development flow for CASIO SH3/SH4 monochrome calcs could be more obvious and less obfuscating.
LifeEmu wrote:
I would like to choose C, or Hitachi Assembly.
I don't own any CASIO Prizm yet but I do have CASIO fx-9750GII/9860GII and tried some C for them. I hope the development flow for CASIO SH3/SH4 monochrome calcs could be more obvious and less obfuscating.

C development on these calculators is very straightforward, you even get working samples. Try to write program in C / asm for cfx 9850G Smile
MPoupe wrote:
Hi,
if you have no better idea, you can make compiler for the CASIO basic, running on the calculator. Lot of people know this language, the editor is already there and some speedup would be very benefical. Smile


Thanks, but Casio BASIC doesn’t compile to WebAssembly, so while that may be useful that would be an entirely unrelated project.

I’ll rephrase this: WebAssembly is a standard originally designed for running compiled languages on the Web, but it also makes a great general-purpose architecture-independent format for self-contained binaries, and many existing languages can target it. I managed to use a program called w2c2 to convert WebAssembly modules to C, which can be compiled for the calculator. This means that it would be possible to use any language that compiles to WebAssembly. Is there any interest in this, and if so what languages should I try to make work?

Progress so far (you can code addons in something very similar to TypeScript with this):
Hi Heath, this is super cool! I will confess to writing almost only C and C++ programs, leaving me with barely any experience in these languages that compile to WebAssembly, except for some OCaml. But I'm interested in seeing how much projects could be ported using this new runtime, since many real-world programs are written in languages that we don't support at all.

I'd also very much like to see any sort of performance data. I don't know much about the WebAssembly runtime uses or what the C programs generated by w2c2 look like, so any insight is welcome.
Lephe wrote:
I'd also very much like to see any sort of performance data. I don't know much about the WebAssembly runtime uses or what the C programs generated by w2c2 look like, so any insight is welcome.


I haven't tried on the calculator so this could be wildly inaccurate but according to https://github.com/turbolent/w2c2#performance it's about 93% of native performance with Coremark on a PC.
MPoupe wrote:

C development on these calculators is very straightforward, you even get working samples.

Yes and no? I tried the examples in CASIO SDK, it worked fine, but then I don't know what to do Sad The programming model is not as clear as TI's, I think.
MPoupe wrote:

Try to write program in C / asm for cfx 9850G Smile

As far as I know, there's no C compiler nor assembler for CFX-9850G, and little documentation is available for this model. Can you share the file if there is any one of them? Razz
LifeEmu wrote:
As far as I know, there's no C compiler nor assembler for CFX-9850G, and little documentation is available for this model. Can you share the file if there is any one of them? Razz

First you need to unsolder ROM chip, copy data to flash, change few bytes to be able to run binary from RAM. Solder flash back to the calculator.
There are some assemblers (I wrote one 20+ years ago), I have no information about C compiler. I think even the manufacturer wrote the FW in asm.
Comparing to this, SDK for fx9860G is very usefull and comfortable, right ? Smile
MPoupe wrote:

First you need to unsolder ROM chip, copy data to flash, change few bytes to be able to run binary from RAM. Solder flash back to the calculator.

This is doable, but would do permanent damage to the calculator so I probably won't?
MPoupe wrote:

I think even the manufacturer wrote the FW in asm.

I don't think so because CASIO change their hardware very frequently. It will be costy to maintain consistency in ASM among models, I think.
MPoupe wrote:

Comparing to this, SDK for fx9860G is very usefull and comfortable, right ? Smile

IMHO the official 9860G SDK is very useful indeed but not very comfortable. The UI is a little bit confusing, and the embedded code editor is basically just a text editior. I prefer a third-party code editor plus a third-party toolchain Razz

EDIT:
1) I don't wanna modify the hardware of a discontinued model, as I only have 1 working CFX-9850GB PLUS.
2) I havn't see the ROM dump yet, could you please post the link to it? Thanks in advance.
3) Yep I'm using VS Code for code editing now, but I still want a more perfect solution(like a better IDE?)
LifeEmu wrote:
This is doable, but would do permanent damage to the calculator so I probably won't?
If you do it properly, you will not damage anything.
LifeEmu wrote:
I don't think so because CASIO change their hardware very frequently. It will be costy to maintain consistency in ASM among models, I think.
I mean cfx9850G. Have you seen the ROM dump? Check it.
LifeEmu wrote:
IMHO the official 9860G SDK is very useful indeed but not very comfortable. The UI is a little bit confusing, and the embedded code editor is basically just a text editior. I prefer a third-party code editor plus a third-party toolchain Razz
You do not need to write the code in the embedded editor. Use anything you want.
Natural languages like Chinese, if that would be possible:)
This is a really cool project!
TypeScript is great and I think it would be good for new users to start programming on the calculator.

I have written a Python program (still in development) called PyG3A, which compiles Python into a Prizm addin, but unlike WebAssembly I had to write it from scratch, so there are still a few caveats.

It would be great if you could open source the project once you have some kind of working example, I'd love to see how it works!
dr-carlos wrote:
This is a really cool project!
TypeScript is great and I think it would be good for new users to start programming on the calculator.

I have written a Python program (still in development) called PyG3A, which compiles Python into a Prizm addin, but unlike WebAssembly I had to write it from scratch, so there are still a few caveats.

It would be great if you could open source the project once you have some kind of working example, I'd love to see how it works!


Thanks! If I get it working in a usable way with some glue code for syscalls I will definitely open source it. I'm thinking of doing a high level API so instead of


Code:
import * as syscalls from './syscalls'
import { textMode, color } from './constants'

syscalls.PrintXY(1, 1, "--Hello World!", textMode.normal, color.black)

while (true) {
  syscalls.GetKey()
}


you could do


Code:
import { console } from './console'
import * as keyboard from './keyboard'

console.log('Hello World!')

while (true) {
  keyboard.waitForKey()
}


I also want to make it work with other languages which is why I asked that in the post but it looks like that might have just confused people.
Your project looks great as well, I should look at that
Heath wrote:

Thanks! If I get it working in a usable way with some glue code for syscalls I will definitely open source it. I'm thinking of doing a high level API so instead of


Code:
import * as syscalls from './syscalls'
import { textMode, color } from './constants'

syscalls.PrintXY(1, 1, "--Hello World!", textMode.normal, color.black)

while (true) {
  syscalls.GetKey()
}


you could do


Code:
import { console } from './console'
import * as keyboard from './keyboard'

console.log('Hello World!')

while (true) {
  keyboard.waitForKey()
}


I also want to make it work with other languages which is why I asked that in the post but it looks like that might have just confused people.
Your project looks great as well, I should look at that


I guess you could do other languages, but I think working on JS/TS first is probably the way to go.

Something I would recommend obviously, you don't have to do it, is to automatically put a while true loop with GetKey() at the end of the converted C. You then would need to support an exit() function, but I think most programmers wouldn't expect the addin to close at the end of the program, unless they specifically programmed it to.

Anyway, that's just my 2 cents.
dr-carlos wrote:
Heath wrote:

Thanks! If I get it working in a usable way with some glue code for syscalls I will definitely open source it. I'm thinking of doing a high level API so instead of


Code:
import * as syscalls from './syscalls'
import { textMode, color } from './constants'

syscalls.PrintXY(1, 1, "--Hello World!", textMode.normal, color.black)

while (true) {
  syscalls.GetKey()
}


you could do


Code:
import { console } from './console'
import * as keyboard from './keyboard'

console.log('Hello World!')

while (true) {
  keyboard.waitForKey()
}


I also want to make it work with other languages which is why I asked that in the post but it looks like that might have just confused people.
Your project looks great as well, I should look at that


I guess you could do other languages, but I think working on JS/TS first is probably the way to go.

Something I would recommend obviously, you don't have to do it, is to automatically put a while true loop with GetKey() at the end of the converted C. You then would need to support an exit() function, but I think most programmers wouldn't expect the addin to close at the end of the program, unless they specifically programmed it to.

Anyway, that's just my 2 cents.


That definitely makes sense, after all my goal is to make it easier to program addins so getting rid of any confusing behaviour is good
WebAssembly programs have their own memory allocators, and you just have to give it a block of memory, and according to https://prizm.cemetech.net/index.php?title=Heap you should use the stack instead when possible, so should I try to give it stack memory rather than heap memory? So instead of allocating memory on demand I could just give it a fixed buffer
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

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

 

Advertisement