Author Topic: Khavi: Java on the Prizm  (Read 59197 times)

0 Members and 1 Guest are viewing this topic.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Khavi: Java on the Prizm
« on: April 04, 2011, 12:34:23 am »
Many of you here have requested a java virtual machine for the Prizm. (most notably Ashbad  ;)) Well I have been studying my java bytecode and I believe that this is quite possible. If you did not know, java bytecode is a stack oriented language in which the Prizm excels at. Now I did not find any of the jazelle extensions that the arm has, but it doesn't mean that java is impossible. What can be done is code the proper functions for each of the instructions, some of which would only take 1 SH3 instruction. The other thing to do is remove all of those fancy, but unnecessary features of the JVM. Stuff like malicious code testing and maybe partial garbage collecting. So right now I'm kind of busy with about 4 other Prizm projects that I'm working on, but during the summer or maybe after the AP exams, I will have time to get started on this.


EDIT: Changed topic title to include the project name
« Last Edit: May 10, 2011, 09:22:22 pm by Qwerty.55 »

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 jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Java on the Prizm
« Reply #1 on: April 04, 2011, 07:18:15 am »
It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Java on the Prizm
« Reply #2 on: April 04, 2011, 07:36:07 am »
Many of you here have requested a java virtual machine for the Prizm. (most notably Ashbad  ;)) Well I have been studying my java bytecode and I believe that this is quite possible. If you did not know, java bytecode is a stack oriented language in which the Prizm excels at. Now I did not find any of the jazelle extensions that the arm has, but it doesn't mean that java is impossible. What can be done is code the proper functions for each of the instructions, some of which would only take 1 SH3 instruction. The other thing to do is remove all of those fancy, but unnecessary features of the JVM. Stuff like malicious code testing and maybe partial garbage collecting. So right now I'm kind of busy with about 4 other Prizm projects that I'm working on, but during the summer or maybe after the AP exams, I will have time to get started on this.

This looks like a great idea. There was once a topic about Java on the NSpire, so I hope this turns out right for the PRIZM :D

Ashbad

  • Guest
Re: Java on the Prizm
« Reply #3 on: April 04, 2011, 08:39:58 am »
:)

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: Java on the Prizm
« Reply #4 on: April 05, 2011, 03:01:45 pm »
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Java on the Prizm
« Reply #5 on: April 05, 2011, 03:04:44 pm »
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P

The Silencer on the PRIZM? :crazy:

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: Java on the Prizm
« Reply #6 on: April 08, 2011, 11:23:15 am »
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P
We could have multi platform games!

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: Java on the Prizm
« Reply #7 on: April 11, 2011, 03:46:33 am »
Okay, I took the liberty of spending a few days exploring the JVM and how it works. It's surprisingly simple. I see absolutely no reason why would we couldn't get a JVM running on the Prizm.

I spent an hour tonight and wrote a routine to parse/validate about half of the .class file format (the rest should be fairly easy to parse). It could probably be used as initialization code for such a JVM.

Code: [Select]
General Parser form:

If R0 holds a pointer to the first byte of the .class file

STC.L SR,@–R15 // Store value to RET to.
MOV.L @R0+,R1
MOV.L (Magic),R2
XOR R1,R2 // If both values are the same, 0->R2
TST R2,R2
BT/S Parse
NOP
RET
(Magic) 0xCAFEBABE

ParseVer:
XOR R4,R4
MOV.L @R0+,R1
MOV.L (Min Major_Minor),R2
MOV.L (Max Major_Minor),R3
CMP/HS R2,R1 // If min version>version
ROTL R4
CMP/HS R1,R3 // If version>max version
ROTL R4
TST R4,R4 // If both false, 1->T
BT/S ParseConst
NOP
RET
(Min Major_Minor) 0x** ** ** ** // Upper two bytes are major version, lower two bytes are minor
(Max Major_Minor) 0x** ** ** ** // Same as before

ParseConst:
MOV.L R0,@R15- // Store pointer to Constant pool
MOV.W @R0+,R1
ROTL R1
CLRT
ROTR R1
MOV.L R1,R8
ADD R1,R0 // Skip over Constant pool

ParseFlags:
XOR R12,R12 //Clear flag register
MOV.W @R0+,R1
ROTL R1
CLRT
ROTR R1
<Other flag checking?>
OR R1,R12 // Add Access flags to lower 16 bits of flag register

ParseClasses:
CLRT
XOR R2,R2
XOR R4,R4
MOV.L @R0-,R1
MOV.B 0x10,R3

Loop1:
ADD 0xFF,R3
ROTR R3
BF/S Loop1
ROTL R2 // Move super_class index into R2

CMP/HS R1,R8
ROTL R4
CMP/HS R2,R8
ROTL R4
TST R8,R1
BT/S GetIndices1
NOP
RET
GetIndices1:
MOV.L @R15+,R7
MOV.L R7,@R15-
ADD R7,R1
MOV.W @R1,R1
<Handle this_class>
ADD R7,R2
MOV.W @R2,R2
<Handle super_class>
Parsefurther:
Etc...

Also, I have a full instruction list of the JVM, along with a few SH3 ASM routines I wrote that happen to perform those operations.
Code: [Select]
During runtime, the following are assumed:

R12 is a 32 bit flag register.
R13 holds PC.
R14 points to the operand stack.
R15 is a stack for interpreter use.


aaload
0x32

aastore
0x53

aconst_null
0x01

aload
0x19
Also supports Wide format, which means the opcode is preceded by 0xC4

aload_<n>
aload_0 opcode = 0x2A
aload_1 opcode = 0x2B
aload_2 opcode = 0x2C
aload_3 opcode = 0x2D

anewarray
0xBD

areturn
0xB0

arraylength
0xBE

astore
0x3A
Also supports Wide format, which means the opcode is preceded by 0xC4

astore_<n>
astore_0 opcode = 0x4B
astore_1 opcode = 0x4C
astore_2 opcode = 0x4D
astore_3 opcode = 0x4E

athrow
0xBF

baload
0x33

bastore
0x54

bipush
0x10

breakpoint
0xCA
Reserved opcode. Should not appear in any .class file.

caload
0x34

castore
0x55

checkcast


d2f


d2i


d2l


dadd


daload


dastore


dcmpg


dcmpl


dconst_<d>


ddiv


dload


dload_<n>


dmul


dneg


drem


dreturn


dstore


dstore_<n>


dsub


dup


dup2


dup2_x1


dup2_x2


dup_x1


dup_x2


f2d


f2i


f2l


fadd
0x62

faload


fastore


fcmpg


fcmpl


fconst_<f>
fconst_0 opcode = 0x0B (11)
fconst_1 opcode = 0x0C (12)
fconst_2 opcode = 0x0D

fdiv
0x6E

fload


fload_<n>


fmul
0x6A

fneg
0x6A

frem


freturn


fstore


fstore_<n>


fsub


getfield


getstatic


goto


goto_w


i2b


i2c


i2d


i2f


i2l


i2s


iadd
0x60

iaload


iand
0x7E

iastore


iconst_<n>


iconst_m1


idiv
0x6C

if_acmpeq


if_acmpne


if_icmpeq


if_icmpge


if_icmpgt


if_icmple


if_icmplt


if_icmpne


ifeq


ifge


ifgt


ifle



iflt


ifne



ifnonnull


ifnull


iinc


iload


iload_<n>


impdep1


impdep2


imul


ineg


instanceof


invokeinterface


invokespecial


invokestatic


invokevirtual


ior
0x80
MOV.L @R14+,R1
MOV.L @R14+,R2
OR R2,R1
MOV.L R1

irem
0x70
MOV.L @R14+,R0
MOV.L @R14+,R2
MOV R2,R3
SUB R0,R3
MOV $20,R4
DIV0U R0,R1
Startdiv:
ADD $FF,R4
DIV1 R0,R1
TST R4,R4
BT/S Startdiv
ROTCL R2
DMULU.L R2,R3
STS MACL,R2
MOV.L R2,@-R14

ireturn


ishl


ishr


istore


istore_<n>


isub


iushr


ixor
0x82
MOV.L @R14+,R1
MOV.L @R14+,R2
XOR R2,R1
MOV.L R1

jsr
0xA8

jsr_w
0xC9

l2d


l2f


l2i


ladd
0x61

laload


land


lastore


lcmp


lconst_<l>


ldc


ldc_w


ldc2_w


ldiv


lload


lload_<n>


lmul


lneg


lookupswitch


lor


lrem


lreturn


lshl


lshr


lstore


lstore_<n>


lsub


lushr


lxor
0x83

monitorenter


monitorexit


multianewarray


new


newarray


