prog-tools add-in for programming on CG50
Posté le 05/04/2025 18:42
I've been working on an add-in to do programming on the CG50. It has tabs like tmux, and each tab can be split once either vertically or horizontally allowing for up to 12 programs to run at once. Only the currently selected program runs until you switch to another tab or split. I think this will work better than the way the built-in Python does it where you have to save the file and lose your place every time you want to run something.
Each of the 12 splits has its own memory in the 2MB of RAM starting at 0x8c200000. When you start a program or move back to a program that's already running, the add-in shifts the memory for the selected program to the top of the heap so it's contiguous with the rest of the free memory and easy to expand.
I'm close to being finished with a simple shell so I can manipulate files without having to leave the add-in. Thanks to LephenixNoir for the help with file system operations and everything else. I plan to add a Forth interpreter next to write programs that run on the calculator.
I made a small framework with SDL2 for testing the add-in. It configures the video memory the same as the CG50 so writing a pixel there works exactly the same as on the calculator. It reimplements some of the gint functionality too so I can compile the add-in for linux which is very convenient for testing.
I'll add some more information as I finish more features. Please let me know if you have any suggestions!
GitHub repo here.
Citer : Posté le 28/04/2025 17:50 | #
The calculator shell is finished now and supports these commands: cat, cd, clear, cp, exit, help, ll, ls, mkdir, mv, rm, rmdir and touch. I started on the Forth interpreter and a little over half of the words (ie functions or commands) I have planned are working.
Forth usually has one large area of memory called the dictionary where global variables, arrays and compiled words (ie functions) are stored. The user can read and write any address as in C or assembly so it's possible to accidently write outside of the dictionary or write data over compiled code and cause a crash. Since this Forth is running on a calculator, I made a few changes so that crashing should be impossible. Addresses used for reading and writing dictionary data start at 0 and refer to the beginning of the dictionary rather than the actual address of the dictionary in memory. Those addresses are masked before each read and write so access is guaranteed to be within the bounds of the dictionary. The data stack is also masked and wraps in the same way so there can be no crashes from underflow or overflow. Masking also prevents alignment problems since the bottom bits can be cleared for 32 and 16 bit accesses to round addresses down. Compiled words are stored in a separate part of memory so there's no way for the use to accidentally change them.
Citer : Posté le 28/04/2025 18:33 | #
I just need to say this UI is gorgeous. @^@
Citer : Posté le 28/04/2025 19:05 | #
Wow impressive work! The project is amazing and so useful for system management tasks!
Citer : Posté le 30/04/2025 17:09 | #
It's very cool. May I ask when the release of fx-cg50 can be released?
Citer : Posté le 01/05/2025 22:56 | #
Thanks a lot!
It's very cool. May I ask when the release of fx-cg50 can be released?
Citer : Posté le 20/05/2025 22:36 | #
Small progress update - the Forth interpreter can now define words and run them. Unlike most Forths, a word can include references to words that don't exist yet (ie word b in the screenshot) and define them later. Also, redefining a word changes all references to the word (ie word a below) not just new occurrences of it.
Citer : Posté le 20/05/2025 22:41 | #
Is the retroactive nature of redefining names standard? I'm used to having the opposite so one can create closures and ensure they're not modified later by accident.
Edit: Like otherwise if you want a complex word you need to remember all of the sub-words to not accidentally override any.
Citer : Posté le 20/05/2025 22:58 | #
No, all the Forths I've seen have it the other way around where you can reuse the name for something else. I can see why that might be useful, although I've never used that functionality for anything myself. I like saving memory when working interactively, and I like how globals work in Python. One use for the standard behavior is using a global variable in one word like a local variable then reusing the same name as a local in another word. I plan to add local variables, so the standard behavior isn't really needed for that. Supporting closures is a good idea. I may implement :NONAME for that situation.
Citer : Posté le 30/05/2025 15:45 | #
Edit: Like otherwise if you want a complex word you need to remember all of the sub-words to not accidentally override any.
Ya, good point. There is SMUDGE to make a word invisible, but then you would have to remember to smudge all the sub-words. I think it would be good to add a word like IMMEDIATE that makes the last defined word overwritable or have an alternative to : like S: that marks it overwritable when it's defined.
Citer : Posté le 09/06/2025 06:04 | #
Latest update - added IF/THEN, BEGIN, DO/LOOP, strings, and a few other things. This totals 125 of the 150 or so words I had planned, so getting toward the end. An empty loop from 0 to 5,000,000 takes about a second, so it should be much faster than Basic.
One thing of note is that I changed the keys around a little bit which greatly adds to quality of life. The biggest improvement is dedicating the (-) key to be space whether alpha is enabled or not so you're not constantly switching in and out of alpha mode to type spaces. Also, pressing alpha twice turns on alpha lock and shift+alpha switches between upper case and lower case.
Citer : Posté le 09/06/2025 14:42 | #
The biggest improvement is dedicating the (-) key to be space whether alpha is enabled or not so you're not constantly switching in and out of alpha mode to type spaces. Also, pressing alpha twice turns on alpha lock and shift+alpha switches between upper case and lower case.
That's interesting. Have you also tried switching between shift or alpha just by checking if the key is pressed down, in a similar way as input in the PythonExtra console works? Personally I found that it made inputting text way faster than having to go in and out of a mode (but it requires using 2 hands).
Citer : Posté le 11/06/2025 16:36 | #
Thanks for the suggestion. I gave PythonExtra a try, and that is also a good way to do it. I'll keep working and see which way makes more sense.