Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: thepenguin77 on October 17, 2011, 04:16:50 pm

Title: Fullrene
Post by: thepenguin77 on October 17, 2011, 04:16:50 pm
Current Version (http://ourl.ca/13513/293560)

First 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)
Code: [Select]
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)
Code: [Select]
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
Title: Re: Fullrene
Post by: Freyaday on October 17, 2011, 06:59:52 pm
Why is it smaller on the 84+?
Title: Re: Fullrene
Post by: Deep Toaster on October 17, 2011, 07:00:55 pm
You got +5 before anybody replied O.O That sounds brilliant, as in really, really useful.
Title: Re: Fullrene
Post by: thepenguin77 on October 17, 2011, 07:08:29 pm
Quote from: Freyaday on October 17, 2011, 06:59:52 pm
Why is it smaller on the 84+?

The 83+BE boot code was built rock solid and as of now, ~15 years after it was released, no flash unlock exists. This means that you have to trick the OS into unlocking flash, which due to the many OS's, inherently takes up more space.

The 84+ unlock is really simple and also, in the 84+ code, I don't have to worry about unlocking the 83+BE (because it is drastically different).
Title: Re: Fullrene
Post by: Freyaday on October 17, 2011, 07:09:46 pm
The 84+ unlock applies to the SE too, right?
Title: Re: Fullrene
Post by: thepenguin77 on October 17, 2011, 07:17:39 pm
Yes, it covers 83+SE, 84+BE, and 84+SE. Those are all basically the same calculator.

