Author Topic: Prizm File formats  (Read 9037 times)

0 Members and 1 Guest are viewing this topic.

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Prizm File formats
« on: March 25, 2011, 01:08:56 am »
While the .g3a format is useful for add-ins, it's bulky and filled with unused space. Furthermore, it greatly increases the amount of memory used for small programs. In light of this, several people, myself included, have come up with new file format proposals to use in an upcoming shell.

z80man's proposal:

Code: [Select]
.org $30002000
data.l $xxxxxxxx   ;header for shell   
data.l $00000002   ;size of executable
data.b $01         ;true if MMU is to be reset
data.b $03         ;speed setting, 0-3
data.b $00         ;true if interrupts are to be disabled
data.b $01         ;true if fpu interpreter is to be enabled
data.b $01         ;true if all general purpose registers are to be cleared before execution
data.b $01         ;true if VRAM and screen are to be cleared
data.b $00         ;true if executable space is to be cleared
data.b $00         ;true if to begin execution in priveleged mode
;next 176 bytes are to be used for future expansion
data.l $00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000,$00000000
;next 64 bytes are for program description. Null terminated
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
;256 color 64 * 64 icon
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
data.b $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
;executable begins at $30004100
RST
NOP

Josjuice's proposal:
http://wiki.prizmwiki.co.cc/wiki/User:JosJuice/File_stuff

My proposal: Probably the most complex, but also probably the most flexible, since addresses aren't explicitly defined and even changes in the format itself can be accommodated. A sample program demonstrating the format with a 32x32 16 bit color icon is attached below. The header itself takes up marginally more than 2 KB.

Code: [Select]
Alternative: Uses a chunk based format (hereafter referred to as packets) in order to maintain compatibility with a wide range of data types
File header format:

Types of errors:
Type 1: Low severity parsing error. The user does not need to be informed and the parser can continue with little to no error handling.
Type 2: Moderate severity parsing error. The user may be informed if the program deems necessary and some error handling should generally be administered.
Type 3: High severity parsing error. The user should be informed and all parsing should be stopped to handle the error immediately.

Packets are identified by a 32 bit header in order to permit efficient register loading during parsing

Packet Bytes 1 & 2: ID bytes.
If the ID word is not recognized, then parsers must skip the packet.
The only time parsers are not allowed to skip packets is if the packets are on a special list (listed below). All programs must contain a copy of this list.
If the ID is found on the secondary list, the parser must return a type 3 error, since further parsing is either useless or impossible.
File Type
FileName
Main()

Packet Bytes 2 & 3: Size bytes.
The size bytes detail the size of the data without the header and are equal to the data size in bytes.
This means that if the packet needs to be skipped, then the address of the next packet is equal to the address of the first byte of data plus the size word.
If the size word is 0x00 00, then the size isn't applicable to the packet type.
If it is 0xFF FF, then the data size is unknown and a type 1 error should be returned.
All other words are valid sizes.
Within the file parsing program itself, each entry in the array of understood packets should include within it the earliest format version that the entry is compatible with.
If a version compatibility packet is present and the packet requires an earlier version than is available for certain packets, they should be skipped.
However, if the packet is a critical packet, then a type 3 error must be generated.

