Please, post your comments! I have this thread dedicated for feedback on progress. I just made the interface up in a few minutes, then wrote it in about 30 minutes.

Still waiting for those comments!

Anyways, work will be done on this... not this week. I will work on it in a month since I can't get my calc until then.

Work started again by picking up where I left off on the gui library. KermM, this is for you. I have a gui widget layout serialized somewhere. Currently, I have the text, callbacks, and widget data separate. Right now, I am making those into one data block which will be ready and used by an assembly-based interpreter. Can you share the layout that you use for DCS widgets? Or are these on the DCS wiki? (I am also looking for internal data storage for it as well (temp variables and such to see how you approached it)).

D: Too bad I promised to a girl that she can lend my 84 with exams, I'd like to test this.

Well, my exams are in two weeks, then a break afterwards. That is the time I will do major work on the OS. For now, just scattered stuff.

Here are some DCS wiki pages
Main GUI page, with TOC
The routine that opens the GUI stack
The routine that pushes a widget onto the stack
The data item for a text button
The data item for a text block (see this page to find out that the DCS text-editing routine changes the text field here)
From this, it appears evident that all of the data is contiguous in the block, with text, callbacks, and widget data as one block. The stack entries are most likely copied to free RAM, as finding a particular item in the stack is an O(n) operation.

Ok, I am finally making some progress.

• Launcher no longer crashes due to the doList code - I malloc'd 2 LCD buffers and never freed them.
  
• Launcher::firstrun no longer leaks 16 bytes
  
• Launcher shows its ram usage in the bottom left corner
  
• all::prefs_getContrast is disabled - I found a case where it inf. loops and a reformat isn't possible before that.
  
• A bug was noticed again where the calc would lock up randomly. Only found on key presses and exaggerated in Launcher::doList, but also seen in the main menu with no greyscale. This must be a fault in the ISR inf. looping for some strange reason. WabbitEmu doesn't have this issue.
  
• Again on the above bug, going into glassKill would have the greyscale ISR off, but hitting keys will re-enable it and continue program control.
  
• Yet again, setting the clock gets stuck a lot.

Just need to track down this major bug and fix the prefs system for me to be happy with the kernel again.

Bug fixes:

• Kernel no longer uses __critical in normal use functions. Key_store needed it because the ISR uses the keyboard hardware.
  
• Made glassLink compile
  
• Located a bug in fopen/fclose/fwrite in gFiler's transfer subprogram.

Currently looking to see why fopen/fclose crashes. Also might be that fopen's ptr is lost all of the time.

I also need seekdir and telldir to rewind .desktop files to save space in RAM (already low, but trying to minimize it completely.

Nice progress, AHelper. I'm assuming that glassLink is a program for sending files and programs over USB or I/O.

I have a question about building for Glass: Are the Cygwin tools compatible with Glass, provided that you use Glass's libraries instead of the GNU ones, or do you have to use a different compiler? I want to try writing for this with Eclipse.

<question removed, see topic split post>

Anyways, gFiler dies. I need to investigate further. Either global ram is being nuked, or fopen and such are dumb.

Due to a topic split, the answer to your question was posted over here. To answer again:


We're now working on LLVM code generation for the z80 architecture though, so eventually llvm-gcc ought to work. Still a ways off though.

I put it on my emulator, wabbitemu, and WOW. Very cool, this just shows whats possible on a simple (yet very complex) ti-84. we really should feel humbled by this {KermM} because he just took every thing to a new level.

Hey, I was just trying to play with GlassOS and start writing for it, but I cannot get it to run. Here are my results so far:
- I put the GlassOS.8xu from the SDK on SourceForge onto my 84 Plus SE on WabbitEmu. The program stayed at the formatting step for over 10 minutes, even with my calc running at max speed.
- I also installed SDCC and Cygwin so that I could run make on example C programs. I was able to compile the sample Hello World program to a .bin file. How would I send that to an emulator or physical calc?

EDIT: Taking a look at the WabbitEmu debugger, it appears to be stuck in this infinite loop at address $D067:

Code:

As you can see, de and b never change, so there is no way it can escape. Trying to change execution to the address after the loop causes it to get stuck back in that loop when I close the debugger and reopen it.

1. Gah, I need to update that ROM. I haven't updated that in a year now.
   
2. You can't actually use that program The programs in the 8xu are embedded into a ROM page. The OS already statically stores page numbers of where things are, so it isn't hard for GlassOS to have programs in the 8xu. You would need to use the actual OS on a calc, but sadly I have an issue with the file transfer program where it corrupts memory somewhere.
   
3. That is probably a flash routine. Either it tried to write somewhere invalid or your emulator isn't up-to-date.
   

I will upload the new 8xu later today. Poke me on IRC so I can make sure it gets done

- Which program are you referring to? I'm actually not running a specific program in GlassOS - this is the OS formatting the file system on first boot. And I assume that you are not referring to WabbitEmu, since you were able to acquire screenshots.
- Also, I'm using Cygwin on Windows to run "make", but how can I get "php-cli" for building the OS? And once that's done, how do I transfer a program I've built to WabbitEmu - or, for that matter, an actual calc?
- And WabbitEmu is up to date - this is the latest version on codeplex.

For your calc, can you give me your calc model, if it has extra ram, and flash chip maker/model. (Last one will need an asm program with direct flash chip access.)

I can't support whatever version of ROM is on the server as it is far out of date.

php-cli, hehe, you need php. I don't build on windows, so I can't help you.

You cannot transfer programs to the emulator, and that will most likely not change. Transferring to the calc: " I have an issue with the file transfer program where it corrupts memory somewhere. "

---

I will get back to working on the OS in a month or two.

I'm not running GlassOS on my calc at all, just on WabbitEmu to be safe. I dumped the ROM fresh off my TI-84 Plus Silver Edition, which has BOOT code 1.02. The number on the back is "2745019938 P-04110", and it does not have extra ram (TI-Boy by calc84maniac does not work). Because I'm running GlassOS on my emulator only, the flash chip maker/model is irrelevant (or is it?).

I know that the ROM on the server is far out of date, but is the source for GlassOS in the SDK, such that I can "make" it and be done? And as far as Linux is concerned, how large is a standard Fedora distribution (so I can boot off a flash drive)?

GlassOS-120512 Released on SourceForge

I suggest trying that and see if problems persist. Also, about building, nikkybot wasn't helpful at telling me an alternative scripting language that I know, but I will replace that last php script

Thank you very much for releasing that. It still isn't fixed - now WabbitEmu crashes during the formatting step, jumping to 8000 and clearing the stack, which suggests a fatal error. However, the OS is not signed, and I couldn't figure out what key I need to sign it with - which key do I use, and where can I find it?

(This is more a bug in the emu as this works on-calc) No signing is needed (That's the magic in WabbitEmu).

About signing, in the event that TI is/will look at this project, I don't want to get involved with signing keys.

Can you post your WabbitEmu version, OS, how you load the 8xu (generate a rom or use a dump of your calc), and the calc model used?

<edit>

I can't reproduce your error. I am running Windows 7 Professional, WabbitEmu 1.6.11.28 (latest), GlassOS-120512.8xu, letting WabbitEmu generate the rom for a TI 84+ SE, and it works fine. Also works fine on previous WabbitEmu releases on Fedora 17.

<edit>

Failing in the fs_format routine happened when I updated flash routines to be more aware of the flash chip and that was due to WabbitEmu being outdated.