This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - AHelper
76
« on: October 08, 2011, 01:30:31 am »
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>
77
« on: October 04, 2011, 11:55:35 pm »
will be, but not currently supported. I don't have any plans for the ti83___ family
78
« on: October 04, 2011, 11:48:21 am »
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.
79
« on: October 01, 2011, 11:51:04 pm »
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.
80
« on: September 27, 2011, 11:27:45 pm »
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..
81
« on: September 22, 2011, 11:44:40 pm »
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
82
« on: September 13, 2011, 12:11:48 am »
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. 
83
« on: September 10, 2011, 01:29:10 am »
The ti89 solves limits correctly, so it is possible. A side note, I already am working on a cas (gCAS2) for GlassOS, which runs oncalc and on PC. I haven't worked on it recently, but it can parse, create a node tree, simplify and approximate it, and create output, including steps in simplifying the problem... :-D
84
« on: September 07, 2011, 05:47:09 pm »
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? 
85
« on: September 05, 2011, 12:51:41 pm »
Does wxwabbitemu allow loading of 8xu's?
86
« on: September 05, 2011, 01:51:25 am »
Here's the anywhere clock:  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
87
« on: September 03, 2011, 10:23:54 pm »
as easy as isr_clock_int = 0;
88
« on: September 03, 2011, 10:18:45 pm »
(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!
89
« on: September 01, 2011, 10:43:28 pm »
SDCC, in the 3.0.0 version and in the optralloc branch, defies that statement by making up opcodes, using a jr when it is clearly trying to jump by a 16 bit number, or just failing to manage the stack... But that's just me and mah buggy OS, which somehow runs.
90
« on: August 30, 2011, 11:52:36 pm »
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
|
Show Posts