Types of packets:
Parent program: ID word is 0x00 00
Contains a 12 byte hex string designating the parent program. This may be a shell, a compiler, or any other program.
File type: 0x00 01
Details general information about the type of file, such as image data or executable program.
Two byte packet.
0x00 01: Executable SH3 Machine code (Prizm equivalent of .exe)
0x00 02: Routine library
FileName: ID word is 0x00 02
Contains an 8 byte ASCII file name of the form **** ****.*** where * can be any printable ASCII character.
The characters following the period are the file extension.
Program name should be padded with 0xFF bytes if not long enough. 12 bytes.
Version compatibility: ID word is 0x00 03
Four byte packet that details the earliest format version that should be applied to each packet.
If this packet is not present, a type 2 error should be generated.
The format for this packet is SB VV SS SV, where SB is the byte 0x55, VV is the version number in hex, SS secondary version number, and SV is the sub-version number.
For example, if the format was of version 01.04.10, then the data in the packet would be 55 01 04 10
Header packet: ID word is 0x00 10
Details additional file specific information, such as the author's name, file comments, references to other files,...
General purpose packet. Can include other packets within itself. Size is thus not applicable. Look for the header end packet.
Language: 0x00 11
Contains a three byte ASCII string detailing the language.
E.G. ENG for English, GER for German, etc...
Checksum: 0x00 12
Contains a 4 byte checksum of the data contained by the Main() packet. The checksum is a standard 32 bit checksum taken Mod 2^32
TimeStamp packet: 0x00 13
Fourteen byte packet consisting of YYYY MM DD HH MM SS, using the 24 hour clock with zero indexed values on the hour, minute, and second.
HeaderEnd: 0x01 00
Marks the end of a Header packet.
Size not applicable.
Icon Packet: 0x01 01
First byte is the number of colors used in the icon image. 0x02 is monochrome, 0x08 is 8 color, 0x10 is 16, etc.
If the first byte is 00 or another unsupported byte, a type 1 error should be thrown and the packet skipped.
If the program requires an icon and the first byte is invalid, the program may contine trying to parse the icon or it may substitute a default icon.
The second and third bytes of the packet are the width and height respectively of the icon.
Fourth byte is unused except for data alignment.
Note that the packet itself can only support icons up to 180 pixels on each side, so all sizes greater than this are automatically invalid.
It is recommended that only certain icon sizes be supported by the program.
If an invalid size is encountered, it may handle the errors in a similar fashion to an invalid color byte in the packet.
File size: 0x01 02
This four byte packet details the size of the data in Main() in bytes. It is not necessary for the format (although the program may require it).
Clock speed packet: 0x01 03
Contains a 6 byte field. The first byte states the CPU clock speed in hex, the second byte details the Peripheral clock frequency, and the third byte details the Bus clock.
The fourth and fifth bytes contain the values to be written to the FRQCR. If overwriting the register isn't desired, the value 0x2000 should be present in these bytes.
The sixth byte is contains the byte to be applied to UCLKCR. If the register is not to be overwritten, the value 0x20 should be used.
Remember that to overwrite UCLKCR, the data must be written with 0xA5 in the high byte of the write word.
MMUCR: 0x01 04
A four byte packet. If present, the data in the packet should be written to the MMU.
This packet need not be supported if the application is to execute outside the P1 and P2 memory areas.
File load: 0x01 05
Contains a series of ASCII filenames, each 8 bytes long, of the format   ^**** ****.***/
The ending "/" character is used to designate the end of each filename and the "*" character designates any printable ASCII character.
The character at the beginning of the string will be "^" if the file is to be loaded into memory and "#" if it is simply to be checked for its presence on the device.
If one or more of the files are not present, then the program should inform the user.
Main(): 0xFF FF
The packet containing all user data (such as code) within the file.
Size is not applicable.

File structure:
Bytes 0-4: ASCII representation of the file extension of the format ".***" If not all of the bytes are used, fill the remaining spaces with null bytes.
All bytes afterwards are contained within packets, which are to be arranged in the ascending order of their ID bytes.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline mikehill2003

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 279
  • Rating: +13/-4
    • View Profile
Re: Prizm File formats
« Reply #1 on: March 25, 2011, 01:13:40 am »
Wow! Thanks!

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Prizm File formats
« Reply #2 on: March 25, 2011, 03:06:35 am »
Would the calc be able to run custom formats though? This is what I am wondering, since I read somewhere that the only way to run something else than BASIC was through g3a files. So while games could be in a different format, the shell would have to be a g3a file.
« Last Edit: March 25, 2011, 03:07:12 am by DJ_O »

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Prizm File formats
« Reply #3 on: March 25, 2011, 03:07:32 am »
This would be for shells and things, similar to how TI-OS can't run some assembly programs designed for shells.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Prizm File formats
« Reply #4 on: May 09, 2011, 02:26:04 am »
Okay, there will be a slight change and version update to my format in order to accommodate different programming languages.

Code: [Select]
Alternative: Uses a chunk based format (hereafter referred to as packets) in order to maintain compatibility with a wide range of data types
File header format:

Types of errors:
Type 1: Low severity parsing error. The user does not need to be informed and the parser can continue with little to no error handling.
Type 2: Moderate severity parsing error. The user may be informed if the program deems necessary and some error handling should generally be administered.
Type 3: High severity parsing error. The user should be informed and all parsing should be stopped to handle the error immediately.

Packets are identified by a 32 bit header in order to permit efficient register loading during parsing

