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 - DrDnar
Pages: 1 ... 18 19 [20] 21 22 ... 38
286
« on: March 06, 2012, 02:52:08 am »
I thought that some Axe programmers would find it useful to be able to run archived programs. Also, the Asm( sequence I posted to run programs in RAM will leak memory if the program you call throws an error. So I wrote an Axiom that lets you run other assembly/Axe programs and fixes memory leak issues. If you want, there's even a provision in there that lets you prevent your subprograms from being run from anything other than this Axiom, in case they do nothing useful on their own. Additionally, it also lets you catch errors that the OS may throw; that is, it lets you prevent that ERR: screen from showing up. The attached ZIP file contains the Axiom, its source code, and all the documentation. I'm a little afraid that the part of the documentation about error handlers is a little unclear, so if you're confused, feel free to ask questions.
Quigibo and Runer112: Feel free to optimize this---I'm sure it can be---and put it in Axe.
Here's an example. Let's say you have a fancy intro screen that's very large. You want it to run if the user has it---regardless of whether it's archived or in RAM---, but you want your program silently to skip running the intro screen if it doesn't exist. Just put this code in the main program:
:AppOnErr(LSKIP)
:RunPrgm("prgmINTRO")
:AppOffErr
:Lbl SKIP
:Your program continues here
287
« on: March 04, 2012, 04:48:32 pm »
Can I undelete an appvar ? I accidentally deleted an Axe back-up file -_-'
Yes, it can undelete appvars, but only if it was archived and you haven't garbage collected since you deleted it. I should note that my original assembly undeleter is much smaller. Its primary disadvantage is not being able to undelete anything except programs and appvars. Fun fact: While writing the Axe undeleter, I had to undelete its source more than once.
288
« on: March 03, 2012, 11:15:52 pm »
So TI never had any intention of allowing third-party native code ever, since that would require writing secure, reliable software. They just figured it would be easier to block us in every way they could. To make their software secure now would require significant refactoring of their code to meet the level of quality that secure code needs to meet. On the plus side, since security doesn't seem to have been on their priority list when they wrote the Nspire software, there's probably still plenty of holes waiting for us to exploit.
289
« on: March 03, 2012, 08:13:01 pm »
You may also be able to configure your router to block access, for example by blacklisting the TI domain name, or blocking whatever port TI's software uses (which won't work well if TI checks using a standard protocol like HTTP).
290
« on: March 03, 2012, 06:28:05 pm »
Doesn't the ARM support protection rings? Why can't TI implement security through a kernel? They could mark most of the system RAM as being off-limits third-party software, preventing people from running the CAS OS on non-CAS models. With preemptive threading, they could ensure that PTT protections would engage when requested and have full effect. The only downside to this is that it would require TI to do some actual work---which costs money---, and understand complicated, difficult things like scheduling, resource tracking, least-privilege security, APIs, and such.
291
« on: March 03, 2012, 04:29:36 pm »
Update: I blame thepenguin77's for this one. Looking at the disassembly of _ExecutePrgm, it's clear that the OS does not save the value in 89ECh (a.k.a. asm_prgm_size) before modifying it, so it turns out that the memory used by the caller will never be properly freed, unless you save it yourself. Fortunately, that's easy to do, so here's the new version: "prgmNAME"Asm(E72AEC89E5EF7C4EE122EC89Edit: calc84maniac suggested rearranging the assembly instruction sequence to make it less ugly, though no smaller or faster. So, once again, keep these points in mind: - Just like running programs with the Asm( token from the homescreen, you need a quantity of free RAM equal to the size of the program being run.
- Because the OS has to shuffle RAM around for this to work, it takes a split second for the new program to start. So if you do this a lot, it'll be really slow.
- If you call yourself like this, the OS will make yet another copy of yourself. Duh.
- Instant quit will return control to the calling program, not the homescreen or the shell. This is because the error handlers get nested. (The good news is that if the calling program throws an OS error, control is returned to the calling program, but I don't believe any Axe programs use error handlers.)
- WARNING: This code will leak memory if the program throws an error! To prevent this, use the Axiom for running programs.
- By extension, do not call a shell's instant quit routine, or the memory used by caller won't get freed.
- Assuming Axe just makes a stub ISR that jumps to the real ISR, you're going to get a crash if you have an interrupt running and you try this, because your ISR just got moved.
- L1 through L6 will not be modified by the OS, neither during calling nor returning. The OP registers, however, will be corrupted.
OS Disassembly: OS 2.55MP _ExecutePrgm disassembly
07:5758:
ld a, 03h
call 3891h
ld a, 38h
jp nz, 2793h
call 178Bh
ex de, hl
ld c, (hl)
inc hl
ld b, (hl)
inc hl
ld a, (hl)
cp 0BBh
jp nz, 2729h
inc hl
ld a, (hl)
cp 6Dh
jr nz, 57D4h
inc hl
push hl
push bc
pop de
push de
ld hl, 2000h
or a
sbc hl, de
jp c, 2729h
ex de, hl
call 1735h
pop hl
push hl
ld de, 9D95h
call 0F81h
pop hl
ld (89ECh), hl
pop hl
ld de, 9D95h
ld bc, (89ECh)
add hl, bc
ldir
579Fh: call 1837h
jr nz, 57AEh
in a, (20)
push af
bit 5, (iy+24h)
call 0DCBh
57AEh: ld hl, 5800h
call 27DAh
call 57FDh
call 2800h
call 1837h
jr nz, 57C4h
pop af
and 01
out (20), a
57C4h: ld de, (89ECh)
ld hl, 0000h
ld (89ECh), hl
ld hl, 9D95h
jp 1368h
57D4h: rst 18h ;rPUSHREALO1
call 5717h
ld hl, 2000h
or a
sbc hl, de
jp c, 2729h
ex de, hl
push hl
call 1735h
pop hl
push hl
ld de, 9D95h
call 0F81h
pop hl
ld (89ECh), hl
call 150Fh
ld de, 9D95h
call 5734h
jr 579Fh
57FDh: jp 9D95h
5800h: call 1837h
jr nz, 580Ah
pop af
and 01
out (20), a
580Ah: ld de, (89ECh)
ld hl, 0000h
ld (89ECh), hl
ld hl, 9D95h
call 1368h
jp 2799h
292
« on: March 03, 2012, 12:18:29 am »
How are you quitting from the second program? It looks like the subprogram is quitting in a manner that prevents the memory being used by the caller from being freed.
293
« on: February 24, 2012, 11:39:17 pm »
I've got an epic solution and optimization for you all. I can both eliminate the problem with Copy( and reduce the code size by about ten bytes. "prgmNAME"Asm(E7EF7C4EBAM! One-liner. EDIT: This code causes a memory leak; see below for the fix. For the curious: ld hl, ptrToName
rst rMOV9TOOP1
bcall(_ExecutePrgm)Also, to recap: The peep-hold optimizer is causing crashes with the Copy( command sometimes. You can stop Axe from doing the peep-hole optimization with ZOOM. However, it's all a moot point since I just replaced the Copy( command with the single assembly instruction rst rMOV9TOOP1.
295
« on: February 24, 2012, 06:22:44 pm »
Huh. . . . it looks like you're doing nothing wrong. I wrote a test program myself and found a problem in the disassembly: prgmA .AAA
Disp "ONE...",i
Copy("prgmAAAA",33912,9
Asm(EF7C4E
Disp "...ONE.",i
Pause 2000prgmAA .AAAA
Disp "TWO",iDisassembly: prgmAAA 9D95: ld hl, 9DC3 ; Disp "ONE...",i
bcall(_450A)
bcall(_452E)
ld hl, 9DCAh ; Copy("prgmAAAA",33912,9
push hl ; Load arguments in a complicated fashion
ld hl, 8478h
ld bc, 0009
ex de, hl
pop hl
ldir ; Copy the data
ldir ; Clobber all of RAM
ld c, (hl) ; ???
ld hl, 9DD0h ; Disp "...ONE.",i
bcall(_450A)
bcall(_452E)
ld hl, 07D0h ; Pause 2000
9DBB: djnz 9DBB
dec hl
ld a, l
or h
jr nz, 9DBB
ret ; End of program code
9DC3: .db "ONE...", 0
9DCB: .db ProgObj, "AAAA", 0
9DD0: .db "...ONE.", 0prgmAAAA 9D95: ld hl, 9D9F ; Disp "TWO",i
bcall(_450A)
bcall(_452E)
ret ; End of program code
9D9F: .db "TWO", 0For some reason, Axe 1.1.2 is inserting the ldir twice, clobbering all of RAM. NOPing one of the ldirs out fixes it. EDIT: Runer112 has a workaround for you: (6:43:18 PM) DrDnar: Runer112: I found an Axe bug, see http://ourl.ca/15239/286978
(6:43:32 PM) Runer112: I saw
(6:43:39 PM) DrDnar: k
(6:43:53 PM) Runer112: I can tell you it's a peephole optimizer problem
(6:44:00 PM) Runer112: so you can fix it by compiling without peephole opts [Use ZOOM---DrDnar]
(6:44:08 PM) Runer112: but I can't tell you why it's happening
(6:44:48 PM) Runer112: I'm sure Quigibo will know it's a peephole optimizer problem too
(6:44:51 PM) Runer112: it's pretty clear
296
« on: February 24, 2012, 05:32:48 pm »
Yes, it's OP1. Yes, control is returned the caller. This code just calls the OS routine that runs assembly programs. You can even run unsquished programs this way. (Ignore the last statement if you don't know what a squished program is.) However, keep in mind a few things: - Just like running programs with the Asm( token from the homescreen, you need a quantity of free RAM equal to the size of the program being run.
- Because the OS has to shuffle RAM around for this to work, it takes a split second for the new program to start. So if you do this a lot, it'll be really slow.
- If you call yourself like this, the OS will make yet another copy of yourself. Duh.
- Instant quit will return control to the calling program, not the homescreen or the shell. This is because the error handlers get nested. (The good news is that if the calling program throws an OS error, control is returned to the calling program, but I don't believe any Axe programs use error handlers.)
- By extension, do not call a shell's instant quit routine, or the memory used by caller won't get freed.
- Assuming Axe just makes a stub ISR that jumps to the real ISR, you're going to get a crash if you have an interrupt running and you try this, because your ISR just got moved.
- L1 through L6 will not be modified by the OS, neither during calling nor returning. The OP registers, however, will be corrupted.
297
« on: February 23, 2012, 01:01:17 pm »
I suggest looking up the DEFLATE standard, which is open and specified in an RFC, unlike RAR.
298
« on: February 23, 2012, 12:53:24 pm »
-Feature request: for the 83+BE, there is not a lot of Rom. So even with smart writeback, GarbageCollecting is frequent (and annoying). Maybe you could add an option "Never writeback" ?
In case you didn't know, MirageOS has this feature.
299
« on: February 21, 2012, 02:58:29 am »
It's not April 1st yet.
Pages: 1 ... 18 19 [20] 21 22 ... 38
|
Show Posts