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.

Current Version

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)
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)
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

The axe code does exactly what I wanted, thanks! Now I can make a password program that will run on RAM clears!

Go to the homescreen, pull a battery, turn it on Sorry about that.

What order does zStart do thins on a RAM clear?  What action happens first, second, etc (stuff like omnicalc installing, program to be run on RAM clear run, stuff like that)

• Check Clear
• Jump to app
• Check Vars and Clear
• Close edit buffer
• Load appVar

=================== From here down runs when you quit zStart also ========================

• Check installed flag
• Do degress/radians
• Do Diagnostic mode
• Do mathprint, mathprint popup, and stat wizards
• Install catalog help hook
• Install axe hook
• Clear port (2E) delay (making ONSCRPT if necessary)
• Set font hook (making the first VAT entry if necessary)
• Handle picture (making OFFSCRPT if necessary)
• Set contrast
• Set ALCDFIX delay
• Make Omnicalc appvar and set hooks (first VAT entry)
• Unlock $C000 (ONSCRPT)
• Set programs parser hook (first VAT entry)
• Set shortcut rawKeyHook
• Disable the headphone hack if it is running
• Run "Run on zStart" program

=================== From here down only happens on ramclears ==================

• Run "Run on RamClear" program
• Reopen edit buffer
• Jump to specific ram cleared message

Hopefully this clears it all up and you can trace back any problems you might have had or will have. (It also shows just how much crap I have in this app )

I agree that OFFSCRPT is a huge source of conflict, but the problem is that, like qwerty said, it's far too late to implement a standard. The reason I say this is because there are quite a few apps that use OFFSCRPT that haven't been touched in several years. We could adapt this new technique of OFFSCRPT cooperation and then the old program would just destroy it.

;VVVVVVVV see edit
The ambitious way to fix this problem would be to make an app that handles this huge mess. What you would do is run a program, let it make its OFFSCRPT, then have the OffScrpt app save that OFFSCRPT into its database. This would continue until the app has a copy of all of the OFFSCRPTs you want to run. Then you go into the app, set priorities on the different OFFSCRPTs and let it run.

The tricky part with this app though would be making it run when shutting down. I believe it can be done through a appChangeHook, but I'm not positive. I think a better solution would be to patch the code that calls OFFSCRPT and instead have it call the app. (Or this app could make an OFFSCRPT )
;^^^^^^^

The less ambitious way to somewhat fix this problem is to only use an OFFSCRPT when you absolutely have to. This means don't destroy OFFSCRPT if you aren't using it. (Not even going to say it)



Edit:
    That won't work. I forgot how OFFSCRPTs work. OFFSCRPTs are exactly what they sound like, off scripts. This means they only get run when you turn the calculator off. In order to run when the calculator turns back on, I would assume that nearly every OFFSCRPT sets a getCSC hook so that as soon as the calculator turns back on, the main app gets run.

In short, only the last OFFSCRPT would appear to get run.

Edit2:
    This also means that standardization of OFFSCRPTs is fundamentally impossible. (Or just really really ugly, glitchy, and hacky)

8 apps, 31 programs, 13 appvars, and 2 groups

Breakdown:

Apps:

• 5 community made utilities
• 2 TI-Database apps
• 1 made by me

Programs:

• 8 community made ASM games
• 2 community made AXE games
• 9 of my ASM games
• 4 flash editing utilities (3 of which delete the certificate)
• 3 of my general utilites
• 5 dependent programs

I may not have much, but I have power :D

Quote from: Sorunome on October 14, 2011, 10:18:51 am

I found a bug: With OS 2.43 it doesn't display always the grayscale pic when turning calc on, with OS 2.55MP it worked... :S

The picture even works on my TI-83+BE (yes, I am mad )

Sorunome's problem is DCS. Go tell kerm to stop destroying ONSCRPT when he doesn't need to.


For Hayleia... I don't even know... There are so many reasons why this shouldn't work. Like, you don't even understand, if you were to ask would it work, my answer would be no, it would never work, ever.[/shock and awe]

After looking into it some more, you just pulled off the craziest hack I've ever seen. Some how, you managed to slip through all of the all of the weird memory maps that I use to pull the picture into the right spot (it doesn't work if the picture is in ram for instance). Then, the strangest part of it all, and the part that I thought was impossible to get around, was the crystal timers. You have managed to evade my crystal timers! And the way you do it is even weirder, your calculator reads data from the LCD thinking it is the crystal timer, and then when it hits a certain byte, it passes the test and continues to draw the picture.

The downsides , if you have quite a few of things in ram, it will corrupt them. That amount is miniumum 8811 bytes, but more like 10,000 bytes in practice. Also, there are some pictures that will crash. If the last row of your picture is entirely white, it's going to crash. (It's slightly more specific, but that will do it.)

In all, awesome. zStart is the most anti-83+BE thing I've ever written and you made it work.

I don't know what I changed......but it works now....wired......

Umm... yay?

Well, Axe 1.0.4 and above has a new feature: Zooming through a program instead of compiling. As there are shourtcuts to compile the programs in editing screen, it would be cool if there could also be a shourtcut for zooming it. And it is atm randomly weather it zooms or compiles.

I'll talk to quigibo. He'll fix the problem, and then, hopefully, he'll give me the option to Zoom so I can give you the option to Zoom

When you edit an archived program, I add $80 to the last letter of the program name. This is so I can have a temporary copy in ram and not make a huge mess by have two instances of the same program.

If you found that program, most likely you exited the program editor without letting the program save. The only way I can think to do this would be to pull your batteries out. But in any case, that program is valid except for the last letter in its name, and if you edit it, when you quit, it will go back to normal.

Along with Geekboy's suggestion. You also need to reenable interrupts. When the interrupt fires, there is an automatic DI that gets run, so you need to undo it.