Packet Bytes 1 & 2: ID bytes.
If the ID word is not recognized, then parsers must skip the packet.
The only time parsers are not allowed to skip packets is if the packets are on a special list (listed below). All programs must contain a copy of this list.
If the ID is found on the secondary list, the parser must return a type 3 error, since further parsing is either useless or impossible.
File Type
FileName
Main()

Packet Bytes 2 & 3: Size bytes.
The size bytes detail the size of the data without the header and are equal to the data size in bytes.
This means that if the packet needs to be skipped, then the address of the next packet is equal to the address of the first byte of data plus the size word.
If the size word is 0x00 00, then the size isn't applicable to the packet type.
If it is 0xFF FF, then the data size is unknown and a type 1 error should be returned.
All other words are valid sizes.
Within the file parsing program itself, each entry in the array of understood packets should include within it the earliest format version that the entry is compatible with.
If a version compatibility packet is present and the packet requires an earlier version than is available for certain packets, they should be skipped.
However, if the packet is a critical packet, then a type 3 error must be generated.

Types of packets:
Parent program: ID word is 0x00 00
Contains a 12 byte hex string designating the parent program. This may be a shell, a compiler, or any other program.
File type: 0x00 01
Details general information about the type of file, such as image data or executable program.
Two byte packet.
0x00 01: Executable SH3 Machine code (Prizm equivalent of .exe)
0x00 02: Routine library
FileName: ID word is 0x00 02
Contains an 8 byte ASCII file name of the form **** ****.*** where * can be any printable ASCII character.
The characters following the period are the file extension.
Program name should be padded with 0xFF bytes if not long enough. 12 bytes.
Version compatibility: ID word is 0x00 03
Four byte packet that details the earliest format version that should be applied to each packet.
If this packet is not present, a type 2 error should be generated.
The format for this packet is SB VV SS SV, where SB is the byte 0x55, VV is the version number in hex, SS secondary version number, and SV is the sub-version number.
For example, if the format was of version 01.04.10, then the data in the packet would be 55 01 04 10
Language: 0x00 04
Contains a four byte ASCII string detailing the language of the code.
E.G. "JAVA" for Java, "LUA " for Lua, "ASM " for ASM and C, etc...
Note the appended space after "LUA" in order to make the string 4 bytes. Longer strings should be truncated.
Header packet: ID word is 0x00 10
Details additional file specific information, such as the author's name, file comments, references to other files,...
General purpose packet. Can include other packets within itself. Size is thus not applicable. Look for the header end packet.
FontLang: 0x00 11
Contains a three byte ASCII string detailing the font  language.
E.G. "ENG" for English, "GER" for German, etc...
Checksum: 0x00 12
Contains a 4 byte checksum of the data contained by the Main() packet. The checksum is a standard 32 bit checksum taken Mod 2^32
TimeStamp packet: 0x00 13
Fourteen byte packet consisting of YYYY MM DD HH MM SS, using the 24 hour clock with zero indexed values on the hour, minute, and second.
HeaderEnd: 0x01 00
Marks the end of a Header packet.
Size not applicable.
Icon Packet: 0x01 01
First byte is the number of colors used in the icon image. 0x02 is monochrome, 0x08 is 8 color, 0x10 is 16, etc.
If the first byte is 00 or another unsupported byte, a type 1 error should be thrown and the packet skipped.
If the program requires an icon and the first byte is invalid, the program may contine trying to parse the icon or it may substitute a default icon.
The second and third bytes of the packet are the width and height respectively of the icon.
Fourth byte is unused except for data alignment.
Note that the packet itself can only support icons up to 180 pixels on each side, so all sizes greater than this are automatically invalid.
It is recommended that only certain icon sizes be supported by the program.
If an invalid size is encountered, it may handle the errors in a similar fashion to an invalid color byte in the packet.
File size: 0x01 02
This four byte packet details the size of the data in Main() in bytes. It is not necessary for the format (although the program may require it).
Clock speed packet: 0x01 03
Contains a 6 byte field. The first byte states the CPU clock speed in hex, the second byte details the Peripheral clock frequency, and the third byte details the Bus clock.
The fourth and fifth bytes contain the values to be written to the FRQCR. If overwriting the register isn't desired, the value 0x2000 should be present in these bytes.
The sixth byte is contains the byte to be applied to UCLKCR. If the register is not to be overwritten, the value 0x20 should be used.
Remember that to overwrite UCLKCR, the data must be written with 0xA5 in the high byte of the write word.
MMUCR: 0x01 04
A four byte packet. If present, the data in the packet should be written to the MMU.
This packet need not be supported if the application is to execute outside the P1 and P2 memory areas.
File load: 0x01 05
Contains a series of ASCII filenames, each 8 bytes long, of the format   ^**** ****.***/
The ending "/" character is used to designate the end of each filename and the "*" character designates any printable ASCII character.
The character at the beginning of the string will be "^" if the file is to be loaded into memory and "#" if it is simply to be checked for its presence on the device.
If one or more of the files are not present, then the program should inform the user.
Main(): 0xFF FF
The packet containing all user data (such as code) within the file.
Size is not applicable.

