For a while now I've talked about an OS I've been working on, and now it has a name, AsylumOS! Asylum is designed with the pure intention of getting the best out of your TI83+ by providing only the best possible functions to programmers. Among the many features to be in Asylum are:

• Running programs on the second RAM page so you can run programs larger than 8000 bytes
  
• New data type .AEX as a replacement for both programs and apps.The header is smaller for quicker transfer, there is no size limitation, and routines are available to quickly shift between multiple page programs. Another great thing about this is data consumption. Before, if a program was to large you had to create it as an app. Apps are pure Intel hex and not assembled bytecode meaning that with checksums and whatnot, the app is almost 3 times the size of the program code itself, and as if thats not enough, due to the design of the pages if your app is 12kb it could be rounded up to 16kb completely wasting memory. Also, data in apps before had to be copied to ram before you could even use it. As you can see, doing this solves a multitude of issues
  
• New data type .AIF as a replacement for the generic .8xi image file. Images can be custom sized, grayscale, and even animated. These images can also be set as a background for your desktop.
  
• New data type .ASF for sounds and music that can be played through the linkport
  
• New data type .AFF for custom fonts
  
• New data type .API for plugins. Each plugin has a specific id. Using this id, you can call insert the plugin into your program. Examples of plugins include media players, and viewers for custom data types like a new image or text format used by a program
  
• Data recovery for calculator resets
  
• Advanced filesystem and USB drivers
  
• Windows-like GUI system
  
• Oncalc data compression (finished)
  
• Optional multithreading so you can do multiple things at once
  
• Multi-calculator networking based on the Calcnet whitepaper
  
• Built in Z80 assembler and linker
  
• Advanced monochrome and grayscale drawing libraries for both 2D and 3D

While this is all great stuff, the downside is that there will be NO compatability whatsoever for TIOS data. Also, Asylum will be distributed with its own data linker and transfer protocol written in Java as the filetypes themselves will no longer be compatable.

Should be interesting; that's certainly an ambitious list. Does the one item that has a (finished) note next to it imply that the remaining items are not yet finished?

Yes it does.
I have made some progress on the others like the filesystem and the drawing libraries but for the most part the others I havent begun yet. I'm am mainly in the drawing phase right now.

*Drawing-board phase? As in designing specifications, plans, and all that? I think that's smart rather than diving in and finding you have to change and kludge a lot of features later.

Thanks
Aside from whats already in the list, can you think of anything else that should be featured in Asylum?

I'm a little confused by your classification of apps as three times too big. Yes, their on-comp representation is very large, but on-calculator they're the proper size. Did I misunderstand you?

Well it was my assumption that app remains written in Intel Hex even after transfer, even if not, a large amount of memory is wasted when the app pages are clamped to 16024 bytes apiece instead of actual size.

Yeah, I don't like the fact that even if you have an App that displays "TI-OS 2.53 MP sucks." on the screen, it still ends up as a 16000-byte monster. Not that you wold ever use an App for doing that.

I'm pretty sure everyone who has made an app is aware of the page clamp horror of which we speak. Not only that, but the extremely large header seems downright unneccessary.

Just another quickly spawned idea, longer filenames, maybe...16 or 20 chars max?

That would be cool. Also, make it so everything can be named in lowercase too.

What about indefinite, null-terminated type fun?

Thats a definate. Really, TIOS was just being a jerk when they added the caps limitation.

Hangon, I have a GREAT idea! Asylum should use a universal header so you can create your own filetypes! Maybe something like this:

Code:

thats pretty much all you'd need in the header, none of that bullcrap TIOS has in theirs.There would be built in file types obviously, but programs could also create their own or perhaps people could even write programs to interpret certain pc files like monochrome bitmaps.

If you're using an App for something like that, then the fault is your own, in my opinion.

Well think of it this way, suppose you had a program that had 9000 bytes of executable code. Because of the TIOS limitations, you'd have to make it as an app.The app data would only be 9128 byte (thats including the app header there) but once its sent that would be rounded to 16024 bytes wasting almost 7000 bytes of memory. TIOS apps are probably the quickest way to run out of mem on you calculator.

That's not a TI-OS limitation, that's a hardware lockdown. You can't execute on the second RAM page ($C000 to $FFFF), so the only workaround would be to let $8000 through $BFFF be an execution page, and have $C000 through $FFFF be used for your VAT, your buffers, your variables like text settings and flags, which would give you a solid 16KB of executable space. That reminds me, BenRyves suggested an excellent idea for a hardware mod to disable the $C000+execution == crash thing...

I consider it a software limitation because they could've fixed it simply by using the second ram page instead of the first. There isnt a hardware limit saying you can only use the first ram page.

Aside from that, the thought of how much memory the TIOS wastes still stands.And I dont really see why you'd need a 128 byte header for an apps when you only need 9 bytes for a program header.

Actually, by default the zeroth RAM page is in the $C000-$FFFF bank.
However, the TI-83+ has no other RAM pages, and not even a way to control what is swapped into the $C000-$FFFF bank.
The table on WikiTI's Port $05 page would suggest that allowing execution on RAM page 0 is possible (for the TI-83+), but I'm not sure how easy that would be to test, as port $16 is protected on the TI-83+

Java + device drivers == lots of not fun.

Java+interfacing any sort of low level hardware==a bad idea.

I didn't mean literally RAM Page 0, I meant the sequentially first of the two RAM pages as mapped to the logical address space by the TI-OS.