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.
Messages - thepenguin77
1
« on: March 18, 2024, 12:30:26 pm »
I think we're going to need the code of the IN program.
Do my programs at least work in isolation for you?
2
« on: March 17, 2024, 06:23:42 pm »
I do miss figuring out how the hardware works and reverse engineering the OS. I don't miss debugging asm code... Here's how to use the program that does accurate timing on the TI-84+ like startTmr: # Start the timers
Asm(prgmTIMESTRT)
# Store the elapsed time (at 1/128s resolution) into Ans
# -1 if an error is detected (timers disabled or system clock went backwards)
Asm(prgmTIMEIT)
Someone should do a whole bunch of testing on this to make sure it's accurate. I've tested all the special cases like 0 and 2^21 (where the final result requires 17 bits to be stored), and they work. But I can't guarantee this works always and forever. I'd probably recommend a basic program that asserts that the outputs from this program are consistently increasing at the same rate and then let that run overnight or something. Caveats: - If you change your system clock, this will be inaccurate
- If you let your calculator turn off, the timers are disabled.
- Running other programs that mess with the timers will break this.
The details: After playing around with the timers, I can see that timer2 get disabled the very first time it overflows which makes it totally useless. This check happens in the interrupt routine and there's no way to stop it. Timer1 and Timer3 don't get disabled as long as their control port has bit 1 set to 0 (they aren't triggering interrupts), so these are both safe to use as far as I can tell. Presumably they get used somewhere but I'm not sure where. The program works exactly as depicted in the python code above. There was a mistake in the original post but I've edited it to fix it. Nothing is too complicated, but coding this up in assembly is rough. I kept the full-precision of the internal clock, so in theory, this program can keep track of time for like 2^32 seconds. The program seems to take 0.0195 seconds to run from within TI-BASIC (just call TIMESTRT then call TIMEIT 10 times and divide ANS by 10). The program stores the timer values as soon as it starts, but whether the slowness is TI-BASIC starting the program or the floating point operations while returning the result I'm not sure. Code and programs attached. It ended up being around 300 lines and 400 bytes.
3
« on: March 07, 2024, 11:48:58 am »
A mention after like 10 years  ? I'm honored. Ski vacations have lots of downtime, you might be surprised how excited I am to actually have a real need to make a Ti84 program again. Here was my solution to this program, idk if it actually works since I haven't messed with the timers in years. The idea is set up 3 timers. Timer2 runs as 128Hz for the actual timing, but this loops every 2 seconds. Timer3 runs at 8Hz to keep track of Timer2. The TI84 clock runs at 1Hz to keep track of Timer2. Program 1: 46h -> (33h) ; 128 Hz on timer2
1 -> (34h) ; no interrupts but loop; does this work?
47h -> (36h) ; 8 Hz on timer3
1 -> (37h) ; no interrupts but loop
Store ports 45h-48h to somewhere secret in ram. MD5Buffer?
0 ->(35h); start timer2 in an infinite loop
0 ->(38h); start timer3 in an infinite loop (does this work?)
Timer2 overflows every 2 seconds. Timer3 overflows every 32 seconds. (Edit, checked in Calcsys, this totally works) Program 2: (this is in python because the asm code to do this will be hard to read) timer2 = (35h) - 1 # subtract 1 so that 255 is the highest value
timer3 = (38h) - 1
simple_elapsed = Compare 45h-48h with stored time to get seconds
# ok, the hard part is that the ti84 clock only has a resolution of 1 second
# we need to be careful if we're really close to 32 seconds
timer3_full_cycles = int( (simple_elapsed - 3) / 32 ) # 3 seconds is overkill
seconds_into_current_cycle_safe = (simple_elapsed - 3) % 32 ; if this is -3 it underflows to 29
if seconds_into_current_cycle_safe > 32 - 6:
if timer3 > 128:
timer3_full_cycles += 1
# timer2 does a full cycle every 16 ticks of timer3
timer3_elapsed = 255 - timer3
timer2_full_cycles = int( (timer3_elapsed - 2) / 16 ) # 2 ticks of safety
ticks_into_current_cycle_safe = (timer3_elapsed - 2) % 16
if ticks_into_current_cycle_safe > 16 - 4:
if timer2 > 128:
timer2_full_cycles += 1
timer2_elapsed = 255 - timer2
final_time = timer3_full_cycles * 32 + timer2_full_cycles * 2 + timer2_elapsed / 128
final_time -> ANS # how do you do this?
I think this code is buggy if you manage to call program 2 within 1/128 of a second of program 1. Should work otherwise unless I'm missing something. Things I vaguely remember and it would be cool if someone could verify them: A. One of the timers messes up TI-OS right? Is that timer1? B. How does one return a list in ANS (or even a simple number like above)?
4
« on: August 11, 2019, 05:43:31 pm »
Having some vital boot|system pages becoming non-executable was something i was considering, which could have happened easily with crappy code.
Like you said, port $24 is probably initialised if things go south, but when you're not sure of something in asm, paranoia is total awareness.
And an old chinese coder used to say "Never overestimate TI.".
EDIT : And even if such port $24 "repair" code exists, it's useless if it's located on a non-executable page itself. #CanYouSmellTheBrick?
It's pretty hard to brick a TI-84. Outside of hardware fault (which I think I saw once in 4 years), I think only brandonW has succeeded in permanently bricking a TI-84. Both he and I have temporarily bricked them by corrupting the certificate, but it's usually possible to fix this by buffer overflowing the boot code link-port receive commands and then clearing out the certificate. (His perma-brick was a maliciously crafted certificate so hardly possible to do by accident.) There's a new way we discovered to brick your calculator which would be to overwrite the boot code, but you have to be trying to do this and I doubt anyone's ever done it. But, onto, "what happens to port $24?". In some rather sketchy experiments where I did overwrite the boot code, I mapped out the starting values of all the ports. It turns out that when the calculator restarts (be it a battery pull or internal kill signal), all of the ports get reset to default values. You can find those values here. Also, the boot code initializes a bunch of stuff. Here's some code from boot code 1.03: ROM:41B5 loc_41B5: ; CODE XREF: ROM:41ACj
ROM:41B5 pop af
ROM:41B6 ld a, 2
ROM:41B8 out (2Dh), a
ROM:41BA call setupLinkHandler
ROM:41BD ld a, 17h
ROM:41BF out (29h), a
ROM:41C1 ld a, 27h ; '''
ROM:41C3 out (2Ah), a
ROM:41C5 ld a, 2Fh ; '/'
ROM:41C7 out (2Bh), a
ROM:41C9 ld a, 3Bh ; ';'
ROM:41CB out (2Ch), a
ROM:41CD ld a, 45h ; 'E'
ROM:41CF out (2Eh), a
ROM:41D1 ld a, 4Bh ; 'K'
ROM:41D3 out (2Fh), a
ROM:41D5 ld a, 0
ROM:41D7 nop
ROM:41D8 nop
ROM:41D9 im 1
ROM:41DB di
ROM:41DC out (21h), a
ROM:41DE di
ROM:41DF ld a, 8
ROM:41E1 nop
ROM:41E2 nop
ROM:41E3 im 1
ROM:41E5 di
ROM:41E6 out (22h), a
ROM:41E8 di
ROM:41E9 ld a, 29h ; ')'
ROM:41EB nop
ROM:41EC nop
ROM:41ED im 1
ROM:41EF di
ROM:41F0 out (23h), a
ROM:41F2 di
ROM:41F3 ld a, 10h
ROM:41F5 nop
ROM:41F6 nop
ROM:41F7 im 1
ROM:41F9 di
ROM:41FA out (25h), a
ROM:41FC di
ROM:41FD ld a, 20h ; ' '
ROM:41FF nop
ROM:4200 nop
ROM:4201 im 1
ROM:4203 di
ROM:4204 out (26h), a
ROM:4206 di
ROM:4207 xor a
ROM:4208 out (0Eh), a
ROM:420A out (0Fh), a
ROM:420C out (5), a
ROM:420E ld a, 3Fh ; '?'
ROM:4210 out (6), a
ROM:4212 ld a, 0F0h ; '='
ROM:4214 out (39h), a
ROM:4216 ld a, 20h ; ' '
ROM:4218 out (4Ah), a
ROM:421A push af
ROM:421B xor a
ROM:421C nop
ROM:421D nop
ROM:421E im 1
ROM:4220 di
ROM:4221 out (14h), a
ROM:4223 di
ROM:4224 or a
ROM:4225 jp nz, unk_0
ROM:4228 pop af
ROM:4229 ld a, 80h ; 'Ç'
ROM:422B out (7), a
ROM:422D call bootCSCScan
ROM:4230 cp 38h ; '8'
ROM:4232 jr z, loc_4279
ROM:4234 cp 20h ; ' '
ROM:4236 jr z, loc_4270
ROM:4238 ld a, (byte_38)
ROM:423B cp 0FFh
ROM:423D jr z, loc_424B
ROM:423F ld hl, (word_56)
ROM:4242 ld bc, 0A55Ah
ROM:4245 or a
ROM:4246 sbc hl, bc
ROM:4248 jp z, unk_53
ROM:424B ; START OF FUNCTION CHUNK FOR sub_461A
ROM:424B
ROM:424B loc_424B: ; CODE XREF: ROM:423Dj
ROM:424B ; sub_461A-7Aj ...
ROM:424B ld sp, 0FFC5h
ROM:424E ld a, 6
ROM:4250 out (4), a
ROM:4252 call initCalc
ROM:4255 xor a
ROM:4256 out (20h), a
5
« on: August 07, 2019, 10:23:34 am »
I'm not adding anything to the discussion, but I just wanted to drop in and say hello thePenguin77. It's nice to see you're still around(and lurking at least  ).
I still exist  This thread sent me an email with the @mention which is why I appeared. I've been considering to drop by omnomirc sometime to talk to people. I don't know when it's busy these days. (P.S. This is what I work on now. Also, I tend to go by bcov77 on other platforms if you feel like googling.)
6
« on: July 29, 2019, 12:35:10 pm »
So, originally, I was going to point out that my "exact-timing" scheme could be rather easily accomplished by using fixed length gaps between your port $10 writes and then using port $29 - $2C to do the t-state level timing for you. But then I saw this quote on the port $2A wiki: ... by adding a delay to any instruction which reads from or writes to ports 10 or 11 ...
Which means that for all these LCD delay routines, in a, $(10) actually takes a lot longer than expected. (An extra 11 t-states on my calculator). I guess this means that there's a huge speedup to be had simply by clearing port $2A (or $29 or $2C depending on your port $20 setting) at the start of your program and resetting it when you're done. (Although, it looks like my old programs do this, so maybe everyone already knows this ¯\_(ツ)_/¯)
7
« on: July 29, 2019, 01:31:35 am »
That's a great idea Sue! I've never thought to try to optimize that before. I originally got that code from somewhere on ticalc.org. (Maybe Pheonix?) In my code it looks like this:
#define DWAIT IN A, ($10) \ AND %10010000 \ JR NZ, $-4
; Then where needed
ld a, 07
out ($10), a
DWAIT
ld a, $20
out ($10), a
DWAIT
ld a, $BF
out ($10), a
I'm not sure how stable the LCD driver is, but if your goal is speed. Maybe you could even figure out how long the delay needs to be between writes and then try to match it exactly with some SMC code or a variable and a jump table. That's how many of the TI-84 music-playing programs account for the different cpu speeds of different calculators.
8
« on: July 10, 2014, 02:59:23 pm »
well, on 2.53MP maybe, but not on 2.55MP.
I had a problem on the 2.55, the same that was lately "discovered" on Cemetech here. That's when I decided I'd get the 2.43 back.
Even without that bug, I found out that I was typing slower on MP because of TI refreshing the whole screen everytime and me trying to type too fast, some keys not being detected between two frames.
I don't even mention incompatibilities with ASM programs, just the fact it's not even that convenient if you want to use it for maths.
Now, if those small issues don't bother you, I can understand that you use it, I just say I won't
That isn't a real bug. It's an artifact caused by the old flash unlock method. I made a patch for it which you can find here.
9
« on: July 08, 2014, 11:44:42 pm »
Honestly, the one thing I've always wanted is a fixed width small font editor (and Builderboy expressing his desire for one in IRC is what prompted me to vocalize mine). Do you think it would be at all possible, if you finished the small font editor, to shoehorn in a fixed width mode? I don't think it would need to have a special display engine, as it could probably use the variable width one with some kind of font hook. That would of course mean forfeiting the extra speed of making it specially for fixed width, but I'd take whatever I can get. And I've obsessively stared at pixels in the past and designed a fixed-width small font, so I could supply bitmaps for any characters that would need to be visually adjusted.
EDIT: Also, Builderboy raised two other excellent suggestions: getting rid of the title line and removing one pixel from between lines, each of which would add another available line.
I display all of the characters with my own routine, so swapping out the character set would be super simple. The only annoying thing I can think of with that editor is that when Axe raises an Error, we can't jump to the line, it opens the editor on the first line.
Other than that, yeah, the small font editor works great as it is, I do use it 
And I am not disturbed by the fact it is not monospaced font, on the contrary I find it less disturbing to have the "original" small font I am used to see in programs.
If you fear it has bugs that would prevent some people afraid of bugs () from using it, just add an option to disable it
I think I tried to add error scrolling, but I guess it doesn't work. And I probably don't need to add an option since it will only be in the two page version of zStart.
10
« on: July 07, 2014, 05:02:17 pm »
Hey, sorry I haven't been on here in a while. I've been working on my android projects lately and haven't touched my calculator in a while. I don't really have the hours of time I used to have to update this stuff. So are there any really critical bugs with zStart that need fixed? I'm not really going to add any new features, at this point I kind of just want to turn zStart into a finished project. Also, does the small font editor work well enough to merit me fixing all the bugs with it? It'll probably take me around 15 hours, so I don't really want to perfect something that no one's going to use. The penguin is in college AFAIK. He'll probably get more active this summer. Hopefully.
Also, lol at this because I have been a lot more active, just in a much more outdoors sense of the word.
11
« on: April 09, 2014, 11:44:53 pm »
I just recently figured this out, and it's so stupidly easy that I have to share it.
1. You're going to need dropbox. If you don't have it, install it.
2. Open an elevated command prompt. (Start > Programs > accessories > right click on Command Prompt > run as admin)
3. Determine the location of your calculator sources (For me it's "C:\asm\source")
4. Determine the location of your dropbox folder (For me it's "C:\users\brian\dropbox")
5. Decide on a name for your backup folder (I picked "C:\users\brian\dropbox\calc_src")
5. In command prompt, type
mklink /j "backup_folder" "source_folder"
I typed:
mklink /j "C:\users\brian\dropbox\calc_src" "C:\asm\source"
And you're done!
What this does is it creates a symlink from your dropbox folder to your sources folder. Basically, dropbox thinks that your source folder is in the dropbox folder and keeps it up to date with the server. This means that all of your calculator sources will be no more than a few minutes out of date.
I had this idea because this morning, my friend's computer got completely wiped by a chinese virus. It's one of those things where you think it could never happen, but then it does.
Also, this won't work with google drive because it can't handle the symlinks.
12
« on: March 20, 2014, 01:49:03 pm »
Instead of fighting about this, can we just agree that although the current documentation is complete, more could be desired? For instance, if we compare the axe commands to the android documentation we can see that the android documentation is very thorough to the point that after reading it, you really shouldn't have any questions. (this is the documentation for Camera.open()). But, if you look at the android documentation, you'll see that it takes more than half of your screen for one command. The purpose of commands.html is to put everything in front of you in a concise way so sometimes the 100% complete explanation isn't given. Whatever happened to that axe wiki? I feel like that's probably the best place for the kind of information you want. A wiki can be as verbose as you like and can provide the actual 100% explanation.
13
« on: March 16, 2014, 04:47:17 pm »
if thepenguin can make a 2-page app, he can make a 3- or 4-page app too right?
What's the point, then? It seems like all it would do is get rid of two physical applications and their menu entries without saving any archive space, which seems like a lot of work for not much benefit. And then things would start getting messy with multiple versions of zStart for people who do and don't want Omnicalc, people who do and don't want Symbolic, etc.
But everyone wants MirageOS libs, no ? It allows to run every single program (except maybe 20).
I'll probably add it eventually. But, I worry that it might be slightly more difficult than simply doing a copy/paste. um, i have noticed some significant bugs in the program editor
sometimes when editing a large program from archive, some code gets replaced and the whole screen gets garbled
Does it happen with every large program? If not, could you post an example that will break? Is there any way to add some sort of "suspend" to the program editor? Press a button and you're at the homescreen, where you can math out that constant you need, and then press it again and you're back where you were.
I've got a better idea. Make ON + MATH return to the last place you were editing.
14
« on: March 13, 2014, 09:16:52 pm »
Here you.
15
« on: March 13, 2014, 08:58:57 pm »
You can sign it yourself, that's what I did. Just get RabbitSign somewhere and drag-and-drop zStart on the "drag and drop over me" file
I'm not really sure how I messed this one up because I literally did this before I uploaded it. Oh well. I'm not sure about the whole gray comments thing. You'd need to be constantly updating the screen for the gray to look solid, which means allocating about 2/3 of CPU time just to grayscale updates. Not only would that result in a pretty noticeable slowdown of the editor, but it would probably have a large (negative) impact on battery life, as well.
And then there's the implementation difficulty, too.
All of that and then the fact that it would take another 1.5KB of ram. I tried to make this program editor emulate the TI-OS one, so to have a program that's not supposed to actually use any ram at all use total probably would have some interference issues. Interestingly though, I display the screen with fastCopy. So in principle, grayscale is possible.
|
Show Posts