Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: the_mad_joob on July 31, 2019, 01:32:14 am
-
Welcome.
I'm currently writing a tiny routine that makes all ROM space executable.
So, it will of course write to ports $22 & $23, but i'm not sure about how they both interact with port $24.
According to the wiki, bits 0 & 1 of port $24 are working as bits 8 of ports $22 & $23 respectively.
Fine.
So, i would expect that no matter how those 2 bits are configured, it would not change anything to the actual execution permission range defined by $22 & $23, since no 8X+ calculator has more than 256 rom pages.
But then, here comes that statement, that makes no sense if those bits are actually ignored :
"Since no 8 MB flash chip exists, this port in effect overrides port 23 and is overridden by port port 22."
How should i understand it ?
Like, let's say i have port $22 set to $80, and port $24-bit0 set to 1.
Does that mean that the ASIC will allow execution on all pages below $180, in other words all of them ? (instead of pages below $80 like i expected)
Even if that's true, i still don't understand why port $24 would "override" port $23 but not $22.
Am i the only one confused ?
Thanks in advance for your time.
-
That is really confusing wording. I think your interpretation is most likely:
Does that mean that the ASIC will allow execution on all pages below $180, in other words all of them ?
-
Yeah, that word "override" has been bothering me for years, actually.
Looks like i'm gonna have to test something myself, since unfortunately, port $24 emulation appears to be lazy enough =[
But i really have to think about it deeply while coding, cause such testing could be dangerous, even if the ram resets, which is one of the outcomes.
-
Out of curiosity, what is your goal with unlocking the execution? Are you just trying to to it for the sake of doing it or do you have some specific use case in mind?
-
Just risked my ass on real hardware, port $24 bits aren't ignored.
So no matter how much rom pages you really have, both rom execution limits will always be defined using 9-bits values.
The good thing about it is that loading %00000001 in port $24 makes all rom executable with just 1 writing, no matter how $22 & $23 are configured.
Out of curiosity, what is your goal with unlocking the execution? Are you just trying to to it for the sake of doing it or do you have some specific use case in mind?
2 purposes :
1) a universal low-level routines collection, mostly for sharing
2) a long-term project, where execution from rom should be a thing
-
What's the risk with using real hardware? Sure you are running code with flash unlocked but you are hardly likely to corrupt things. Maybe if you set it so that none of flash is executable and it gets stuck in a reset loop but unless the port lets you deny execution on page 0 the OS should fix it... right? I know the OS does some strange things but I'd be really surprised if it doesn't set the executable limits for flash on boot. It does with the RAM execution.
-
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?
-
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 (http://wikiti.brandonw.net/index.php?title=83Plus:State_of_the_calculator_at_boot).
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
-
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.
Thanks for sharing =]
So, if i understand correctly, "what" resets the ports to default values is "outside" of the boot code itself?