As far as I know, nobody has yet written a routine to detokenize the output of the Axe input routine. I'm a bit surprised, because the routine is pretty easy to write. Below I have posted my implementation. It is rather large, because I just threw it together tonight and haven't optimized it at all. Maybe I will work on that tomorrow, maybe I won't. You could definitely shrink it by at least 10%---probably more like 30%---if you removed the local stack variables and did something more fancy.
UPDATE 14 January 2013: Fixed a bug in the Axiom, specifically a bug in the buffer overrun check. It was accidentally hard-coded for a fixed buffer size of 256 bytes because an arithmetic error. Also shaved two bytes off the routine.
Here's a sample program that just redisplays whatever you type in:
The Axe input command is small, but it returns data in the OS's tokenized form. As far as I know, there is no built-in system for limiting what the user can enter. The input command allocates a temporary variable in user memory to hold the user's input. This may or may not be an advantage for you. The temporary variable is a legitimate system variable, inasmuch as it has a VAT entry and is length-prefixed. However, the OS will automatically delete the temporary variable for you when your program ends, so you do not need to worry about leaking memory.
The Detokenize( command uses the String>Eqn( token as its key. The token is located in the Catalog and is not in any other OS menu. This routine is about 115 bytes.
Detokenize( takes three arguments: The pointer returned by input, a pointer to where you want to store your output, and the size of the output buffer. Detokenize( does not return any status information. If the detokenized string cannot fit into the output buffer, the last full token that fit will be the last token in the string. The output is zero-terminated, which is what the Axe Disp command expects.
It is not safe to point make the output overwrite the input. Many tokens expand to more than one character, so the detokenized text could overwrite the input token stream.
Detokenize( can also be used to detokenize equations, strings, BASIC programs, your Axe program's own source code, &c.
The input command creates a temporary variable in RAM. This command uses the CleanAll B_CALL to erase all temporary variables, including the one created by input. This is not necessary, but may be useful if you want to make sure the RAM is free so you can do other things.
The key for CleanAll() is ClearAllLists. This routine is 3 bytes.
This command is useful for parsing tokens yourself. It returns 0 (false) if the input byte is a one-byte token. It returns 1 (true) if the input byte is the first byte of a two-byte token. The high byte of the input argument is ignored. This wraps the IsA2ByteTok B_CALL.
The key for ISA2ByteTok( is Fpdf(, under DISTR. This routine is 9 bytes.
This command is useful for generating detokenized strings yourself. It calls the Get_Tok_Strng B_CALL to get the string for a particular token. The input is a POINTER to the token to get the string for. Thus, if A points to the token you are processing, you do Get_Tok_Strng(A) to get the string for A, not Get_Tok_Strng({A}). The string is stored into OP3 (address 848E in hex). The string is not zero-terminated. Instead, this routine outputs the length of the string.
The key for Get_Tok_Strng( is Fcdf(, under DISTR. This routine is 13 bytes.
I'm not opposed to the idea, but I'm pretty sure you're reading that wrong. It's not that execution is allowed on page 80, but that it would be allowed in the first kilobyte of page 82 if the execution limits did not wrap around at 32k (see port 21.)
aeTIos, you can create a comment with no text by just typing a semicolon. It's what I do.
I find that creating a simple program in Mimas to test something is faster than creating it on a computer and sending it over. Certainly, an in-system assembler is useful, if not always pleasant.
You might consider making the C000h limiter more flexible, by allowing one to define any address. This would be useful for making applications and for program only intended for the TI-83+SE/TI-84+/SE, which allow code up to 0C3FFh.
Validating takes a while on boot code 1.03 (which I'm guessing you have), iirc it can get upwards of 10 minutes
Just realized that, my bad.
You need to patch/downgrade your boot code. It's really quite funny: we only figured out that hacking the boot code was possible as a consequence of us researching ways to get around the new keys. Although, really, I've always felt that the best method would be to write an entirely new OS receiver, which we can do because there's a nearly unfixable bug in the OS. (According to BrandonW, fixing it would require removing the ability to send variables directly to the archive, or completely rewriting the entire variable receiving code.)
10: Sonic Genesis version I'm pretty sure 100% run means 100% ring run.
Sonic 2 (and not Sonic 1 or 3&K) will give you a 50,000 point bonus (which in turn gives you a 1-up) if you get every free-standing ring in an act. See my videos EHZ1, EHZ2, CPZ1, and CPZ2. Also see this TAS, which seems to have stolen my CPZ 1 and 2 routes.
It's a wonderful way to handle strings, as long as you have fewer than 256 of them. The assembly code for returning the string given its index is beautifully simple.
My worry is that the graph buffer is stored directly into Flash.
Highly unlikely. I doubt even TI is silly enough to do that. The 3.5 MB figure supports this: The TI-84+SE has 1.5 MB of user-available memory out of 2 MB. The TI-84+C SE is advertised to have 3.5 MB of user-available flash out of a probable 4 MB. The fact that the OS is still about 500 K in size suggests that they did not allocate 150 K of flash for a graphics back-buffer.
calc84 pointed out in IRC that 8000h will still need to map RAM, no matter what TI does. But I'm still guessing that port 6 will map flash in 00 to FF, and not map any RAM. Port 7 will either not function, not map any flash, or map only some flash, e.g. only the bottom half.
I mentioned this in IRC, but not in the forum: The TI-83+ uses a 512 K flash chip, the TI-84+ uses a 1 MB flash chip, and the TI-83+SE and TI-84+SE both use 2 MB flash chips. These chips follow a standard layout and use a standard command set. In the same family of chips is a 4 MB flash chip, which uses a similar command set. However, the boot sector break-down in the 4 MB family is different. The smaller chips break one 64 K sector into a 32 K sector, a 16 K sector, and two 8 K sectors; the 4 MB chips break one sector into eight 8 K sectors. This broken-up sector is termed the "boot sector" by the datasheets, and is either first or last sector; TI always selects the chips which break up the last sector.
Now for prediction time: In the TI-83+ family, the 32 K sector was used for the OS, the 16 K sector for the boot sector, and the two 8 K sectors for the certificate. In the TI-84+, they needed another 16 K of flash for the USB routines for the boot code. They kept the convention that the 32 K sector is used for the OS. So instead, they made one of the 64 K sectors a boot sector. So 48 K of flash is wasted. Had they used to 32 K sector for the extra USB boot routines, only 16 K would have been wasted. (BrandonW likes to point out that this would require rearranging some of the OS. I say, so what? It's within their power to do so.) My prediction is this: They will keep this silly layout, wasting 48 K of flash, instead of using some more of those aptly-named boot sectors.
Xeda, actually, I'm starting to suspect seriously my idea that they've completely eliminated RAM paging in order to allow the extra archive to map into pages 80-FF. So available RAM will continue to decrease.
More importantly:
Quote from: IRC
(4:54:01 PM) OmnomIRC: (O)<calc84maniac> 84 Plus C SE has no 3D graphing (4:54:06 PM) OmnomIRC: (O)<calc84maniac> CHALLENGE ACCEPTED
We're going to hold you to that. And we want color and lighting effects.
21 K of user memory, 154 K of video RAM. There is a serious fracking engineering WTF. Also, why is there a 3 K decrease in available user memory? Previously, TI has allocated new memory for new static OS vars in off-page RAM. Have they decided to eliminate that RAM entirely?
Quote from: FAQ
Is the TI-84 Plus C Silver Edition allowed on high-stakes exams?
Yup, the TI-84+C SE can be used on exams that will determine your ULTIMATE FATE IN LIFE.
On the comparison chart, they list a "MathPrint everywhere" feature. This suggests that pretty printing will be available in other edit buffer contexts. That's a definite UI improvement, but it will break some of our existing tools. TI's anti-hacking staffers must be nigh-orgasming.
Your OS should still be there. Pull a battery out and put it back in and the password prompt should come up again. If not, you can resend it only from another TI-84+ or TI-84+SE. Or, of course, you can use you computer. Resending the OS will never erase anything in the archive.
If the password prompt is still there, you will need to force a RAM reset to clear Krolypto from RAM (but not the archive, of course). First, remove all four AAA batteries. Then, get a little screw driver and remove the backup battery. Wait a few minutes and replace the batteries. The calculator should boot normally.
To erase the password, you will need to delete the hidden appvar the password is stored in. If you have Calcsys, just find the appvar and change the first byte of its name to an actual letter to unhide it. Otherwise, you can use this assembly language fragment to delete the appvar. Type it into a new program, and then run it using Asm( .
ld hl, name rst MOVE9TOOP1 b_call(_DelVarArc) ret name: AppVarObj, " calcdb2" Finally, using pi as your password is definitely easily guessable. There's a story in Surely You're Joking, Mr. Feynman! about a scientist who used e as his safe combination as Los Alamos where the atomic bomb was being developed. Mr. Fenyman guessed it and put notes in the scientist's safe to scare the crap out of him. Don't do it again.
Spoiler For Extract from the book:
During the summer after the war I had some documents to write and work to finish up, so I went back to Los Alamos from Cornell, where I had taught during the year. In the middle of my work I had to refer to a document that I had written before but couldn't remember, and it was down in the library. I went down to get the document, and there was a soldier walking back and forth, with a gun. It was a Saturday, and after the war the library was closed on Saturdays. Then I remembered what a good friend of mine, Frederic de Hoffman, had done. He was in the Declassification Section. After the war the army was thinking of declassifying some documents, and he had to go back and forth to the library so much -- look at this document, look at that document, check this, check that -- that he was going nuts! So he had a copy of every document -- all the secrets to the atomic bomb -- in nine filing cabinets in his office. I went down to his office, and the lights were on. It looked as if whoever was there -- perhaps his secretary -- had just stepped out for a few minutes, so I waited. While I was waiting I started to fiddle around with the combination wheel on one of the filing cabinets. (By the way, I didn't have the last two numbers for de Hoffman's safes; they were put in after the war, after I had left.) I started to play with one of the combination wheels and began to think about the safecracker books. I thought to myself, "I've never been much impressed by the tricks described in those books, so I've never tried them, but let's see if we can open de Hoffman's safe by following the book." First trick, the secretary: she's afraid she's going to forget the combination, so she writes it down somewhere. I started to look in some of the places mentioned in the book. The desk drawer was locked, but it was an ordinary lock like Leo Lavatelli taught me how to open -- ping! I look along the edge: nothing. Then I looked through the secretary's papers. I found a sheet of paper that all the secretaries had, with the Greek letters carefully made -- so they could recognize them in mathematical formulas -- and named. And there, carelessly written along the top of the paper, was pi = 3.14159. Now, that's six digits, and why does a secretary have to know the numerical value of pi? It was obvious; there was no other reason! I went over to the filing cabinets and tried the first one: 31-41-59. It didn't open. Then I tried 59-41-31. That didn't work either. Then 95-14-13. Backwards, forwards, upside down, turn it this way, turn it that -- nothing! I closed the desk drawer and started to walk out the door, when I thought of the safecracker books again: Next, try the psychology method. I said to myself, "Freddy de Hoffman is just the kind of guy to use a mathematical constant for a safe combination." I went back to the first filing cabinet and tried 27-18-28 -- CLICK! It opened! (The mathematical constant second in importance to pi is the base of natural logarithms, e:2.71828...) There were nine filing cabinets, and I had opened the first one, but the document I wanted was in another one -- they were in alphabetical order by author. I tried the second filing cabinet: 27-18-28 -- CLICK! It opened with the same, combination. I thought, "This is wonderful! I've opened the secrets to the atomic bomb, but if I'm ever going to tell this story, I've got to make sure that all the combinations are really the same!" Some of the filing cabinets were in the next room, so I tried 27-18-28 on one of them, and it opened. Now I'd opened three safes -- all the same. I thought to myself, "Now I could write a safecracker book that would beat every one, because at the beginning I would tell how I opened safes whose contents were bigger and more valuable than what any safecracker anywhere had opened -- except for a life, of course -- but compared to the furs or the gold bullion, I have them all beat: I opened the safes which contained all the secrets to the atomic bomb: the schedules for the production of the plutonium, the purification procedures, how much material is needed, how the bomb works, how the neutrons are generated, what the design is, the dimensions -- the entire information that was known at Los Alamos: the whole shmeer!" I went back to the second filing cabinet and took out the document I wanted. Then I took a red grease pencil and a piece of yellow paper that was lying around in the office and wrote, "I borrowed document no. LA4312 -- Feynman the safe-cracker." I put the note on top of the papers in the filing cabinet and closed it. Then I went to the first one I had opened and wrote another note: "This one was no harder to open than the other one -- Wise Guy" and shut the cabinet. Then in the other cabinet, in the other room, I wrote, "When the combinations are all the same, one is no harder to open than another -- Same Guy" and I shut that one. I went back to my office and wrote my report. That evening I went to the cafeteria and ate supper. There was Freddy de Hoffman. He said he was going over to his office to work, so just for fun I went with him. He started to work, and soon he went into the other room to open one of the filing cabinets in there -- something I hadn't counted on -- and he happened to open the filing cabinet I had put the third note in, first. He opened the drawer, and he saw this foreign object in there -- this bright yellow paper with something scrawled on it in bright red crayon. I had read in books that when somebody is afraid, his face gets sallow, but I had never seen it before. Well, it's absolutely true. His face turned a gray, yellow green -- it was really frightening to see. He picked up the paper, and his hand was shaking. "L-l-look at this!" he said, trembling. The note said, "When the combinations are all the same, one is no harder to open than another -- Same Guy." "What does it mean?" I said. "All the c-c-combinations of my safes are the s-s-same!" he stammered. "That ain't such a good idea." "I-I know that n-now!" he said, completely shaken. Another effect of the blood draining from the face must be that the brain doesn't work right. "He signed who it was! He signed who it was!" he said. "What?" (I hadn't put my name on that one.) "Yes," he said, "it's the same guy who's been trying to get into Building Omega!" All during the war, and even after, there were these perpetual rumors: "Somebody's been trying to get into Building Omega!" You see, during the war they were doing experiments for the bomb in which they wanted to get enough material together for the chain reaction to just get started. They would drop one piece of material through another, and when it went through, the reaction would start and they'd measure how many neutrons they got. The piece would fall through so fast that nothing should build up and explode. Enough of a reaction would begin, however, so they could tell that things were really starting correctly, that the rates were right, and everything was going according to prediction -- a very dangerous experiment! Naturally, they were not doing this experiment in the middle of Los Alamos, but off several miles, in a canyon several mesas over, all isolated. This Building Omega had its own fence around it with guard towers. In the middle of the night when everything's quiet, some rabbit comes out of the brush and smashes against the fence and makes a noise. The guard shoots. The lieutenant in charge comes around. What's the guard going to say -- that it was only a rabbit? No. "Somebody's been trying to get into Building Omega and I scared him off!" So de Hoffman was pale and shaking, and he didn't realize there was a flaw in his logic: it was not clear that the same guy who'd been trying to get into Building Omega was the same guy who was standing next to him. He asked me what to do. "Well, see if any documents are missing." "It looks all right," he said. "I don't see any missing." I tried to steer him to the filing cabinet I took my document out of. "Well, uh, if all the combinations are the same, perhaps he's taken something from another drawer." "Right!" he said, and he went back into his office and opened the first filing cabinet and found the second note I wrote: "This one was no harder than the other one -- Wise Guy." By that time it didn't make any difference whether it was "Same Guy" or "Wise Guy": It was completely clear to him that it was the guy who was trying to get into Building Omega. So to convince him to open the filing cabinet with my first note in it was particularly difficult, and I don't remember how I talked him into it. He started to open it, so I began to walk down the hall, because I was a little bit afraid that when he found out who did it to him, I was going to get my throat cut! Sure enough, he came running down the hall after me, but instead of being angry, he practically put his arms around me because he was so completely relieved that this terrible burden of the atomic secrets being stolen was only me doing mischief.
It's a great book. You should definitely buy a copy to read.
That's not as impressive as the ROM dump hack for the TI-81. I'd bet a large amount of money the exploit(s) were found by analyzing a ROM dump of the game and locating potential bugs, such as buffer overflow exploits. Moody had to do the ROM dump hack for the TI-81 without an actual ROM dump, so he had to make a lot of educated guesses.
It's TI's completely failed counter to the factoring of the OS signing keys. It shows that the current engineers in the educational department have no understanding of what happened.
Show Posts
