Doors CS 7: 3 app pages, 49KB. Is this ok?
Yes, I have the space, provided you make the feature set worth it.
 91%  [ 41 ]
No, even with the features I can't afford three app pages.
 8%  [ 4 ]
Total Votes : 45

ZagorNBK wrote:
That sounds like a good idea.
Yeah, that sounds like an excellent idea! At the risk of sounding n00bish, do we yet know of a dependable way to differentiate the nSpire from a real 83/84 series? I know about bits 5 and 7 of Port 2 to differentiate 83+, 83+ silver, or 84+/84+ silver, but let's see what WikiTI has to say...

Edit: Well, there's Port 21h to differentiate the 84+ and 84+SE, but where does that leave us on the nSpire issue? http://wikiti.brandonw.net/index.php?title=83Plus:Ports:21

Edit2: Ah, of course, the nSpire version numbers should do the trick, crossposted the code below from WikiTI for my reference:


Code:
BCALL _GetBaseVer ; EF6F4C
push af           ; F5
ld a,b            ; 78
BCALL _SetXXOP1   ; EF8C47
BCALL _DecO1Exp   ; EF6742
BCALL _DecO1Exp   ; EF6742
pop af            ; F1
BCALL _SetXXOP2   ; EF8F47
rst 30h           ; F7
BCALL _StoAns     ; EFBF4A
;;-FloppusMaximus
This could give people a great reason to switch to Doors Smile
Something occurs to me, though, BrandonW. How would I be able to differentiate actual illegal instructions from data with that value? Even replacing an instruction-only chunk of code would be challenging, as I'd have to differentiate between one, two, and three-byte instructions.
make a LUT table with the page + address of all instances of undocumented instructions in your code, and do it at startup when you first detect the Nspire.
elfprince13 wrote:
make a LUT table with the page + address of all instances of undocumented instructions in your code, and do it at startup when you first detect the Nspire.
No no, but we're talking about other people's code, not mine. I already made my code nSpire-proof. Smile
KermMartian wrote:
elfprince13 wrote:
make a LUT table with the page + address of all instances of undocumented instructions in your code, and do it at startup when you first detect the Nspire.
No no, but we're talking about other people's code, not mine. I already made my code nSpire-proof. Smile

I wouldn't be so sure about that: DoorsCS has strange bugs on the N-Spire that didn't occur on a TI-83+. For example, if I press the [ON] button while being in DoorsCS, the calc will shut down but won't start up again. The only way to make the 84+ boot again is by reinstalling the whole N-Spire OS.

Other bugs in DoorsCS freeze the calc, and because the N-Spire saves the calc's state and shuts down when I take out the keyboard, I don't have the time to take out the batteries to do a RAM clear. The only way to RAM clear is by either reinstalling the OS or by pressing the Reset button on the N-Spire, which does a RAM and ROM clear, thus erasing all data on the 84+.

That's way I switched to MirageOS, even though I prefer DoorsCS. Also note that MirageOS works perfectly (with the patch) on the N-Spire...
Kerm, there's no way around the data vs. code issue. It's going to be inherently buggy, but if the program doesn't work anyway on the Nspire, what's it going to hurt to try it?

To determine if you're running on an Nspire, the only way to tell is by checking the OS version (which you said, and I really do not like), or look for the presence of ED ED on the boot page, which takes a second, but it works. I have some code somewhere that does that...

Here's the crappy group of functions I came up with a long time ago for Nspire-specific stuff:


Code:

LockKeypad:
;Locks the Nspire to the 84+SE keypad (wrong keypad error with Nspire one).
;Inputs:  None
;Outputs: None
;Notes:   This must be run from RAM.
;         Destroys appData - appData+4
;         Requires Flash unlocked.
        ld a,03h
execInvalid:
        push af
        ld hl,3FF0h
        ld de,appData
        ld bc,5
        ldir
        xor a
        ld de,7FF0h
        ld b,0EDh
        call WriteAByte
        xor a
        ld de,7FF1h
        ld b,0EDh
        call WriteAByte
        pop bc
        xor a
        ld de,7FF2h
        call WriteAByte
        xor a
        ld de,7FF3h
        ld b,10h
        call WriteAByte
        xor a
        ld de,7FF4h
        ld b,0C9h
        call WriteAByte
        call 3FF0h
        xor a
        ld hl,appData
        ld de,7FF0h
        ld bc,5

