Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - z80man

Pages: 1 2 [3] 4 5 ... 62
31
Casio Calculators / Re: Prizm goals
« on: October 26, 2011, 01:47:07 pm »
Do you know why accesong the vram is so slow? A friend tried to make his own PutDD, and that was very slow (about 25 fps with, and 33 wihtout)
Yes Casio's PutDD uses the DMAC to transfer data from the VRAM to the display ram. The advantage of the DMAC is that is fully autonomous because it is hardware based instead of being repeated cpu instructions. It also can access ram contents in 64 bit chunks while the cpu can only do 32 bits at a time. Also make sure the VRAM is being accessed from the 0xaxxxxxxx space and not the 0x8xxxxxxx space because the latter will result in slowdowns due to continuous cache misses while the former reads directly from memory and ignores the cache.

From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.

Problem with what we did a long time ago was that the function to overclock is very cpu specific. The code we used was for the SH3 while we need to use code designed for the SH4A. Also because apps execute from virtual memory which cannot access hardware addresses, the function has to be written to physical ram and then executed. Based off what Ive seen this can all surprisingly be done from C so overclocking will not require asm. Do note that the required features for compiling this C code can only be done on gcc while the mini-sdk requires asm to be written to overclock.

32
Math and Science / Re: Inverse kinematics
« on: October 26, 2011, 12:54:48 am »
Well, say the base frame is (0,0,0) and the tool frame is (2,4,-8), each of the articulations is, say, 20cm, and that's all I know (I don't care of XYZ positions of the angles in between), there's some way to calculate the 4 angles?
Hmm that's far beyond my own knowledge of physics. It seems like either way you will have to calculate the xyz coordinate of each joint and have them all add up to your destination. You know that the points joint 3 for example could be forms a hollow sphere and each point upon that sphere is the center of another hollow sphere with each of those points being a possible position of joint 4 and the total shape is now a solid sphere with a diameter of 40 cm. How to calculate the individual angles though is something I can't figure out.

33
Math and Science / Re: Inverse kinematics
« on: October 26, 2011, 12:34:11 am »
If you were to for example call the arm between joints 2 and three 2_3 and you wanted joint 3 at the xyz coordinate of (2,4,-8) in relation to joint 2, you would need to compute the inverse tangent to find the angle. To do so you need a right triangle with one angle at joint 2 and the other joint 3. Because this triangle is not aligned with the axis's you will need to break it down into 2 other triangles, one for y and the other for xz with their hypotenuses forming the legs of your final triangle. so if you solve for the Pythagorean theorem for x and z you get 8.246. Then because the xz leg is the opposite of the angle your solving for, you put it above the y leg which is the adjacent. So you would solve for the inverse tangent of 8.246/4 which equals 64.1 degrees. Now that is only part of the solution as you still need to find the rotation degree which is defined by x and z. Solving the inverse tangent for z over x yields a result of -75.96 degrees which is in the clockwise direction. So your final movement needs to be a clockwise rotation of 75.96 degrees and the arm needs to be bent to an angle of 64.1 degrees. The full formula for the bending angle is tan(-1)( sqrt((x)^2 + (z)^2) / y ) and the formula for rotation is tan(-1)( z / x ) All of this calculated with my trusty Prizm

34
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 11:44:27 pm »
Perhaps this should be tested but atm I don't have a program set up nor the time because I have plenty of homework to do :(
Maybe if I have some time later I'll have some alpha based sprite run around the screen and go through the edges.

35
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 11:29:40 pm »
Eww bad bad typecasts. They won't work (ever try adding a short* to a short*?) and they're just not needed. Adding an int to a pointer is the preferred method for offsetting anyway.
It's been awhile since I did some heavy messing around with type casts. Looks like I forgot that adding an int to a pointer results in an implicit type cast. All of my programming class stuff (which is in java) makes pointers a lot harder when I come back to C especially because java is very strongly typed.

36
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 10:46:02 pm »
I guess that what happens when you code with little sleep and don't have access to a test platform :P
The x_inc I used (and must of accidentally deleted) is for how much the bitmap pointer needs to be incremented every time a new row is drawn. It is left at zero unless the bitmap overlaps either or both the left and right edges, Here is what I modified to hopefully work. Also one thing that I forgot to do is add some pointer type casts as even though I'm pretty sure  gcc will compile this, g++ could have some issues de to the stronger C++ rules about type casts.
Code: [Select]
#define WIDTH 384
#define HEIGHT 216

short * VRAM = (short*) GetVRAMAddress();

void alphaSprite(int x, int y, int width, int height, short * bitmap, short alpha)
{
int x_inc = 0;
if (y < 0)
{
bitmap -= (short*)(y * width);
height += y;
y = 0;
}
if (height > HEIGHT - y) height = HEIGHT - y;

if (x < 0)
{
                bitmap -= (short*)x;
width += x;
x = 0;
                x_inc += -x;
}
if (width > WIDTH - x)
        {
             width = WIDTH - x;
     x_inc += WIDTH - (width + x);
        }
int y_index;
int x_index;
short * base = (short*)(y * WIDTH) + x + VRAM;
for (y_index = height; y_index > 0; --y_index, base += (short*)WIDTH - width, bitmap += (short*)x_inc)
{
for (x_index = width; x_index > 0; --x_index, ++base, ++bitmap)
{
if (*bitmap != alpha) *base = *bitmap;
}
}
}

