two words

hell yeah!!!!

my two words are "port it" heh

i'd love to see this on the 83(+)

although, i played it on an 86 and it is pretty sweet

The game uses a combination of Lite86 and lossy compression of the tracks to compress its levels so that they are very very small. They then have to be decompressed on the calculator. The 86 can handle this since it has a little less than 16kb of unused space for programs to use (i.e. decompress these levels to). A port of this game to 83 would only allow 3 or 4 tracks... not exactly good for replay value.

still that would be cool on the TI-83(+)
i think that a less advanced display like simple big text would be ok if the play remained the same

all i have to say is

words = words + 1

"go for it"

Wont it be easier to say.. words = words++

You mean words++

i still think it would be nice, and i'm sure that Dan, the 83+ miracle worker could get it done

ROFLASC! I don't want to bash Dan (well, actually I do, but that's another issue (who'd be stupid enough to program for a 83?)), but impossible things are simply impossible. What Kirk says is true, the game cannot be ported in its current form.

That false because on the 83+ we have 160000k of archive mem!!!!!
Paxl

Although this is true, it would still require something like 12kb free (don't remember quite how much is the limit off hand) in addition to the game size. This would make the game require about 16kb of space. That's stupid, it would require 3x as much temp space as the program size.

could you at least try? maybe look at ram, and see if you have enough to load the level. i don't think it's any more rediculous (spelling?) than a game, i can think of a recent one, that requires all your memory, except the shell to run it.

Yes, while the 83+ does have 160K of archive memory, none of it can be used during program execution. Program commands need to be accessed much more quickly than Flash ROM can provide them. Also, Flash ROM takes way too much time to write to, thus causing a program, especially assembly, far too much time to record any changes you or the program make.

Interesting. I wont argue that it would be a slight pain to get this game to work on the 83 Plus, but not for these reasons. Code running from Flash ROM runs at the same rate as code running from RAM. Otherwise the TIOS would have some trouble, not to mention applications, which are run directly from RAM. In the grand scheme of things running an application would probably be quicker than a RAM program since you don't have to do any relocation (of course, this isn't actually the case, since the TIOS does some wacky validation and certificate writing stuff when running applications).

Of course, no code would be running from Flash ROM anyhow, since programs are copied to RAM before they're run. And since the memory requirement in question is not for the program code, but for the data, it becomes a sort of mute point.

As for speed of writing to Flash, it actually doesn't take so much time to write to, it's just that you can't write to it. The TIOS does a good job of making sure you never directly write anything to Flash, so you either have to copy a program to RAM, modify it, and send it back to ROM, or just not modify it at all. Of course, the issue of data space is not related to the program modifying itself, so this doesn't matter.

As Kirk pointed out, the problem is that there's a lack of RAM space to decompress the levels to. I can't say that I've checked exactly how much is needed, but from what I hear it's quite a lot. That means you'd have to keep your RAM fairly clear so that levels could be decompressed. I suppose it's not too big of a problem since you all of that archive memory to keep programs in, but it could become inconvenient.

Depending on how the code is written, it would be possible to gain some memory back by fragmenting the program and relocating parts into free spots of memory. Generally this would be a waste of time, but the 83 Plus is really overflowing with fairly large blocks of memory which would never be used during program execution. There's nearly 3k of free space laying about (which doesn't being to compare with the 86...I know), and some more if you can bare direct writes to the screen. Since the memory is fragmented, it wouldn't help much with the data requirement, but some of space used for code that was moved there could then be used for data. Back to the original point, archive memory would be useful terms of holding the compressed levels (and would have nothing to do with program execution or speed), but you'd still need a bunch of free RAM. So basically, a port would be possible, though slightly annoying. Sorry for the long post.

(Oh, and a (not so) quick aside to that person who so eloquently asked why I'd be so stupid program for the 83(plus) and not other calculators...I do so because I like programming for it. Of course the TI-86 is more powerful, it was built that way. If all I wanted to do was be able to program for the most powerful platform, I'd be programming for a computer instead of a calculator. I like the challenge of having to work with limited resources. Of course, the fact that the TI-83 was my first calculator might have influenced my interests).

I forgot to mention, congrats to Jonah on this game. Regardless of the calculator, this is not such a breeze to pull off and it looks really nice!

On every embedded device I've ever seen, loading the OS or kernel from Flash does not mean executing it from Flash. Usually, there's a tiny loader program that is hardware, but that isn't fancy enough to need much updating: like LILO in Linux. TI calculators have a similar program that, upon powerup, copies the OS from Flash to the 'System' section of the normal RAM or a special Z80 processor cache. The real reason you do not want to use Flash like RAM is because each bit in Flash has a finite number of times it can be written to before it fails.

I very much doubt that this is the case. The Flash chip has high enough access times for code to run directly from it, so there's no reason to do otherwise. I don't think TI would waste the money to include yet memory buffer to load code from Flash into. Not to mention that either it would have to be 512K (very unlikely since there is only one 512K chip on the circut board, the Flash ROM chip) or the current mapped page would have to be loaded to this special cache, which would take much more time than a few clock cycles (you can read from a new flash page after a single output instruction, you don't have to wait for any delay for it to load). There's no way the ROM copies the Flash to a "system section of RAM", since the RAM is only 32K and all of that is accounted for very well.

I agree that the reason Flash is not used like RAM is that it has limited writes. That's why TI protects the chip (well, among other reasons). The Flash, however, has an unlimited number of reads, so there's no reason for code to be run from any other place.

Yes, they are decompressed on the calc, but why would you decompress them all at the same time? You would only need enough space to hold one track in memory while you race.

Heh, have you actually tried the game? The levels are enormous. (And levels that are not enormous are not at all fun to play.) Only one track is decompressed at a time, obviously. To do otherwise would be stupid. A game like the Alien game below uses the method of only decomperssing tiny maps at a time, and when you get to the edge of the map it says "Entering ___". But that would be kind of bad for a racing game like megacar.

Can't you just like the game as it is? Buy an 86, and stop whining.

It's times like these when I'm glad I own five calculators. :)

I own five calculators, too! Unfortunately they're the wrong five calculators. :-(