nop
0x00

pop


pop2


putfield


putstatic


ret


return


saload


sastore


sipush


swap


tableswitch


wide

Opcodes and descriptions can be found here.

It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?

That depends on what you mean by "Virtual machine." The JVM is essentially nothing more than an interpreter. It just happens to interpret the machine code for a virtual machine.
« Last Edit: April 11, 2011, 03:58:59 am by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Java on the Prizm
« Reply #8 on: April 11, 2011, 05:24:23 am »
Okay, I took the liberty of spending a few days exploring the JVM and how it works. It's surprisingly simple. I see absolutely no reason why would we couldn't get a JVM running on the Prizm.

I spent an hour tonight and wrote a routine to parse/validate about half of the .class file format (the rest should be fairly easy to parse). It could probably be used as initialization code for such a JVM.

Code: [Select]
General Parser form:

If R0 holds a pointer to the first byte of the .class file

STC.L SR,@–R15 // Store value to RET to.
MOV.L @R0+,R1
MOV.L (Magic),R2
XOR R1,R2 // If both values are the same, 0->R2
TST R2,R2
BT/S Parse
NOP
RET
(Magic) 0xCAFEBABE

ParseVer:
XOR R4,R4
MOV.L @R0+,R1
MOV.L (Min Major_Minor),R2
MOV.L (Max Major_Minor),R3
CMP/HS R2,R1 // If min version>version
ROTL R4
CMP/HS R1,R3 // If version>max version
ROTL R4
TST R4,R4 // If both false, 1->T
BT/S ParseConst
NOP
RET
(Min Major_Minor) 0x** ** ** ** // Upper two bytes are major version, lower two bytes are minor
(Max Major_Minor) 0x** ** ** ** // Same as before

ParseConst:
MOV.L R0,@R15- // Store pointer to Constant pool
MOV.W @R0+,R1
ROTL R1
CLRT
ROTR R1
MOV.L R1,R8
ADD R1,R0 // Skip over Constant pool

ParseFlags:
XOR R12,R12 //Clear flag register
MOV.W @R0+,R1
ROTL R1
CLRT
ROTR R1
<Other flag checking?>
OR R1,R12 // Add Access flags to lower 16 bits of flag register

ParseClasses:
CLRT
XOR R2,R2
XOR R4,R4
MOV.L @R0-,R1
MOV.B 0x10,R3

Loop1:
ADD 0xFF,R3
ROTR R3
BF/S Loop1
ROTL R2 // Move super_class index into R2

CMP/HS R1,R8
ROTL R4
CMP/HS R2,R8
ROTL R4
TST R8,R1
BT/S GetIndices1
NOP
RET
GetIndices1:
MOV.L @R15+,R7
MOV.L R7,@R15-
ADD R7,R1
MOV.W @R1,R1
<Handle this_class>
ADD R7,R2
MOV.W @R2,R2
<Handle super_class>
Parsefurther:
Etc...

Also, I have a full instruction list of the JVM, along with a few SH3 ASM routines I wrote that happen to perform those operations.
Code: [Select]
During runtime, the following are assumed:

R12 is a 32 bit flag register.
R13 holds PC.
R14 points to the operand stack.
R15 is a stack for interpreter use.


aaload
0x32

aastore
0x53

aconst_null
0x01

aload
0x19
Also supports Wide format, which means the opcode is preceded by 0xC4

aload_<n>
aload_0 opcode = 0x2A
aload_1 opcode = 0x2B
aload_2 opcode = 0x2C
aload_3 opcode = 0x2D

anewarray
0xBD

areturn
0xB0

arraylength
0xBE

astore
0x3A
Also supports Wide format, which means the opcode is preceded by 0xC4

astore_<n>
astore_0 opcode = 0x4B
astore_1 opcode = 0x4C
astore_2 opcode = 0x4D
astore_3 opcode = 0x4E

athrow
0xBF

baload
0x33

bastore
0x54

bipush
0x10

breakpoint
0xCA
Reserved opcode. Should not appear in any .class file.

caload
0x34

castore
0x55

checkcast


d2f


d2i


d2l


dadd


daload


dastore


dcmpg


dcmpl


dconst_<d>


ddiv


dload


dload_<n>


dmul


dneg


drem


dreturn


dstore


dstore_<n>


dsub


dup


dup2


dup2_x1


dup2_x2


dup_x1


dup_x2


f2d


f2i


