[TI ASM] Application Header Format
Moderator: MaxCoderz Staff
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
[TI ASM] Application Header Format
I'm adding app header generation and app signing (via Wappsign) to Brass, and have hit upon the problem that I can't work out what format the app header is meant to follow.
The app header program gives me a header that has a different format to the app header in the example that comes with the SDK (and, as far as I can tell, neither work as expected, though that's probably more a case of my mixing up the two different forms).
Is there an app header reference anywhere?
The app header program gives me a header that has a different format to the app header in the example that comes with the SDK (and, as far as I can tell, neither work as expected, though that's probably more a case of my mixing up the two different forms).
Is there an app header reference anywhere?
For Wizards I use the following header with Wabbit:
Code: Select all
.org $4000
.db $80,$0F ;Field: Program length(MUST BE 1ST 2 BYTES)
.db 0,0,0,0 ;don't worry about this
.db $80,$12 ;Field: Program type
.db $01,$04 ;leave as is
.db $80,$21 ;Field: App ID
.db $01
.db $80,$31 ;Field: App Build
.db $01
.db $80,$48 ;Field: App Name
.db "Wizards " ;MUST BE 8 BYTES
.db $80,$81 ;Field: App Pages
.db $02 ;Number of pages(don't worry wabbit corrects this)
.db $80,$90 ;No default splash screen (below is just data, leave it)
.db $03,$26,$09,$04,$04,$6f,$1b,$80,$02,$0d,$40,$a1
.db $6b,$99,$f6,$59,$bc,$67,$f5,$85,$9c,$09,$6c,$0f
.db $b4,$03,$9b,$c9,$03,$32,$2c,$e0,$03,$20,$e3,$2c
.db $f4,$2d,$73,$b4,$27,$c4,$a0,$72,$54,$b9,$ea,$7c
.db $3b,$aa,$16,$f6,$77,$83,$7a,$ee,$1a,$d4,$42,$4c
.db $6b,$8b,$13,$1f,$bb,$93,$8b,$fc,$19,$1c,$3c,$ec
.db $4d,$e5,$75
.db $80,$7F
.dw 0,0,0,0,0,0,0,0,0,0 ;(Padding is important!!!!)
Revolution Software
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Whats wrong with multipaged apps? theres no difference in the header other than number of pages field.
You should also becareful on the appname, I remember some old TI apps were using 0 instead of spaces and that resulted a ti connect incapatibilty, and even though logic would say changing $80,$4* to the length of the name TI has decided that its better if their programming departments don't understand what each are doing.
You should also becareful on the appname, I remember some old TI apps were using 0 instead of spaces and that resulted a ti connect incapatibilty, and even though logic would say changing $80,$4* to the length of the name TI has decided that its better if their programming departments don't understand what each are doing.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
I'm currently padding the name with spaces, truncating to 8 characters if it's too long.
As for what's wrong with multipage apps - I have no idea, otherwise I would have fixed it
The .hex files load into Flash debugger (no error message displayed) but the app doesn't appear in the Apps menu (and 'erases' the old app if one was installed with the same name).
Wappsign signs it (and appears to fill the unused $4000->$8000 range with $FF), but loading it into Flash Debugger ends up throwing lots of 'invalid instruction' errors. Sending it to PTI/real calculator displays a 'Receiving *<app name>' message, but gives up half way through (no validation).
I'm guessing a lot here, but confirmation would help - I can see that page 0 is at $4000, size $4000, and run at $4000. I'm guessing that page 1 is at $8000, also size $4000, and is either run from $4000 (paged in) or $8000 (?)
As for what's wrong with multipage apps - I have no idea, otherwise I would have fixed it
The .hex files load into Flash debugger (no error message displayed) but the app doesn't appear in the Apps menu (and 'erases' the old app if one was installed with the same name).
Wappsign signs it (and appears to fill the unused $4000->$8000 range with $FF), but loading it into Flash Debugger ends up throwing lots of 'invalid instruction' errors. Sending it to PTI/real calculator displays a 'Receiving *<app name>' message, but gives up half way through (no validation).
I'm guessing a lot here, but confirmation would help - I can see that page 0 is at $4000, size $4000, and run at $4000. I'm guessing that page 1 is at $8000, also size $4000, and is either run from $4000 (paged in) or $8000 (?)
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
The first execute opcode should be at $4080(atelast thats the important one), where the app chooses to run after that fact is entirely up to it.
You are leaveing room on the last page for the signature right? It needs 96 bytes, so even if it is a 1 page app it needs 96 bytes on the end. I'm pretty sure Wappsign doesn't do any checking to verify if the number of pages is correct (it will simply tack on the signature even if it leaves the page bounds).
I can't think of much more that would mess with multipaged apps and not single paged apps.
You are leaveing room on the last page for the signature right? It needs 96 bytes, so even if it is a 1 page app it needs 96 bytes on the end. I'm pretty sure Wappsign doesn't do any checking to verify if the number of pages is correct (it will simply tack on the signature even if it leaves the page bounds).
I can't think of much more that would mess with multipaged apps and not single paged apps.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Yes, sorry, I should have said that - if you take a look at this there's a .block 128 after the start of page 0 to allow space for the header.
I didn't know about the final 96 bytes (not that that's an issue at the moment) - I'll make sure to add a check to the assembler to make sure you're not overwriting it with your own code.
Here's a test app - doesn't contain any code, just the sequence $33,$66,$99 on both pages:
... produces:
Erm, actually, that does look wrong. The record at $8000 is missing $33.
I think I need to check the hex output again
I'll get back to you on this one.
I didn't know about the final 96 bytes (not that that's an issue at the moment) - I'll make sure to add a check to the assembler to make sure you're not overwriting it with your own code.
Here's a test app - doesn't contain any code, just the sequence $33,$66,$99 on both pages:
Code: Select all
.binarymode ti8xapp ; TI-83+ Application
.defpage 0, $4000, 16*1024, $4000
.defpage 1, $8000, 16*1024, $4000
.page 0
.block 128 ; Advance 128 bytes for header
.db $33,$66,$99
.page 1
.db $33,$66,$99
Code: Select all
:20400000800F000000008012010480210180310180484150502020202020808102809003C7
:20402000260904046F1B80020D40A16B99F659BC67F5859C096C0FB4039BC903322CE003E0
:2040400020E32CF42D73B427C4A07254B9EA7C3BAA16F677837AEE1AD4424C6B8B131FBBC7
:20406000938BFC191C3CEC4DE575807F000000000000000000000000000000000000000023
:04408000336699FF0B
:038000006699FF7F
:00000001FF
I think I need to check the hex output again
I'll get back to you on this one.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
You can tell I use hex formats a lot...
I would just insert a ":0200000200rpcs" record between the main data chunks?
I assume, therefore, that '$8000' is never used, and the address field would be $4000 again when the second page starts again?
In which case, the .defpage directive is almost entirely redundant (and confusing) in Brass.
I would just insert a ":0200000200rpcs" record between the main data chunks?
I assume, therefore, that '$8000' is never used, and the address field would be $4000 again when the second page starts again?
In which case, the .defpage directive is almost entirely redundant (and confusing) in Brass.
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
YupI would just insert a ":0200000200rpcs" record between the main data chunks?
I assume, therefore, that '$8000' is never used, and the address field would be $4000 again when the second page starts again?
Still good for rom generation.In which case, the .defpage directive is almost entirely redundant (and confusing) in Brass.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
All you really need to know for a page is the size (to stop you from going over the bounds) and, optionally, an origin (to save you from typing in .org). I can't really see any situation where you'd need to add an offset into the file, as you'd assume the pages would be consecutive in the binary.
That seems a lot more sensible, in my mind - can you see any problems with it?
Code: Select all
.defpage number, size, [org]