File structure:
Bytes 0-4: ASCII representation of the file extension of the format ".***" If not all of the bytes are used, fill the remaining spaces with null bytes.
All bytes afterwards are contained within packets, which are to be arranged in the ascending order of their ID bytes.

This are the parts that have changed.
Code: [Select]
Language: 0x00 04
Contains a four byte ASCII string detailing the language of the code.
E.G. "JAVA" for Java, "LUA " for Lua, "ASM " for ASM and C, etc...
Note the appended space after "LUA" in order to make the string 4 bytes. Longer strings should be truncated.

...

FontLang: 0x00 11
Contains a three byte ASCII string detailing the font  language.
E.G. "ENG" for English, "GER" for German, etc...

This is version 01.00.02
« Last Edit: May 09, 2011, 02:31:36 am by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline JosJuice

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1344
  • Rating: +66/-14
    • View Profile
Re: Prizm File formats
« Reply #5 on: May 09, 2011, 09:54:30 am »
This seems to be nice and flexible. There are a few things I noticed, though...

You say that the ID bytes are bytes 1 & 2 of a packet and that the size bytes are bytes 2 & 3. Aren't the size bytes supposed to be 3 & 4?
What is the purpose of the packet of the type 00 00?
Why is the 00 02 packet necessary? Don't we already know the name of the file? Also, limiting files to 8 characters is a bad idea. The Prizm OS can handle more than 8, but it usually only displays 8. (This also applies to the 01 05 package - limiting ourselves to 8 chars might be bad.) And why do you use FF instead of 00 as null?
In the 00 03 packet, why is 55 needed?
Is it necessary to have both 00 01 and 00 04?
For 00 11, I recommend that you use some kind of standard, for example ISO 639-3.
Are shells allowed to run programs even if the 00 12 checksum isn't present? I think it's a good idea to make it possible, but to prevent programs from running if there's an invalid 00 12 packet.
Is it possible to have 16-bit icons in 01 01? And can there be more than one 01 01 package, in case the file includes multiple icons for different viewing modes/shells?

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Prizm File formats
« Reply #6 on: May 09, 2011, 01:54:16 pm »
Yes, the size bytes are byte 3 & 4, not 2 and 3.

