yoman82 wrote:
Doesn't CrunchyOS and OmniCalc both feature compression?
And: I can run Joltima, it's working fine. *using it now*
in DoorsCS? O_o which release?
6.2, you run zjload, and then it boots up and starts normally. I haven't experienced any errors at all.
yoman82 wrote:
6.2, you run zjload, and then it boots up and starts normally. I haven't experienced any errors at all.
huh, I've never gotten it to run on my calculator. maybe my VAT is taking up too much space >_< that used to happen occasionally with Gemini or Desolate.
elfprince13 wrote:
yoman82 wrote:
6.2, you run zjload, and then it boots up and starts normally. I haven't experienced any errors at all.
huh, I've never gotten it to run on my calculator. maybe my VAT is taking up too much space >_< that used to happen occasionally with Gemini or Desolate.
Yeah Gemini is huge though I have heard of people successfully separating the maps from the game so that the maps could be archived.
That sounds like an excellent idea.
The only way I've ever successfully run Gemini is through msd8x.
I didn't think Desolate was that huge though. It has the data and engine separate, after all. I might be misunderstanding the meaning of "VAT" though...
jbr wrote:
That sounds like an excellent idea.
The only way I've ever successfully run Gemini is through msd8x.
I didn't think Desolate was that huge though. It has the data and engine separate, after all. I might be misunderstanding the meaning of "VAT" though...
every program you have on your calculator takes up a few bytes of RAM, even when archived because of its entry in the VAT (Variable Allocation Table). When you have a lot, as I do, it makes a noticeable difference.
elfprince13 wrote:
jbr wrote:
That sounds like an excellent idea.
The only way I've ever successfully run Gemini is through msd8x.
I didn't think Desolate was that huge though. It has the data and engine separate, after all. I might be misunderstanding the meaning of "VAT" though...
every program you have on your calculator takes up a few bytes of RAM, even when archived because of its entry in the VAT (Variable Allocation Table). When you have a lot, as I do, it makes a noticeable difference. Generally it's about 18 bytes or so per program, group, variable, app, etc. It can be more or less depending on the name length.
ZagorNBK wrote:
Even on the SE's?
yes, unless I'm misunderstanding something.
ZagorNBK wrote:
Even on the SE's?
Why would it be different on the SE's? That's how it works on all of the calculators, that is also why you have a better chance of being able to play Gemini on a non-SE since you have fewer programs meaning fewer vat entry's even when every thing is archived.
TheStorm wrote:
ZagorNBK wrote:
Even on the SE's?
Why would it be different on the SE's? That's how it works on all of the calculators, that is also why you have a better chance of being able to play Gemini on a non-SE since you have fewer programs meaning fewer vat entry's even when every thing is archived.
well, you a LOT more room on the SE, so wouldn't that "chance" be actually better on the SE...?
rthprog wrote:
TheStorm wrote:
ZagorNBK wrote:
Even on the SE's?
Why would it be different on the SE's? That's how it works on all of the calculators, that is also why you have a better chance of being able to play Gemini on a non-SE since you have fewer programs meaning fewer vat entry's even when every thing is archived.
well, you a LOT more room on the SE, so wouldn't that "chance" be actually better on the SE...? No, because the size of the useable RAM on the SEs is the same as on the non-SEs; Gemini must be in RAM to play, the VAT is in RAM, and thus you're working with the same space constraints and it's irrelevant if it's an SE or not. In fact, if it's an SE, it's more likely you have lots of programs and groups saved away in your archive but taking up VAT space in your RAM.
Oh, I thought that the SEs didn't have a VAT, or that it wasn't stored in the usable RAM...
ZagorNBK wrote:
Oh, I thought that the SEs didn't have a VAT, or that it wasn't stored in the usable RAM...
False. Neither of those are true; it both has a VAT, and it is stored in useable RAM.
Can you upgrade calculator ram?
DShiznit wrote:
Can you upgrade calculator ram?
Unfortunately, no; the OS is programmed to only be able to understand the amount of RAM built-in to the calculator, so if you wanted to solder in a replacement RAM chip, you'd have to rewrite significant portions of the OS.
Are you planning on at least releasing a 6.3 with one or two of these suggested features, should we never get to 7.0?
yoman82 wrote:
Are you planning on at least releasing a 6.3 with one or two of these suggested features, should we never get to 7.0?
Oh, we'll get to 7.0, don't worry, the question is just when. But yes, there will be intermediate versions as well.
KermMartian wrote:
Generally it's about 18 bytes or so per program, group, variable, app, etc. It can be more or less depending on the name length.
Just to have it said, applications don't have VAT entries.
Any work done on an intermediate version yet? Will one be out soon? *Hopeful* *really loves this project*
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum