I'll ask questions here.

First one -- what syscall can I use to do non-blocking checking for a keycode, and what group of keycodes correlate to it? PRGM_GetKey() for some reason throws an error "undefined reference to _PRGM_GetKey" even though I define "keyboard.hpp". Help?
When in doubt, check the documentation thread.

EDIT:

EDIT2: Removed to save space.
Aren't those the keycodes for the getkey routine I made several months ago? Those won't work for syscall keycodes though. But because I suck with image editing software I'll let someone else take care of it.
Qwerty: That documentation is irrelevant for this situation, since he's using the PrizmSDK GCC-based package, as far as I can tell. Ashbad:


Code:
int PRGM_GetKey(){
unsigned char buffer[12];
   PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}


You can just use equates like KEY_PRGM_UP, KEY_PRGM_RETURN, etc.
z80man wrote:
Aren't those the keycodes for the getkey routine I made several months ago? Those won't work for syscall keycodes though. But because I suck with image editing software I'll let someone else take care of it.


Oops, forgot about that Razz
Ignore those keycodes then :p

@Kerm, that's not useless because the syscalls in that thread are

1) Possible to use in GCC via the code I gave Ashbad earlier
2) The basis for the syscalls in GCC, which from what Jonimus has led me to believe, cover almost all of the ones in that thread.

Anyway, fixed:



EDIT:

The actual value for the x^2 key is 008B, not the value listed in the key. Pressing the ALPHA button changes the keycodes returned. Be careful of that.
KermMartian wrote:
Qwerty: That documentation is irrelevant for this situation, since he's using the PrizmSDK GCC-based package, as far as I can tell. Ashbad:


Code:
int PRGM_GetKey(){
unsigned char buffer[12];
   PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}


You can just use equates like KEY_PRGM_UP, KEY_PRGM_RETURN, etc.


Thank you Kerm, that was very helpful Wink

another question, though it's not related just to the prizm -- it's about structs. I read up about them, though I'm not completely sure how they work. It's only a group of variables, am I correct? No functions within them? And, as an addition, what are unions and how are they similar to structs?
Ashbad wrote:
KermMartian wrote:
Qwerty: That documentation is irrelevant for this situation, since he's using the PrizmSDK GCC-based package, as far as I can tell. Ashbad:


Code:
int PRGM_GetKey(){
unsigned char buffer[12];
   PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}


You can just use equates like KEY_PRGM_UP, KEY_PRGM_RETURN, etc.


Thank you Kerm, that was very helpful Wink

another question, though it's not related just to the prizm -- it's about structs. I read up about them, though I'm not completely sure how they work. It's only a group of variables, am I correct? No functions within them? And, as an addition, what are unions and how are they similar to structs?
A struct is sort of like a class, but every variable is public unless specified and there are no functions. Unions allow variables to share the same memory. Such as if two shorts and one int need to represent the same memory.
Put another way, structs are ways to organize a bunch of related variables into a single container, for example the position and health of a player, or something like that, where you might have a lot of players and thus a lot of structs, each containing the same variables but relevant to different players. Unions are ways to reuse the same variable as if it was different types.
Thanks, that explains it Smile

Also, I'm now having an unfixable error in my source. No matter how I change the program, it still occurs. Here is the error:


Code:
System ERROR
REBOOT    :[EXIT]
INITIALIZE:[EXE]
 ADDRESS(W)
 TARGET=0810000A
 PC    =0810000A


I assume this is the equivalent of a RAM clear on an 84+? Anyways, I've changed my main() routine to absolutely nothing (the example has a return Clean_Exit; but even without it the error still happens). I really have no idea what would be causing this. I would be very grateful if you could look at my Source File and My Sprite Data File (both are pastebins) and help me figure out what I'm doing wrong.

EDIT: and important data (maybe?): no errors whatsoever from the compiler.
I suspect that the error may be the result of your program trying to jump to that address, which could easily cause the system to complain.
The question is why, though if he is using the old SDK it could be the broken Prizm.ld, but I'm not sure.
I'm using the new GCC one Sad I looked over the code again, and I still have no idea why it's happening.
It looks like a problem with the linker script. Puzzling out what the error message means, it looks like it faulted trying to do a word access to memory at 0x810000A. After compiling it myself and having objdump do a disassembly, that seems to support my initial conclusion, and the offending code seems to be part of crt0:

Code:
00300018 <dataDone>:
  300018:       d2 13           mov.l   300068 <v_ram_ebss>,r2  ! 810000e
  30001a:       d3 12           mov.l   300064 <v_ram_bbss>,r3  ! 810000a <_bbss>
  30001c:       e1 00           mov     #0,r1
