Reviving the Vera project!
Moderator: MaxCoderz Staff
Would it be possible to implement a compressed file system for RAM/archive?
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate
<My Artwork>
<My Artwork>
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
I'd say it wouldn't be too hard..
After all, if you have fopen() and such, then one only has to add a few flags about how/whether the file is compressed.. I think..
Good compression (not just RLE which wouldn't do much good for most programs) is very hard to implement
But well, as far as the flash-disadvantage goes, if you want to edit a file you're probably going to have to buffer it in RAM anyway..
After all, if you have fopen() and such, then one only has to add a few flags about how/whether the file is compressed.. I think..
Good compression (not just RLE which wouldn't do much good for most programs) is very hard to implement
But well, as far as the flash-disadvantage goes, if you want to edit a file you're probably going to have to buffer it in RAM anyway..
-
- MCF Legend
- Posts: 1601
- Joined: Mon 20 Dec, 2004 8:45 am
- Location: Budapest, Absurdistan
- Contact:
Well, things are somewhat easier as long as you only need to access data sequentially, but I don’t think that’s very typical in a calculator application. I’m still advocating the view that we shouldn’t try to mimic the functionality of desktop computers but design the system while always keeping the capabilities of the platform in sight.King Harold wrote:After all, if you have fopen() and such, then one only has to add a few flags about how/whether the file is compressed.. I think..
The algorithm is just part of the problem. The real difficulty is that good compression requires far more memory than what we have. Bad compression isn’t worth the trouble.King Harold wrote:Good compression (not just RLE which wouldn't do much good for most programs) is very hard to implement
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
Maybe the compression could be a "kernel module" or something.
What about PuCrunch? Doesn't CrunchyOS do PuCrunch?
What about PuCrunch? Doesn't CrunchyOS do PuCrunch?
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate
<My Artwork>
<My Artwork>
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
Yes it does, although I've never figured out why it only compresses levels...
But thats not the point. IMO, one of the main reasons that all the past OS projects have failed is because people wanted to add in so many features. I don't even think that we should bother discussing extras until a functional base has been created.
But thats not the point. IMO, one of the main reasons that all the past OS projects have failed is because people wanted to add in so many features. I don't even think that we should bother discussing extras until a functional base has been created.
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
Nope, you can use Lite8x to compress ION and MirageOS programs, too, and CrunchyOS will still run them (and you don't have to have Omnicalc installed to do so).JoostinOnline wrote:I am pretty sure that programs must be written specifically for crunchy to support compression. I did, however, mix up pucrunch with ionlevelcompresser.kalan_vod wrote:It can compress programs..JoostinOnline wrote:Yes it does, although I've never figured out why it only compresses levels...
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate
<My Artwork>
<My Artwork>
- JoostinOnline
- Regular Member
- Posts: 133
- Joined: Wed 11 Jul, 2007 10:42 pm
- Location: Behind You
If you use Lite8x, then you need enough ram for the size of the original program PLUS the size of the compressed programs, so the programs you compress can't be larger than around 15K (I can't remember, but I think that was the limit). Crunchy programs are compressed so that they can be up to 24K, since they only take up the original size when decompressed for execution. Also, you are correct that Omnicalc does not have to be installed, but it does have to be on your calculator.
- elfprince13
- Sir Posts-A-Lot
- Posts: 234
- Joined: Sun 11 Dec, 2005 2:21 am
- Contact:
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
I don't get why everyone is talking about an 8Kb limit...
On TIOS there is this limit because all programs are copied to $9D95 and 8811 bytes further you're on RAM page 0 ($C000), it's $9D95 because the stupid TI uses all the rest for static variables (instead of putting it between the stack and their variable list)
But if we make our own OS I think it's wise to (if we're going to make programs run from RAM after all (btw I'm working on a relocating routine that copies the program to RAM and immediately offsets all JPs and CALLs)) to keep all pages from where we can execute free of variables we can stuff somewhere else (like right before the stack) so we have 16Kb and not 8Kb.
Or am I missing the point?
On TIOS there is this limit because all programs are copied to $9D95 and 8811 bytes further you're on RAM page 0 ($C000), it's $9D95 because the stupid TI uses all the rest for static variables (instead of putting it between the stack and their variable list)
But if we make our own OS I think it's wise to (if we're going to make programs run from RAM after all (btw I'm working on a relocating routine that copies the program to RAM and immediately offsets all JPs and CALLs)) to keep all pages from where we can execute free of variables we can stuff somewhere else (like right before the stack) so we have 16Kb and not 8Kb.
Or am I missing the point?