It's only when you introduce the 83+BE that things get messy.
Title: Re: Fullrene
Post by: boot2490 on October 17, 2011, 07:22:14 pm
Off topic but about axioms:
Could you make an axiom that could play two or three notes at the same time?
Title: Re: Fullrene
Post by: Yeong on October 17, 2011, 07:23:05 pm
I think that was suggested a lot already O.o
For now, you'll have to live with Calcmod XP
Title: Re: Fullrene
Post by: thepenguin77 on October 18, 2011, 05:50:16 pm
Most Recent Version Here (http://ourl.ca/13513/259599)

For those who haven't figured out where the name came from, I knew I had to use the word full, as in "full Ram", but I had to make it cool. So then I decided on Fullrene, those cool carbon creations, only to find out that it's spelled Fullerene (http://en.wikipedia.org/wiki/Fullerene).

I believe that this axiom is ready to go. It appears to work on every emulator I've tested it on, so it should be good.

A few notes on usage:



You should already know how Axioms work, but if you don't, send this appvar to your calculator and put it in flash. To include the axiom in your Axe program, add the line:
Code: [Select]
:AsmComp(FULLRENE)
   or
:#Axiom(FULLRENE)      (Axe hooks)

Then, include this line preferably at the top of your program.
Code: [Select]
:Fcdf()        (all calculators)
   or
:Fcdf()r        (non-83+BE calculators)

If you can't find Fcdf(, it's in [2nd] [Vars] [9 or 0] ;)

Also, if today is your lucky day, here is the code to optimize: (I'd be happy with even a single byte)
Spoiler For Spoiler:
R Version
Code: [Select]

scf
REP_NEXT
call unlockflash
REP_NEXT
call rVersionEnd
or a

unlockFlash:
in a, (06)
push af
REP_NEXT
ld (saveSP), sp
ld sp, $82A9+$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

jr z, _83PlusSE


_84Plus:
ld ($80C8), a
ld ($80C9), hl
jp $4529


_83PlusSE:
push af ;sp-2
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:
Non R Version
Code: [Select]
scf
REP_NEXT
call doIt
REP_NEXT
call allVersionEnd
or a

doIt:
        in a,(6)
        push af
push af
;UnlockFlash:
;Unlocks Flash protection.
;Destroys: appBackUpScreen
;          pagedCount
;          pagedGetPtr
;          arcInfo
;          iMathPtr5
;          pagedBuf
;          ramCode

        ld a,7Bh
        call translatePage
        out (6),a

ld hl, ($5092)
ld a, ($5094)

        call translatePage
        out (6),a
        ld a,0CCh
ld b, a
        cpir
        ld e,(hl)
        inc hl
        ld d,(hl)
ld (iMathPtr5), sp
        push de
;       pop ix

ld a, $C3
ld ($9898), a
REP_NEXT
ld hl, returnPoint
ld ($9899), hl

        ld hl,pagedBuf
        ld (hl),98h
        ld de,pagedBuf+1
        ld bc,49 ;so lucky VV
push bc
        ldir
        ld hl,(iMathPtr5)
push hl
        ld de,9A00h
        ld bc,50

ld a, c

        ldir  
        pop de
        ld hl,-14
        add hl,de
        ld (iMathPtr5),hl
pop iy ;that was convenient
;       ld iy,0056h-25h
;       ld a,50 ;covered
        ld (pagedCount),a
        ld a,8
        ld (arcInfo),a
;       jp (ix)
translatePage:
       bcall(_NZIf83Plus)
        ret z
        and 1Fh
        ret
returnPoint:
        ld iy,flags
ld hl,(iMathPtr5)
        ld de,14
        add hl,de
        ld sp,hl
        ex de,hl
        ld hl,9A00h
        ld bc,48
        ldir

in a, (02)
rlca
jr c, regularUnlock

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

If you're in Chrome, it's probably best to just quote this post.
Title: Re: Fullrene
Post by: Deep Toaster on October 18, 2011, 08:25:48 pm
I was just about to post here asking you if you left the ER out on purpose. It's a cool name anyway though :D
Title: Re: Fullrene
Post by: boot2490 on October 20, 2011, 11:47:27 am
What does it do...?
Title: Re: Fullrene
Post by: Yeong on October 20, 2011, 12:02:18 pm
I think it's just like crabcake: get the limit off of asm compiling
Title: Re: Fullrene
Post by: C0deH4cker on October 20, 2011, 02:41:19 pm
if youre using chrome and know a little html, you can just right-click on the code box, click "Inspect element", double click where it says "height: 20px; " and change the 20 to something more like 260. I dont know why it is set to be only 20 pixels high; it just is.

Edit: or, you could just remove the style="" attribute altogether. that's how normal code boxes are.
Title: Re: Fullrene
Post by: thepenguin77 on October 20, 2011, 02:52:15 pm
That is by far the greatest thing I have learned all week. I didn't realize that you could edit webpages on the fly. I'll have fun with this ;D

(Yes, I realize it's only on my computer)
Title: Re: Fullrene
Post by: ztrumpet on October 20, 2011, 03:13:46 pm
Quote from: C0deH4cker on October 20, 2011, 02:41:19 pm
if youre using chrome and know a little html, you can just right-click on the code box, click "Inspect element", double click where it says "height: 20px; " and change the 20 to something more like 260. I dont know why it is set to be only 20 pixels high; it just is.

Edit: or, you could just remove the style="" attribute altogether. that's how normal code boxes are.
Thank for the tip!  It's pretty awesome. :D
Title: Re: Fullrene
Post by: C0deH4cker on October 20, 2011, 03:14:16 pm
lol. ive been doing stuff like this with firefox's firebug for years, and ive just recently started liking chrome, which has a firebug-like interface built in. for those of you who for some reason still use Internet Explorer *shudders*, as long as you use IE 8 or later, if you press F12, a similar window will pop up, but it isnt nearly as good.
Title: Re: Fullrene
Post by: DJ Omnimaga on October 20, 2011, 05:28:48 pm
Yeah the code tag glitch with spoiler tags is a bit annoying. However it seems every spoiler tag mod on SMF site has it O.o. I guess it could be modified as you said, though.
Title: Re: Fullrene
Post by: BalancedFury on October 20, 2011, 05:47:58 pm
Quote from: Deep Thought on October 17, 2011, 07:00:55 pm
You got +5 before anybody replied O.O That sounds brilliant, as in really, really useful.
+9 now :P
Title: Re: Fullrene
Post by: Deep Toaster on October 20, 2011, 06:23:40 pm
C0deH4cker's little trick reminded me how annoying code-in-spoiler screwups are in Chrome, so I made a little bookmarklet to fix it.

Code: [Select]
javascript:var i=document.querySelectorAll('.alt2 .code');for(var j=0;j<i.length;j++)i[j].style.height='auto';void(0)
Copy that to your URL bar (and add the "javascript:" to the beginning again, because Chrome strips it for some reason) and watch this:

Spoiler For Spoiler:
Code: [Select]
a
b
c
d
e
f
g
h
i
j
k
l

That should be fixed now :)

If you like it, make it a bookmark!
Title: Re: Fullrene
Post by: C0deH4cker on October 20, 2011, 07:04:27 pm
Works for MobileSafari :P
Thanks!
Title: Re: Fullrene
Post by: Deep Toaster on October 20, 2011, 07:11:30 pm
It secretly works in Firefox as well, but there's no point in that since Firefox does it right anyway lol

Aaanyway, back to the topic.
Title: Re: Fullrene
Post by: DJ Omnimaga on October 20, 2011, 08:40:55 pm
I wonder if they can be changed via CSS, though... if that's the case then it wouldn't require modifying board files.
Title: Re: Fullrene
Post by: Deep Toaster on October 20, 2011, 10:00:42 pm
Nope, it's definitely from JavaScript :/
Title: Re: Fullrene
Post by: Builderboy on October 21, 2011, 06:13:42 pm
Just tried this out with PortalX and it works beautifully!   :w00t:  Very well done!
Title: Re: Fullrene
Post by: thepenguin77 on October 21, 2011, 06:18:16 pm
I'm very glad to hear that, because I never actually tested it ;D

I don't have the means to make an axe program large enough to test it so I just figured that since it put the ports in the right states, it should work. And I guess it does.
Title: Re: Fullrene
Post by: Deep Toaster on October 21, 2011, 09:07:34 pm
Quote from: thepenguin77 on October 21, 2011, 06:18:16 pm
I'm very glad to hear that, because I never actually tested it ;D
Glad it works then lol

Any plans to pick up Portal, Builder? :o
Title: Re: Fullrene
Post by: DJ Omnimaga on October 21, 2011, 09:23:12 pm
It would be cool, although I don't think he planned to work on large calc projects anymore. D:

Also nice work on Hurricane Irene... er... Fullrene ThePenguin77. :D
Title: Re: Fullrene
Post by: Hayleia on October 31, 2011, 04:27:51 am
Great work ! but I have a question :P
Do we need to compile for a shell or does it work in noshell and apps too ?
Title: Re: Fullrene
Post by: Quigibo on October 31, 2011, 05:10:31 am
As far as optimizations, I found one byte for the all models case:

Code: ("old") [Select]
        ld de,pagedBuf+1
        ld bc,49 ;so lucky VV
push bc
        ldir
        ld hl,(iMathPtr5)
push hl
        ld de,9A00h
        ld bc,50

Code: ("new") [Select]
        ld de,pagedBuf+1
        ld bc,49 ;so lucky VV
push bc
        ldir ;bc is now zero
        ld hl,(iMathPtr5)
push hl
        ld de,9A00h
        ld c,50 ;since b is already zero...
By the way, if you need absolute addressing in the $0000 to $3FFF range, I can add a new prefix to ignore the automatic replacements if that's convenient.  I didn't think anyone would ever need to jump or call addresses there, but I guess for hacks like this that could be important.
Title: Re: Fullrene
Post by: LincolnB on October 31, 2011, 09:54:43 am
Quote from: Deep Thought on October 21, 2011, 09:07:34 pm
Quote from: thepenguin77 on October 21, 2011, 06:18:16 pm
I'm very glad to hear that, because I never actually tested it ;D
Glad it works then lol

Any plans to pick up Portal, Builder? :o

Portal has been picked up, and is in full production right now.
Title: Re: Fullrene
Post by: thepenguin77 on October 31, 2011, 10:44:35 pm
Quote from: Hayleia on October 31, 2011, 04:27:51 am
Great work ! but I have a question :P
Do we need to compile for a shell or does it work in noshell and apps too ?

It works for everything except apps. If you think about it, there wouldn't even be a need to use this in apps. (At least for axe ;D)

Quote from: Quigibo on October 31, 2011, 05:10:31 am
As far as optimizations, I found one byte for the all models case:

Very clever

Quote
By the way, if you need absolute addressing in the $0000 to $3FFF range, I can add a new prefix to ignore the automatic replacements if that's convenient.  I didn't think anyone would ever need to jump or call addresses there, but I guess for hacks like this that could be important.

I didn't need it for this one, but with more hacks, I can see that being necessary. Especially if you wanted to invoke the error handler.
Title: Re: Fullrene
Post by: jacobly on October 31, 2011, 11:03:32 pm
Quote from: Quigibo on October 31, 2011, 05:10:31 am
By the way, if you need absolute addressing in the $0000 to $3FFF range, I can add a new prefix to ignore the automatic replacements if that's convenient.  I didn't think anyone would ever need to jump or call addresses there, but I guess for hacks like this that could be important.
That would be much better than what I currently do!
Code: [Select]
BJump:
 ld   hl,50h
 push hl
 ret
Title: Re: Fullrene
Post by: Builderboy on November 06, 2011, 02:30:24 pm
Hmmm so Portal Prelude has been using Fcdf()r this entire time without a hitch, but just recently to increase compatibility I switched to the slightly larger Fcdf(), and now I simply get a RAM clear upon starting the program.  Ideas?
Title: Re: Fullrene
Post by: thepenguin77 on November 06, 2011, 09:14:57 pm
Quote from: Builderboy on November 06, 2011, 02:30:24 pm
Hmmm so Portal Prelude has been using Fcdf()r this entire time without a hitch, but just recently to increase compatibility I switched to the slightly larger Fcdf(), and now I simply get a RAM clear upon starting the program.  Ideas?

Umm... I have no idea. But I fixed it. It worked in wabbitemu, but not on a real calculator.


Also, quigibo's optimization was added.

Edit:
   Code in first post. Changes on lines 64 and 82
Title: Re: Fullrene
Post by: Darl181 on November 22, 2011, 11:57:12 am
I'm getting some problems with this..first off how do you restore the calc and quit without it crashing b/c the quit code's past the limit?
Title: Re: Fullrene
Post by: thepenguin77 on November 22, 2011, 03:59:14 pm
You need to make sure that Fcdf() is the first line, (or close) of your program. If this is true, you shouldn't have any problems. If you do, then I would assume something else is broken.
Title: Re: Fullrene
Post by: Darl181 on November 22, 2011, 05:26:26 pm
Quote from: thepenguin77 on November 22, 2011, 03:59:14 pm
You need to make sure that Fcdf() is the first line, (or close) of your program. If this is true, you shouldn't have any problems. If you do, then I would assume something else is broken.
Well I just changed the cragcake stuff to the fullrene stuff so it's like
.name
#Axiom(FULLRENE)
Fcdf(1)
and the last line's Fcdf(0) so yeah.

What's odd is that it was epic-crashing last night, but now it's working properly..I'm not sure if it's going over the limit now tho b/c it was earlier.
Title: Re: Fullrene
Post by: thepenguin77 on November 22, 2011, 05:27:29 pm
Oh, I changed the syntax on you. Now it's just Fcdf() at the start of the program. I should properly release this sometime...
Title: Re: Fullrene
Post by: Xeda112358 on November 22, 2011, 05:29:01 pm
Quote from: jacobly on October 31, 2011, 11:03:32 pm
Code: [Select]
BJump:
 ld   hl,50h
 push hl
 ret
I think that can be shortened to:
Code: [Select]
BJump:
 ld   hl,50h
 jp (hl)
>.>
kthxbai
*poof*
EDIT:
wait *cough* back
Why not jp 50h? .__.
EDIT2:
thepenguin77 'splained why not XD
Title: Re: Fullrene
Post by: Darl181 on November 22, 2011, 05:44:44 pm
Quote from: thepenguin77 on November 22, 2011, 05:27:29 pm
Oh, I changed the syntax on you. Now it's just Fcdf() at the start of the program. I should properly release this sometime...
XD
It's still Fcdf(0) to close it, then?
Title: Re: Fullrene
Post by: thepenguin77 on November 22, 2011, 05:55:59 pm
No, you don't close it, it closes automatically. Just put Fcdf() at the start. Then, imagine that there is a bracket after it that encapsulates your entire program.
Title: Re: Fullrene
Post by: epic7 on November 30, 2011, 05:09:51 pm
I cant get it to work.

I have
#Axiom(FULLRENE)
Fcdf(1)
.Code
Lbl C
Repeat getKey(9)
.Text
If getKey(15)
sub(SAVE)
Fcdf(0)
Return
End
End
Fcdf(0)
Return
.More code
Title: Re: Fullrene
Post by: thepenguin77 on November 30, 2011, 05:24:27 pm
Quote from: thepenguin77 on November 22, 2011, 05:27:29 pm
Oh, I changed the syntax on you. Now it's just Fcdf() at the start of the program. I should properly release this sometime...
Quote from: Darl181 on November 22, 2011, 05:44:44 pm
It's still Fcdf(0) to close it, then?
Quote from: thepenguin77 on November 22, 2011, 05:55:59 pm
No, you don't close it, it closes automatically. Just put Fcdf() at the start. Then, imagine that there is a bracket after it that encapsulates your entire program.

I mean, what more do I need to say?
Title: Re: Fullrene
Post by: Builderboy on November 30, 2011, 05:44:24 pm
Maybe put it in the first post, or the post you link to in the first post?
Title: Re: Fullrene
Post by: Darl181 on November 30, 2011, 06:24:24 pm
Or take this out of it :P
Quote
Also, I picked Fcdf( as my token, if you don't like it or have a better one, I'm all ears. (Fcdf(1) unlock, Fcdf(0) lock)

Anyway this is working great for me ;D
Title: Re: Fullrene
Post by: epic7 on November 30, 2011, 07:24:10 pm
I saw just use
Fcdf()
In a later post, but since fcdf(1) was in the first post, I went with that
Title: Re: Fullrene
Post by: epic7 on December 01, 2011, 03:40:25 pm
KEEP GETTING RAM CLEARS
Title: Re: Fullrene
Post by: Darl181 on December 01, 2011, 06:19:41 pm
Just to clarify you only need the fcdf() in the beginning, nothing else.
Title: Re: Fullrene
Post by: epic7 on December 01, 2011, 08:08:38 pm
I just used
#Axiom(FULLRENE)
Fcdf()

and it crashes

Is this another anti-83+BE program?
Title: Re: Fullrene
Post by: Yeong on December 01, 2011, 09:06:35 pm
I believe there is one for TI-83BE XD
Title: Re: Fullrene
Post by: epic7 on December 01, 2011, 09:15:29 pm
I used it. Doesnt work.

At least RoboGun doesn't exceed the limit for dcs
Title: Re: Fullrene
Post by: DJ Omnimaga on February 25, 2012, 09:53:05 pm
Feature suggestion: WabbitEmu and PindurTI compatibility.
Title: Re: Fullrene
Post by: Builderboy on February 25, 2012, 10:16:52 pm
Shouldn't that be the other way around?  If it works on the calculator, it should work on the emulator.  If it doesn't, I would think it would be a feature request for the emulator instead of the program, since the emulator is the one that is not working properly.
Title: Re: Fullrene
Post by: LincolnB on February 25, 2012, 10:25:00 pm
Good point. +1 Builderboy
Title: Re: Fullrene
Post by: DJ Omnimaga on February 25, 2012, 10:28:05 pm
Quote from: Builderboy on February 25, 2012, 10:16:52 pm
Shouldn't that be the other way around?  If it works on the calculator, it should work on the emulator.  If it doesn't, I would think it would be a feature request for the emulator instead of the program, since the emulator is the one that is not working properly.
Yeah maybe, but Buckeye claims it works fine on his end, so I think he won't be fixing that issue anytime soon. :S
Title: Re: Fullrene
Post by: Builderboy on February 25, 2012, 10:31:47 pm
Hmm ThePenguin probably should work directly with Buckeye to find out why it doesn't work for some people.
Title: Re: Fullrene
Post by: DJ Omnimaga on February 25, 2012, 11:22:22 pm
That could work, too.
Title: Re: Fullrene
Post by: thepenguin77 on March 25, 2012, 05:54:22 pm
Rejoice all of you over-sized axe program designers, I actually fixed this! The fix came when I figured out a way to change the universal flash exploit so that it wouldn't corrupt OS. The result of my change was a drastically smaller universal flash exploit, and, one that didn't crash.

The reason Fullrene was crashing in the past was that the old unlock routine actually wrote to the OS. This went unnoticed for a very long time. But the problem is that after a write goes out to flash, you have to wait a while before flash will start working again. This also went unnoticed in the routine until I slightly changed it. I had the program return slightly too early and it caught the calculator off guard. The result was a crash that didn't happen in wabbitemu and was virtually untraceable.

But, here it is. 78 bytes for the r version and 123 for the regular one. Be sure to check the first post if you think you can optimize it. ;D

Also, if you want the new unlock routines, just ask me for them. I'd attach them here, but that feels a little dangerous. (It's only 75 bytes :D)


Edit:
    Just put Fcdf() or Fcdf()r very early in your program to use them. Preferably, don't force quit after you use it.
Title: Re: Fullrene
Post by: DJ Omnimaga on March 25, 2012, 06:26:29 pm
Glad to see an update. Question: Will this actually fix Fullrene compatibility with WabbitEmu?
Title: Re: Fullrene
Post by: thepenguin77 on March 25, 2012, 07:06:17 pm
Fullrene has always worked on Wabbitemu. The problem was that it didn't work on some 83+BE's.
Title: Re: Fullrene
Post by: DJ Omnimaga on March 25, 2012, 08:40:14 pm
But it didn't for me on 84+ emulation ???
Title: Re: Fullrene
Post by: thepenguin77 on March 26, 2012, 12:47:11 am
Oh, right, I know why that is. You were probably using bootfree which doesn't contain the same flash unlock exploits as the TI boot code. I don't think I can really make it work with boot free (unless it has it's own specialized unlock routine)
Title: Re: Fullrene
Post by: Runer112 on March 26, 2012, 02:33:49 am
I managed to cut down the non-83+BE version from 76 bytes to 67 66 bytes. I really don't think it's going to get much smaller, this is after an hour or two of trying every crazy optimization idea I can think of. Any challengers are welcome. :P

Note: I haven't actually tested it, so I hope it works.

EDIT: I thought of a really crazy way to save another byte when I woke up this morning: make the lddr run all the way through flash down to de=0. :hyper:

Code: [Select]
xor a
REP_NEXT
call unlockflash
REP_NEXT
call rVersionEnd
ld a, $10


unlockFlash:
di
push af
in a, (06)
push af

REP_NEXT
ld hl, returnPointz+$8138-$80FE
ld de, $8138

ld a, d
out (05), a
dec a
ld i, a
dec a
out (06), a

in a, (02)
and e
jr z, $+4
ld e, $02

ld b, d
ld c, e
lddr

ex de, hl
add hl, sp
ex de, hl
ld sp, $82A9+$4000

jp nz, $4529
call $4276


returnPointz:
ex de, hl
ld sp, hl

out (05), a
pop af
out (06), a
pop af
out ($25), a

bcall(_flashWriteDisable)
ret


rVersionEnd:
Title: Re: Fullrene
Post by: thepenguin77 on March 28, 2012, 10:27:08 am
Ok, that's ridiculous. But it will totally be in the next version.

On another note, has anyone actually used this with success?
Title: Re: Fullrene
Post by: Darl181 on April 01, 2012, 07:29:35 pm
Quote from: thepenguin77 on March 28, 2012, 10:27:08 am
On another note, has anyone actually used this with success?
If you mean the attached appvar, then yes.  I'm running a 11kb program with no problems :)
(btw it also works in wabbit)
Title: Re: Fullrene
Post by: DJ Omnimaga on April 02, 2012, 07:59:07 pm
Quote from: thepenguin77 on March 26, 2012, 12:47:11 am
Oh, right, I know why that is. You were probably using bootfree which doesn't contain the same flash unlock exploits as the TI boot code. I don't think I can really make it work with boot free (unless it has it's own specialized unlock routine)
So what would I need to do to get it to work in Wabbit? Do I need to create a new ROM with a special program or something? I hate creating ROMs because the last time I did with VTI it took like 30 minutes to dump... ???
Title: Re: Fullrene
Post by: thepenguin77 on May 05, 2012, 02:44:19 pm
Sorry for the super late response. (I often forget to check the Axe subforum)

You need a rom based off of a real calculator. This means you'll have to use rom8x or similar to get the boot code off of your calculator.
Title: Re: Fullrene
Post by: parserp on May 14, 2012, 07:22:26 pm
Quote from: thepenguin77 on March 25, 2012, 05:54:22 pm
Just put Fcdf() or Fcdf()r very early in your program to use them. Preferably, don't force quit after you use it.
What do you mean by that?

EDIT: also, this works great for me :D, but not on people with 83+ s. D: (I am using Fcdf())
Title: Re: Fullrene
Post by: C0deH4cker on May 14, 2012, 07:24:30 pm
I assume it will crash the calculator, or it will leave flash unlocked.
Title: Re: Fullrene
Post by: BalancedFury on May 14, 2012, 07:25:11 pm
oh okay that makes more sense
I was gonna ask the same thing parser did, but then I realized I would be ninja;d by parser
Title: Re: Fullrene
Post by: parserp on May 14, 2012, 07:26:56 pm
hmm, that makes sence, but, what about how do you force quit?
Title: Re: Fullrene
Post by: C0deH4cker on May 14, 2012, 07:30:20 pm
Returnr

Also, it looks like fullrene rewrites the program exit function to restore the stack pointer to the original location and disable flash writing.

EDIT: Meaning if you force quit (which restores the stack pointer to the value it was before the program was run and rets back to the old pc), unknown problems may arise.
Title: Re: Fullrene
Post by: Matrefeytontias on November 09, 2013, 04:09:19 pm
Epic bump,

It seems that this doesn't work on my TI-83+.fr (2010 edition) under OS 1.19. I have a 15547 bytes program starting with :
Code: [Select]
:.IKARUGAX
:#Axiom(FULLRENE)
:Fcdf()
:ReturnI compiled it for MirageOS, I launched it from RAM (so I had around 8k free RAM when I launched it), it apparently launched properly, and when it was about to exit, it crashed.

Any idea ?

EDIT : it has boot code 1.01 and base code 1.19
Title: Re: Fullrene
Post by: thepenguin77 on November 10, 2013, 02:13:44 am
So, weirdly enough, it doesn't crash for me on the 1.01fr boot code. This means I have basically no idea what is going on. I tried different compile targets and running with Mirage, but none of that had any effect. And the part of the boot code this calls is unchanged in the fr version.

The best thing I can say is use Returnr. Not allowing Fullrene to finish isn't really a good practice, but it's not actually going to hurt anything. My only guess would be an old Axe version, but if you're up to date, then I have no idea.

I attached a version of the stripped down program that runs correctly on the rom, see what it does for you. (It's a noshell compile, so you can use Asm( for maximum isolation).
Title: Re: Fullrene
Post by: DJ Omnimaga on November 10, 2013, 02:15:37 am
Wow I didn't know there was a Boot 1.01... O.O
Title: Re: Fullrene
Post by: Matrefeytontias on November 10, 2013, 03:32:13 am
Asm(prgmFULLTEST) ran fine, exited fine and didn't mess with the free ARC display. So I guess it worked.
Title: Re: Fullrene
Post by: thepenguin77 on November 10, 2013, 01:11:53 pm
Quote from: Matrefeytontias on November 10, 2013, 03:32:13 am
Asm(prgmFULLTEST) ran fine, exited fine and didn't mess with the free ARC display. So I guess it worked.

Well, that means the problem isn't FULLRENE and is somehow the way you are compiling it.
Title: Re: Fullrene
Post by: Matrefeytontias on November 10, 2013, 03:07:04 pm
I updated my Axe version from 1.2.1a to 1.2.2 ... now the resulting 15k MirageOS program that uses FullRene doesn't even run properly ... It does run indeed, but all pointers are messed up, and it still crashes on exit (using classic Return, not Returnr).
EDIT : I finally remembered that Axe 1.2.2 moved the A-θ variables buffer to $90D3, which area I used in my program. Oh well.
I had no more success with Return, and using Returnr made MirageOS angry, so I had to use Asm(CDB940) as a return instruction to skip the Fullrene custom exit point ($409B is MirageOS's call _quitToShell). And it finally works :D

It would be nice if I could simply use Return though.
Title: Re: Fullrene
Post by: Matrefeytontias on March 04, 2014, 06:44:00 am
Bump,

Worms went over 8192 bytes too, so I tried using it. Well, on my (as always) TI-83+.fr 2010 edition, it still runs well and crashes on exit (with MirageOS, still). I did Fcdf() at the very start and just Return, and it crashes. I again had to use Asm(CDB940).
Title: Re: Fullrene
Post by: Matrefeytontias on March 05, 2014, 06:10:24 am
Bump again,

Apparently, not closing the RAM page causes the calc not to detect TI-Connect. I only have to force the OS closing the page with a manual RAM clear and everything works again. Would it be possible to have a separate program closing the page for us that would be to be ran outside of MirageOS ?
Title: Re: Fullrene
Post by: thepenguin77 on March 12, 2014, 03:03:42 pm
Quote

Bump again,


Apparently, not closing the RAM page causes the calc not to detect TI-Connect. I only have to force the OS closing the page with a manual RAM clear and everything works again. Would it be possible to have a separate program closing the page for us that would be to be ran outside of MirageOS ?


What do you mean by closing the ram page? Do you mean making C000 non-executable again? I feel like if I made that program, it's just going to crash for you.
Title: Re: Fullrene
Post by: Matrefeytontias on March 13, 2014, 03:02:04 am
Yes I mean making $C000-$FFFF non-executable. Apparently TI-Connect only wants it this way. And well, we can't know until we try.
Title: Re: Fullrene
Post by: thepenguin77 on March 13, 2014, 09:16:52 pm
Here you.
Title: Re: Fullrene
Post by: chickendude on November 09, 2014, 04:30:55 am
Btw, is there a copy of this routine available for assembly programmers? I'm not exactly sure what to do with the source in the first post, for example what are all the REP_NEXT macros? I've been able to get around the C000 limit on the 84+/SE, but haven't figured out how to get around it on the 83+BE.
Title: Re: Fullrene
Post by: Runer112 on November 09, 2014, 11:25:29 am
Just ignore all the REP_NEXT macros. They're markers to signal to the Axiom system that the next instruction references an address that needs to be linked up at compile time.
Title: Re: Fullrene
Post by: chickendude on November 10, 2014, 03:26:45 am
Thanks, i just tested it out on my 83+ and it works, but exiting the program crashes the calc. It exits just fine on the 83+SE, though.
Title: Re: Fullrene
Post by: Runer112 on November 10, 2014, 12:55:04 pm
If I recall, there was at least one bug that occurred on real 83+ hardware but not in any emulator, and it could never successfully be pinpointed and solved. You may be running into that bug. Or, perhaps code flow isn't still working quite right due to the translation from its Axiom form, which you might be able to solve by debugging it in an emulator.
Title: Re: Fullrene
Post by: chickendude on November 10, 2014, 06:58:59 pm
I've followed it in a debugger and it  works just fine or seems to at least on TilEm. It also works fine on the 83+SE, but running it on the real hardware for the 83+ (or at least mine) causes it to crash upon exit.
Title: Re: Fullrene
Post by: Matrefeytontias on November 10, 2014, 07:10:59 pm
Don't bother trying, it's a Fullrene bug that was never fixed. I had exactly the same problem with IkarugaX, my workaround was to just return from the program without going through Fullrene's exit handler.
Title: Re: Fullrene
Post by: chickendude on November 10, 2014, 10:43:54 pm
Does that have any other side effects other than not reopening the $C000 protection? It seems to work ok for the 15mhz calcs, so for the meantime i'll just add a check  for those. I'll read up on the ports over at WikiTI and see if i can figure out what exactly the code's doing.
Title: Re: Fullrene
Post by: chickendude on November 11, 2014, 03:45:09 am
Ok, looking through the 83+-specific code:
Code: [Select]
        ex de, hl    ;HL is too close to SP
        ld (hl), b    ;b is zero
    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.01It seems like there are a couple shortcuts taken, for example instead of outputting $7 to port 05 they send $1F to both port 05 and 06, i assume the upper bits of port 05 are unused? Then it runs the 84+ code? I'm also not sure how we get back to "returnPoint". I've really got no idea what's going on in the unlock flash section, is the size of the routine taken into consideration? I tried adding some extra code to debug it but it caused weird stuff to happen when exiting. I see that some stuff ($8214-$8167 bytes) is getting LDDR'd into $8214, though i'm not sure where all these numbers come from. The code getting copied stretches into the main program code (ie. beyond Fullrene).