Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: AHelper on August 12, 2011, 12:32:42 am
-
Sorta cross posting, but in case not everyone is on cemetech...
GlassOS (technically GlaßOS, but for ease of typing...) is an OS written for the ti84pse. It is > 95% written in C. I use SDCC for all compiling needs (and for other headaches). Yeah, it's different, but this OS is ~8-10 months old. It has USB ready to use, task switching, GUI library, and a working filesystem. I am getting ready for a public beta release this friday, or a few days after (busy schedule).
Now, just to state it here: GlassOS is a replacement for AOS/tios. I provides no compatibilities for running asm/basic programs, nor current linking software. It's goal is to provide a C environment for the calc.
Now, does that mean it doesn't do math? By itself, nope. But do I have a minimal cas? gCAS2 is being worked on. For other stuffs, such as non-stop ramblings and status updates, cemetech.net will have it.
Questions? Rants? SDCC support group? Feel free to ask away
<update>
Well, it has been 5 months since my last commit to the project. This project is not dead!
-
Interesting. Will it support C++ as well?
-
No, mainly because C++ on calc would be too sloppy. C allows for strict and low level access of the memory. AFAIK, there are no C++ cross-compilers for the z80.
-
I suppose you could use the old C++ to C compiler and then go from there, but I don't see much advantage to doing that.
-
This is pretty cool, glad to see news over here about it. Any screenies you want to post?
-
Well. This is interesting./me wonders if he can dual boot
-
No dual booting... For that, look at OS2. I don't know if it is runnable/usable, but it dual boots...
All screenies are on cemetech.net, and since sourceforge isn't letting me have a directory visitable via http, I will have to update my scrieenie page. There are about 40 images sitting in a folder.
<edit>
I hacked together some php code to display all images I have for GlassOS. Some aren't screenies, but are "Just there".
Look at them at http://glassos.sf.net/viewer.php (http://glassos.sf.net/viewer.php)
-
(http://glassos.sf.net/img/menu.gif)
I found this screenshot I think you should put here.
Also, you said "Beta Release on Friday", which Friday, or is that Cemetech topic old already?
Either way this is looking like a great project, nice you made a topic on Omnimaga too.
-
No dual booting... For that, look at OS2. I don't know if it is runnable/usable, but it dual boots...
All screenies are on cemetech.net, and since sourceforge isn't letting me have a directory visitable via http, I will have to update my scrieenie page. There are about 40 images sitting in a folder.
<edit>
I hacked together some php code to display all images I have for GlassOS. Some aren't screenies, but are "Just there".
Look at them at http://glassos.sf.net/viewer.php (http://glassos.sf.net/viewer.php)
Do I detect a Game of Life?
-
yup, gol1.gif (http://glassos.sf.net/img/gol1.gif). It should still compile, but, again, uses C, which is not what the gfx library is there for.
-
So, passwords for GlassOS... Would anyone want this? This will be OS-wide, so a battery pull will not work. Recovery abilities can be made using the USB or something...
Also, I am finally working on the OS, which means USB progress! yay.......
-
Hmm sounds interesting. Just make sure it's easy to recover loss passwords for the user, so they don't need to reset their entire memory or something. :P
Also glad to see USB progress :D
-
For me, password reset can be done many ways... Connect to your computer, connect to anything USB, delete everything in /home, wipe the flash, or just invalidate the OS. Obviously not all are... nice, but those are the only ways I can think of....
Other suggestions? I may do the first (connect to your computer) or delete user files (wipe /home).
-
THE FIRST!!!!!!
-
Preferably the first. Also make sure the password protect function doesn't glitch when connecting an I/O link cable to the calc. I still remember when my TI-83+ was turned OFF and had Mirage 1.1 installed, then connecting an I/O cable prompted a glitched password prompt, even if that was disabled, followed by a RAM clear or Blues Lines of Death :P
-
o_O
GlaßOS doesn't use the IO as I don't have anything hardware-wise to test it with. And even if the calc resets, the password will still run at boot
-
Ah I see, I guess it might be fine then. It was just a strange glitch in Mirage X.x. I think it was worse under OS 1.12 than 1.14, though, and only happened on my 83+, not my 83+SE (which is quite ironic considering most MOS problems affected 15 MHz calcs at the time).
-
(cross-post from cemetech)
I am getting the clock code to work in the OS. So, I have this question: Does anyone want the date/time to be available at any time? Such as press [GRAPH] (obviously when the program doesn't use it, like a game or gCAS2) and the date and time will pop-up over the running program, suspending it until you exit out. You can also change the time in that screen and look at a calendar. If yes, then how I code this will be different, so input is needed asap!
-
(cross-post from cemetech)
I am getting the clock code to work in the OS. So, I have this question: Does anyone want the date/time to be available at any time? Such as press [GRAPH] (obviously when the program doesn't use it, like a game or gCAS2) and the date and time will pop-up over the running program, suspending it until you exit out. You can also change the time in that screen and look at a calendar. If yes, then how I code this will be different, so input is needed asap!
Getting the clock from anywhere would be nice, as long as it would be easy for developers to prevent that from happening in programs.
-
as easy as
isr_clock_int = 0;
-
yeah it would be nice IMHO. Kinda like in Starcraft II, when I want to make sure it's not already time to go to work or bed. :P
Also for your OS, please make sure it preserves the time after resets, if possible. I hate how when the 84+ OS RAM clears my clock is reset to midnight. It makes it pretty much useless considering how many RAM clears I get.
-
The anywhere clock would be nice. I agree with DJ's time saving idea too. That's the reason I gave up using the clock on my TI.
-
Here's the anywhere clock:
(http://glassos.sf.net/img/clock.gif)
Its slow as it has no key repeat yet and wabbitemu on linux is slowwww..... A few minor bugs with double key press when exiting, but works from any application that doesn't have var_clock_int set to 0
-
Its slow as it has no key repeat yet and wabbitemu on linux is slowwww.....
wxwabbitemu isn't but it doesn't screenshot yet.
-
Does wxwabbitemu allow loading of 8xu's?
-
Does wxwabbitemu allow loading of 8xu's?
It can load everything wabbitemu can. You could also make your 8xu into a rom if you want. I have a tool that can do that I think...Maybe it's not 8xu format to rom though...
-
Looks nice AHelper. You should probably add a space between the time and the AM/PM thing, though.
-
I will change that, along with centering and aligning the set time header.
Also, sorry about the flickering. There is a flicker because I am calling ion_copybuffer, then printf twice per second. printf uses direct LCD drawing, so the flicker will be there. Why? The gfx library isn't mature enough to be used to replace the direct drawing. Isn't printf fun? ;D
-
Latest compile stats (as I have nothing special going on other than planning):
GlassOS binary code size equates to 93,909 bytes, covering 8 ROM pages over 4 sectors, when compiled with "SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)".
Code may be smaller when using the unstable branch made to do much more optimization. Sector bounds are messed up from previous testing. OS still pending USB testing and fs-based programs (yes, SirC, keep nagging about it). Direct ASM support is not implemented, SDCC calling methods must be used and can be done. Full-page app allocation code is untested. Clock display still not finished. USB clock setting not implemented.
:-\
-
GlaßOS is not dead yet! A pre-beta has been released, and more will come!
Find a bug? Report it on my bugtracker on sourceforge. If you don't find it, I won't fix it. :-P
Current release only contains gFiler and glassKILL. Next release will add gCAS2
-
So, i have been working on gCAS2 recently. This begs the question: Where should GlassOS focus its usefulness, more educational efforts, or more game/scripting work?
Remember that SDCC is ideal for this OS, but is not limited to only C dev..
-
Do you realize that, with the ess-zett, it looks like GlaDOS waaayyy too much? ;-)
(...he says, while wearing his Portal t-shirt)
-
i know, KermM calls it GlaDOS :-S
As a side-note, i am wondering how important on-calc debugging is... GlassOS right now has the ability to assert and give some debug info, but nothing serious. So, what about using the USB? GlassOS will send debug info over the USB and have it logged so that it can be easier to find bugs and such...
Some methods that will be of use:
- dprintf(bool ts, char *format, ...) This command will send formatted text over the USB. bool ts, when true, will print out the current time, memory pages, and pc. The rest of the function is the same as sprintf(). with ts==true, the debug text will look like "[12:00:14 :: 1/78/82/81/0x42E3] Hello world!" with the format [time :: thread id/ bank 1/ bank 2/ bank 3/ pc] text...
- dumpt() will dump the current thread's state and stack.
- dump() will dump all ram, maybe some ports
- assert() will print out over the USB in addition to the LCD
- breakpoint() will stop the calc, dump the current thread and thread ram to USB, and will let you change variables and the stack from the PC. Maybe allowing you to step through the code using timers
There may be other functions, but these listed above will be able to be turned off on-calc, so you don't waste CPU cycles when you don't want debugging. Memory dumps and such will not be dumped to terminal output, but will be viewed from a Qt GUI.
-
So, i have been working on gCAS2 recently. This begs the question: Where should GlassOS focus its usefulness, more educational efforts, or more game/scripting work?
Remember that SDCC is ideal for this OS, but is not limited to only C dev..
It really depends on what you want to do with it. However, since this is intended to replace TI-OS and cannot be booted with it; I would say math functions are essential. Most calc owners are students and need their calcs. for Math. If it can't do a certain degree of math required for their classes they will have little reason to use this. Game dev and programming are nice sure, but a I'd focus on getting it to do it's primary job first. :)
-
gCAS2 already appears to handle everything but stats and graphing...
i don't think on-calc debugging of the actual OS is necessary unless you need it, since ideally the avg user shouldn't have to debug the OS :P
-
I agree, math functions are important. Because the OS is just there to provide a C environment and gCAS2 is just a user program, they will be updated separately.
A note on the debugging, the functions for debugging aren't intended to debug GlassOS - it's there so user programs can send debug info. The user will not be aware that debug info is being sent, or nothing when the USB cable is disconnected.
As a side-note, GlassOS has a new build system that isn't insane! ..... but still uses one php script to generate a header... This cleanup task will be sent to svn on sf.net eventually and should build as-is.
-
GlassOS (technically GlaßOS, but for ease of typing...) is an OS written for the ti84pse.
Will it also be supported on a 'normal' 84+?
-
will be, but not currently supported. I don't have any plans for the ti83___ family
-
Why will it not be supported on the 84+ regular edition? All that is different is the 480 KB of user archive (on TI-OS) instead of 1540. It even has crystal timers, the clock, the extra RAM page and 15 MHz.
Or are you actually planning the OS to be considerably larger in size than the TI-OS? O.O (which would be the only reason why one would make a program incompatible with the 84+ regular edition)
Btw nice to see new progress on this.
-
Keep in mind, DJ, SDCC does make very large programs, often 3-4 times what Asm can produce. It might well be twice as large as TI-OS.
-
Oh ok then that explains it I guess X.x
-
GlassOS is smaller than AOS. The 84p isn't supported as the flash size is hard-coded. Also, note that the binary sizes made by SDCC are dependant on the coder and his/her optimization of the code. I have done minimal optimizing of the OS in order to get functions made and get further testing of the OS and the API. Optimization, rewrites, and possible asm-conversions of functions will occur later. You could also look at AOS being much larger if the code wasn't optimized. It is possible to reorder code in C to lower the cyclomatic complexity of functions to greatly reduce function sizes (as I have done in Islands).
</rant>
-
Good to hear, since that means we should have a lot more room than I was fearing.
And wow, GlassOS is smaller? That's impressive, but I guess it's partly from the fact that AOS has some things further implemented. Still very cool, though.
-
Ah I see why now. Thanks for the explanation.
-
i have been doing major work on gCAS2. i have gotten the linux build working. gdb + kdevelop4 = yum. i have debugged it enough so that i worked out an SDCC compile error, and i got variables to work! i am currently writing a plotter for it. Hopefully it will be functional and useful
-
Plotter meaning grapher? Awesome! So this intends on covering all math functions, not just equations and arithmetic? Will it also handle statistics?
I thought it would just be a replacement for the homescreen, but with CAS functions. This is very good to hear!
-
i will try to make the most out of it... but only so much that i know how to do,
Also, GlassOS beta is sorta-stable again and is now open-sourced on sf.net's svn. An actual binary will come when i get the USB working... when i have time.
(i hate my keyboard not letting me type an upper case 'i' >:-( )
-
Good to hear, I hope you don't have too much troubles x.x. Also why does your keyboard prevents you from using an uppercase i? ???
-
This looks like great progress. I quite like the graphics of the gfiler. Keep up the good work!
-
DJ_O: No idea... anyone know the X11-related program that displays key events and such?
Jonius7: Thanks, gFiler needs some help with its browse GUI, though...
Getting the latest SDCC that has a newer, better register allocater and makes smaller output. (3.0.4)
-
Hmm no clue, you could maybe ask in the computer usage help section in case somebody knows. I never had any issue with letters not being useable, although I did have issues with sticky keys :P
-
Its really weird... Its like it can't process the I key with an extra key held down... But its only certain keys. If I hold right shift, up, or left (arrows, and maybe more), then the I key will not register being pressed. Hitting other keys works. I have no idea how this issue can exist considering the keyboard I'm typing on right now has had many drinks spill into it, and to the lower parts of the laptop, but it still runs perfectly fine. I know it isn't the OS as a fresh install of Fedora 15 and a debian OS have the same problem. :-\
On the side, I am thinking about how to make GlassOS not use direct LCD drawing... Firstly, many programs use putchar() either directly or by using puts, printf, etc. to draw text and don't care about buffers. The ones that do (games, clock, etc.) use gfx_putchar. Other things like line drawing and buffered line drawing are separate functions. A flag can be set to have the buffer auto-drawn after each function call depending on how you use it, ex. a text-based program can just call printf and work, but a game will have to set the flag, call printf and other gfx routines, then call ion_copybuffer when done manually. Both instances will use the same function, but without the flag set will cause it to do ion_copybuffer when done.
-
It definitively seems like hardware issues.
As for the LCD drawing, would not using it only affect the OS itself, not games? If it's the latter, would it affect grayscale quality, for example?
-
Well, the OS itself is the kernel and the launcher. It may effect a few as they assume that there is no LCD buffer set up on program start, but I may use the LCD buffer, then directly clear it and draw text. That will not clear the buffer and will result in the buffer drawn with text on it. But other than that, it would just need me to optimize things, like Islands will be able to draw text properly as I made it before you could draw text in gfx mode (which I just hacked into page 0x7C and drew the font as sprites, ew). If I have system popups and notifications (wink), then I can easily draw to the screen by making a copy of the LCD buffer, removing it when done. Before, I had to make a buffer, copy the LCD to the buffer by reading the LCD ports, which is slow, then make another one as a working copy/foreground, draw the background rectangle (direct only), make ANOTHER buffer, copy from the LCD again into that one, then manage them all. 1st buffer is to restore when done, 2nd is for clearing the screen (clear text from the box in the clock), and the 3rd to draw to. Instead, I can just make a copy of the current and copy the buffer back as to clear it because everything will draw directly. ^_^
Forgot to address greyscale. Firstly, the greyscale is not a feature of the OS. It is done by using the custom hook provided by the OS. The clock, I think, turns it off when running, and some other things. However, if you are running a greyscale program, you can handle it manually instead. When the key is pressed, have the current buffer ready for the b/w drawing (clear, a pause screen with text above there the box will be at, etc.), then call the doclock function. This implies that you have var_clock_int = 0.
-
Hmm I see then. Just as long as this won't affect programmers negatively too much either (such as how much troubles Kerm had to make Doors CS7 works in OS 2.53 MP or higher). :P
Also were you planning to make a topic about Islands at one point here when it progresses again? I remember seeing it and it looked quite cool so far, although I've never played the original.
-
Hmm I see then. Just as long as this won't affect programmers negatively too much either
I try to keep changes to the OS backwards compatible, such as me not changing glassKILL code for 2-3 months when doing major kernel/lib changes and the game ran just fine :-D
Also were you planning to make a topic about Islands at one point here when it progresses again? I remember seeing it and it looked quite cool so far, although I've never played the original.
Have you seen the original game? I linked to a rooster teeth vid. on cemetech of a game being played. And I do plan to make a topic here when the game is finished. I need to rewrite it when I complete the gfx merge in the OS. For now, cemetech will still be my progress forum area. As for now, no progress was done on it. I have been busy on school and stuff to do much with the OS at all, really, other than get the source in the svn. :-\
Side-note: The latest SDCC is too slow for me to use. It takes 7+ minutes to compile a small code file (clock and font data)... And it fails to work on the kernel code (I should submit a patch to them)
-
Ah ok yeah I think I do remember now. Hopefully you can resume work on it at one point. School and work can be annoying at times X.x (debugging too).
-
Heh, debugging... Although I don't have too much asm-programming in GlassOS, I will say that I rarely debug C code per amount of code that I write. Not saying that I don't do it, nor do I know how much others debug asm routines. You can thank C/SDCC for that.
I hope that I will have time to work on it tomorrow. That USB...
Oh, another thing to poll on... Since the ISR already showed that it can just pop up when it feels like it with the clock, what would anyone say about popup notifications? If you get highlighted on IRC, a program has an update, an alarm for your clock goes off (all features that will be added), then a small notification bubble will push your display up and show the notification text and icon. It can be cleared away and will not take focus away from you program (lasting a few seconds), or a flag can be set to hide notifications altogether. Plausible? Not worth it? (looking at calcs with 3 ram pages that can only run 1 user program:-( )
-
The shift-I problem sounds (can't say for sure) like a problem with your keyboard. Is it a new thing? If it hasn't been there long I'm probably wrong.
-
It started suddenly earlier on in the month. I didn't abuse it as much as my other laptop ;-) Too bad the keyboard is breaking and not the mouse
-
Well, I have been working on a greyscale function, but I need help... I am getting very odd images from this function:
http://fpaste.org/aHAj/ (http://fpaste.org/aHAj/)
on-calc, the screen gets corrupted when first drawn, so :-\. On the PC (WabbitEmu), the LCD is set, but what is displayed is wrong. I will post a screenie eventually...
-
Well, I have been working on a greyscale function, but I need help... I am getting very odd images from this function:
http://fpaste.org/aHAj/ (http://fpaste.org/aHAj/)
on-calc, the screen gets corrupted when first drawn, so :-\. On the PC (WabbitEmu), the LCD is set, but what is displayed is wrong. I will post a screenie eventually...
The screen is reaaaly crappy, and you have to wait 10 microseconds between updates, otherwise it displays garbage. Hope that helps! :O
-
Yeah from what I remember, the LCD delay needs to not be too quick. I don't remember if it's very different between calc hardware revisions, though.
-
I use port 0x10 bit 7 to see when I can write to it... and I do. I revised the posted code and the same thing happens. Something really bad is going on with it... I will take a picture of it later tomorrow
-
So, I have a screenie of what the calc and emulator do...
(http://glassos.sf.net/img/badlcd.gif)
There is no RAM corruption at all. I have yet to step through the code
Also, the wavy lines should all be diagonal in one direction, not waving back and forth.
-
Thanks to Runer112 at cemetech for pointing this out: (oops @credit)
(http://img.removedfromgame.com/imgs/0-corruption.png)
Turns out that I didn't set the column back to 0... and the corruption was the launcher screen.
Greyscale works perfectly now! Here it is:
(http://glassos.sf.net/img/goodlcd.gif)
-
Well, I have gotten the greyscale lib working and can be accessed easily. Things to use:
// FUNCTIONS
void grey_on(void); // Turns on greyscale
void grey_off(void); // Turns off greyscale
// VARIABLES
unsigned char greybuf[2]; // 0 - light, 1 - darkDoing lcd_buffer = greybuf[0] (or [1]) will change the selected layer and can be drawn to it using gfx_* and ion_* functions. With that said, glassKILL was hacked into using greyscale (which I wanted to do before but never got around to it) here it is:
(http://glassos.sf.net/img/glasskill2.gif)
I already know it is slow to draw because I draw the background checkers like an idiot. I need a function to do it instead of a giant vertical sprite of checkers, then drawing it across..... >.<
Other than that, the greyscale ISR and ion_* functions are the only functions in the program in asm - the rest are in C.
Upcoming changes will be a better title screen, a highscore tracker, fixed icons (slow bot is hard to see when on white, garbage is garbage), and non-flickering checkerboard. Maybe a menu for a help and about page.
-
The background drawing is fast now and draws in under 1 frame ^_^ However, the tasking system is bugged and isn't quitting programs properly and task switching sometimes causes violations... :-(
-
Thanks to Runer112 at cemetech for pointing this out: (oops @credit)
(http://img.removedfromgame.com/imgs/0-corruption.png)
Turns out that I didn't set the column back to 0... and the corruption was the launcher screen.
Greyscale works perfectly now! Here it is:
(http://glassos.sf.net/img/goodlcd.gif)
This looks like it some SERIOUS potential for being the best graphics I've ever seen on a calculator. You can seriously go awesome places with stuff like that, like putting it in menus and good stuff. When I start getting into programming calcs from computers (not everything on calc like it is now for me) I'm going to start writing programs for this OS
-
Is Dualbooting even a remote possibility?
-
With TI-OS? I got the idea from KnightOS's devving that it requires quite a bit of work, which I haven't seen happen (in the dual-booting scene) in glassOS. I could be very wrong on both counts but I haven't heard anything about them, and besides, I would happily switch given the fact that GlassOS has its own CAS!
-
Thanks to Runer112 at cemetech for pointing this out: (oops @credit)
(http://img.removedfromgame.com/imgs/0-corruption.png)
Turns out that I didn't set the column back to 0... and the corruption was the launcher screen.
Greyscale works perfectly now! Here it is:
(http://glassos.sf.net/img/goodlcd.gif)
This looks like it some SERIOUS potential for being the best graphics I've ever seen on a calculator. You can seriously go awesome places with stuff like that, like putting it in menus and good stuff. When I start getting into programming calcs from computers (not everything on calc like it is now for me) I'm going to start writing programs for this OS
"Technically", you can start writing programs the same that that i write them. The catch is that you must write programs in the OS that will be included in the .8xu as the USB drivers are lacking my attention. But the greyscale lib will be getting more work done when the OS undergoes a large change... which will not be fun to do :-S
With TI-OS? I got the idea from KnightOS's devving that it requires quite a bit of work, which I haven't seen happen (in the dual-booting scene) in glassOS. I could be very wrong on both counts but I haven't heard anything about them, and besides, I would happily switch given the fact that GlassOS has its own CAS!
I talked with SirC about dual booting a while back. it seems possible, but TIOS must be modified to not touch certain sectors from reading, writing and GC deletion. We both have different ideas about the boot manager, but both will work. I don't have any current plans to add one right now, but maybe in the future...
About gCAS2, it still needs much more work right now, and it has a large hatred of SDCC. So far, graphing works, but because it uses floats, it is slow and has math issues. My plan is to find a 32-bit double library (fixed point math) that can compile and run and use that for gCAS. Floats right now work, but precision is lost.
-
Well, for graphing you don't need gigantic floats, especially with the resolution we deal with.
Also, it might be a good idea to support sci. notation in the numbers: That should allow for deep zooms without massive floats.
-
ooh, good luck with USB support.
-
The USB stack works, the file transfer protocol is there, but not coded yet. Besides that, the USB is stable (or was, untested after many changes) and uses libusb1 on linux.
-
The USB stack works, the file transfer protocol is there, but not coded yet. Besides that, the USB is stable (or was, untested after many changes) and uses libusb1 on linux.
What about mac and windows support?
-
I don't have a mac so no binaries can be made by me, but if you have Qt4 and libusb1 libs/headers, then you can build the back/frontends. Windows, the libusb1 driver isn't good as far as I have read.
-
Later on today I will start writing the USB stuffs again. Now, program transfer will need a lot of large changes in the OS for it to handle them, so that may take a while.
-
Good luck working on that. The USB stuff definitively seems like a major PITA to work on. I remember someone else was suggested to add USB multiplayer to his game here and he said it was out of the question because it would be way too hard.
-
Like I said before, the USB driver and stack is there and has already worked. I already have a front end that can browse the files on the calc. I have a routine, untested, to receive files and programs, but the PC-side has no code yet. Receiving programs must be done after I change how programs are stored on-calc. Firstly, I am finally making file-based programs, binary code inside of files in the FS, separated from page-apps, binaries with a page to themselves. This will mean that page-apps will no longer be connected to the filesystem at all and will be virtualized in /bin and /lib. Saving to them is easy, managing them isn't. I am thinking about /bin and /lib are page-based binaries and /usr/bin and /usr/lib are for file-based apps.
A note about file-based apps - They are stored in the filesystem, but can't go over their size of 16KB. They take the place of the launcher, so task switching is disabled and USB access will be limited. These programs should be used for small tasks, such as games and small utilities. Now, once I have a way to start them, then the USB code will be tested.
The only part about the USB code that doesn't work is host-mode, as I don't have a proper USB cable for it.
-
What is AOS?
-
It was another name for TIOS (z80) that I heard before. I am not using that name not that much as I stopped working on my ti89.
-
Getting the full Linky driver, now libusb.so, to work. That will add host mode functionality to the OS and free up space on ROM 0. USB stack usage will not change.
-
Here's a screenie before the kernel gets an LCD rewrite:
(http://glassos.sourceforge.net/img/glassos_rc1_1.gif)
Shows bounds checking on days for months and for leap years <-- pita to make code for.
The clock in launcher should display mm/dd, and has been fixed. Fun fun fun...
The setup screen? That's for firstboot of the OS. Not finished yet, but that's how it will look. Suggestions for changes are very welcome!
-
can you also add a 24 hour clock?
-
When I add in locale options, the setup screen will ask you how you want to see your date and time.
-
Your GUI appears to be coming along quite nicely. ^^
-
thanks!
I have a few problems, some major, that must be addressed before a release:
heap2_defrag is somehow failing... Don't know what goes wrong yet as I haven't tested it.
Clock text overflows outside the box
Text input on setup isn't 0'd out first
Greyscale has noticeable pulsing (pulse every .75 seconds, otherwise no flicker... :-? )
-
that looks very cool. Not super designy and maybe not as user friendly as it could be but it looks very useable and I don't think UI will be a big issue. Nice work!
-
Greyscale has noticeable pulsing (pulse every .75 seconds, otherwise no flicker... :-? )
As far as grayscale, can you set it to a customizable interrupt?
-
Customizable interrupt as-in an im 2 interrupt, or changing the timings that the greyscale function gets called from the im 1 interrupt (current)?
Currently, a custom callback is used from the OS's interrupt running from a timer. I think I am missing an interrupting something somewhere as wabbitemu shows no odd timing.
-
That reminds me, if some of your font letters look exactly like TI's, could TI send you a DMCA takedown notice even though a bunch of other software/devices use them?
-
I already cited the source of the font (font.h, but missing the font name and not spelled as "GNU FreeFont"). It is pixel-for-pixel imitation of a GNU FreeFont. DMCA? Doubt it due to unoriginality as there are only so many ways to draw characters.
-
I already cited the source of the font (font.h, but missing the font name and not spelled as "GNU FreeFont"). It is pixel-for-pixel imitation of a GNU FreeFont. DMCA? Doubt it due to unoriginality as there are only so many ways to draw characters.
/me reaches for his collection of zStart fonts he made...
-
There was probably a better way to get a font than open a text editor, type all characters, set the font, scale it down until it is the right size, then use a text editor and type out the binary sprites for all characters and symbols... twice for both sizes. It took hours to get it right, months to fix bugs in the drawing routines... :'(
-
Customizable interrupt as-in an im 2 interrupt, or changing the timings that the greyscale function gets called from the im 1 interrupt (current)?
Currently, a custom callback is used from the OS's interrupt running from a timer. I think I am missing an interrupting something somewhere as wabbitemu shows no odd timing.
The user should be able to change the amount of times the grayscale routine is being called from your mode 1 interrupt. That will help you with your grayscale flickering.
-
Ah. That will part of the OS prefs. You can run a tuning wizard in the Launcher to fine tune the greyscale, and all programs that use greyscale will use the frequency that you chose. The firstrun setup wizard will also do the tuning, but right now it only gets the hostname. (last page of the setup right now)
-
One of the issues that will pop up in GlassOS is flash fragmentation. I already have a routine that will defragment flash pages and sectors. The only issue is that I can't just defragment whenever. So, opinions are needed... I have a couple of ways to go about this.
- If a file IO fails due to out of space, it should defragment a sector so that it can write. It will fail completely if no flash can be freed. Warns if other programs are running.
- If a file IO needs space, it should ask the user what type of defragment should be done. A quick or a long defrag. Also warns for other programs.
- File IO would simply return a no memory error.
The issue with defragmenting on the spot is that FILE* structs in any process will not be changed to reflect the moved data. The last one, well, you might loose your data, but if done right, you can simply close other programs, defrag, then swap back to that task to save. But :-\
I can see the first 2 being available if I keep track of file structs, but that would be... odd. There would be a max open files per-process (read and write) so that I can change the data when defragmenting without the user program knowing.
I would like to see the 2nd, but that could get ugly with the fs code. 3 is more controlling as you can delete files that you don't want before defragmenting, thus letting you free up space whereas 1&2 would just fail. But 3 isn't straightforward coming from TIOS...
:w00t:
-
I think it should be 1 by default. The flash memory layout should be transparent to the average user.
Maybe 2 can be selected under advanced options or something like that.
I personally think option 3 would be annoying.
-
hmm... for 1&2, I could add in a magic number in global ram, and changing it will signal to all open file handles, when used, to update their page/addresses...
I do agree that it should be transparent to the user. My head only has the extreme cases running through it, like running out of ROM completely, programs with open file handles for reading, etc..
-
programs with open file handles for reading, etc..
That's true. I guess you have to copy the file to ram in order to be read and call the OS to save it again.
But you're probably already doing that.
-
Nope. The file is read unbuffered. Writing is done per fputc/fputs (fputs will become fwrite later) call. The fs page is locked until either a fragment is made or fclose is done. crashing programs leave open-ended files which must be recovered or removed.
-
(I need more input from the above query)
On a side note: Should the Launcher theme the background for seasons/special occasions? I was thinking about a monochrome image placed onto the background using light grey for things such as x-mas/december-stuffs, holidays, birthdays, special events, or w/e. Probably configurable - specify a date and a filename and it will display the image when the day comes around. Maybe even changing the banner text.
On the other side of the note: The OS is winding down as the PC-software will need to be moved along. The OS is in good shape right now, still with a few bugs, like turning the calc off when the USB or timers trigger, contrast cannot be changed, LCD doesn't change power levels, etc.. Almost there!
-
Sounds a lot like my old OS idea, iV OS. You should add a basic256 or python interpreter.
-
I don't think a seasonal/ event based background theme is necessary at all. It wouldn't even work with the 83+SE or the 83+BE anyways right?(they have no clock).
-
this project is os (read: so) nice..
and i don't know why, but i felt like designing a kind of logo for it, it isn't that special, buti like it. do whatever you want to with it
edit:i can get you other views ans surfaces/colors if you want to, it's made in full 3D so it isn't a lot of work to change..
(http://img.removedfromgame.com/imgs/GlassOS.GIF)
-
Nice!
Can you make it rotate?
-
euh, i tried it, but the result isn't as it is supposed to be xs
here's one (with ads, free avi to gif converter..) but as you can see it's shocky and the lines around the letters don't dissapear..
i'll try to learn how to fully animate and render it in once. If anyone know how to do this so it gives a good result, please tell me, i'm using Solid Edge v20
(http://img.removedfromgame.com/imgs/GlassOSAnimated.GIF)
-
I don't think a seasonal/ event based background theme is necessary at all. It wouldn't even work with the 83+SE or the 83+BE anyways right?(they have no clock).
Actually GlassOS was not planned for the 83+ series I think, just the 84+.
-
That is true DJ_O. The OS depends on the added hardware of the 84 line. Currently, only the ti84pse is supported due to the flash size harded coded still. I still need to fix that -_-
-
But yeah the thing is the 83+SE, while it has crystal timers, lacks a clock. It has no USB either too, so no USB stuff. It's slightly faster than the older 84+ calcs, though, and has the extra RAM pages. It also has a tendency to break faster than other models too, it seems. <_<
-
The OS has quite a bit of code put towards the USB and clock. Removing those would not let any PC connections as I don't have IO code (no IO cable to test with). I don't have the actual hardware so I simply can't code and test it.
Older models as-in the ti84___ calcs with 8 RAM pages?
-
yeah. Also thanks for reminding me of the amount of RAM pages. :P
-
Yeah... the lack of RAM pages kinda sucks as GlassOS uses them for task switching, but when there's only three, it will only allow one user program and the launcher...
I could redo it to have the launcher and two user apps with 3 pages, but the page layout needs to be slapped about
-
Do you mean on extra RAM pages calcs there is multitasking and on other models there isn't?
-
Currently, yes. I am going to get around this by hopefully removing the global ram, or at least mapping it elsewhere. Note that with games, you probably can't task switch anyways, as well as non-full page programs. Again, I will work on it later on.
-
Ok, good luck. It would be nice if you could, since fewer and fewer people will own calcs with extra RAM in the future (they date back in 2004-07)
-
Note that there is always one program running. 3 RAM pages lets the Launcher and a user program run. But yes, I could make the global RAM the Launcher's RAM page and have the other 2 pages open for user programs.
-
To get at the problem posted above, I will use port 27 (http://wikiti.brandonw.net/index.php?title=83Plus:Ports:27) to remap global data from RAM 0. Actually, has anyone ever had to depend on this feature before (port 27 not 28)?
Also, the USB communication testing has gone well, so here is a look at the GUI running and browsing files and folders from the calc:
(http://glassos.sf.net/img/glasslink2.png)
Not done, obviously, and more extensive notes on how the above was done was posted on the Cemetech GlassOS thread. (No need to copy/paste)
<edit>
Oh I should make a note about this
Do you mean on extra RAM pages calcs there is multitasking and on other models there isn't?
1) Task switching is allowed on all calcs as there is always the Launcher running. You can jump to the Launcher at any time and run other programs or kill running ones.
2) Not quite multitasking, but more task switching. Once a program is backgrounded, it only gets to run again if a USB event or custom callback is triggered for that process.
:w00t:
-
This could go in another topic, but... :-\
glassKILL is finally done for now. An extended demo showing glassKILL, gFiler, suspending and resuming of those processes, and the highscore storage for glassKILL
Here is a screenie:
(http://glassos.sf.net/img/glasskill3.gif)
Just added the score tracking and the backgrounding support
-
great :) i like the way you can browse through your files and the homescreen (the one with the icons)
glasskill is that game, right?
-
Will this OS run well on an old TI-83 Plus?
-
I'm afraid not, Mr. President, due to the lack of a USB port. It does run, but there is no way to transfer data to/from the calc, unless someone writes an IO linking program
-
Screenie looks very nice.
If I were you, I think 83+ support is something I would consider. There are quite a few people who only have the 83+ models.
-
ti83+ support will never happen 9from me) with GlassOS due to the flash chip size, lack of USB and lack of hardware.
-
Ah, I see. Pity. :(
-
(cross-post)
So, gosusbcommd, glassLink, gFiler, and my flash commands are working, and I have successfully sent a binary program to the calc via USB! It is a full page program. File transfers have been working for a while, but massive transfers weren't successful until now.
Right from the daemon, here is a speed recording:TIME TO SEND: 2.773631
WRITE/SEND SPEED: 5907.058293 bpsFrom previous tests, 7.6KB/s is the speed of just USB, so 6KB/s that includes writing isn't bad.
This is the time to defragment and send 8 chunks of 0x800 (2049 bytes per packet) and write them to the flash. The binary alone doesn't run in Launcher, a .desktop file was also sent over to allow the program to be registered in the Launcher. After sending those 2, the program is ready to run (I sent another glassKILL and it worked perfectly!)
Later on I will get binary deletion and other transfer quirks worked out. Expect a release of the PC code soon (still unstable).
-
Very nice! =)
-
Very nice! =)
Thanks!
-
Hmm, what about the SE? It has more RAM and Flash (I think :P) and the new crystal timers, but no USB or RTC. With a proper IO driver (could be community-made) it seems like it would be doable.
-
Why has no one informed me about this project? And can someone please explain how our former president managed to stumble across our forums? lol.
I'm rather excited about what I hear so far in this project. I program mainly in C, and C based languages, so hearing about an OS for z80 that is going to support C based development natively (unless I misread that) is very exciting! is it going to have an on-calc compiler? or is it going to work through some kind of interpreter system? Also have any programs been tested on it yet? Or is it too early in development for that kind of thing still?
I'm thoroughly impressed with the work so far though, the fact that you can get SDCC to give you output that can fit on the calc is pretty impressive in and of itself. I never had much luck with it, which is one of the reasons I never really started built much of anything for z80. Now I might just mess around with it! It would certainly be much easier to adapt to that system in C than having to get good at ASM.
I hope to hear more about this soon! Keep up the good work!
-
I just typed a long response addressing everything you mentioned, and it failed to post, so I will say:
Thanks!</burningrage>
-
Side-project progress:
gCAS2, a CAS made to run on GlassOS (also works on Linux and Prizm (see KermM's 3D graphing add-in)), is making some progress. I now added graphviz support and distributing. Here is a gif of what the cas does when evaluating (a+1)*(a+2)*(a+3):
(http://glassos.sf.net/img/gcas3.gif)
Each block is a node, 13 bytes for GlassOS and 24 bytes for Linux. The cas steps through and evaluates one node at a time until it cannot. This gif shows 30 steps with a max ram usage of 337b on GlassOS and 696b on linux (tree size).
-
Looks pretty nice. Will it be possible for teachers to disable it so GlassOS users can still use their calc during US exams?
-
Firstly, gCAS2 is not required by GlassOS. It is a separate program in the GlassOS project and must be installed separately. Disabling it would be done the same way as deleting flash apps in TIOS. Be aware that since gCAS2 has both a shared library and a front-end, removing the library will cause other programs that use it to also be removed.
Second, using gCAS2 right now would be a huge disadvantage as it doesn't have a lot of features. :-)
-
Oh right, so I guess they can just remove it then lol. I thought you were integrating it or something.
-
Plus, a student who can go to the lengths of successfully installing GlassOS and gCAS2 can handle the math on the ACT, IMO :P
-
Well, I started on working on the OS again after 5 months of silence. I have worked on gCAS2 in response to KermM's Graph3DP addin for the Casio Prizm and haven't touched anything else. Well, now I am getting back into the unfinished parts of the OS: the newGUI code, the USB, and package system.
-
Huzzah! This is definitely the best 3rd party OS around, which is definitely going to be on my 84+!
-
Mine too!
Oh, and you should put in a way to transfer OSes to other calcs, if at all possible. Not exactly a huge priority, but it would help with spreading the OS goodness.
-
Glad to hear. I hope this OS project eventually comes to fruition :)
-
Great project, is there a download link for the latest build for gCAS2?
-
Since I am working on my entry for the Cemetech Contest #9, I don't have any time for the next few days to touch any other code. Once I am done with this, I will resume working on gCAS3, a reworking of the function and algorithm system of gCAS2 in order to make it smaller and a bit easier to make functions. Once I finish gCAS3's new features, I will then work on adding it back into GlassOS and making another unofficial release.
-
I should check your entry at some point. I didn't have much time to do so yet. Anyway glad to see this is still alive too :)
-
I should check your entry at some point. I didn't have much time to do so yet. Anyway glad to see this is still alive too :)
Thanks, I am still here. I logged in due to the fact that searching GlassOS here didn't pull up this thread, so I was concerned :\ I can search it now, so I have no idea what happened yesterday (the search finished way sooner than it should have taken).
-
Just bumping a post here, anyone trying to build GlassOS from svn should be able to do so (I have finally added the missing tools). Also, the FORTH interpreter that was added is not yet in subversion.
-
Good to hear it is still progressing :)
-
This is NOT dead? O.O
Pretty awesome, especially if you think about how long this project already existed! :D
-
Holy snap I saw one guy code in FORTH with RedPower (Minecraft mod), and I really think this language is much harder than ASM. D: I hope you'll add a BASIC interpreter at one point.
-
In some ways forth is actually easier. For one thing, the language has relatively few operations and no pointer management.
On the other hand, you do have a massive stack to worry about, and it's not exactly straightforward to follow.
The best reason to have a forth interpreter is probably because of how much easier it is to create than other language interpreters.
-
Would Forth be the only available language for this OS? If it's really as hard as Z80, maybe it would be good to have an alternative, such as an optional port of Axe or Grammer. Of course that would require the respective authors to port them, though.
-
Just like any computer, for a language to run an interpreter has to be made for it. There's nothing preventing other languages from running on it, except for lacking a port. Axe, in particular, would need modifications to accomodate the new OS structure, but most of the internal code it generates would be fine as-is.
Also, Forth is not as hard as z80, at least in my opinion. However, it's not exactly straightforward to look at.
-
FORTH take some getting used to. Learning to manipulate the stack to do exactly what you want without pondering it for a couple minutes will require you to seriously dive into the language and do some real work in it. After that it's not too bad.
In some ways forth is actually easier. For one thing, the language has relatively few operations and no pointer management.
Yes it does. Though not used nearly as often as in other languages, FORTH has variables, and they are used as pointers (declaring a variable defines a word that pushes the address of the variable to the stack, and you can manipulate it like any other number on the stack).
-
In any case, since GlassOS has a fully implemented libc, it would be fairly trivial to port Lua.
-
Bump, FORTH isn't the only language, a form of LISP is in the making that will be cross-platform in C. Currently, it is being held back due to a lack of a tiny cross-platform floating point library. Neither are completed and GlassOS work is on hold due to other projects taking up my time.
-
Aaah I see. Hopefully you find more time to work on this in the future. What are your currently active projects btw?