37
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 04:53:17 pm »
I should have clip' too, may you do it, please?
Sure, I based this example off my previous routine but with some more work I can get a more optimized version out.
Code: [Select]
#define WIDTH 384
#define HEIGHT 216

short * VRAM = (short*) GetVRAMAddress();

void alphaSprite(int x, int y, int width, int height, short * bitmap, short alpha)
{
     int y_index;
     int x_index;
     short * base = y * WIDTH + x + VRAM;
     if (y < 0)
     {
          base += (y & 0x8fffffff) * WIDTH;
          bitmap += (y & 0x8fffffff) * WIDTH;
          height += y;
          y = 0;
     }
     if (height > HEIGHT) height = HEIGHT + y;
     for (y_index = height; y_index > 0; --y_index, base += WIDTH - width, bitmap += x_inc)
     {
          
          for (x_index = width; x_index > 0; --x_index, ++base, ++bitmap)
          {
               if (*bitmap != alpha) *base = *bitmap;
          }
     }
}

38
Introduce Yourself! / Re: Haven't gotten around to introducing myself!
« on: October 25, 2011, 01:06:34 am »
Welcome to omni. I had tried last year to convince my math department to switch to Casio but ran into several difficulties even though all the faculty loved the Prizm.
-the teachers are not yet trained on how to use Casio calcs
-the students who already have difficulty with their 84's will be confused by the Prizm
-parents do not want to buy a new calculator
-the math department has some alliance with TI that is difficult to break

and yet the administration announced that starting next year all textbooks will be replaced with $800 ipad 2's  :P

39
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 12:17:41 am »
I think if (*base != alpha) should be if (*bitmap != alpha) because you want that color in the bitmap to cause transparency, not that color in VRAM.

Edit: Also, base += WIDTH should be base += WIDTH - width because base was increased by the inner loop.
Good eye there. I was umm testing you for your ability to catch my on purpose mistakes  :/

The error has been fixed in my above post

40
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: October 25, 2011, 12:10:01 am »
I assume you mean that the alpha color is supplied at runtime and is only a single bit of alpha meaning that every pixel is either opaque or fully transparent. Here's what I got, it should do the trick. It's pretty simple and do note that it doesn't support clipping so if you need that ask and I'll write another routine.

Edit: fixed bug
Edit2: fixed another bug

Code: [Select]

#define WIDTH 384
#define HEIGHT 216

short * VRAM = (short*) GetVRAMAddress();

void alphaSprite(int x, int y, int width, int height, short * bitmap, short alpha)
{
     int y_index;
     int x_index;
     short * base = y * WIDTH + x + VRAM;
     for (y_index = height; y_index > 0; --y_index, base += WIDTH - width)
     {
          for (x_index = width; x_index > 0; --x_index, ++base, ++bitmap)
          {
               if (*bitmap != alpha) *base = *bitmap;
          }
     }
}


41
News / Re: OS 1.03 and PHYSIUM add-in
« on: October 24, 2011, 11:00:01 pm »
Because Casio removed the 1 Mb limit that would mean that the code used to manage the mmu (virtual memory) has been changed. Previously the executable contents of the g3a file were mapped to virtual memory in pages of a size of 64 kb (I believe) with the mmu capable of holding up to only 128 pages at a time which would mean that the max executable size of a g3a could be 1 Mb . Pages themselves for the sh4a can vary from 1 kb to 1 Mb. Now with the OS update it seems as if the new code uses larger pages (to be checked later once I download this). This also means that more space in the mmu table is available so other programs will have more flexibility if they rely on virtual memory. And also it is not an issue if programs are fragmented as they are mapped as multiple pages but I've never seen this before with the memory and if there wasn't enough room for a file the OS will just run garbage collecting to open up a large enough gap. My last remark is that apps are never loaded to ram for execution but are instead kept in flash. Due to the technical nature of the sh4a reading from flash and ram takes exactly the same amount of time, it is only writing that is done differently. Also for the majority of the time most reads and writes are done in the cache which is significantly faster.

Edit: btw with the physium add-in I can recall some discussion awhile back on the Casio education fb page asking for an app with a periodic table. Perhaps Casio has fully entered the social media world and is taking suggestions from there?

42
Casio Calculators / Re: Compiling stuff for Prizm
« on: October 24, 2011, 03:21:14 pm »
Hello!
I want to begin coding for Prizm, but i don't understand any micro/mini/nano/shufle sdk...
COud you help me, please?
I have the same problem... I don't know how can I build some g3a.
I find that the easiest way to get started is to the gcc SDK hosted on cemetech at http://cemetech.net/forum/viewtopic.php?t=6613&start=0
start with the default project and compile it by running make.bat
To start your own project use the included makefile as a template and modify the sections that read default to that of your own project. Or for the time being while you learn, just modify the code of default and see what you can do. If you have any questions I recommend that you start a help topic here for your projects.

43
Other Calculators / Re: Axe Optimization Contest
« on: October 14, 2011, 12:14:21 am »
I wonder if Runner's example could be expanded upon by using a lookup table because the if values are all consecutive. maybe, maybe not but that's all I got.

44
Miscellaneous / Re: Do u think this is fair?
« on: October 13, 2011, 11:43:08 pm »
I just had to do this...


45
Miscellaneous / Re: how to improve my crysis 2 speeds?
« on: October 13, 2011, 10:56:22 pm »
For a game like Crysis 2 ram is extremely important. ram will hold textures, object meshes, object physics data such as vectors, game code data, audio files, map files, and the all important executable.

Pages: 1 2 [3] 4 5 ... 62