Many of us out here are Axe programmers. Many of us also don't want to code in SH3 asm (not me of course, SH3 asm is the best ). Many of us do not want to go through all of the difficult steps to set up a C compiler. So there is a solution for this. Make Axe for the Prizm.

Now this project hasn't even been started yet. I'm not even the one in charge of the language. But what I have here is an early development of the Getkey routine. So when the Axe port does come around someday, you will be able to interface with the keyboard. How this instruction works is that it returns the word length code through the stack. What is great about this routine is that the codes are easy to remember, it is extremely fast, and it supports multiple key presses.

So how to use it? Well the answer is you can't right now. unless of course you integrate it with a program you wrote in C or asm. but anyways it will function just like your standard BASIC or AXE getkey routine where you can say GetKey ->A. Before I can teach you how to use multiple key presses, I have to teach you how the instruction works internally. what is great about the SH3 is that the keyboard is memory mapped. How that works is that there are 10 bytes representing the state of the keyboard starting at 0xA44B0000. Basically each row of keys has its own byte and each key has its own bit within that byte. (On key has its own byte; 0101) So for a single key press, the routine returns the byte index of the key pressed in the MSB and the value of that byte in the LSB. An example the EXE key. Because exe it located in the first byte 00xx is the first part evaluated then because pressing the the exe key toggles bit 2 in relative address 00, 4 is loaded into the lower byte. That then yields a result of 0004. So for multiple key presses everything works just about the same way. for this example say you are pushing the shift key 0940 and the up arrow 0902. Normally you would add the 2 MSB's together, but not when they are the same. So in this case they are both 9 so do not add them. But you always add the LSB's of all the keys being pushed. So 02 + 40 = 42. Then your result would be 0942.

Sorry that this might be a bit vague. If you have a question on either the source or the routine usage, please ask.




Getkey:
MOVA  @($07,PC),R0    ;$A44B0000
MOV  $0A,R1
Loop:
DT R1
BT/S  $08             ;Exit
MOV.B  @(R0,R1),R2
CMP/PL  R2
BF/S  $FA             ;Loop
MOV  R1,R4
SHLL8  R4
ADD  R2,R3
BRA  $F6              ;Loop
ADD  R4,R3
Exit:
RTS
MOV.L  R3,@-R15
data.l  $A44B0000

What I still want to do is treat libraries as separate files from the shell. That way an older shell can upload the libraries from a newer shell and use that to run newer programs. Think of it like MirageOS uploading the DoorsCS7 libraries that way it can run programs that make use of those libraries.

I decided to make a timeline on how progress for the emulator will go.
1. incorporate about 20 instructions along with a memory model. include a simple debugging interface (testing phase)
2. incorporate somewhere between 50-80 instructions with an advanced debugging interface. include a simple screen mapped to the vram. include multi threading
3. incorporate all of the SH3 instructions. begin attaching important peripherals such as MMU, FRQCR, and ports. add support for rom memory
4. attach all standard peripherals used by the Prizm. Begin support for Prizm unique peripherals ie LCD driver, add support for the Prizm specific opcodes, incorporate full keyboard emulation
5. Include all peripherals used by the Prizm, begin support for serial port (including sound), usb port. Allow FAT32 communication between the emulator and the host computer. Advanced gui support now incorporated with a full suite of advanced debugging tools.  Include real time disassembler and hex editor. First version of plug in scripting language to allow users to create and distribute their own apps that make use of the emulators resources to allow extended functionalities.
6. First stable release

And of course each release number includes sub-releases that patch bugs, add minor updates, and  include optimizations. The next scheduled release is for this weekend and will include a new test program that uses all of the available instructions, linux executable, major optimizations, and documentation on how to create your own programs. Currently on the version that I'm using (not the release a few posts up) I'm getting speeds of twice the current release.

Well... it's Texas Instruments we're talking about here, after all.

(Although if Casio tried to lock down the Prizm, then they failed even harder, since it got cracked a few weeks after its release)

A couple of weeks, I'm pretty sure we got our own apps on in under a week. In fact we were running apps before the announced release of the Prizm on January 15th.

I never knew that Axe apps were deleted after 16 runs Probably because I've never ran one of my Axe apps more than 16 times before recompiling. but still it just sounds strange to see apps get deleted like that.

But if you used your own link protocol, could you send an app to another calculator without having to sign it correctly.

I've now started work on creating an SH3E library for the the SH3. In case you don't know the SH3E is a version of the SH3 that incorporates an fpu. Later on I'll create libraries for the SH4 which incorporates double length double length data along with video acceleration hardware (except when emulated it will be more like video deceleration ). For the libraries I'm making three versions of each function. In each version there are three different sub-sets for a inline function, callable function, and an interrupt triggered function. On the inline version, the register numbers are labeled Ra, Rb, Rc and so on. When used in code the programmer should define these registers as they see fit. FR0-FR15 are memory locations along with the FPSCR and the FPUL.
Fast version:
The fastest possible version of each instruction. May destroy some registers during execution so care must be taken when using them. Is more of a floating point library than an fpu emulator as it ignores the system and control registers found in the emulated hardware.

