Can I run BOS on a real calculator yet?
TIny_Hacker wrote:
Can I run BOS on a real calculator yet?
Absolutely! Assuming you're willing to contend with the current lack of software and interface.
Installation is as easy as running the installer on-calc.
Uninstalling BOS to reinstall TIOS can be done a few different ways. Notably the on+2nd+del+reset method, but there is also a built-in uninstall feature in the recovery menu.
Another quick update post before I forget to announce: BOS will soon be able to back up TIOS and reinstall it without necessitating use of a PC! The installer provides a simple Y/N prompt so it doesn't always backup TIOS. Additionally to this, on first boot BOS will search for TI variables stored in archive, importing/converting them into BOS files! (check the "/usr/tivars" directory)
This will allow for extra features and programs to be imported into BOS until a file transfer program becomes available for it.
This will allow for extra features and programs to be imported into BOS until a file transfer program becomes available for it.
- 24 Jun 2021 09:25:16 pm
- Last edited by beckadamtheinventor on 25 Jun 2021 12:29:01 pm; edited 1 time in total
BOS's default UI now has icons!
Eye candy:
Also, on a far more exiting note, BOS now supports "software threading"! Effectively allowing multiple programs to run in rapid sequence. It works by switching threads when a program tells the OS to handle the next thread. Such as when waiting for a keypress or between loop cycles.
When a thread switch is triggered, the values of the PC, SP, IX, and IY registers as well as the current malloc ID (which is implemented separately) are backed up. Then the same registers are re-loaded with the values backed up from the next running thread.
Long story short, PC, SP, IX, and IY are (in the eye of the thread) conserved upon a thread switch. Which means that this feature will be compatible with the BOS fork of the CE C toolchain! (soon)
Threads are run in the order they are spawned, and each living thread will run once before another thread is re-run.
I have, of course, written another kind of key waiting routine:
Code:
Which queues a thread to do the following:
1. check if a key is pressed
2. if no key pressed: handle next thread and goto 1 when we resume.
3. check if no keys pressed
4. if key(s) pressed: handle next thread and goto 3 when we resume.
5. run callback(key)
6. stop this thread.
The reason I have the thread stop once a key is pressed is so that the program can choose whether to continue grabbing keys without needing to stop the thread manually.
Note that this function spawns a thread but doesn't start it. The thread will be handled when it is eventually run as a result of a thread switch.
I am currently unsure as to whether it would be worth it to implement this system using interrupts to trigger the thread switch, due to it necessitating more registers be backed up. I am probably not going to implement it that way.
I have tested the new features on my revision L CE and it works as expected.
Eye candy:
Also, on a far more exiting note, BOS now supports "software threading"! Effectively allowing multiple programs to run in rapid sequence. It works by switching threads when a program tells the OS to handle the next thread. Such as when waiting for a keypress or between loop cycles.
When a thread switch is triggered, the values of the PC, SP, IX, and IY registers as well as the current malloc ID (which is implemented separately) are backed up. Then the same registers are re-loaded with the values backed up from the next running thread.
Long story short, PC, SP, IX, and IY are (in the eye of the thread) conserved upon a thread switch. Which means that this feature will be compatible with the BOS fork of the CE C toolchain! (soon)
Threads are run in the order they are spawned, and each living thread will run once before another thread is re-run.
I have, of course, written another kind of key waiting routine:
Code:
int th_WaitKeyCycle(void (*callback)(uint8_t));
Which queues a thread to do the following:
1. check if a key is pressed
2. if no key pressed: handle next thread and goto 1 when we resume.
3. check if no keys pressed
4. if key(s) pressed: handle next thread and goto 3 when we resume.
5. run callback(key)
6. stop this thread.
The reason I have the thread stop once a key is pressed is so that the program can choose whether to continue grabbing keys without needing to stop the thread manually.
Note that this function spawns a thread but doesn't start it. The thread will be handled when it is eventually run as a result of a thread switch.
I am currently unsure as to whether it would be worth it to implement this system using interrupts to trigger the thread switch, due to it necessitating more registers be backed up. I am probably not going to implement it that way.
I have tested the new features on my revision L CE and it works as expected.
Moar eye candy using the new threading feature 
Don't mind the corruption at the end, still working out some bugs... lol
Don't mind the corruption at the end, still working out some bugs... lol
- 25 Jun 2021 12:00:11 pm
- Last edited by randomguy on 25 Jun 2021 12:34:58 pm; edited 2 times in total
so I was trying to build BOS from the source using the latest CE C toolchain with make, but the terminal said that there was a syntax error. I am on macOS Catalina.
Thank you in advance!
Thank you in advance!
randomguy wrote:
so I was trying to build BOS from the source using the latest CE C toolchain with make, but the terminal said that there was a syntax error. I am on macOS Catalina.
Code:
Thank you in advance!
Code:
make
python build.py -b -i -d
File "build.py", line 109
os.system(f"fasmg {self.path}src/main.asm {self.path}obj/main.bin")
^
SyntaxError: invalid syntax
make: *** [bos] Error 1
Thank you in advance!
I suppose I should fix the makefile to use python 3 specifically, (which the build script relies on) as opposed to using the default installation of python which isn't necessarily python 3.
EDIT: Should be fixed now.
EDIT2: I forgot to remove bpm from the build, hence another error. Should be fixed now.
BOS v1.11.0021 alpha (pre-release) has now been released on GitHub!
The filesystem is now ludicrously faster than it was before, FAT32 USB drive reading is once again functional, recovery options can now recover from most issues, and many bugfixes!
Here's some eye candy:
The filesystem is now ludicrously faster than it was before, FAT32 USB drive reading is once again functional, recovery options can now recover from most issues, and many bugfixes!
Here's some eye candy:
Wow this is cool will this work on a python edition Calc also what is the minimum or maximum os needs for the calc.
No, it's an operating system, so you need a calculator with either extremely old bootcode or with patched bootcode in order for it to work. You can't patch the bootcode on Python edition calculators.
It's replacing the OS entirely, so the TI-OS version isn't really relevant.
It's replacing the OS entirely, so the TI-OS version isn't really relevant.
commandblockguy wrote:
No, it's an operating system, so you need a calculator with either extremely old bootcode or with patched bootcode in order for it to work. You can't patch the bootcode on Python edition calculators.
It's replacing the OS entirely, so the TI-OS version isn't really relevant.
It's replacing the OS entirely, so the TI-OS version isn't really relevant.
Ok thanks I wasn't sure if the os could be replaced on python calculators. Thanks again.
How would you build it? It's not built on the GitHub, so it doesn't include the 8xp file for installing on a physical calculator.
It has an error when I try to compile it.
It has an error when I try to compile it.
sJRw wrote:
How would you build it? It's not built on the GitHub, so it doesn't include the 8xp file for installing on a physical calculator.
It has an error when I try to compile it.
It has an error when I try to compile it.
https://github.com/beckadamtheinventor/BOS/releases/tag/v1.11.0021
Sorry, I didn't look at the releases. Right now I'm wondering how it is compiled? I don't know how to make a rom file, or sign an OS or stuff, and I'm interested in making my own for the CE, but I don't really know how to add the fancy stuff that BOS has right now, what with the python and stuff.
sJRw wrote:
How would you build it? It's not built on the GitHub, so it doesn't include the 8xp file for installing on a physical calculator.
It has an error when I try to compile it.
It has an error when I try to compile it.
What's the error? Please make an issue on the GitHub repo so I can try and fix it.
DarkSystem wrote:
It seems that this project is kinda dead, with the code still being updated but no more releases?
Not dead, just not being developed as actively as it used to.
PaulGamerBoy360 wrote:
Is a New GUI going to be made?
It should be relatively easy to make an alternative GUI for the OS, if you check /etc/config/boot/onboot.cmd you can change what is launched when the OS boots. The main GUI is just a program.
It's been almost 3 years since the last release, but here is BOS v1.18.0000!
https://github.com/beckadamtheinventor/BOS/releases/tag/v1.18.0000
From the release notes:
https://github.com/beckadamtheinventor/BOS/releases/tag/v1.18.0000
From the release notes:
Quote:
A literal metric ton of fixes, yes I know it's been 3 years since I've released something. :p
Note for those on hardware:
Unfortunately due to the sheer volume of changes between the previous release and this one, you will have to uninstall BOS completely and reinstall TIOS before you can update to this new version.
Some of the important things:
long file names
turning off the calculator now actually puts the calculator into low-power mode
files larger than 64k can now be received via msd
files larger than 64k can now be created via fs_Alloc
fix some critical filesystem bugs
themes and background images for the main GUI
themes carry over into command line programs and cmd
change filesystem block size to 64 bytes
change malloc block size to 16 bytes
serial file transfer interface PC -> calc
improvements to memedit, info, ls, cedit, msd
implement zx7 decompression sysutil (compression not yet functional)
improve file type/data checking and make it uniform
add PATH / LIB fallback values so the OS doesn't throw a fit if they're missing
quoted arguments for the command line interface (you can now have spaces and colons in an argument)
implemented a bunch of compatibility routines
some implementation of the VAT for compatibility
zx0 decompression routines
support for flash applications using offsetinstruction macros (automatically formatted with the flash_executable macro in bos.inc)
re-implement compressed RAM executables
implement recursive text execution using the OP stack
text execution now uses ti.begPC, ti.curPC, ti.endPC
executables built for TIOS now start in 16bpp mode
...and a whole heck of a lot more that I don't remember and can't find in the commit logs. 😀
Note for those on hardware:
Unfortunately due to the sheer volume of changes between the previous release and this one, you will have to uninstall BOS completely and reinstall TIOS before you can update to this new version.
Some of the important things:
long file names
turning off the calculator now actually puts the calculator into low-power mode
files larger than 64k can now be received via msd
files larger than 64k can now be created via fs_Alloc
fix some critical filesystem bugs
themes and background images for the main GUI
themes carry over into command line programs and cmd
change filesystem block size to 64 bytes
change malloc block size to 16 bytes
serial file transfer interface PC -> calc
improvements to memedit, info, ls, cedit, msd
implement zx7 decompression sysutil (compression not yet functional)
improve file type/data checking and make it uniform
add PATH / LIB fallback values so the OS doesn't throw a fit if they're missing
quoted arguments for the command line interface (you can now have spaces and colons in an argument)
implemented a bunch of compatibility routines
some implementation of the VAT for compatibility
zx0 decompression routines
support for flash applications using offsetinstruction macros (automatically formatted with the flash_executable macro in bos.inc)
re-implement compressed RAM executables
implement recursive text execution using the OP stack
text execution now uses ti.begPC, ti.curPC, ti.endPC
executables built for TIOS now start in 16bpp mode
...and a whole heck of a lot more that I don't remember and can't find in the commit logs. 😀
Register to Join the Conversation
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
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