first comment =)

Second comment.

eminem.... chronic 2001.... dre... coming soon...... and as they saw dre next to a burned down house with a can full of gas and a hand full of matches and still no one find out... http://www.eminem.wxs.org

HHAHAH!
FOUTH COMMENT!
May the best program win.

I think that the new system will be great because it will allow people to know if they're going to be nominated on the 10th of the month instead of having to wait 30 days every time.

Both Ion and Prosit have already won the POTM before. How come they are on the list again?

Ok, after looking over the list of winners more carefully, here are a list of programs that have already won but are on this month's nomination list:

Tetris Attack for the TI-83
Galaxian for the TI-83
Ion for the TI-83
SimCity for the TI-85
YAS for the TI-86
Prosit for the TI-89/92+
Phoenix for the TI-89/92+
Virtual TI for Computer Utils (twice)

--

What's the point of leaving these programs on the nomination list if they can't win anyway? Bill Clinton isn't going to be on the ballot for the general presidential election next year, because he can't be elected again. So there is no point. Please, someone tell me the point of leaving these programs on the list.

If a program is ever updated, it's allowed to be on the ballot again.

No its not.. if a program has already won, it can't win again.

Personally, I think Phoenix and VTi deserve to win every month. :)

As I explained in the news item, those that already won were not eligible and that you should not nominate them. We are currently revamping our software at this time to provide the switch in our nomination methods. Consequently, it doesn't make sense to implement the changed programming required to do this check at this time.

Why haven't the TI-83 and TI-83 Plus sections been combained yet? You combine the TI-89 and TI-92 Plus sections, why not these two? More programs are made for both the TI-83 and TI-83 Plus than for both the TI-89 and TI-92 Plus.

But frankly, it doesn't matter if you don't combine them, as long as you are consistant and seperate the TI-89 and TI-92 Plus.

Please, do one or the other. But be consistant!

89 and 92+ asm are so much alike that programs can easily be ported on both machines. 83 and 83+, however, require a great deal of work to port.

No, not really... programs can easily be compiled for both the TI-83 and TI-83 Plus using the Ion shell. Plus, its not very likely users will own both a TI-89 and TI-92 Plus, so why combine those two sections?

But most 83 users use SOS over ION

Most TI-89 users don't own a TI-92 Plus. :)

Although you are correct in saying that programs can be cross-compiled easily, this is _not_ the same situation as the 89 and 92 plus. The 89 and 92 Plus are (basically) identical. Code written for one works on the other with little or no modification. The 83 and 83 Plus, on the other hand, are fundamentally different calculators, as one has different ROM, different memory, etc. They just happen to share a number and a user interface.
--
Phil

Sure, but why combine the TI-89 and TI-92 Plus? Its not like very many people own both of them. People release programs for only the TI-92 Plus, and you are making TI-89 users vote for such programs. Its not fair.

While some internal characteristics may be more similar on the 92+/89 than on the 83+/83, from the perspective of users and many programmers the opposite is true.

Even though system calls may be the same on the 89 and 92+, think about how much of a game is spent on doing these. Now compare that with much time is spent drawing on the screen. Clearly, most games will spend more time in the latter. In order to make the same game run on a TI-89 and TI-92+ without changes, you would have to either base it on the TI-89's screen (in which case, 48% of the display on the TI-92+ would be unused) or base it on the 92+, in which case 48% of what you had intended to display would be invisible. Clearly, programs have to be designed differently for the 89 and 92+. Actually, I can think of other possibilities, such as using a 192x120 display or something like that, wasting less of the 92+ screen while having only a little invisible on the 89, but it's hardly a better solution. The screen size (displayed screen size, not the buffer size) is a very important part of the design of many games.

For the TI-83 and TI-83+, on the other hand, the screen display (the largest component of almost any game) has the same size. Since Ion programs do run on both 83 and 83+, it can hardly be argued that it's difficult to make one program run well under both. And while certain issues may cause porting problems, generally converting a TI-83 SOS program to Ion is not difficult. No major rearrangements need to be done. Even though the ROM and memory are different, those problems are mostly dealt with automatically with Ion so most programmers don't even care about them.

Also, don't forget that the TI-89 and 92+ have completely different keyboard layouts. This may not matter for strategy games, but in an action game it's clear that this is a major part of the design. Since keys are arranged differently, the best layout may be different. Worse still, the keyboard hardware ports are arranged in a completely different way. Simply trying to make a program which reads keys such as the arrows in hardware on the 89 and 92+ would require you to check which calculator you're running (and reading hardware ports is necessary to detect multiple-key presses, as is often needed in an action game). I can't hardly see how this is (from the point of view of one making a game, not of one making a shell) is less complex than "porting" SOS to Ion, which is mostly just a matter of changing rom calls to use the bjump and bcall macros, and the Ion build process/include files automatically give you versions for both calculators.

