Author Topic: Prizm Getkey (Read 12399 times)

z80man · « **on:** March 25, 2011, 02:50:05 am »

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.

Code: [Select]

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

DJ Omnimaga · « **Reply #1 on:** March 25, 2011, 03:04:20 am »

There is also the people that tried learning C but just can,t get used to that type of language and prefer z80-TI-BASIC or Casio BASIC style syntax. I personally tried on 68K and couldn't get used to C, so I stuck to TI-BASIC for the 83+ using libs, then Axe arrived.

I'M happy to see the possibility that an Axe Casio port might happen in the future. I wish you good luck on it, however, as these projects are huge undertakings, although fortunately, you already have the language pretty much designed by Quigibo, so it would be a matter of coding it and finding equivalent for BASIC functions that are missing or different.

AngelFish · « **Reply #2 on:** March 25, 2011, 03:31:18 am »

DJ Omnimaga · « **Reply #3 on:** March 25, 2011, 03:37:16 am »

Is there any difference other than the shape looking closer to a Prizm keypad?

AngelFish · « **Reply #4 on:** March 25, 2011, 03:38:05 am »

I fixed a typo in one of the keys, so not really. But making that was better than homework and it gave me an excuse to play around with paint.net

DJ Omnimaga · « **Reply #5 on:** March 25, 2011, 03:43:50 am »

Ok thanks for the info. These would be the final key codes, right? In the Casio Axe would we type the full 0020 for example? Or would 20 be fine?

AngelFish · « **Reply #6 on:** March 25, 2011, 03:45:21 am »

It will probably use much shorter mnemonics such as 1, 2, 3, 4, etc and simply translate them into the keycodes.

SimonLothar · « **Reply #7 on:** March 25, 2011, 06:01:08 am »

Quote from: z80man on March 25, 2011, 02:50:05 am

...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...

The 0xA44B0000 register set is not a standard feature of the SH3-group. If you program another SH3-based machine, you won't find the set. It is a special feature of the Prizm. The Prizm MPU is a 7705/7720/XXXX hybrid (the OS identifies the MPU as 7305, which is CASIO customized, t. i. a lot of registers are not documented).

http://ourl.ca/8207/178228

AngelFish · « **Reply #8 on:** March 25, 2011, 06:34:45 am »

* Qwerty.55 facepalms

I don't know how I missed the capitalized text saying "RENESAS 730501" and "RENESAS 735501" in the OS.

SimonLothar · « **Reply #9 on:** March 25, 2011, 06:57:45 am »

Quote from: Qwerty.55 on March 25, 2011, 06:34:45 am

I don't know how I missed the capitalized text saying "RENESAS 730501" and "RENESAS 735501" in the OS.

The 7355 is the 7705 hybrid of the 9860GII-series
The 7337 is the 7705 hybrid of the 9860G-series
The string "RENESAS 735501" in the Prizm OS is debris from legacy GII-OSes.
Obviously they used some parts of the legacy source (of course

).

AngelFish · « **Reply #10 on:** March 25, 2011, 06:59:18 am »

Yeah, I noticed the discussions from Casiocalc on Google talking about that.

z80man · « **Reply #11 on:** March 25, 2011, 11:21:35 pm »

Here was what I was thinking about the mnemonics. Because identifying the keys as 0020 and 0101 is the fastest way to work with the keys, internally that will stay the same. The keys though will be identified using numbers in which we have several options: Axe keys (Keep the key codes as close as possible to the original Axe ones), Casio BASIC keys (Use the exact same keys as Casio BASIC), TI BASIC keys(TI BASIC layout format, my personal favorite), or just a numerical index (1,2,3,...). There are no technical benefits to anyone because the translation will be done at compile time. It is just whichever layout the community would prefer. We can make a poll for this sometime.

Now to use mnemonics in your code. Yo won't be able to just refer to the keys as 45 or 12, but instead as k(45) or k(12). That way the compiler knows to translate the values. The k() part could really be anything, it will probably be replaced with an unused token. Now if you want to have multiple key presses you would say k(45+12). When saying this the compiler will not just add 45 and 12, but add their translated values instead. Also the k() translation would be smart enough to evaluate 0220 + 0210 as 0230 while 0520 + 0220 as 0740.

DJ Omnimaga · « **Reply #12 on:** March 25, 2011, 11:25:10 pm »

Ah ok. How would it be if someone made a language like Axe? Would we be able to do stuff like Getkey(45) and the compiler would translate back to a machine code-compatible format?

z80man · « **Reply #13 on:** March 25, 2011, 11:48:08 pm »

Quote from: DJ_O on March 25, 2011, 11:25:10 pm

Ah ok. How would it be if someone made a language like Axe? Would we be able to do stuff like Getkey(45) and the compiler would translate back to a machine code-compatible format?

Now that you mention it, doing Getkey(45) should automatically translate the 45 value (but it would be a different, faster routine that only checks for that one key, unless it is a multiple key press test then it would be the original routine still). The k() instruction would be for more like if you used code like this.

Code: [Select]

:Getkey->A
:if A= k(45)
:blah
:if A= k(12)
:blah

I did realize one conflict if you said something like Locate 1,1,A and A happens to hold a keycode. In that case the internal keycode would be displayed instead of the mnemonic. So if you do k() on a non-constant variable, it will be a run time translation instead of a compile time one. If you do k() on a variable that contains a multiple keypress code, unfortunately null will be returned because it is impossible to translate that on variable data.

DJ Omnimaga · « **Reply #14 on:** March 27, 2011, 09:18:02 pm »

Hmm I see, thanks for the info.

Would we also have a direct input routine like Getkey(keycode)? Basically in the following code:

If Getkey(45)
Do stuff
End

It will do stuff if the key 45 is pressed. This one allowed for multiple keypresses.

Author Topic: Prizm Getkey (Read 12399 times)

z80man

Prizm Getkey

DJ Omnimaga

Re: Prizm Getkey

AngelFish

Re: Prizm Getkey

DJ Omnimaga

Re: Prizm Getkey

AngelFish

Re: Prizm Getkey

DJ Omnimaga

Re: Prizm Getkey

AngelFish

Re: Prizm Getkey

SimonLothar

Re: Prizm Getkey

AngelFish

Re: Prizm Getkey

SimonLothar

Re: Prizm Getkey

AngelFish

Re: Prizm Getkey

z80man

Re: Prizm Getkey

DJ Omnimaga

Re: Prizm Getkey

z80man

Re: Prizm Getkey

DJ Omnimaga

Re: Prizm Getkey