WriteFlash:
;Writes BC bytes from HL to ADE
;Inputs:  A is page
;         HL is source
;         DE is destination
;         BC is number of bytes to write
;Outputs: ADE is next destination location
;         HL is next source location
;         BC=0
;Notes:   This must run from RAM.
;         Requires Flash unlocked.
        push af
WriteFlashLoop:
        pop af
        push af
        push bc
        ld b,(hl)
        call WriteAByte
        pop bc
        bit 7,d
        jr z,noOverflow
        res 7,d
        set 6,d
        pop af
        inc a
        push af
noOverflow:
        inc hl
        dec bc
        ld a,b
        or c
        jr nz,WriteFlashLoop
        pop af
        ret

UnlockKeypad:
;Unlocks the Nspire from the 84+SE keypad (no more wrong keypad error).
;Inputs:  None
;Outputs: None
;Notes:   This must be run from RAM.
;         Destroys appData - appData+4.
;         Requires Flash unlocked.
        ld a,04h
        jr execInvalid

IsNspire:
;Determines if calculator is an Nspire.
;Inputs:  None
;Outputs: Carry set if NOT Nspire
;Notes:   This must run from RAM.
;         Destroys all
        scf
        in a,(2)
        bit 7,a
        ret z
        in a,(21h)
        and 3
        scf
        ret z
        in a,(6)
        push af
        ld a,7Fh
        out (6),a
        ld hl,4000h
        ld bc,4000h
isNspireLoop:
        ld e,(hl)
        inc hl
        dec bc
        ld a,b
        or c
        scf
        jr z,exitIsNspire
        ld a,e
        cp 0EDh
        jr nz,isNspireLoop
        ld e,(hl)
        inc hl
        dec bc
        ld a,b
        or c
        scf
        jr z,exitIsNspire
        ld a,e
        cp 0EFh
        jr nz,isNspireLoop
exitIsNspire:
        pop bc
        ld a,b
        out (6),a
        ret

EraseFlash:
;Erases Flash sector (sets all to 0FFh)
;Inputs:  A is Flash page within sector
;Outputs: A is start of next Flash sector
;         All registers preserved
;Notes:   This must run from RAM.
;         Requires Flash unlocked.
        push bc
        and 0FCh
        ld b,4
eraseLoop:
        call EraseFlashPage
        inc a
        djnz eraseLoop
        pop bc
        ret

EraseFlashPage:
;Erases Flash page (sets all to 0FFh)
;Inputs:  A is Flash page
;Outputs: All registers preserved
;Notes:   This must run from RAM.
;         Requires Flash unlocked.
        push hl
        push de
        push af
        ld bc,4000h
        ld de,4000h
        push af
loop:   pop af
        push af
        push bc
        ld b,0FFh
        call WriteAByte
        pop bc
        inc de
        dec bc
        ld a,b
        or c
        jr nz,loop
        pop af
        pop af
        pop de
        pop hl
        ret

WriteAByte:
;Writes byte B to A:DE
;Inputs:  A is page
;         DE is address
;         B is byte to write
;Outputs: DE=DE+1
;         All preserved
;Notes:   This must run from RAM.
;         Requires Flash unlocked.
        push af
        push bc
        push hl
        ld c,a
        in a,(6)
        push af
        ld a,c
        ld hl,(OP1)
        push hl
        push af
        ld a,8
        out (6),a
        ld hl,OP1
        ld (hl),b
        .db 0EDh,0EFh
        pop af
        out (6),a
        ldi
        pop hl
        ld (OP1),hl
        pop af
        out (6),a
        pop hl
        pop bc
        pop af
        ret

unlockFlash:
;Unlocks Flash protection.
;Inputs:  None
;Outputs: Destroys all
        ld a,1
        ld (appInfo+2),a
        bcall(50CBh)
        ret
