Since the TI-83+ was released, I have received a few emails asking for a port of Joltima to the TI-83+. Since I have no TI-83+ (or TI-83 for that matter) I was wondering if there are any TI-83+ programmers out there that would be willing to do the port instead. I know that the 83+ probably segments the memory up like the TI-86 which would give the calculator a size limit. Joltima was ported to the TI-86 in about an hour by Bill Nagel as the game easily can be divided into sections. Is this the only problem to porting games from the 83 to the 83+ or is there more to it? Although I have no plans to go purchase a TI-83+, I am curious about it's differences.

I was wondering about that myself. My friend just got a ti-83+. Can you not play games on a ti-83+ that you could normally play on an 83?

The TI-83 Plus is not ASM-compatible with the TI-83 in any way whatsoever. Something about 5k chunks of memory or something.

Pat Milheron posted information when we announced the calculator's launch. I plan to compile this and a little extra info and update the FAQ Real Soon Now.

Actually, there's an 8k limit for regular ASM programs (remember that the 16k limit on the 83 was overcome). The only other changes - according to the information TI has provided the TI-83+ SDK Beta testers with - is a change in RAM and ROM addresses. There's also another ASM-like format, applications. These are ASM programs with a few special modifications that are stored in Flash ROM. The application space is split into 10 chunks of 16k, and each portion of an application takes up a full block (a 1 byte program and a 15k program both take 16k, 16001 byte programs through 31999 byte programs take 32k, etc) and can take multiple blocks. These can be up to the full 10 blocks of 160k =)

Perhaps a stupid question, but what's the deal with the flash rom in the 83+, or all flash calcs I suppose. I mean, what can you put in it? Just those special flash applications TI sells? Or can you actually have 160k of regular assembly games on your calc? That would obviously be pretty cool. And speaking of flash apps, are/will/can there be any not from ti? Are we gonna see huge 100k+ games any time soon? I have no money, and if I did I wouldn't spend it on another calculator :), but I'm curious.

TI invented the concept of a flash upgradable ROM to prevent calculators from becoming "obsolete" more quickly. As everyone noticed with the 89 and 92+ already, some applications for electrical engineering and such have already been released. Also, an upgrade to the ROM (v1.05) providing a wealth of bugfixes has also been released. If they didn't make the 89/92+ flash upgradable, they'd have to install the new rom versions in all the new calculators and you wouldn't be able to upgrade older models. That's somewhat bad; many asm games for the 85 (and ZShell for that matter) don't work on extremely old ROM versions.

--BlueCalx

Flash ROM has several uses. It allows the calculator's ROM to be updated to newer versions, which may have new features or bug fixes, without buying a new one. Flash ROM space not used by the calculator's ROM can be configured as User Archive memory, where programs and variables can be stored -- they can only be played directly from RAM, but they can be stored while not in use. Say you have 2 20k games: You store one in archive and one in RAM and play the one in RAM. You can then archive the one in RAM, unarchive the other one (moving it to RAM), and then play it. On the regular 83 you only had the RAM and could only keep one of those games. Also, TI reserves 160k of Flash ROM to be used for "Applications," which are specially written and digitally signed, so that they can be made to only run on one calculator - and sold - or be shareware and run on any 83+. And a single application _COULD_ be up to 160k, although then that would be the only application (and it better be GOOD =)

160K ought to be enough for a really nice RPG... right? =)

-Miles Raymond

It would be quite hard to program a 160k rpg that is split into 16k chunks, where none of the chunks can be accessed by each other.

Hey now, don't forget about Final Fantasy Legend II. =)

Tsk tsk Dave, you haven't been reading your documentation - the apps can access other chunks

Now all the archives need is the ability to view the readme file of a zip file without downloading the whole zip. Or maybe the ability to download any single file from a zip file without having to download the whole thing. For example, if I download the new SFII, and accidentally delete my favorite player, I could just download that file, instead of re-downloading the whole package.

That would violate the author's wishes. Most of them want to keep the ZIP intact. People might download the game without it's readmes which is a *big* no-no.

--BlueCalx

Just downloading the readme would be a good idea, as it could give people a better idea of what a program/game is about than the one line description provides. It would be like the file_id.diz standard that used to be used by BBS's.

But those same people who would just not download the readme are the same people who just download them, but never read them. Just because they download it doesn't mean they don't delete it (or at least ignore it) immediatly.

However, even if you don't buy that argument, why couldn't the archives just allow seperate viewing of the readme file. Often times a program is added to the archives, and I can't tell exactly what it is/does. If I could just view the readme, it would save me the trouble of downloading files, and later realizing that I would never use the program.

I don't really see this as too much of a problem, as most of the files in the archive are around 1K in size, and can be downloaded extremely quickly by most any internet user.

"I don't really see this as too much of a problem, as most of the files in the archive are
around 1K in size, and can be downloaded extremely quickly by most any internet user."


Allowing people to view the readme file immediatly on in their browser would save a lot of time. Having to download the program, then open a file manager, then unzip it, then open it is an inconvience. And most files are much larger than 1k. The average TI-89 asm game is 29.2k in size. Since I am a TI-89 user, I have to download an average of 30k per game just to read more about it, and see if I want to put it on my calc. That is a waste of bandwidth, and slows down ticalc.org.

Bandwidth-wise, a modem user won't even scratch the obscenely fast connection that I know ticalc.org is on :)
As for the 89 games, you probably have 56k, so that should take around ten seconds to download. That's not that long a time. Also, winzip has a feature letting you view readmes under notepad or whatever before you unzip the file.

--BlueCalx

Well,
If you dont have time to download the file and look at it then you shouldnt have the time to send it to your calc and work/play with the prog/game. I mean, come on. What are we talking, like, 5 minutes?
- Matt

What if the author includes a readme that is HTML, RichText, or a Word Document? In the case of HTML there may be a few extra images that ticalc has to keep around. Besides, even with a 28.8 connection, it doesn't take long to download most files on ticalc.org.

It's not about bandwidth. It's about all these tiny zip files that I have to download, just to find out what they are. If I can't read the readme ahead of time, at least let me see a nice 3 or 4 sentence description of what the program is.

The real problem with this is the file space it would take. ticalc.org has about 7500 files (actually, a bit more than that, but hey). Now, assuming all but 500 files have readmes (most do, trust me), that means ticalc.org needs at least 7000 new web pages. Ok, now if I recall, there's a 4k overhead on each page. That means, at minimum, 7000 x 4 = 35,000K of new files. Plus, an automated system would need to be devised to make these pages, and a mass generation of pages for currently existing files would need to be done. And all that work would keep us from working on something interesting and it would take up 35mb of disk spce needlessly.

Well, that makes sense. But how about adding another box on the program submission form that allows for a more detailed description than the current 1 line description? You wouldn't have to make more pages -- just one more paragraph (or less) of text on each page.