Packet 0x00 00 is so that default icons (like Doors CS' default icons for Axe, BASIC, ASM, etc) are possible. Packet 0x00 02 serves two purposes. The first is the same as the names in the .g3a format; to allow for naming without FAT lookup. The second is that program will not necessarily have access to the name of the program and/or will find it much easier to use that packet than to look it up. The 8 characters limit is just so that the name is a nice round number.  FF is used as null for no particular reason. As for packet 0x00 03, 0x55 is used to pad the packet into being 4 bytes long. I tried to keep packets aligned on 4 byte boundaries so that they are easier to access in code.

Is it necessary to have both 00 01 and 00 04?

Probably not. I'd forgotten about 0x00 01 :P
However, 0x00 04 does allow people to specify languages without a format change, while 0x00 01 doesn't. The File type packet was also intended more for general things like "Music," "Function Library," etc... I'll probably combine them, though.

For 00 11, I recommend that you use some kind of standard, for example ISO 639-3.

That's an excellent idea. Thanks for pointing it out.

Are shells allowed to run programs even if the 00 12 checksum isn't present? I think it's a good idea to make it possible, but to prevent programs from running if there's an invalid 00 12 packet.

If the packet isn't listed here, then it can be ignored:

Quote
   The only time parsers are not allowed to skip packets is if the packets are on a special list (listed below). All programs must contain a copy of this list.
   If the ID is found on the secondary list, the parser must return a type 3 error, since further parsing is either useless or impossible.
      File Type
      FileName
      Main()

Actually, that's confusing and it doesn't fully address what I intended which was that those three packets *cannot* be skipped and if they aren't found during parsing, the program cannot be executed. The checksum packet isn't on that list, so programs can run fine without it.

Is it possible to have 16-bit icons in 01 01? And can there be more than one 01 01 package, in case the file includes multiple icons for different viewing modes/shells?

I've changed the format to accommodate all of those :)


Code: [Select]
Icon Mode: 0x01 06
Size is always multiple of 2.
First byte is the icon mode number (1 byte integer). A value of FF means "all modes." In order to prevent FF icons from overwhelming other icons on the list, they must always be the last entry in the list and and the parser may thus return before seeing this byte. The second byte is which occurrence of the icon packet should be used if this is the current mode. The third byte, if present is the icon mode number and so on. Packet icons  occurrences are 0 indexed.

Ex:  Shell is in "Mode 7," which uses full 16 bit color and there are two icons to select from, one for mode 7 and one for the rest of the modes.
0106 0004 0700 FF01
0x0101 FFFF FFFF 1010 <image code>


Icon Packet: 0x01 01
First two bytes are the number of colors used in the icon image. 0x00 02 is monochrome, 0x00 08 is 8 color, 0x00 10 is 16, 0xFF FF is 16 bit, etc...
If the first two bytes are 00 00 or another unsupported word, a type 1 error should be thrown and the packet skipped.
If the program requires an icon and the first two bytes are invalid, the program may continue trying to parse the icon or it may substitute a default icon.
The third and fourth bytes of the packet are the width and height respectively of the icon.
Note that the packet itself can only support icons up to 180 pixels on each side, so all sizes greater than this are automatically invalid.
It is recommended that only certain icon sizes be supported by the program.
If an invalid size is encountered, it may handle the errors in a similar fashion to an invalid color byte in the packet.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Prizm File formats
« Reply #7 on: May 09, 2011, 08:48:48 pm »
Okay I like some of the changes you made, but I question the need for defining Java and Lua programs in the header as wouldn't those be in .class files and whatever format Lua is compiled to. The shell itself can detect .class files and can pass those onto the virtual machine for interpreting. There are also many features that the shell would have that would remove the need for a complex header. Really I thought this header was just for executable programs and every other file type would be handled just like windows does. In fact the idea was to model the shell around the Windows Explorer and how it handles files. And within the explorer would also be a terminal which would handle all of the operations the user does. This just like any computer would be hidden if the terminal is not open.

Other features which for the most part are not included as of now, but will be featured in later versions are:

Hooks: An example of where this could be used is if a .jpg file appears in the current directory. Instead of using the standard icon for .jpg files a hook could be triggered corresponding to either the shell itself or another program that has registered a .jpg hook with the shell. The .jpg handler could then return a icon that is a scaled down version of the actual image data. Other example could be in java where if the cursor is held over a .class file the .class handler could return information such as author and company to be displayed, this information being found by parsing that particular file. The last example is a right click hook. Now if you have Notepad++ installed on your computer whenever you right click on a file you will see the option "Edit with Notepad++" a similar feature could also be setup with hooks. As you see the possibilities are endless.

Terminal: Also known as a command line on Windows systems. You may not think of it much, but when you click on a cpp file on your computer, hidden from you the text "C:\Program Files (x86)\Notepad++\notepad++.exe C:\users\z80man\documents\myprogram.cpp" is being typed into the terminal (minus the z80man part :P) The same thing would be done when opening a file or running a program from the shell. You even have the option to open the terminal yourself and type commands or too run your own batch files.

Libraries: Okay one of my biggest points has been cross-compatibility and backwards compatibility for the Prizm. Along with this has also been location independent code. When using multiple libraries in a program location independent code can pose issues when these are random, often user made libraries, that the shell has no prior knowledge about. To deal with this a set of shell calls are being developed that upon startup of a program, the program will pass the names of libraries and their given ID (this can be any number the programmer wishes and is not defined in the library, but in the program that way two libraries don't end up both having 42 as their ID) Then whenever a library call is made (which is done in the exact same manner as the OS syscalls are done except it is a different address) the stack is read for the ID number and the shell will then call the proper  routine from the proper library.

Compression: Because there is very limited space available in flash it is important that programs use as little space as possible. Part of this is handled through the powerful array of malloc() calls available so that the programmer does not have to have large areas of 0's in code.  this is also handled by the emphasis of runtime libraries which reduce redundant code. The other thing is to encourage compressed files and folders. An example of a compressed file would be jpg's for images as they are often almost a third smaller than their bmp counterparts. Now because handling jpg's can be difficult in code shell calls can be devised to return a pointer to a bmp after being passed a pointer to a jpg as an argument. An example of folders would be zip's tar.gz's tar.xz's and so on. To make things easier for the programmer shell calls to handle these folders would be required. 

Multi Tasking: This feature is still far off from being implemented  anytime soon, but the idea would allow the execution of multiple programs and opening of multiple files. The advantages could also be seen if a windowing system could be setup too.

Wobbly Windows: I make my case clear :P

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline nogoodatmath

  • LV0 Newcomer (Next: 5)
  • Posts: 2
  • Rating: +0/-0
    • View Profile
Re: Prizm File formats
« Reply #8 on: May 10, 2011, 08:13:46 pm »
Hi,

I am looking for someone who can make the Algebrator program work on the Casio Prizm Calculator.

Algebrator is a .exe file type. The prizm needs a .3ga file type. Here is the link to the program Algebrator http://www.algebrasolver.com. I have the algebrator program I can send to anyone willing to give it a try. The Algebrator program is 6.0 mb and does not need to be installed.

Offline turiqwalrus

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 840
  • Rating: +51/-2
  • Wheeeeeee~!
    • View Profile
Re: Prizm File formats
« Reply #9 on: May 10, 2011, 08:19:42 pm »
Hi,

I am looking for someone who can make the Algebrator program work on the Casio Prizm Calculator.

Algebrator is a .exe file type. The prizm needs a .3ga file type. Here is the link to the program Algebrator http://www.algebrasolver.com. I have the algebrator program I can send to anyone willing to give it a try. The Algebrator program is 6.0 mb and does not need to be installed.
welcome to the forum :)
however, I think that this is not the right section to be posting this :P
I would try learning C/C++ or SH3 assembly and make a port, as there is no .exe to .g3a converter.
« Last Edit: May 10, 2011, 08:19:50 pm by turiqwalrus »

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Prizm File formats
« Reply #10 on: May 10, 2011, 09:37:18 pm »
Hi,

I am looking for someone who can make the Algebrator program work on the Casio Prizm Calculator.

Algebrator is a .exe file type. The prizm needs a .3ga file type. Here is the link to the program Algebrator http://www.algebrasolver.com. I have the algebrator program I can send to anyone willing to give it a try. The Algebrator program is 6.0 mb and does not need to be installed.
Sorry that's a bit much to be asking right now when Prizm dev is only just getting started. The program that you're pointing out seems to be like a CAS and would be extremely difficult to make right now with either C/C++ or asm. Yes we do have plans to some day implement a CAS this will take several months or even a year. Our current priorities are to make games ;)