People on SAX and IRC suggested that in light of all the MathPrint headaches with TI-BASIC programs, Doors CS should automatically enable Classic mode when running TI-BASIC programs. I consider this a worthy addition to the suggested feature set.
KermMartian wrote:
People on SAX and IRC suggested that in light of all the MathPrint headaches with TI-BASIC programs, Doors CS should automatically enable Classic mode when running TI-BASIC programs. I consider this a worthy addition to the suggested feature set.


Absolutely, but make a way to flag a program to make DCS NOT convert it when running. I don't know what MathPrint is, but I assume it would make output nice for math programs.
foamy3 wrote:
KermMartian wrote:
People on SAX and IRC suggested that in light of all the MathPrint headaches with TI-BASIC programs, Doors CS should automatically enable Classic mode when running TI-BASIC programs. I consider this a worthy addition to the suggested feature set.


Absolutely, but make a way to flag a program to make DCS NOT convert it when running. I don't know what MathPrint is, but I assume it would make output nice for math programs.
Well, just the way BASIC programs should always turn AxesOff and clear the graphscreen on the assumption that the axes may be on and/or the graphscreen might be dirty, I hope that BASIC programmers will explicitly turn on MathPrint when they want their programs to use it. Do you think that is sufficient, or do I need to make a new DCS header to tell DCS to not disable MathPrint?
KermMartian wrote:
foamy3 wrote:
KermMartian wrote:
People on SAX and IRC suggested that in light of all the MathPrint headaches with TI-BASIC programs, Doors CS should automatically enable Classic mode when running TI-BASIC programs. I consider this a worthy addition to the suggested feature set.


Absolutely, but make a way to flag a program to make DCS NOT convert it when running. I don't know what MathPrint is, but I assume it would make output nice for math programs.
Well, just the way BASIC programs should always turn AxesOff and clear the graphscreen on the assumption that the axes may be on and/or the graphscreen might be dirty, I hope that BASIC programmers will explicitly turn on MathPrint when they want their programs to use it. Do you think that is sufficient, or do I need to make a new DCS header to tell DCS to not disable MathPrint?


Oh, I didn't think about that. That's definitely valid.
KermMartian wrote:
foamy3 wrote:
KermMartian wrote:
People on SAX and IRC suggested that in light of all the MathPrint headaches with TI-BASIC programs, Doors CS should automatically enable Classic mode when running TI-BASIC programs. I consider this a worthy addition to the suggested feature set.


Absolutely, but make a way to flag a program to make DCS NOT convert it when running. I don't know what MathPrint is, but I assume it would make output nice for math programs.
Well, just the way BASIC programs should always turn AxesOff and clear the graphscreen on the assumption that the axes may be on and/or the graphscreen might be dirty, I hope that BASIC programmers will explicitly turn on MathPrint when they want their programs to use it. Do you think that is sufficient, or do I need to make a new DCS header to tell DCS to not disable MathPrint?


What's MathPrint?
It's something in the new OS 2.53:

http://www.cemetech.net/forum/viewtopic.php?t=4229
http://www.ticalc.org/archives/news/articles/14/145/145828.html
Hey, Kerm. The countdown says 37 days. progress, or postponment mark two? I'm totally okay with the second option.
KermM says he won't even get started until April 15th.
SirCmpwn wrote:
KermM says he won't even get started until April 15th.
April 16th, actually, the day that the more-or-less final draft of my Master's thesis is due.
I was wondering if it was 37 days or -1037 at first
Well, it has decreased every day for a while now, so I think it's 37. However, I don't think that it's entirely accurate, because there is no way KermM is going to write a whole app in that time.
KermMartian wrote:
SirCmpwn wrote:
KermM says he won't even get started until April 15th.
April 16th, actually, the day that the more-or-less final draft of my Master's thesis is due.


Still looking for people to proofread your thesis?
Ultimate Dev'r wrote:
KermMartian wrote:
SirCmpwn wrote:
KermM says he won't even get started until April 15th.
April 16th, actually, the day that the more-or-less final draft of my Master's thesis is due.


Still looking for people to proofread your thesis?
Absolutely, I'll send it along when I finish the chapter I'm working on.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... , 12, 13, 14  Next
» View previous topic :: View next topic  
Page 13 of 14
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement