Results
|
Choice
|
Votes
|
|
Percent
|
No, it would be redundant
|
81
|
33.1%
|
|
No, people will abuse it
|
13
|
5.3%
|
|
Yes, new members will need it
|
17
|
6.9%
|
|
Yes, why shouldn't there be one
|
56
|
22.9%
|
|
Undecided, I'm fine either way
|
14
|
5.7%
|
|
68K Rocks!
|
64
|
26.1%
|
|
|
Re: Should a TI-84 Plus directory tree be created for uploading when it's completely compatible with the TI-83 Plus?
|
edenist
(Web Page)
|
Yeah, just to avoid some confusion really.
It wont do any harm, but will make things easier, seeing as the programs written for the 84+ will have more processor speed in mind.
[by the way, just curious, by saying backwards compatible.... does that mean ASM too, or just basic progs?]
|
Reply to this comment
|
26 April 2004, 11:03 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: New DirTree = Bad
|
Rob van Wijk
|
The 83+SE already has a 15 MHz processor, just like the 84+ and 84+SE will have. TI fixed this potential incompatability by putting in a switch that controls whether the processor runs at 6 MHz (just like the 83- and 83+), or 15 MHz.
There is no reason I can think of why this same switch wouldn't be in the 84+. Everything will run on 6 MHz by default, unless it wants to run on 15 MHz (and can therefore be assumed to be capable of running at that speed).
Sure, as time goes by, and the 83+BE is used less and less, it will become standard practice to bluntly set 15 MHz in one of the first lines of your program, but that doesn't matter; for now, they'll be compatible, even for Asm programs.
|
Reply to this comment
|
28 April 2004, 22:55 GMT
|
|
Re: Should a TI-84 Plus directory tree be created for uploading when it's completely compatible with the TI-83 Plus?
|
Ayial
|
You should post that if you own the 84, consult the 83 archive files. This way, new members will be able to see that they are compatible, and this will also increase downloads for people who make 83 files. If you make an 84 section, people will just duplicate every file and re-upload it to keep their download statistics up. I'm all up for not having this section.
|
Reply to this comment
|
26 April 2004, 12:53 GMT
|
|
Re: Should a TI-84 Plus directory tree be created for uploading when it's completely compatible with the TI-83 Plus?
|
Michael Vincent
(Web Page)
|
Yes, because there are several new functions added that BASIC programs can use, involving the clock. This would cause incompatibility issues alone.
ASM programs will also have additional B_CALLs and other things to facilitate using the USB port and the clock.
|
Reply to this comment
|
26 April 2004, 13:34 GMT
|
|
Re: Should a TI-84 Plus directory tree be created for uploading when it's completely compatible with the TI-83 Plus?
|
chemoautotroph
(Web Page)
|
It would be about as stupid as creating a TI-89 Titanium tree.
|
Reply to this comment
|
26 April 2004, 16:25 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Should a TI-84 Plus directory tree be created for uploading when it's completely compatible with the TI-83 Plus?
|
Patrick Davidson
(Web Page)
|
There are a lot of things that could have been changed. Two of the things that they did change (and which in themselves break most ASM stuff) are:
1. The RAM is actually located in the first 256K of address space (0x000000 to 0x03ffff) but on the regular TI-89 you could access "ghost space" beyond this (such as 0x040000 to 0x07ffff) which would wrap around and refer to the RAM that was meant to appear at lower addresses. Since the interrupt table at the very start of memory is "protected" against writing (though this is very easily switched off) some programs would write to the higher addresses which wrap around and access the table, but don't trigger the protection. This was also used to beat the size limit, since if the last part of real RAM is allowed execution, so is the ghost space.
Unfortunately this won't work on the TI-89 Titanium. Older versions of TI-GCC used the ghost space to set interrupts, although this has recently been fixed.
2. Also, TI has moved the starting location of the ROM to 0x800000. Many programs (included TI-GCC ones, until this was recently fixed) would try to find the start address by reading the function table and ANDing with 0x600000. Now this has to be changed to 0xe00000 to accomodate all version. Only one character of source to change, but will still break without it. Since calculating this is often part of HW version checking (necessary for grayscale among other things), programs not aware of the TI-89 Titanium may assume the calculator is HW1 (meaning grayscale won't appear correctly) or perhaps even crash.
Fixing programs should be easy in most cases, but will need to done separately for each program. This could be a problem if the author is no longer around and source code is unavailable. Some work has been done on automated patchers but I don't think they are completely effective yet.
|
Reply to this comment
|
30 April 2004, 01:08 GMT
|
|
1 2 3 4 5
You can change the number of comments per page in Account Preferences.
|