But I would suggest attempting this in BASIC as that has floating point support and make sure you try the equation solver app as it has some powerful functions.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Prizm File formats
« Reply #11 on: May 10, 2011, 09:58:40 pm »
Holy walls of text batman! O.O

z80man with hooks, would it allow things like xLIB where some BASIC commands functionality are modified to do things like sprite displaying?

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Prizm File formats
« Reply #12 on: May 11, 2011, 12:36:55 am »
Holy walls of text batman! O.O

z80man with hooks, would it allow things like xLIB where some BASIC commands functionality are modified to do things like sprite displaying?
I don't see why not. I was planning a rewrite of the BASIC interpreter at some time to allow high powered BASIC coding with more powerful capabilities such as spiriting. Although those hooks would be based within the interpreter itself and probably not the shell unless the interpreter becomes part of the shell. It just makes me wonder how many languages will be available to a Prizm coder. Lua, Java, C/C++, BASIC, asm, etc...

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Prizm File formats
« Reply #13 on: May 11, 2011, 12:56:13 am »
The entire interpreter? Or do you just mean certain functions like Locate and math commands that are not useful in games?

And yeah I am curious how many languages will there be. We need one that is easy but fast for sure, because notice how few Nspire developers there were until Lua arrived.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Prizm File formats
« Reply #14 on: May 11, 2011, 01:00:48 am »
The entire interpreter? Or do you just mean certain functions like Locate and math commands that are not useful in games?

And yeah I am curious how many languages will there be. We need one that is easy but fast for sure, because notice how few Nspire developers there were until Lua arrived.
First off everything that would be used in a game, but then I realized ow useful a BASIC rewrite would be for making high powered math programs such as a CAS or 3d graphs. So most functions except for ones that are really trivial and you wouldn't use in either a math program or game.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)