TI Releases ROM v1.15 for the 83+
Posted by Nick B. on 26 August 2002, 05:52 GMT
OS 1.15 has magically become available for the 83+. We're told that this version adds two features: TI-keyboard support and improved support for the CBL2 on the Silver Edition.
If either of these things apply to you, or you complusively need the latest and greatest thing, visit the TI store and select the appropiate subsection.
|
|
|
The comments below are written by ticalc.org visitors. Their views are not necessarily those of ticalc.org, and ticalc.org takes no responsibility for their content.
|
|
Re: TI Releases ROM v1.15 for the 83+
|
Konstantin Beliakov
(Web Page)
|
ehem...first post :)
anyways, i'd get the latest update for my 83+ even tho i almost don't use it after i got my 89. it'd be cool to have clock on an 83+ like on 89/92 after the new AMS!
|
|
26 August 2002, 06:10 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
PolarDPres
(Web Page)
|
pot, and after those post, I am quitting, no I wasn't high when I posted that though, dot.tk site stats said a saudi had visited my site, and Im from the US.
and purple shampooer wasnt me
and goats are an inside joke with my friends, one of my friends was caught by his mom looking at well, goat porn, dont ask, I dont get it, we just make fun of him.
|
|
5 September 2002, 20:33 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
Benjamin Moody
|
But suppose you set the timer to its lowest (8hz, right?) So you'd only need to check every 32 seconds. Now, the update routine is very short:
in a,(timerctl)
and 4
ret z
ld a,1
out (timerctl),a
ld a,(mytimer)
inc a
ld (mytimer),a
ret
(or we could test for overflow, update next timer, whatever)
Nice programs will let the interrupt routine do this. Mean programs won't. To support the less nice programs, we could simply add the routine into, say, fastcopy, or some other library routine that we expect to be called fairly often. For new programs that don't want an interrupt, all they will need is to call TimerUpdate at some point during their main loops. Remember, it only needs to be called once every 32 seconds. That's a long, long time.
|
|
2 September 2002, 21:21 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
lord_nightrose
(Web Page)
|
Ok, you're right... I misread the copyright law... ripping does indeed fall under fair use. Just like recording a TV show does, too. However, if you have any emulated video games on your computer, you're breaking the law (not that I don't...). Video game ROMs do NOT fall under the 'fair use' policy. If you read the little warranty/license notes in the back of any video game instruction book, they stipulate that you cannot legally use the software if you attempt to make any sort of copy of it. Mainly because they're easy to distribute freely, and that is breaking the law. Now, if you have a ROM grabber for any old console system, and you make the ROM yourself, THAT is legal, as long as you only run one copy at once. However, simply having ROMs you have NOT made on your computer is NOT legal.
|
|
2 September 2002, 09:16 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
lord_nightrose
(Web Page)
|
CD keys are easy to crack because they're not often truly encrypted. It's not even a checksum, where the last 8 to 16 bytes or so of the total amount of data on the CD are converted to ASCII characters, because this would mean that every CD would work with the same key - and ONLY that key, since the total would never change. It's more likely that a CD key is based upon some math formula where the ASCII values of the letters/numbers in the key are multiplied, added, divided, subtracted, etc. by/to something, then the sum of these is run through some function. This method, obviously, could produce numerous working results, but you'd have to figure out the formula (which generally isn't too hard) to crack the key.
|
|
29 August 2002, 19:31 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
Michael Vincent
(Web Page)
|
WinZip is not encryption, it's compression. I'm not sure which algorithm exactly it uses, but a common (and really simple example one) is Huffman. You calculate the frequency that each possible byte value occurs in the data to be encrypted, and then make a tree with the most often at the top, and the least common down off many branches...The algorithm has you take the two least nodes, combine them, add together, and some other trivial steps. Anyway, when you decrypt you read one bit at a time, and go left on the tree for 0, and right for 1, until ending up at a value.
Encryption also uses algorithms, but relies on stuff such as data-dependent rotations and secret keys, in which you depend upon having a password/key no one else has, and the fact that you rotate bits dependent on the data to be encrypted. There's also stuff like S-boxes to increase randomness. If you are interested, you can download an encryption application I wrote for the TI-83 Plus at http://michaelv.org/programs/krolypto/ Don't be scared of the disclaimer about people in rogue nations :)
|
|
30 August 2002, 03:42 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
Torael
|
Eh.....I'm not sure, ask Michael.....I mean, the other, well known Michael, not me 0_o. Ehm, anyway, even if that did work, this way is far faster. You just...well, I think I'll let it remain a secret, you can figure it our for yourself. ;)
|
|
31 August 2002, 02:05 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
lord_nightrose
(Web Page)
|
It probably uses a modified form of a binary compression tree... basically, what this does is makes a list of all the characters used in a file (bytes are converted to ASCII), then maps them out on a binary tree (a data structure like what a family tree would look like upside down if each set of parents had only one child). In this way, you can start at the root and work your way down going left or right; each time you go left, you follow the '0' path, and each time you go right, you follow the '1' path. When you put all the 1s and 0s together as binary numbers, you've now created your own character coding system... and if the file's data doesn't use all 256 ASCII characters, this method will compress the data.
For example:
Take the word 'moonshine'. You could map it out as:
____s
__o
____h
m
____i
__n
____e
Then, the letters are as follows:
m='1'
o='11'
n='10'
s='111'
h='110'
i='100'
e='101'
and moonshine can be read as '111111011111010010101'
which is a lot smaller than the binary code for each of the letters in moonshine. The compressed version is 21 bits (not even 3 bytes), and the original would be 72 bits (9 bytes). Obviously, 21 is less than 72.
I'm not sure if I have this exactly right... because the way I've said it could make decoding a problem. Ah, well... you get the general idea.
|
|
30 August 2002, 18:46 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
lord_nightrose
(Web Page)
|
Hence, what I just said! That's the problem with my method. There IS a solution... like I said... "I think the tree is actually built in a way that all the
letters are on leaf nodes (no child nodes), meaning that whenever you hit a letter it *HAS* to be the right one (since there are none beyond it)." Here's a
much better example of this:
m
X/
/ \o
/
| n
/X__/
/ \s
X
\ h
\X_X/
| \i
| e
\/
\X
Notice that none of the letters have any child nodes. (an 'X' is a node with a NULL value):
m = 111, o = 110, n = 101, s = 100, h = 011, i = 010, e = 001
which are the decimal numbers 1, 2, 3, 4, 5, 6, and 7. Moonshine is encoded as:
111110110101100011010101001
Only 27 bits. Far less than the original 72.
To decode, go back along the tree, guided by the bits, until you reach a leaf node.
1... node linked to n/s & m/o nodes
11... node linked to m & o nodes (the 0 DOES matter, so you can distinguish 'h' from '0')
111... m node!
The process continues until you reach the end of the bits. Eventually, you come out with 'moonshine'.
The reason compression works so much better with plain text documents is that they tend to use a very predictable set of characters: A-Z, a-z, 0-9, and
punctuation/accented characters. Even if there are others out of these ranges, they will add very litte to the compression map. A bitmap compresses
similarly, because it uses very repetitive pieces of data whenever large chunks of identical pixels are near each other.
With more complex files (such as .EXE files), the data stored is more likely to use characters not normally found in a text file. Therefore, not only will
the compression map be bigger, but the file will compress less as a result.
Hope this helps explain what I meant!
|
|
2 September 2002, 09:44 GMT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: TI Releases ROM v1.15 for the 83+
|
Benjamin Moody
|
Some bits you read will cause you to get a character, and some will cause you to read the next bit.
Here is roughly how we would Huffman-compress "moonshine":
* We find the freqency of each letter, and sort them.
o = 2
n = 2
m = 1
s = 1
h = 1
i = 1
e = 1
* The two least common are combined, so i and e become (i,e). (i,e) has freqency 2, so it is now the most common letter.
(i,e) = 2
o = 2
n = 2
m = 1
s = 1
h = 1
* We repeat until we have a complete tree: ((n,m),(s,h)),((i,e),o)
* Now, we code
n as 000
m as 001
s as 010
h as 011
i as 100
e as 101
o as 11
to get
001 11 11 000 010 011 100 000 101
or
00111110 00010011 10000010 1
So if we read 11, we don't need to get a third bit, because o is a complete tree itself, equivalent to any other pair.
While this isn't the best example, you can see that since o is more common, it is written in only 2 bits, while the other letters take 3 bits each.
|
|
31 August 2002, 20:33 GMT
|
|
1 2 3 4 5 6 7 8 9 10 11 12
You can change the number of comments per page in Account Preferences.
|