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
61
« on: November 05, 2011, 01:52:00 pm »
Thanks to Runer112 at cemetech for pointing this out: (oops @credit)
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:
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.
62
« on: November 01, 2011, 03:09:59 pm »
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... :-(
63
« on: October 30, 2011, 09:32:15 pm »
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:  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.
64
« on: October 26, 2011, 09:45:37 pm »
Thanks to Runer112 at cemetech for pointing this out: (oops @credit) 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:
65
« on: October 26, 2011, 05:13:22 pm »
So, I have a screenie of what the calc and emulator do...  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.
66
« on: October 25, 2011, 11:54:05 pm »
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
67
« on: October 25, 2011, 10:40:50 pm »
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/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...
68
« on: October 22, 2011, 11:03:23 pm »
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
69
« on: October 22, 2011, 11:00:48 pm »
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:-( )
70
« on: October 22, 2011, 09:00:21 pm »
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)
71
« on: October 22, 2011, 08:47:16 pm »
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.
72
« on: October 22, 2011, 07:35:38 pm »
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.
73
« on: October 20, 2011, 11:24:06 pm »
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)
74
« on: October 19, 2011, 07:40:57 pm »
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' >:-( )
75
« on: October 09, 2011, 11:21:26 pm »
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
|
Show Posts