Safe version:
Protects registers from being corrupted, and is only a little bit slower than the fast routines. Closely emulates the actual hardware, but still doesn't incorporate the fpu system and control registers. 

True version:
Is an exact copy of the emulated hardware instruction. May be slow in some routines due to the system and control registers that must be managed. Also ensures that none of the general purpose registers are corrupted.

FABS  FRn
Floating point absolute value of FRn
;FABS  FRn

;*******************************
;inline
;Ra is the register to be processed
;destroyed registers
;Ra, T bit

ROTR  Ra    ;shifts Ra 1 bit right. LSB is placed into the T bit
ROTCL Ra    ;shifts Ra 1 bit left. T bit placed into the LSB of Ra


;*******************************

;callable function
;@(R15) is the data to be processed
;data returned to @(R15)
;registers destroyed
;R1 and T bit

MOV.L @R15,R1    ;pops single argument off the stack. only one argument so no point in decrementing R15
ROTR  R1         ;shifts R1 1 bit right. LSB is placed into the T bit
ROTCL R1         ;shifts R1 1 bit left. T bit placed into the LSB of R1
RTS              ;return to code. Delayed branch
MOV.L R1,@R15    ;pushes single argument back on

;*******************************

;interrupt
;jumped to from the interrupt handler
;@(R15) is the data to be processed
;registers destroyed
;R1 (bank 1)


MOV.L @R15,R1    ;pops single argument off the stack. only one argument so no point in decrementing R15
ROTR  R1         ;shifts R1 1 bit right. LSB is placed into the T bit
ROTCL R1         ;shifts R1 1 bit left. T bit placed into the LSB of R1
RTE              ;SSR/SPC -> SR/PC. returns to code. Delayed branch
MOV.L R1,@R15    ;pushes single argument back on the stack
;FABS FRn

;*******************************
;inline
;Ra is the register to be processed
;cannot use R1 as Ra
;destroyed registers
;Ra

MOV.L R1,@-R15   ;pushes R1 onto the stack
MOVT  R1         ;moves the T bit into R1
MOV.L R1,@-R15   ;moves R1 onto the stack
ROTR  Ra         ;shifts Ra 1 bit right. LSB is placed into the T bit
ROTCL Ra         ;shifts Ra 1 bit left. T bit placed into the LSB of Ra
MOV.L @R15+,R1   ;pops R1 off the stack. T bit
MOV.L R2,@-R15   ;pushes R2 onto the stack
MOV $00,R2       ;moves 0 into R2
CMP/HI R1,R2     ;if the T bit was 1 then the T bit equals 1. Sounds retarded I know :P
MOV.L @R15+,R2   ;pops R2
MOV.L @R15+,R1   ;pops R1

;*****************************
;callable
;NOT FINISHED

;*****************************
;interrupt
;jumped to from the interrupt handler
;@(R15+8) is the FR to be processed
;registers destroyed
;FRn


MOV.L R1,@R15+    ;pushes R1 onto the stack
MOV.L R2,@R15+    ;pushes R2 onto the stack
MOV.L @R15,R2     ;pops FR address off the stack. No decrement
MOV.L @R2,R1      ;places contents of @R2 into R1
ROTR  R1         ;shifts R1 1 bit right. LSB is placed into the T bit
ROTCL R1         ;shifts R1 1 bit left. T bit placed into the LSB of R1
MOV.L R1,@R2    ;places result in FRn
MOV.L @R15-,R2   ;pops R2
RTE              ;SSR/SPC -> SR/PC. returns to code. Delayed branch
MOV.L @R15-,R1    ;pops R1So this was some of the hardest stack work I've ever done before. And it was only on the simplest of the floating point math operations. In fact I still haven't finished the safe version of the callable function or any of the true functions yet. May God save us all when we start working on the true version of the square root and the division functions. Just as a head up here is the C code for the fpu divide instruction. Now just imagine the SH3 asm version of that while preserving all of the registers.
FDIV(float *FRm,*FRn) /* FDIV FRm,FRn */
{
clear_cause_VZ();
if((data_type_of(FRm) = = sNaN) | |
(data_type_of(FRn) = = sNaN)) invalid(FRn);
else if((data_type_of(FRm) = = qNaN) | |
(data_type_of(FRn) = = qNaN)) qnan(FRn);
else case((data_type_of(FRm) {
NORM :
case(data_type_of(FRn)) {
PINF :
NINF : inf(FRn,sign_of(FRm)^sign_of(FRn)); break;
default : *FRn =*FRn / *FRm; break;
} break;
PZERO :
NZERO :
case(data_type_of(FRn)) {
PZERO :
NZERO : invalid(FRn); break;
PINF :
NINF : inf(Fn,Sign_of(FRm)^sign_of(FRn)); break;
default : dz(FRn,sign_of(FRm)^sign_of(FRn)); break;
} break;
PINF :
NINF :
case(data_type_of(FRn)) {
PINF :
NINF : invalid(FRn); break;
default :zero (FRn,sign_of(FRm)^sign_of(FRn)); break
break;
}
pc += 2;
}

Actually the Prizm does have a very long battery life. I've had my Prizm since Christmas now and I use it for at least one hour everyday. In that time I have not changed the batteries once.