Reviving the Vera project!

Jim e · Post by **Jim e** » Fri 14 Sep, 2007 7:03 pm

The 8k limit is a software controlled hardware limit, however I don't know how to turn it off on the Silver editions. So that could definitely cause a problem.

Demon · Post by **Demon** » Fri 14 Sep, 2007 7:33 pm

Would it be possible to implement a compressed file system for RAM/archive?

CoBB · Post by **CoBB** » Fri 14 Sep, 2007 7:54 pm

You need a lot of horsepower for an efficient compression (decompression is a different business), and I don’t think it could be practical in any way. Also, you need to decompress things to use them, so you couldn’t keep unchanging data in the flash, which is a big disadvantage.

King Harold · Post by **King Harold** » Fri 14 Sep, 2007 7:54 pm

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

CoBB · Post by **CoBB** » Fri 14 Sep, 2007 8:05 pm

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

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:Good compression (not just RLE which wouldn't do much good for most programs) is very hard to implement

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 · Post by **King Harold** » Fri 14 Sep, 2007 8:31 pm

The conclusion seems absolute: No compression.

But hey, it could be done.. If just to be cool

CoBB · Post by **CoBB** » Fri 14 Sep, 2007 9:39 pm

Creating a whole new OS is cool enough, I don’t think you need to add impractical features on top of that just because you can.

Demon · Post by **Demon** » Fri 14 Sep, 2007 10:42 pm

Maybe the compression could be a "kernel module" or something.

What about PuCrunch? Doesn't CrunchyOS do PuCrunch?

JoostinOnline · Post by **JoostinOnline** » Sat 15 Sep, 2007 1:29 am

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.

kalan_vod · Post by **kalan_vod** » Sat 15 Sep, 2007 1:44 am

JoostinOnline wrote:Yes it does, although I've never figured out why it only compresses levels...

It can compress programs..

JoostinOnline · Post by **JoostinOnline** » Sat 15 Sep, 2007 6:14 am

kalan_vod wrote:
JoostinOnline wrote:Yes it does, although I've never figured out why it only compresses levels...
It can compress programs..

I am pretty sure that programs must be written specifically for crunchy to support compression. I did, however, mix up pucrunch with ionlevelcompresser.

Demon · Post by **Demon** » Sat 15 Sep, 2007 4:05 pm

JoostinOnline wrote:
kalan_vod wrote:
JoostinOnline wrote:Yes it does, although I've never figured out why it only compresses levels...
It can compress programs..
I am pretty sure that programs must be written specifically for crunchy to support compression. I did, however, mix up pucrunch with ionlevelcompresser.

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 · Post by **JoostinOnline** » Sat 15 Sep, 2007 6:04 pm

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 · Post by **elfprince13** » Sun 16 Sep, 2007 1:56 am

has anyone talked to tari yet? he's working on his own operating system and last I heard he was making good progress.

driesguldolf · Post by **driesguldolf** » Sun 16 Sep, 2007 4:11 pm

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?