Stop programming and write your book.
merthsoft wrote:
Stop programming and write your book.
^You just posted a thread begging us to force you to write your book because you have failed to motivate yourself, then you immediately post a coding post. 
christop wrote:
I'm not sure if it's valid C90/C99, but it is valid according to K&R C (which GCC allows). You can even omit types on global variable declarations. 
It's generally considered poor form to leave off types, of course
It's generally considered poor form to leave off types, of course
"poor form"? It's a code error. Nobody codes in K&R C. Whenever someone talks about "C" they always mean ANSI C, which basically replaced K&R C in the late 80s (even the K&R "C Programming Language" book switched to ANSI C)
GCC actually does *NOT* support K&R C, but does have some support with the "-traditional" option.
Kllrnohj wrote:
christop wrote:
I'm not sure if it's valid C90/C99, but it is valid according to K&R C (which GCC allows). You can even omit types on global variable declarations.
It's generally considered poor form to leave off types, of course
It's generally considered poor form to leave off types, of course
"poor form"? It's a code error. Nobody codes in K&R C. Whenever someone talks about "C" they always mean ANSI C, which basically replaced K&R C in the late 80s (even the K&R "C Programming Language" book switched to ANSI C)
GCC actually does *NOT* support K&R C, but does have some support with the "-traditional" option.
Nope, some of it actually is valid code in both C89/C90 (C90 is C89 with very minor changes) and C99. Here is what C89 has to say about function definitions (1988 draft from http://flash-gordon.me.uk/ansi.c.txt since the C89 standard is not freely available, AFAIK):
Code:
function-definition:
declaration-specifiers<opt> declarator
declaration-list<opt> compound-statement
declarator:
pointer<opt> direct-declarator
direct-declarator:
identifier
( declarator )
direct-declarator [ constant-expression<opt> ]
direct-declarator ( parameter-type-list )
direct-declarator ( identifier-list<opt> )
declaration-list:
declaration
declaration-list declaration
declaration:
declaration-specifiers init-declarator-list<opt> ;
declaration-specifiers:
storage-class-specifier declaration-specifiers<opt>
type-specifier declaration-specifiers<opt>
type-qualifier declaration-specifiers<opt>(I compiled all of these syntax definitions from various parts of the standard.)
That says declaration-specifiers (the return type of a function) is optional, and the parameter list can simply be an identifier list without types. All of the following function definitions are therefore valid C89:
Code:
func(x, y) { return 9001; }
func(x, y) int x; { return 9001; }
((((func))))(x, y) int x; int y; { return 9001; } /* yes, this is valid */
int ((func))(x, y) { return 9001; }Then again, C99 defines the function definition syntax as this (from http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf):
Code:
function-definition:
declaration-specifiers declarator declaration-list<opt> compound-statementThe only difference is that declaration-specifiers is not optional as it is in C89, so you cannot omit the return type in C99.
Also, it appears that variable declarations without a type is not valid, according to C89 (C99 has the same syntax definition here):
Code:
declaration:
declaration-specifiers init-declarator-list<opt> ;
declaration-specifiers:
storage-class-specifier declaration-specifiers<opt>
type-specifier declaration-specifiers<opt>
type-qualifier declaration-specifiers<opt>
init-declarator-list:
init-declarator
init-declarator-list , init-declarator
init-declarator:
declarator
declarator = initializerBut, since init-declarator-list is optional, this syntax does allow the following meaningless code:
Code:
extern;
void;
static void const;
Really quick.
Explain what
Code:
returns if it's an integer (int).
Also, how fast can the Prizm update stuff on the screen? Can it update 20+ moving objects without lag?
Explain what
Code:
&keyreturns if it's an integer (int).
Also, how fast can the Prizm update stuff on the screen? Can it update 20+ moving objects without lag?
Raylin wrote:
Really quick.
Explain what
Code:
returns if it's an integer (int).
Explain what
Code:
&keyreturns if it's an integer (int).
& always returns a pointer. If key is an int, then &key will return int*. However, you have to be careful with that, as key will have been created on the stack and thus you need to make sure than you don't hold on to the pointer longer than key is on the stack.
Code:
someMethod(&key);is probably fine, but
Code:
return &key;is a huge no-no.
Quote:
Also, how fast can the Prizm update stuff on the screen? Can it update 20+ moving objects without lag?
That is really two different questions. The first is what is the fill rate of the Prizm. Fill rate is how many pixels can be pushed in a second. I have no clue what the prizm can do there.
The second part of that is more about how many pixels those objects are and how optimized your algorithm is. It also matters how much extra work you want to do, such as whether or not you want to simulate physics interactions between them.
Responding to the Prizm-specific questions, with moderate rendering and screen-refreshing in a tight loop, at 58MHz, we can get around 22FPS. Much of that time is spent in the DMA from the VRAM to the LCD, and I worked out the math to some impressive double-digit mbps from the VRAM to the LCD, so 22FPS is pretty good here.
I'm down with that.
Now, here's another question.
How does the Prizm handle suspended data or variables?
I tested a Hello World program which pauses at the end and waits for a key to be pressed. What usually happens is that, from a fresh start, it works like it's supposed to do. Any other time, it just flashes the text and that's it.
Now, here's another question.
How does the Prizm handle suspended data or variables?
I tested a Hello World program which pauses at the end and waits for a key to be pressed. What usually happens is that, from a fresh start, it works like it's supposed to do. Any other time, it just flashes the text and that's it.
Self-modifying code is no longer an option when moving from the z80 calculators to programming for the Prizm, but luckily, you can open and save files, just as you might use AppVars.
KermMartian wrote:
Self-modifying code is no longer an option when moving from the z80 calculators to programming for the Prizm, but luckily, you can open and save files, just as you might use AppVars.
I don't think I was clear in my question.
Good info, though.
What I meant to say was, when I made my Hello World g3a and put it on my Prizm calculator, it worked just fine from a clean start. A clean start, in this case, means after closing the program completely via opening another program or turning off the calc. However, after going to the menu and reopening said addin, it only flashes the text to the screen and disappears.
This is the code for it.
Code:
#include <color.h>
#include <display_syscalls.h>
#include <keyboard_syscalls.h>
#include <keyboard.hpp>
void main()
{
Bdisp_AllCr_VRAM();
PrintXY(1,1," Hello World!",TEXT_MODE_NORMAL,TEXT_COLOR_GREEN);
PrintXY(1,2," This is just a test!",TEXT_MODE_NORMAL,TEXT_COLOR_BLUE);
PrintXY(1,3," Another test!",TEXT_MODE_NORMAL,TEXT_COLOR_RED);
int key;
do{
GetKey(&key);
} while (!key);
} Raylin wrote:
What I meant to say was, when I made my Hello World g3a and put it on my Prizm calculator, it worked just fine from a clean start. A clean start, in this case, means after closing the program completely via opening another program or turning off the calc. However, after going to the menu and reopening said addin, it only flashes the text to the screen and disappears.
This is the code for it.
Code:
This is the code for it.
Code:
int key;
do{
GetKey(&key);
} while (!key);
}Potentially a bug in your code. You aren't initializing key, meaning it will basically have a random value on startup, depending on whatever the previous value at that spot in ram happened to have. I don't know how GetKey works to know if it will always set a value, but if GetKey can return without changing the value of key, then you just need to initialize key.
You should *always* initialize your variables.
Register to Join the Conversation
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
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