0030001e <bssLoop>:
  30001e:       32 32           cmp/hs  r3,r2
  300020:       8b 01           bf      300026 <bssDone>
  300022:       af fc           bra     30001e <bssLoop>
  300024:       22 16           mov.l   r1,@-r2
Note the word access to 810000a.

I think setting some section alignment in the linker script should fix it:

Code:
SECTIONS
{
        /* Code, in ROM */
        .text : {
                *(.pretext)     /* init stuff */
                *(.text)
                *(.text.*)
        } > rom
       
        /* Read-only data, in ROM */
        .rodata ALIGN(4): {
                *(.rodata)
                *(.rodata.*)
        } > rom
       
        /* RW initialized data, VMA in RAM but LMA in ROM */
        .data ALIGN(4): {
                _bdata = . ;
                *(.data)
                *(.data.*);
                _edata = . ;
        } >ram AT>rom
       
        /* Uninitialized data (fill with 0), in RAM */
        .bss ALIGN(4): {
                _bbss = . ;
                *(.bss) *(COMMON);
                _ebss = . ;
        } >ram
}


I'd guess you uncovered this problem partially by chance and partially through your zealous use of shorts. Compare to Kerm, whose code seems to mostly use ints instead, which are 32 bits wide on SH targets and hence will have no alignment issues. Your shorts open up the possibility of such unaligned accesses moreso.

This brings up that I had at some point hoped to optimize the crt0 routines a little more to handle such unaligned cases, but at this point I think having smaller initialization code is preferable to having it be slightly faster.
hmm, okay, I guess that means I'll be using ints from now on. Thanks for the explaining though, I appreciate it Smile
Ashbad wrote:
hmm, okay, I guess that means I'll be using ints from now on. Thanks for the explaining though, I appreciate it Smile

No, do whatever you want. It's a bug on my end, and I think the slightly changed chunk of prizm.ld in my post should fix it (but somebody needs to test it and see if that actually fixes it..).
oh, okay Smile thanks for all of the help!
Updated prizm.ld is here http://jonimoose.net/calcstuff/prizm/prizm.ld you can drop it in projects/common and all should be good, assuming Tari's suspicions are correct.
TheStorm wrote:
The question is why, though if he is using the old SDK it could be the broken Prizm.ld, but I'm not sure.
^I'd bank on this possibility. Have you grabbed this latest version?

http://jonimoose.net/calcstuff/prizm/PrizmSDK.zip
I would recommend using ints most of the time for Super H coding unless you are doing extensive division. This is especially true if the values are unsigned. On the Super H when it comes to shorts and chars generally signed values are more optimized due to the automatic sign extension done by the cpu. With unsigned values an extra zero extension is required to get the proper result. And even ints are more optimized when signed because some comparison instructions only work with with signed values. These being greater than zero and greater than or equal to zero tests.
I hope Ashbad doesn't mind if I ask a couple questions here.

Since I managed to get the MingGW compiler working on my system, I've been trying learning the language a bit by messing around with the provided code. But it seems that I'm not doing something properly, because neither the unmodified code nor the modified code display anything on the screen.

Here's the code I'm working with:


Code:

#include <display.h>
#include <keyboard_syscalls.h>
#include <SYSTEM_syscalls.h>
#include <keyboard.hpp>
//
void main(void) {
   int x = 1;
   int y = 1;
   int color = 0;
   int mode = 0;
   int key;
   int iContinue = 1;

   char* heart = "----";
   heart[2] = 0xE5;
   heart[3] = 0xE2;
   heart[4] = 0xE3
   Bdisp_AllCr_VRAM();

   while (iContinue) {
      Bdisp_AllCr_VRAM();
      PrintXY(x, y, heart, mode, color);
      Bdisp_PutDisp_DD();
      switch (key) {
         case KEY_CTRL_EXIT:
            iContinue = 0;
            break;
         case KEY_CHAR_8:
            y = y == 1 ? 8 : y-1;
            break;
         case KEY_CHAR_2:
            y = y == 8 ? 1 : y+1;
            break;
         case KEY_CHAR_6:
            x = x == 0 ? 21 : x-1;
            break;
         case KEY_CHAR_4:
            x = x == 21 ? x=1 : x+1;
            break;
         case KEY_CHAR_PLUS:
            color = color == 7 ? 0 : color+1;
            break;
         case KEY_CHAR_MINUS:
            color = color == 0 ? 7 : color-1;
            break;
         case KEY_CHAR_MULT:
            mode = !mode;
            break;
         case KEY_CHAR_DIV:
            mode = !mode;
            break;
      }
   }

   return;
}
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement