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?

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.

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:

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.. 

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.

Sounds a lot like my old OS idea, iV OS. You should add a basic256 or python interpreter.