This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - thepenguin77
16
« on: November 21, 2011, 06:19:13 pm »
I need some chess sprites in 3 color gray for my title screen. I meant to add these a long time ago, but I never got around to it.
For the actual pictures, they need to be about 25x50 (if you've ever played my chess game, they need to fit on the sides) and they need to be in the colors, dark gray, light gray, and white, with a black background.
You can make whatever piece you want as long as it's not a pawn, and preferably it should be the white piece. I'll need two different pieces.
Also, if it means anything to you, I hope for this program to become quite popular. (TI-Chess is in the toplists on ticalc.org, so since this is roughly equivalent on the 84+ scene, we should expect a similar result.)
Edit:
I am working on adding them myself, but I suck. I am not artistic at all.
17
« on: October 21, 2011, 05:53:11 pm »
I was looking through starfox when I saw some code that used DJNZ in an unconventional way, this made me think about how useful it is, so here are some things I just thought of.
On this first one, you're going to say, "well duh," but I bet you don't do it.
Let's say you want to see if A==1:
dec a
jr nz, AWasnt1
You could replace it with this for only 1 extra t-state:
ld b, a
djnz AWasnt1
One benefit of this is that you don't destroy A. Now before you start complaining about that 1 t-state, just remember, if you manage to put your result into B rather than A, this routine becomes 3 t-states faster.
Here is another common code structure that I run into a lot:
ld a, (hl)
dec a
jr nz, not1
...
jr final
not1:
dec a
jr nz, not2
...
jr final
not2:
dec a
jr nz, not3
...
jr final
not3:
dec a
jr nz, not4
...
jr final
not4:
...
final:
Why not replace it with this, which is both faster and smaller (you don't need the jumps if you can leave b at 0):
ld b, (hl)
djnz not1
...
not1:
djnz not2
...
not2:
djnz not3
...
not3:
djnz not4
...
not4:
djnz not5
...
not5:
final:
Finally, this one is a bit more of a stretch, but you can use B as a flag byte, take for instance this byte plotter:
;######################################
;plot a byte
;a = byte
;b = inverse 1 = yes, 0 = no
;de = xy
plotAByte:
ld c, d
ld d, 0
ld h, d
ld l, e
add hl, de
add hl, de
add hl, hl
add hl, hl
srl c
srl c
srl c
ld e, c
add hl, de
ld de, plotSScreen
add hl, de
djnz inversing
or (hl)
ld (hl), a
ret
inversing:
cpl
and (hl)
ld (hl), a
ret
Also, while it's not a new idea today, I have used DJNZ in weird ways before, I typically do it when unpacking bytes from storage. This routine is from zStart and pulls a name out of storage from 6 bytes to 8 bytes. I use B as a bit counter.
pop hl
ld ix, op1+1
ld bc, 8*256+6
ld d, 8
xor a
unpackNameLoop:
rr (hl)
rra
djnz notNextUnpackByte
inc hl
ld b, 8
notNextUnpackByte:
dec c
jr nz, unpackNameLoop
ld c, 6
rra
rra
ld (ix), a
inc ix
xor a
dec d
jr nz, unpackNameLoop
18
« on: October 17, 2011, 04:16:50 pm »
Current VersionFirst of all, I wrote this axiom because I've heard that CrabCake doesn't really like the newer versions of Axe. So if it still works, then I am sorry hot_dog. I also wanted to write this though so I can finally use port (25h) which I spent a long time trying to discover. The goal of this axiom is exactly what the goal of CrabCake was, to allow you to use all of the memory in the calculator for your program to run. The way I am doing it is completely through ports, which means that there shouldn't be any side effects at all. In fact, you don't technically have to undo these changes, though you probably should. Since runer told me that we don't want to remake a remake, I'm not even going to post the Axiom yet, instead, I'm going to post the code so that if anyone sees any optimizations, they can tell me. One important thing that I am taking into consideration is that I made a crazy small flash unlock routine that only works on non-83+BE calculators, so I have two versions of the axiom. Also, I picked Fcdf( as my token, if you don't like it or have a better one, I'm all ears. Fcdf()r - Currently 76 bytes (non-83+BE version) rVersion:
scf
REP_NEXT
call unlockflash
REP_NEXT
call rVersionEnd
or a
unlockFlash:
di
in a, (06)
push af
REP_NEXT
ld (saveSP), sp
ld sp, $82AB+$4000
ld a, 1
out (05), a
rrca
ld i, a ;$80
dec a
out (06), a ;$7F
in a, (02)
bit 5, a
ld a, $C3 ;jp
REP_NEXT
ld hl, returnPointz
_84Plus:
ld ($80C8), a
ld ($80C9), hl
jp nz, $4528
_83PlusSE:
ld ($80FE), a
ld ($80FF), hl
jp $4276
returnPointz:
saveSP equ $+1
ld sp, 0000
xor a
out (05), a
pop af
out (06), a
ld a, $10
jr nc, wasUndoing
xor a
wasUndoing:
out ($25), a
bcall(_flashWriteDisable)
ret
rVersionEnd:
Fcdf() - 124 bytes (all calculator models) allVersion:
scf
REP_NEXT
call doIt
REP_NEXT
call allVersionEnd
or a
doIt:
in a, (6)
push af
push af
REP_NEXT
call unlockFlashz
in a, (02)
rlca
jr c, regularUnlock
ex de, hl ;HL is too close to SP
ld (hl), b ;b is zero
pop af
ld a, $1F
jr c, notLocking
ld (hl), a ;should be $0F
notLocking:
dec hl
out (06), a
out (05), a ;should be 7
call $46D8 ;hack, works on 1.00 and 1.01
push af
regularUnlock:
pop af
ld a, $10
jr nc, wasUndoingz
xor a
wasUndoingz:
out ($25), a
finishUp:
pop af
out (06), a
bcall(_flashWriteDisable)
ret
UnlockFlashz:
;Unlocks Flash protection.
;Destroys: pagedCount
; pagedGetPtr
; arcInfo
; iMathPtr5
; pagedBuf
; ramCode
di
REP_NEXT
ld hl, returnPoint+$8214-$81E3
ld de, $8214
ld a, e
ld (arcInfo), a ;should be 08-15
ld (pagedCount), a ;just has to be over 2
ld bc, $8214-$8167
lddr
ld (iMathPtr5), de ;must be 8167
ld iy, 0056h-25h ;permanent flags
add a, e
ld (pagedBuf), a ;needs to be large, but under 80
REP_NEXT
call translatePage
ld hl, ($5092)
ld a, ($5094)
REP_NEXT
call translatePage
ld a, $CC
cpir
dec hl
jp (hl)
returnPoint:
ld hl, $0018
ld (hl), $C3 ;dummy write
flashWait:
ld iy, flags
djnz flashWait ;wait for write to finish
add hl, sp
ld sp, hl
translatePage:
bcall(_NZIf83Plus)
jr z, not83
and 1Fh
not83:
out (06), a
ret
allVersionEnd:
I had to mess with brandonW's routine in this one a bit due to the way axe handles addresses. So, any optimizations? Edit: Cut a byte off the normal routine. Chopped off 11 more. Another 4 byte the dust. Fixed a glitch due to the 4 byte cut. 3 More. 1. 11 again Edit2: Before new system - 162. After - 123
19
« on: October 01, 2011, 01:47:39 pm »
 Sometimes the text box disappears. Refreshing the page fixes it. Edit: This is only since the update. It didn't used to happen.
20
« on: September 18, 2011, 01:27:11 am »
A while ago when I was making my boot code 1.03 exploit, I was looking through the app security code when I found absolutely horrendous code. The whole system of app trials appears to be written by someone who has been programming z80 for less than a week. The worst part though is that this person was assigned to write code that protects paid apps and is run on a privileged page. But of all the app trials code, this one routine just sticks out as the worst TI code I've ever seen.
Here it is in it's entirety:
transformA:
push bc
ld c, 11h
sub c
jp nc, loc_4F03
or a
adc a, c
cp 0
jr z, loc_4F03
cp 1
jr z, loc_4F03
ld b, a
dec b
ld a, 2
loc_4EFA:
sla a
djnz loc_4EFA
ld b, 1
sub b
jr loc_4F05
loc_4F03:
ld a, 0
loc_4F05:
pop bc
ret
First off, what is the purpose of this routine? It is a really complicated way to calculate the number of trials an app should have, I'll show the code that calls it at the end. But let's try to figure out what this routine does. (To be honest, I didn't figure it out until just now.)
The expected results are given by this table:
if A = 0-16 result = 2^A - 1
if A >= 17 result = 0
However, since the result is returned in A, the real table is:
if A = 0-8 result = 2^A - 1
if A >= 9-16 result = 255
if A >= 17 result = 0
Now, let's break this down and see where they went so wrong.
transformA:
push bc
ld c, 11h
sub c
jp nc, loc_4F03
or a
adc a, c
When you see this, your expected response should be "wtf." What are they doing? First off, why don't they just do CP 11h \ JR NC, loc_4F03? Then, why do they use ADC? I honestly believe the person who wrote this code didn't know that ADD existed.
cp 0
jr z, loc_4F03
cp 1
jr z, loc_4F03
ld b, a
dec b
ld a, 2
Again, horrible. CP 0 is a no. CP 1 is acceptable, but DEC A is preferred. And would you look at that, they DEC A anyways!
loc_4EFA:
sla a
djnz loc_4EFA
ld b, 1
sub b
jr loc_4F05
They actually did the loop correct, which is a surprise. But what on earth are they doing at the end. Again, I don't think this programmer knew that you are allowed to do actions to A, like ADD and SUB. But the worst part is that they could have used DEC A, but what really sets this apart is that they have already used DEC once! It's not like they didn't know it existed.
loc_4F03:
ld a, 0
loc_4F05:
pop bc
ret
They finally wrap it up with this. XOR A would be preferred, but the programmer probably didn't know what XOR does.
For comparison, here's how the routine should look:
transformA:
or a
ret z
cp 11h
jr c, notOver17
xor a
ret
notOver17:
ld b, a ;b is trash anyways
ld a, 1
shiftLoop:
add a, a
djnz shiftLoop
dec a
ret
Ok, but it doesn't stop there, here's the code that calls it.
call getCertByte
loc_4E55:
push af
ld b, 9
sub b
jr c, loc_4E6B
pop af
ld b, 8
sub b
call transfromA
ld d, a
ld a, 8
call transformA
ld e, a
jr loc_4E72
loc_4E6B:
ld d, 0
pop af
call transformA
ld e, a
loc_4E72:
It should be noted that LD A, 8 \ CALL transformA is the equivalent of LD A, 255.
Well, I hope you enjoyed that. Hopefully this will help to explain the dislike of TI that the more advanced assembly programmers share. It is code like this that causes Err:Version and Err:Bad Address, and the OS is full of it.
Edit:
Hey, what an awesome post to be number 1000.
21
« on: August 29, 2011, 10:16:50 am »
This is a guide for people for whom TI-Connect is not working, TI-Connect can't find their calculator, TI-Connect is giving strange error messages, TiLP screwed up your TI-connect setup, or TI-Connect is just not working correctly via USB with their 83+, 84+, or their 84+SE / 84+ Silver Edition on Windows XP, Window Vista, or Windows 7. (Enough key words) First and foremost, you have to realize that TI-Connect errors mean nothing. What the error says, and what actually went wrong are usually completely different. Here are the things to try if you get an error message:- Try clearing RAM (2nd, +, 7, 1, 2)
- Try new batteries (this will fix 90% of cases)
- Check to make sure that your variable name doesn't include illegal characters. For programs, this is anything besides uppercase letters and numbers. (The real name, not the Windows name)
- Check to make sure that you are actually sending the correct file format. .83p -> 83, .8xp -> 83+, 84+ and 84+SE
- Check to make sure that TI-connect is actually recognizing your calculator as the correct calculator
- Make sure that your calculator has enough free memory. If it does, but just barely enough, you might have run into the problem of the memory not being continuous. To solve this, send all your programs to your computer and send them back from biggest to smallest.
On a side note, when it asks you to select a cable, if you are using usb, none of those are the correct choice, so you'll just have to wait for your calculator to show up. If none of this works, then it's time to have some fun. At any point during the following list you can stop to see if it works, just remember that you'll have to redo all of the previous steps if it doesn't work. Almost flawless fix method:1. Open Device Manager (Control Panel>System>Devices>Device Manager) 2. Plug your calculator into a usb port that you know you've plugged it into before. 3. Find your calculator on the Device Manager list, usually under LibUSB devices 4. Right click>Uninstall 5. Repeat 2-4 for any USB port you may have plugged your calculator into. 6. Uninstall TI-Connect through windows 7. If you are on a 32 bit operating system go to C:\WINDOWS\System32\DRIVERS\ and delete libusb0.sys. (It's a driver) If you are on a 64 bit operating system, I've never had to delete the drivers, but they are: silvrlnk.sys and tiehdusb.sys. 8. Experimental (though, unlikely to break anything): If you have previously installed TiLP, go to C:\Program Files\Common Files\LPG Shared\drivers\usb\ and delete anything with a .inf extension. 9. Restart your computer 10. Reinstall TI-Connect And it should work. If it doesn't work, you probably have something else going on since this basically removes all traces of TI-Connect. It will even make TI-Connect work after you've installed TiLP. At this point, you should probably start a topic on this website explaining your problem. (Don't contact TI Cares as they are absolutely no help) If you are going to be using TI-Connect a lot, you might want to think about buying a Silver Link cable. You can find them at BestBuy for around $15 (at least you used to be able) and they are much more reliable than direct USB. One end of the cable plugs into your usb port, and the other plugs into the I/O port on the calculator. A final note about why changing your batteries fixes almost 90% of cases. The TI-84 was designed to run on 3.3V, this means when you batteries are low, they are down around 3.4V. But, USB will accept a voltage no lower than 5V. See the problem? If your calculator is running at 4V, it will be perfectly content and tell you that your batteries are fully charged, but when you go to use USB, it's not going to work at all and TI-Connect will give you "Error: Access Denied" or similar. Rechargeable batteries have also cause a lot of troubles in the past because of the whole 5V issue. Rechargeable batteries don't always charge to the same voltage as standard alkaline and this means that even fully charged batteries may not work. Update 4/16/2013I believe (though currently untested) that if you get the error where TI-Connect asks you to locate libusb0.sys, you can solve it by deleting TiLP's .inf files. (Step 8 ) The exact wording on this error is: The file "libusb0.sys" on TI-84 Plus USB Device Install Disk is needed Type the path where the file is located, and then click OK. Also, since they are really hard to find, here is a TI-Connect driver download, with tiehdusb.sys and silvrlink.sys in a zip. TI-Connect Drivers (32 bit and 64 bit):TI's Official PageOmnimaga Mirror (in case TI's page disappears) Last update: 7/7/2014
Still valid as of: 7/7/2014 DO NOT POST IN THIS THREAD FOR TI-CONNECT HELP, MAKE A NEW ONE INSTEAD
22
« on: August 28, 2011, 03:12:31 pm »
So... it looks like they nerfed the free version and took out z80. Sorry about that...This isn't exactly breaking news, but I thought people should know about this. IDA v5.0 is free now and is by far the best way to disassemble OS's and files, the reason it's so good is simply because you make changes along the way. Here is the download page for IDA. A good way to start with IDA would be to disassemble your boot code. To get your boot code, take the .8xv that Rom8x gives you and cut off the 8xv data up front. The last two bytes you will remove will be $00, $40 and the first one you will save will be $3E. You'll also want to take off the two byte checksum at the end. Once you have that, go into ida, X out the window that pops up and open your .bin file. From there, select processor = Zilog z80 and set 0000-7fff as rom and 8000-ffff as ram. Then set the loading address to $4000 and have fun. After you've gotten used to the feel of IDA and now understand the purpose of the boot code better, you can try to disassemble the OS. The problem with OS's is that they need to be broken up into several pages. You can do this manually, or you can use BrandonW's Pterodactyl which will do it for you. After you have the pages, just load each on individually and start disassembling. Also, with Pterodactyl, it will make a .idc file for each page. If you run that on the correct page, it will mark ram with the labels in ti83plus.inc as well as marking OS routines in the code. Well, have fun. Hopefully this will lead to a greater knowledge of the operating system and perhaps a few more cool projects in the future. (It might also show you why Ti sucks at coding  )
23
« on: August 23, 2011, 05:54:25 pm »
In short, this is the boot code 1.03 hack. When boot code 1.03 first came out, I searched pretty hard for an exploit that would allow unsigned OS's to be sent to the calculator. I ended up disassembling the entire boot code only to come up short. So I figured it wasn't possible. But then, brandonW said that he had found a way to do it, but of course, was not going to tell anyone (for safety reason, the same reason I'm releasing this so late.) This energized me to look through the boot code, and sure enough, I figured out how to do it. But guess what? Brandon and I had come up with entirely different ways to beat the boot code. This is actually really cool because it means we are covered the next time TI releases an boot code. So, we should be able to downgrade operating systems for quite some time. The reason I had to wait so long to release this was so that it would not be easy for TI to change their boot code to beat my exploit. I think now is a good time to release this because TI has already made their supply of calculators for the 2011-2012 school year and it's about this time of year that people will start looking for a way to downgrade. And actually, I'm not even sure that TI will be able to reverse engineer my exploit once they find out about it, but that's another story. So, here is the patcher: This is just an extension of my old AboutNam, the code has been finished for several months now, I just had to wait to release it. Here's what the exploit does: - Allows unsigned OS's (512 bit RSA and 1024 bit RSA)
- Allows unsigned apps
The cool part is that this exploit works on all boot codes all the way back to the 83+, so feel free to use it there. And allowing/disallowing is as simple as selecting "Unsigned OS's" vs "Signed OS's." While you're at it, you might as well put your name in the certifiacte :D As far as side effects go, here's what I've noticed: - Validation of OS's in boot code 1.03 takes ~5 minutes less :D
- If the unsigned OS's are selected, the calculator will finish receiving the OS and reboot without telling the sending calculator/Ti-connect that it has finished. This is because I intercept control before the final confirmation packet is sent (which is after validation) and I have no way to tell whether the OS was received via USB or I/O. A very simple work around is to just close Ti-connect. When sending from another calculator, the calculator will just say Error in Xmit, so there's really no problem there.
- The above is also true for receiving apps with unsigned apps enabled
- When you run this program on an 83+BE, it will clear ram when it's done. I did this on purpose.
- If you always use unsigned apps, you'll have no idea whether the apps will actually work on other calculators (not really a side effect)
If you want a copy of the source, just PM me, I'll be happy to send you a copy as long as you are: not TI, or are not going to send it to TI. In fact, it actually makes me happy when people look at the source, so don't feel at all like it will annoy me. I'd attach it, but like I said, I want this exploit to remain valid for a while. Lastly, if you are going to run this program from a shell (yes you can), be sure that the program is archived. This is because it manually deallocates itself and jumps to the OS, which means if it's in ram, it's essentially deleting itself. If you run it from TI-OS, it will just run like a normal program. Why does it deallocate itself you ask? Because I encrypted it :D Edit: Why do you need this?If you don't understand any of the above information, then the only reason you need this program is to downgrade your calculator from OS 2.55 to something else if you have boot code 1.03. First off, your calculator won't have boot code 1.03 unless you bought it within the past month. Secondly, to check, press [Mode][Alpha][Ln]. If it does not say BOOT Code 1.03, then you have nothing to worry about. The reason you would run this is because TI added in anti-downgrade protection in the boot code that would only allow you to run OS's 2.55 and higher. Of course, some people won't want to run that OS, so run this and you'll be able to downgrade.
24
« on: August 11, 2011, 07:38:41 pm »
We've been needing this for a long time, so I finally made it. http://wikiti.brandonw.net/index.php?title=83Plus:OS:Secret_Key_CombinationsI feel wikiTi is a better location than a post since over time, a post will fade away into page 2, then page 3. Looking at that page, TI has some favoritism for the Swedish/Norwegians because with press to test, they don't delete their languages. Also, Mem Cleared for Singapore doesn't leave behind any language apps.
25
« on: July 25, 2011, 10:08:06 pm »
New Version down belowI've seen way to many people getting their archives corrupted and losing all of their hard work lately, so I figured it's time for a solution. Normally when your archive is corrupted, you can't boot your calculator. The only way to do it is to hold CLEAR and turn it on. The problem though is that all of your programs in the archive will not be listed in the program menu, which means that they can't be sent to your computer. The only way to make them show up is to ram clear, but that will crash since your archive is corrupted. So, what I did was to make a program that parses the archive and rebuilds the vat. I tried to cover every possible way that would make the calculator crash, so this should work every time. Then once your programs are listed on your calculator, you can send them to your computer and clear mem, fixing all of your problems.  The steps to make this work are pretty easy: 1. Clear Ram while holding clear 2. Send this program 3. Run it with Asm( 4. Send all your variables back to your computer 5. Clear Mem Here are the errors that I protect against: - Oversized arc header size
- Undersized arc header size
- Garbage archive data
- Programs that cross sectors
- Zero length names
- Names longer than 8
I think these are really the only things that can go wrong with an archive entry, if anyone thinks of any others, tell me. One of the big ways I protect against random garbage is by only accepting appVars, programs, protected programs, and groups. It is highly unlikely that a random archive garbage will claim to be one of those variables as well as having a names that is between 1 and 8 characters. Here's the program with the source, the more people who look at the source, the more holes in it we can find, so look at it. ;D
26
« on: July 17, 2011, 06:14:05 pm »
 Here's what I did. Go to the reset ram menu, (2nd, +, 7, 1) and press 2, let go of 2, and hold clear really fast. If you did it right, your archive will appear to be empty. Then, just do the classic left + right + ON, and enable press to test. Everything will look normal. But after a quick ram clear, your archive is back including your groups. This same trick can be used to: - Protect your programs from 5+8+ON
- Protect your programs from 2+8+ON (Singapore)
- Protect your programs from the entire Reset Ram>Archive menu, (2nd, +, 7, right)
I know I've already made OS patches to beat it, but the key here is that this doesn't require OS patches. So at least now, if you ever get stuck in a weird situation, you can get by without deleting your groups. If you're lucky, you might even be able to trick your teacher with the Clear Arc vars too.
27
« on: July 08, 2011, 12:46:55 am »
That's right, I'm keeping with tradition of names by using Tru, but I'm also breaking the mold by making a 6 letter app name. I think this video should sum it up. Basically, I started this a while ago, but then USB called me and I stopped working on it. However, seeing Sircmpwn playing music from his flash drive energized me to finish this. From the classical estimates, this should be impossible, grayscale takes 50% of the processor while sound takes 90%, so how did I do it? Triple threading!!! I am actually doing 3 different things at once on this program. I am playing sound, updating grayscale, and copying new video data, all at once. I think one of the humorous parts of this is the insane data rate. The video runs at 10 fps, 10 * 768 * 2 = 15,360 Bytes/s. The sound runs between 17,500 Bytes/s and 20,000 Bytes/s. So that's a total of 34KB/s. That means it burns through Mirage in .5 sec! At this rate, the 84+SE can hold about 45 seconds and the 84+BE can hold around 15. But hey, this is full video on the calculator. I'm also trying to make the conversion process user friendly this time. I'm terrible at directshow and such, but so far, I have the inputs to my program as <soundfile.wav> <videoFile.wmv> where the sound is a .wav and the video file is a .wmv at 192x128 and 30 fps, which is relatively easy to do. I wanted to let you input 1 file and your cpu speed, but I couldn't even resize the BMP's for the video through Windows's routines, I had to do it by hand From an asm standpoint, this program is insane. First off, you take a grayscale video program. I am displaying a grayscale buffer at 60Hz and copying in new data at 10Hz. That's nothing special, but then I overlay sound interrupts running at 40Khz over top of that. These interrupts lower my base cpu speed to 500KHz, which is just enough time to copy in a new picture  Better yet, for the first time, I'm using all 3 crystal timers, 2 of which are producing nested interrupts. And you know, since it's me, perfect grayscale. It's not adjustable yet, but it will be. In my current setup, I have video and audio looping independently, in the numa numa, assuming you are using the right processor speed, the video and sound are supposed to be the same length, however, the sound ends up being slightly longer since you can't interrupt instructions (which also causes the white noise.) But, I might be able to adjust for that. I could make them loop together, but I'm setting up for Nyan Cat Here's the source and some samples of this video. I included samples clocked for 15Mhz (wabbit), 15.65Mhz, and 16.3Mhz (mine). So use them if you want. I just have two warnings, 1) I don't think these apps will validate on the calculator, I used a workaround, but it does take a 1/2 hour to send, 2) these sound dreadful in wabbitemu, there's not much that can be done about that. So have fun. (If you can't figure out how to run it and crash your calculator, I lol at you) Edit: New download link
28
« on: June 30, 2011, 11:28:18 pm »
This topic is mostly for documenting stuff we find so it doesn't all stay on IRC. Keep discussing on IRC, but if any important discoveries are made, we'll put them here. All this information was provided by reflashing my boot code: (thanks to brandonW for the flasher)    At boot, we now know that the memory mapping is as follows: 0000h - 3FFFh: Page 7F - boot code execution 4000h - 7FFFh: Page 00 8000h - BFFFh: Page 00 C000h - FFFFh: Ram Page 00 The way to return page 00 to 0000h is to execute on a page pointed to by port (06h). This is either the $4000h bank in memory map mode 0 or both the $4000 bank and the $8000 bank in memory map mode 1.
29
« on: June 28, 2011, 05:32:47 pm »
This whole process started a long time ago when FloppusMaximus unlocked flash on his calculator. Then came custom OS's, the key factoring, and finally modifying the boot code. This will remove almost all traces of TI from your calculator, but your not quite done, you still can't execute code >$C000. However, today, I managed to do it. I executed code all the way from $C000 to $FFFF on page 0. I was playing around with DrDnar's MicrOS preparing to do some boot code changes, when I got a little scared and decided to play around with the protected ports a little. I kept going down the line seeing what would change, and what wouldn't, when all of a sudden, writing to port (25h) crashed my calculator. After a little bit of experimentation, I figured out that any value higher than 17h caused a restart. Then I noticed that port (26h) also crashed my calculator, so after a bit more playing, I realized that any value lower than 1Ah would cause a reset. Why this actually happened caused me quite a bit of trouble. I started outputting different values to the ports and seeing what I could get to crash. I tried running all sorts of programs with these ports enabled and I wasn't really getting any results. But finally, four hours later, with lots of trial and error with StarFox, I realized that the programs would crash if they executed ram low in memory. A quick check with a RET placed at $8000 confirmed this and then I was off to test the limits. Setting port (25h) to 17h crashed when PC went below 9C00h. 16h crashed at 9800h. So obviously it is counting by 400h. I then did some testing with port (26h). 19h crashed at A800h and 1A crashed at AC00h. So again, counting by 400h. After a bit more testing, I realized that these ports are looking at the ram chip as a whole where page 00h comes first, then 01h, 02h, and so on and setting the upper and lower ram execution limits. So... Send 00h to port (25h) and FFh to (26h) and your calculator will never crash from PC execution ever again. For more details, see the newly updated wikiTi for ports 25h and 26h.
30
« on: June 23, 2011, 12:30:29 am »
This now works on 83+'s, check it outA couple months ago, I was talking to BrandonW about how I put my name on the about screen through OS mods. He said that was cool, but to do it the right way I had to put it in the certificate. He then told me how extremely hard it was and how many different things you had to get right to make it work. At the time, the just sounded scary so I didn't look into it. But now, I've been looking through the boot code for receiving OS's and I noticed that the OS headers are actually pretty simple. I then realized that the certificate uses the exact same format and it also wasn't that scary. So then, after a bit more disassembling, I added a few bytes to the certificate, and sure enough, there was my name on the about screen. The only problem was that there was a line called "Cert.Revision" which displayed garbage. So after a little tweaking I got that working. I was happy and started writing this program. I was going to add a certificate revision field, with a revision number subfield, and a about screen subfield with an about screen text group. But as I was looking more into the boot code. I realized that if I added these fields, I also had to store the keys in the certificate, otherwise, the calculator would refuse to receive any apps or OS's. After lots of trial and error with the keys and the format they needed to be in. (At first I had all the keys switched around and in the wrong format) and 5 failed CtlgHelp transfers and 1 failed OS transfer (I had to delete the certificate, but I was prepared for this.) I finally got it to work. Then, I spent a long time making sure this was the most secure program ever because I don't ever want it to glitch. (This includes sending 4 OS's and several apps to two separate calculators.) I should also mention that I made this program very forgiving. It doesn't assume anything. If you have brandonW's 0005 key installed on your calculator, this mod won't even touch it. It also has code to deal with things previously in the certificate that shouldn't be there. You can see this in the way that it lets you edit what you have already put in the certificate. Here is a list of the fields it adds: - 0300 Certificate revision - 0100 Certificate revision number - 0500 About screen data - 0510 About screen text - 0700 Key list - 0710 04 OS key header - 0730 04 OS key data - 0710 0A OS key header - 0730 0A OS key data - 0710 0104 app key header - 0730 0104 app key data - 0710 010A app key header - 0730 010A app key data And the end result:  So here's how you can do this. First, download BrandonW's CertTools and send GETCERT.8xp to your calculator. Then run it and transfer your certificate (appVar) back to your computer. It's a good idea to have a copy of your certificate on your computer anyways. (You don't have to do this, it's just a good idea) Next, send the attached ABOUTNAM.8xp to your calculator and run it. Select "Add Name". It will now ask you for a certificate revision number, you don't have a choice, you have to give it one. Then it will ask your for your about screen text, make that whatever you want. It will then install the changes and you can go check out your cool about screen. The best part, it is persistent through OS transfers. It is essentially permanent. There are only 3 ways to get rid of it: 1) run this program and select "Remove", 2) Send your certificate back with PUTCERT.8xp, 3) Delete the certificate. If the program instantly quits on you, that means that you either 1) are using an 83+ (I'm not sure if this will work exactly the same) or 2) have low batteries. If it quits while it is installing, that means it encountered an "F" size byte and figured it's just better to quit. This really shouldn't happen. So have fun, I made this program as secure as possible. I don't believe you could do anything to crash it, other than maybe pulling out your batteries. (Which is a bad idea) Edit, the picture wasn't working right:  Edit2: My files got orphaned.
|
Show Posts