f2l


fadd
0x62

faload


fastore


fcmpg


fcmpl


fconst_<f>
fconst_0 opcode = 0x0B (11)
fconst_1 opcode = 0x0C (12)
fconst_2 opcode = 0x0D

fdiv
0x6E

fload


fload_<n>


fmul
0x6A

fneg
0x6A

frem


freturn


fstore


fstore_<n>


fsub


getfield


getstatic


goto


goto_w


i2b


i2c


i2d


i2f


i2l


i2s


iadd
0x60

iaload


iand
0x7E

iastore


iconst_<n>


iconst_m1


idiv
0x6C

if_acmpeq


if_acmpne


if_icmpeq


if_icmpge


if_icmpgt


if_icmple


if_icmplt


if_icmpne


ifeq


ifge


ifgt


ifle



iflt


ifne



ifnonnull


ifnull


iinc


iload


iload_<n>


impdep1


impdep2


imul


ineg


instanceof


invokeinterface


invokespecial


invokestatic


invokevirtual


ior
0x80
MOV.L @R14+,R1
MOV.L @R14+,R2
OR R2,R1
MOV.L R1

irem
0x70
MOV.L @R14+,R0
MOV.L @R14+,R2
MOV R2,R3
SUB R0,R3
MOV $20,R4
DIV0U R0,R1
Startdiv:
ADD $FF,R4
DIV1 R0,R1
TST R4,R4
BT/S Startdiv
ROTCL R2
DMULU.L R2,R3
STS MACL,R2
MOV.L R2,@-R14

ireturn


ishl


ishr


istore


istore_<n>


isub


iushr


ixor
0x82
MOV.L @R14+,R1
MOV.L @R14+,R2
XOR R2,R1
MOV.L R1

jsr
0xA8

jsr_w
0xC9

l2d


l2f


l2i


ladd
0x61

laload


land


lastore


lcmp


lconst_<l>


ldc


ldc_w


ldc2_w


ldiv


lload


lload_<n>


lmul


lneg


lookupswitch


lor


lrem


lreturn


lshl


lshr


lstore


lstore_<n>


lsub


lushr


lxor
0x83

monitorenter


monitorexit


multianewarray


new


newarray


nop
0x00

pop


pop2


putfield


putstatic


ret


return


saload


sastore


sipush


swap


tableswitch


wide

Opcodes and descriptions can be found here.

It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?

That depends on what you mean by "Virtual machine." The JVM is essentially nothing more than an interpreter. It just happens to interpret the machine code for a virtual machine.

Qwerty: That looks awesome!

Do compiled programs need Java or some special app in the calculator to run? How fast is it?

Java on the Prizm, now I want a PRIZM even more.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Java on the Prizm
« Reply #9 on: April 11, 2011, 03:26:01 pm »
What will be needed is some sort of JVM to run .class files. There are two ways to do this:
1. The JVM is made like a shell that loads the program into ram and then executes it.
2. My other plan was in the asm shell I'm currently working on is to allow programs to register an extension

-hold on for more, bell just rang

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 AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Java on the Prizm
« Reply #10 on: April 11, 2011, 03:28:57 pm »
I finished the routine to parse .class file headers right before you posted this...

EDIT:

The extensions are going to be stored in whatever file allocation table the Prizm uses, probably appended to the name of the file itself. That table would also contain a pointer to the file for easy access.

Also:

Code: [Select]
General Parser form:

If R0 holds pointer to the first byte of the .class file

STC.L SR,@–R15 // Store value to RET to.
MOV.L @R0+,R1
MOV.L (Magic),R2
XOR R1,R2 // If both values are the same, 0->R2
TST R2,R2
BT/S Parse
NOP
RET
(Magic) 0xCAFEBABE

ParseVer:
XOR R4,R4
MOV.L @R0+,R1
MOV.L (Min Major_Minor),R2
MOV.L (Max Major_Minor),R3
CMP/HS R2,R1 // If min version>version
ROTL R4
CMP/HS R1,R3 // If version>max version
ROTL R4
TST R4,R4 // If both false, 1->T
BT/S ParseConst
NOP
RET
(Min Major_Minor) 0x** ** ** ** // Upper two bytes are major version, lower two bytes are minor
(Max Major_Minor) 0x** ** ** ** // Same as before

