Show Posts

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

Pages: [1] 2 3 ... 108
TI Z80 / Re: Accurate Subsecond Timing
« 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?

TI Z80 / Re: Accurate Subsecond Timing
« 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:
Code: [Select]
# Start the timers

# Store the elapsed time (at 1/128s resolution) into Ans
#   -1 if an error is detected (timers disabled or system clock went backwards)

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.

  • 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.

TI Z80 / Re: Accurate Subsecond Timing
« on: March 07, 2024, 11:48:58 am »
A mention after like 10 years :3? 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:
Code: [Select]
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)
Code: [Select]
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)?

ASM / Re: [8X+] port $24 question
« 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:
Code: [Select]
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 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

ASM / Re: Better LCD Delay Routines?
« 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 :P 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.)

ASM / Re: Better LCD Delay Routines?
« 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:
Code: [Select]
... 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 ¯\_(ツ)_/¯)

ASM / Re: Better LCD Delay Routines?
« 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 (Maybe Pheonix?) In my code it looks like this:

Code: [Select]
#define DWAIT IN A, ($10) \ AND %10010000 \ JR NZ, $-4

; Then where needed

        ld      a, 07
        out     ($10), a
        ld      a, $20
        out     ($10), a
        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.

TI Z80 / Re: zStart - an app that runs on ram clears
« 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.

TI Z80 / Re: zStart - an app that runs on ram clears
« 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 (:P) 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.

TI Z80 / Re: zStart - an app that runs on ram clears
« 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.

TI Calculators / Perhaps the simplest backup method yet
« 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.

Axe / Re: [Controversial] Better Axe Documentation Could Be Needed
« 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

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.

TI Z80 / Re: zStart - an app that runs on ram clears
« 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.

TI Z80 / Re: Fullrene
« on: March 13, 2014, 09:16:52 pm »
Here you.

TI Z80 / Re: zStart - an app that runs on ram clears
« 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. :P
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.

Pages: [1] 2 3 ... 108