Try considering some examples of actual programs:

Galaxian 1.3 is available for Ion. A single source file, 2465 lines in length, is used to build both the TI-83 and TI-83+ versions. There are a total of 58 lines of conditional code (i.e. stuff assembled for one calculator but not the other), which is 2.35% of the total source.

Phoenix 3.9 is available for DoorsOS. It has 15 source files, total 5804 lines in length. The same files build both TI-89 and TI-92+ versions. It has 919 lines of conditional code differing between calculators, which is 15.84% of the total source. There's this much conditional code even though Phoenix really sidesteps the display issues for the gameplay itself, simply having the center of the 224x120 play area on the TI-92(+) shown on the TI-89.

In other words, as soon as 15.84% becomes greater than 2.35%, there will be very good reason to have TI-83 and 83+ separate while not having TI-89 and TI-92+ separate. Until then, such a scheme doesn't make sense.

(Note: since I wasn't terribly careful when adding up the above totals, I can't promise that the figures I have are 100% correct. However, I'm sure that they're reasonably close to what I've written above; the 89/92+ certainly have a difference many times greater than that between the 83 and 83+)

You have way too much time on your hands don't you? :)
HOw long did it take you to write that?

I don't remember how long it took, but I think it was 15 - 20 minutes. Anyway, no amount of time is too much time for an issue as important as this.

I must argue with your comparison with the 83/83+ screens. While they are the same size the number of pixels per inch is different.

The point is that the number of pixels on the entire screen is the same. That's all that matters when determining whether programs should be grouped together. Even though I haven't looked at the two calculators side by side, by looking at the pictures on TI's web site, and the VTI skins, I can tell that if the physical size isn't the same, it's at least very close.

If the physical size of the screen *were* an important factor, then ticalc.org needs to have different sections for TI-83 games and TI-83 games projected with a ViewScreen. Also, that would make computer games different depending on the size of monitor used. Obviously, this makes no sense; what's relevant is the logical size of the screen that's being used.

So what? The only thing that matters to programmers is the number of pixels.

Your argument is in no way scientific. You took only one random file for each calc and compared that. You might as well compare programs that were easily ported from the 82 and 83. You would then say that since there were few differences between the program for the 82 and 83, then those two calcs must be combined.

And what about the arguments on their other side? They don't even seem to exist at all!

Also, I think I need to point out that these selections are in no way random. In order to be as fair as possible, I chose programs that do similar things (i.e. they're both shoot-em-up games) and based on code from the same person (which is me, because I more easily know which parts of the code I made conditional in my own stuff, instead of having to analyze programs I'm not familiar with).

If you think that I specifically chose examples for my favor, you're absolutely wrong! In fact, there's probably more difference between 83 and 83+ for Galaxian than there is for most games, since it equates APD_BUF and TEXT_MEM depending on the calculator, instead of using the "saferam" defines given, and also seems to have some sections of conditional code which actually are the same for both calculators (i.e. in a large block with some differences, several lines that are the same appear at the top of each option). And as I've already mentioned, Phoenix has *fewer* changes between calculators than other games are likely to have. I'm even counting the sprite images in the size of Phoenix, not just the code; I could have easily taken that out and gotten an even higher number.

I'm not claiming that the percentages of conditional code are the same in all programs.
If you'd bothered to read the article carefully, you would have noticed that the numerical example is only there to illustrate the general point, which is that (in a program that consists largely of screen display, such as most games) the display is the most important part!

If you would like to conduct a more careful study by analyzing a larger selection of programs, please do so. I expect that you will probably find the results to favor my position even more than these ones do, since most programs for Ion would probably need no conditional code at all, and most TI-89 <-> 92+ conversions that more fully take advantage of the screen of each calculator would need even more changes.

As far as the TI-82 and TI-83 go, I don't actually think that those should be combined, but it is certainly true that it makes more sense to combine TI-82 and TI-83 than to combine the TI-89 and TI-92+, since the 82 and 83 are much more similar. The reason is that the interface to the programmer is fundamentally different (even though not much so) unlike the 83/83+ which have the same on (Ion).

I would be interested in learning what *you* think are good criteria for determining which contests should be merged. In particular, what rule makes the TI-89 and 92+ the same while the TI-83 and 83+ different? The only things I can think of that would come anywhere close to making sense are (1) whether or not it has Flash ROM, which has no effect on most games, with the exception of allowing more storage and (2) what the internal interface to the system is, which is made completely transparent by the shell, so while it matters to shell programmers it's irrelevant to anyone else.

Just so everyone knows for sure, here are the criteria that I use:

1) Processor. I think this one should be obious.
2) Screen size. As I've mentioned before, most games are closely tied to the screen, so they need to be designed to fit it, so they must be done very differently for different calculators.
3) Shell interface and build process. If the interface to the system that a program (i.e. not the shell) uses is similar, then that makes (from the point of view of anyone but the shell programmer) the calculators very similar. When, in the case of the 83 and 83+, programs are easily built for both calculators with little or no differences in the source, that also makes them very similar.