ParseConst:
MOV.L R0,@R15- // Store pointer to Constant pool
MOV.W @R0+,R1
MOV.L R1,R8
ROTL R1
ADD R1,R0 // Skip over Constant pool

ParseFlags:
XOR R12,R12 //Clear flag register
MOV.W @R0+,R1
ROTL R1
CLRT
ROTR R1
<Other flag checking?>
OR R1,R12 // Add Access flags to lower 16 bits of flag register

ParseClasses:
XOR R2,R2
XOR R4,R4
MOV.L @R0-,R1
MOV.B 0x10,R3
CLRT
Loop1:
ADD 0xFF,R3
ROTR R3
TST R3,R3
BF/S Loop1
ROTL R2 // Move super_class index into R2

CMP/HS R1,R8
ROTL R4
CMP/HS R2,R8
ROTL R4
TST R4,R4
BT/S GetIndices1
NOP
RET

GetIndices1:
MOV.L @R15+,R7
MOV.L R7,@R15-
ADD R7,R1
MOV.W @R1,R1
<Handle this_class>
ADD R7,R2
MOV.W @R2,R2
<Handle super_class>

Parsefurther:
MOV.L R0,@15-
MOV.W @R0+,R1
MOV.W R1,R4
XOR R2.R2
Loop2:
ADD 0xFF,R1
MOV.W @R0+,R3
CMP/HS R3,R8 // R8 must be carried from the previous sections!
TST R1,R1
BF/S Loop1
ADD 0x01,R2
ADD 0xFF,R2
CMP/EQ R2,R4
BT/S FieldsMethods
NOP
RET
FieldsMethods:
MOV 0x01,R3
Loop3:
MOV.L R0,@R15-
MOV.W @R0+,R1
MOV 0x04,R2
MULU.W R1,R2
STS MACL,R1
ADD R1,R0
TST R3
BF/S Loop3
ADD 0xFF,R3

Parseattribs:
MOV.W @R0+,R1
MOV 0x07,R2
MULU.W R1,R2
STS MACL,R2
MOV.L R0,@R15-
ADD R2,R0
ParseInstruct:
Etc...

When it's reached the end of the header, the stack contains pointers to the Attributes table, the methods table, the fields table, the constant pool table, as well as a pointer to a the location to exit to. There might are a few bugs in this code that I still have to fix, but it's mostly functional.
« Last Edit: April 11, 2011, 03:50:42 pm by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Java on the Prizm
« Reply #11 on: April 11, 2011, 11:46:32 pm »
@Qwerty I see an optimization in there. When you use the MULU.L instruction do not follow it with the STS MACL. If you access the MAC following a multiply instruction, MULU will take 3 cycles, but if you put at least one other instruction in between the MULU and the STS, then MULU only takes 1 cycle ;)

And the idea with the extensions was for the asm shell. Just like Doors the shell doesn't have to be for asm programs only. Added features could be BASIC progs too. But my main idea was that the shell would have something like a registry found on windows systems. Because on windows for example Microsoft word will register the .doc file extension to itself. So whenever you select a .doc file, word will open that file. The same idea could apply to a .class file on the shell. When a .class file is selected then the JVM will be ran with a pointer to the file to run, passed as an argument.

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 AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Java on the Prizm
« Reply #12 on: April 11, 2011, 11:51:22 pm »
Nice catch. I must have missed that.

However, I just noticed a simpler way of detecting .class files: use the "magic" number 0xCAFEBABE. It's present in all .class files, so it can identify them and my file format can easily allow that particular header to be invalid.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Java on the Prizm
« Reply #13 on: April 12, 2011, 10:50:51 am »
[A bit Offtopic]

Qwerty, I just noticed you're already writing SH3 (PRIZM) assembly very well, never expected you guys to dominate it so fast :) Nice job

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Java on the Prizm
« Reply #14 on: April 12, 2011, 02:44:21 pm »
Nice catch. I must have missed that.

However, I just noticed a simpler way of detecting .class files: use the "magic" number 0xCAFEBABE. It's present in all .class files, so it can identify them and my file format can easily allow that particular header to be invalid.
Yes that is an easier way of detecting class files, but when it comes to a shell that is designed for any file format type, using something like 0xCAFEBABE is not universal. So it might be easier if the first time you run the java program it does a call to the libraries of the shell with "class"  and an icon as an argument. Then when viewing files in a screen similar to Doors, all class files will have a coffee cup icon and when you click on it java will be run with the class file as an arg

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)