If we see things from the user level, it's even more clear why the 83 and 83+ should be together, while the 89 and 92+ shouldn't be. You have to remember that most users who own an 89 or 92+ don't own both! Therefore, putting games only for one calculator (especially only for the 92+, which has fewer users) doesn't allow it to have a fair chance, since many people who can vote in that category can't even run the program (they can't run it properly anyway). Of course, it's also true that the 83 and 83+ aren't usually both owned by the same person. However, the programs for them are functionally identical, so an 83 user is qualified to judge games on the 83+. I seriously doubt that you could tell the difference between screenshots of the 83 and 83+ versions of a game. Why? Because they're the same program! On the other hand, I think it's fairly easy to tell the 89 version from the 92+ one.

Exactly. :) I couldn't have said it much better myself. I really don't see any easy, fair, and perfect way of doing the POTM right now. I'm really interesting in seeing what ticalc.org has planned for next month, they tell me it will solve everything and be perfect. I have my doubts though. :)

The reason why there are different categories for POTM is because not everyone owns every TI graphing calculator. It would be vastly unfair to have only one category, because for a calculator that most people don't have (like the Ti-92 Plus), those programs would almost never win. So really, each calculator should have its own category. That's what Patrick was saying, the TI-89/92 Plus category should really be broken up into two different categories.

The screen resolution is much different.
Thats like saying the 82 and 85 are the same calculator because they are z80 and dont have flashROM

Actually, TI purposely allocated the same amount of video memory to both the TI-89 and the TI-92+, which makes them identical except for the case design and the geometry software on the 92+. The TI-83 and the TI-83+ have different internal ROM calls and memory structures (i.e. FlashROM is only present on the 83+). Judging from physical aspects alone (screen-size, case design, etc.), it would be easy to say that the 83 and the 83+ are more similar than the 89 and the 92+. However, you can't judge a book by its cover, and you certainly can't judge a calculator by its cover, either.

~ferich

Ok but some people make programs only for the TI-89 and some only for the TI-92 Plus. Why are those two calculators combined into one section? Users don't own both calcs.

In the SDK that comes with DoorsOS, there is a batch file that compiles asm into binary. I found that it will produce an error if you do not compile a program for both the 89 and the 92+ (i.e. both _xdef ti89 and _xdef ti92plus are needed). But as far as the calculator is concerned, they are identical with the exception of geometry software and case design.

~ferich

With Ion, you can compile a program for both the TI-83 and TI-83 Plus. Same thing. :) And don't say that everyone doesn't use Ion, everyone doesn't use Doors OS either. :)

Ummm... What about the Ztetris incident? Isn't that an example of compiling for both 83 and 83+ and not working? My guess as to why some programmers release software only for the 89 or 92+ is because they don't have the second calculator to test the program on. Many people would like to avoid Ztetris-like problems.

I do, however, believe that programs made for more than shell should be grouped together as one program, instead of counting as three.

So if someone makes a game for AShell83 and SOS, those should be grouped/counted as a single program. But if the game is also for Ion, then it gets counted twice, since its also for the TI-83 Plus?

I know it's a paradox, but it's the best way.

Of course, if you made a game for the 92+, you can always compile it and run it on a 89. But what will happen then ? Only one part of the screen will be visible, and the keys will be misplaced. The same key problem will happen if you run a 89 program on a 92+.
So, we can consider the two calcs are differents, because they won't run correctly assembly games that were not designed for them. And believe me, when you designed a game to take advantage of the huge 92+ screen, it is not easy at all to make a 89 version of it.

Thing is that 89 programs can run on 92+ if they are doors, plusshell, or shell-less compatible right? (Or did I make that up?) But only Ion programs will run on the 83(+). What should ticalc do with the SOS or Ashell programs, or even shell-less (ehem, stranded, ehem)?
- Matt

Some can, but some can't.

ticalc.org should seperate the TI-89 and TI-92 Plus sections.

actually, Ion games can be made to run on the 83 can't they?

Yes, both the TI-83 and TI-83 Plus.