@Ross... Yeah, i am stuck with guys a little longer, haha... Now i have to do stuff like setting I/O pins, flashing LEDS, declaring variables. Is there more info i could find about basic I/O functions?
If you mean the Parallax cog I/O functions, look at some of the demo programs (e.g. test_leds.c - although I don't know if you have any LEDs on an ASC board). All the cog functions are available - see the Catalina Reference Manual (look for the section Cog Functions starting around page 42).
If you mean the "stdio" type I/O functions (e.g. printf(), scanf() etc) I'd recommend you look at a book on C. There is one online here - any book that covers ANSI C will do!
Once you have a led flashing you can start to do some things that are easier in C than in Spin, like loading and reloading cogs from within code. So you can have 20 cog functions in pasm and you can load them in and out of cogs as you need them.
Also there are a whole lot of things already built into Catalina, like sd card access. Use standard C expressions as Ross has already done all the hard work behind the scenes talking to an sd card.
Lots of fun. Try a "for" loop to print "Hello World" ten times.
I've narrowed things down using v3.0 and v3.3 using the command line only and not using code::blocks. This is the compile and download dos screen from v3.0 which works, and below it is the one from 3.3 which gives the cursor at about position 8,8 and no text (or prints random characters). Any help here would be very helpful as I'm a bit stumped by this one.
===================
SETTING UP CATALINA
===================
CATALINA_DEFINE = [default]
CATALINA_INCLUDE = [default]
CATALINA_LIBRARY = [default]
CATALINA_TARGET = [default]
CATALINA_LCCOPT = [default]
CATALINA_TEMPDIR = [default]
LCCDIR = C:\Program Files\Catalina
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
Catalina Compiler 3.0
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\xmm_default.spin
parsing C:\Program Files\Catalina\target\Catalina_Common.spin
parsing C:\Program Files\Catalina\target\Catalina_HUB_XMM_Loader.spin
parsing C:\Program Files\Catalina\target\Catalina_XMM.spin
parsing C:\Program Files\Catalina\target\Catalina_HMI_Plugin_HiRes_Vga_No_Mouse.spin
parsing C:\Program Files\Catalina\target\Catalina_comboKeyboard.spin
parsing C:\Program Files\Catalina\target\Catalina_VGA_HiRes_Text.spin
parsing C:\Program Files\Catalina\target\Catalina_CogCount.spin
parsing C:\Program Files\Catalina\target\Catalina_Float32_A_Plugin.spin
parsing C:\Program Files\Catalina\target\Catalina_CogStore.spin
parsing C:\Program Files\Catalina\target\Catalina_SD_Plugin.spin
compiling xmm_default.spin
compiling Catalina_HUB_XMM_Loader.spin
compiling Catalina_XMM.spin
compiling Catalina_HMI_Plugin_HiRes_Vga_No_Mouse.spin
compiling Catalina_comboKeyboard.spin
compiling Catalina_VGA_HiRes_Text.spin
compiling Catalina_CogCount.spin
compiling Catalina_Float32_A_Plugin.spin
compiling Catalina_CogStore.spin
compiling Catalina_SD_Plugin.spin
compiling Catalina_Common.spin
writing 32768 bytes to C:\Program Files\Catalina\target\xmm_default.eeprom
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\Catalina.spin
compiling Catalina.spin
writing 69724 bytes to NEW.binary
renaming output file from NEW.binary to NEW_temp.binary
combining target and program to NEW.binary
code = 35620 bytes
cnst = 468 bytes
init = 176 bytes
data = 652 bytes
file = 70236 bytes
Payload XMM NEW
Using Propeller (version 1) on port COM1 for first upload
Using port COM1 for subsequent uploads
I've narrowed things down using v3.0 and v3.3 using the command line only and not using code::blocks. This is the compile and download dos screen from v3.0 which works, and below it is the one from 3.3 which gives the cursor at about position 8,8 and no text (or prints random characters). Any help here would be very helpful as I'm a bit stumped by this one.
Can you post the code for NEW.C ? I'll check it out tonight.
/*
* main.c - main program
*/
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Hello World\n");
while(1) ; // the propeller reboots on exit - this line prevents that
return 0;
}
This is the code for new.c, but I think it may be something more complicated. Is there a printout, or a .lst file or something that shows what is going on along the way? For instance, one difference between v3.0 and v3.3 is that I selected "8k cache" in the setup program, but I don't think I selected a cache on the first one. But that might not be the problem either. If one of those listings has a cache enabled and the other does not, how would you know from those listings?
You have not selected any cache option in either compile shown in your post above. If you are compiling your XMM utilities with the cache enabled, then you must compile your program with the same cache option enabled.
Most likely this is your problem. Either recompile your XMM utilities to not use the cache, or recompile your program with the same caching option.
If it is then I am thinking of making an 8k cache the default. One would always want a cache, right?
Thanks Ross.
Well, that's up to you - but remember that such a cache comes at a real cost - not only the lost 8k of Hub RAM, but an extra cog as well!
In some cases, this could make a perfectly valid program fail to run.
The only place I tend to use the cache is on boards that use Flash memory (where it is mandatory) - and even then I tend to only use a 1k cache for most purposes. The nature of caching is that adding more RAM to the cache over the minimum amount quickly becomes less beneficial.
The cost is not that high is it? I mean, you might have a few k for the screen buffer, and there is the stack, and local variables, but that should still leave a lot left over. And with the ability to reload cogs from code precompiled into C arrays, cogs are not so precious any more.
How is the cache working? Is it that you might have some code, possibly it is a function, and without a cache, you are reading the code in over and over from something external (ram/flash etc). And with a cache, all of that function might end up in the cache so now a loop or whatever will run faster because each instruction is being read out of ram?
Why does 8k use an extra cog more than 1k? I didn't know that...
No, sorry - I didn't mean that the 8k cache in particular uses an extra cog. All the caches use 1 extra cog, regardless of size. Only the Hub Ram used changes between the different cache sizes.
The cost is not that high is it? I mean, you might have a few k for the screen buffer, and there is the stack, and local variables, but that should still leave a lot left over. And with the ability to reload cogs from code precompiled into C arrays, cogs are not so precious any more.
How is the cache working? Is it that you might have some code, possibly it is a function, and without a cache, you are reading the code in over and over from something external (ram/flash etc). And with a cache, all of that function might end up in the cache so now a loop or whatever will run faster because each instruction is being read out of ram?
It depends on so many things that it is hard to be definitive. But the cost is likely to be unacceptably high if you are using a HiRes VGA option (which at the higher resolutions can take 8 - 10k of Hub RAM just for the screen buffer), or if you use the TV option plus graphics (which takes even more Hub RAM) and your program is very recursive (which takes a lot of stack space).
It is true that with the ability to load cogs dynamically, we are not so cog-bound as we used to be - but reloading cogs is only an option for things that are not constantly required. If you had (for example) some motors to control, you couldn't simply reload the motor cogs whenever you want to drive the motors - the response time would probably be too long.
The cache works like any other cache - when you request some data from XMM RAM, it reads not only that data but the whole page of data containing the data you requested - on the assumption that you are likely to request more data from the same page soon. This works very well for code, which is mostly sequential with only occasional jumps. It also works well for most data elements (e.g. strings, where you typically access the whole string byte by byte, and not just a random byte here or there).
- although I don't know if you have any LEDs on an ASC board
You can plug a standard LED right into the header between P13 and GND. No resistor necessary. It may be a little dim, but you should be able to see it.
On another subject - I just noticed your web address. Someone from that domain apparently donated to Catalina, but when I tried to send the Catalina Optimizer in return, or even just respond to the email, my emails just kept bouncing and I couldn't figure out who it was from!
Do you want a copy of the Optimizer? If so, send me a PM with an email address and I will send you a copy.
Ok, the secret was in the caching. My IDE had not been updated to include that as a switch, and when I was recompiling in v3.3 I was adding caching but it was not in the command line.
Right now I can't see a reason not to add a cache, but obviously if I run out of memory or something I'll revisit that.
Can I ask you to please take a look at the command line my IDE generates and the one code::blocks is generating? I have a feeling that there are some settings that may not be used now, and/or maybe I do need to add them to code::blocks but I am not sure how.
Ok, the secret was in the caching. My IDE had not been updated to include that as a switch, and when I was recompiling in v3.3 I was adding caching but it was not in the command line.
Right now I can't see a reason not to add a cache, but obviously if I run out of memory or something I'll revisit that.
Sounds reasonable. From memory, I think enabling the cache does improve the speed of XMM program execution on the DracBlade.
Can I ask you to please take a look at the command line my IDE generates and the one code::blocks is generating? I have a feeling that there are some settings that may not be used now, and/or maybe I do need to add them to code::blocks but I am not sure how.
There seem to be a few differences eg plugin, x5, the size of the memory, and shared.
Your advice for each of these would be most appreciated.
Sure:
-D PLUGIN : this option is used to enable the "generic" plugin. It is probably a hangover from your working through the Getting Started with Plugins tutorial. If you no longer need to load the generic plugin, you don't need this. If you do, add it as a linker option in the project's build options instead - i.e:
-x5 : this was the previous way of specifying the LARGE memory mode. It can still be used, but in Code::Blocks you now simply set the LARGE build option (and similarly, instead of -x2, in Code::Blocks you would now simply set the SMALL build option).
-M 512k : This is the same as selecting the Set Memory Size build option, and setting the MEM_SIZE custom variable to 512k. This is the recommended way of doing this in Code::Blocks.
-D SHARED_XMM : I don't think this is required on the DracBlade, and anyway if it is needed, this kind of thing is now done by adding it to the DracBlade_CFG.inc file - in this case, by including a line like the following:
Ok, I'm working on some boards now where I take the dracblade and turn it into a Gadget Gangster tower. I think that will make it easier to mix and match all the options that catalina now has - eg change the memory, then just change one GG board, not the whole thing.
While reading the manual I came across the description of the memory models:
The memory models are:
TINY. The default for Catalina is to produce TINY programs. These
programs can be up to 32kb in size. This model corresponds to the normal
Parallax mode used for SPIN or PASM programs.
TINY programs can be programmed into EEPROM, or loaded using any
program loader, including the Parallax Propeller Tool, the Parallax
Propellant loader, Catalina’s Catalyst SD card loader or Catalina’s
Payload serial loader.
All the programs we have compiled to this point have resulted in TINY
programs.
SMALL. On platforms that have external memory available, Catalina can
produce SMALL programs. These programs can have code segments up to
16Mb in XMM RAM, but all data segments, the stack and the heap space
must fit into the normal Propeller 32kb of Hub RAM.
Copyright 2011 Ross Higson Page 10 of 47
Catalina C Compiler Getting Started
SMALL programs can be loaded into EEPROM, or they can be loaded with
Catalyst or Payload.
LARGE. On platforms that have external memory available, Catalina can
produce LARGE programs. These programs can have code and data
segments and heap space up to a total of 16Mb in XMM RAM – the 32kb
Hub RAM is used only for stack space.
LARGE programs can be loaded into EEPROM, or they can be loaded with
Catalyst or Payload.
And I was thinking about how the "small" model works, with code in external memory, and the data, stack and heap are in the hub.
With caching, this means the moving of the code from 'external storage' into the propeller is going to be a lot faster. So I was wondering if one could think about another model where you don't have external memory. The program sits in an sd card, and bits of it are cached into the hub for running the program. All variables are in the hub. All access to the sd card is going to be reads, no writes, so the sd card won't wear out. This could simplify the hardware as you don't need a memory chip(s). Would this work?
And then I was thinking of another model, where you take the above a bit further, and put the data in external memory, the stack and heap stay in the hub, and the code stays on the sd card.
Neither of these would be practical at all before caching came along, but with caching, does it open up these two as possible new models?
... I was thinking about how the "small" model works, with code in external memory, and the data, stack and heap are in the hub.
With caching, this means the moving of the code from 'external storage' into the propeller is going to be a lot faster. So I was wondering if one could think about another model where you don't have external memory. The program sits in an sd card, and bits of it are cached into the hub for running the program. All variables are in the hub. All access to the sd card is going to be reads, no writes, so the sd card won't wear out. This could simplify the hardware as you don't need a memory chip(s). Would this work?
And then I was thinking of another model, where you take the above a bit further, and put the data in external memory, the stack and heap stay in the hub, and the code stays on the sd card.
Neither of these would be practical at all before caching came along, but with caching, does it open up these two as possible new models?
Yes, using the SD Card in place of XMM RAM would be easy. The result would be very similar to the FLASH modes (since the SD Card is really just a bunch of FLASH chips with fancy packaging). You could have both SMALL and LARGE modes.
I just have to find the time to code up a suitable XMM access module. Someone else is welcome to have a go at it - otherwise I will add it to my list of "things to do".
That would be pretty cool. I've got a Gadget Gangster tower that is 4 boards high, but if you did this, you should be able to run big C programs on the Gadget Gangster USB board as it is: http://gadgetgangster.com/
Now I have Hello World on either a VGA or TV simply by setting a checkbox in code::blocks, I've found one thing is that on the TV screens I am getting a lot of shimmering on the screen with catalina, but not with kyedos. They are using the identical 40x13 TV driver, so I traced through the differences and it comes down to one line in mode
long %10010 'mode
Set that last bit to 1 and it shimmers, set it to 0 and it doesn't.
That last bit is the NTSC/PAL select. My little TVs autoselect and I've found NTSC looks better. But of course, here in Australia we are PAL. But then again, all the US is NTSC. I don't know if you feel strongly about this but I was wondering about making the default NTSC rather than PAL?
Ross, I have Optimizer 3.1. So you must have sent it to me somehow. Though I am at a loss to remember how or find the email. If you do have a second, I'd appreciate if you could send a test message to martin@1mgh.com and PM me the bounce message if you get one.
Ross, I can see "small" mode on SD card using cache. But, how would "LARGE" mode work?
I don't think it would be a good idea to be contuously writing to SD (besides being extremely slow).
Or, do you mean using SD along with some other SRAM chip?
Yes, using the SD Card in place of XMM RAM would be easy. The result would be very similar to the FLASH modes (since the SD Card is really just a bunch of FLASH chips with fancy packaging). You could have both SMALL and LARGE modes.
I just have to find the time to code up a suitable XMM access module. Someone else is welcome to have a go at it - otherwise I will add it to my list of "things to do".
Ross.
Ross, I did one (single, maybe not enough motivated) attempt at using the uSD on RamBlade as raw flash for code, while using another card on a companion board for disk services.
Tried to load a stripped copy of femtospi under that, as a low level driver to provide intialization, read_block and write_block, but probably is not the correct way (should be using it as a plugin maybe).
This because lately both my RamBlades have been misteriously failing with XMM stuff. :depressed:
I have an unrelated question: is the refresh of dynamic rams still supported?
As I understand, it should be managed by the cache driver, but the memory test reading seems to indicate that I still have a refresh problem, even including the cache (and calls to refresh function in the cache command loop).
Thanks guys... I actually have an LED blinking on pin 0. It is very dim, but noticeable enough to know it is working. I am guessing the resistor(For 5 v shields) is to blame for that. Oh, and Martin, i see solder pads underneath the board where the headers are located. I would assume if someone were to make a solder bridge across those, that the connection would bypass the protection resistors?
@Ross... I have read over the LED demo several times just to get a handle on everything that is going on, but i have two(Maybe three) questions.
First being: The _dira/ outa commands can support ALL 32 I/O pins right? And the other question relating to that is: Can you use a binary value to send to the dira/outa registers, like you could in SPIN.. You know something like this:
Outa[%10000000] := 1
Or a numeric value like
Outa[12] := 1
I tried using the % and C didn't know what it was. I am not really sure what number system that the #define bitmask 0x00008000 uses? Is that hex? Sorry, i should probably know this stuff by now.
My last question was the += command(That the count variable uses)... I read online that that is a compound assignment operator for addition... So that would be the same as saying,
Oh, and Martin, i see solder pads underneath the board where the headers are located. I would assume if someone were to make a solder bridge across those, that the connection would bypass the protection resistors?
Comments
If you mean the Parallax cog I/O functions, look at some of the demo programs (e.g. test_leds.c - although I don't know if you have any LEDs on an ASC board). All the cog functions are available - see the Catalina Reference Manual (look for the section Cog Functions starting around page 42).
If you mean the "stdio" type I/O functions (e.g. printf(), scanf() etc) I'd recommend you look at a book on C. There is one online here - any book that covers ANSI C will do!
Ross.
You're determined to send me bankrupt, aren't you? :frown:
READ MY LIPS: NO MORE DISCOUNTS!!!
Once you have a led flashing you can start to do some things that are easier in C than in Spin, like loading and reloading cogs from within code. So you can have 20 cog functions in pasm and you can load them in and out of cogs as you need them.
Also there are a whole lot of things already built into Catalina, like sd card access. Use standard C expressions as Ross has already done all the hard work behind the scenes talking to an sd card.
Lots of fun. Try a "for" loop to print "Hello World" ten times.
I've narrowed things down using v3.0 and v3.3 using the command line only and not using code::blocks. This is the compile and download dos screen from v3.0 which works, and below it is the one from 3.3 which gives the cursor at about position 8,8 and no text (or prints random characters). Any help here would be very helpful as I'm a bit stumped by this one.
and the v3.3 download
Can you post the code for NEW.C ? I'll check it out tonight.
Thanks.
/* * main.c - main program */ #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello World\n"); while(1) ; // the propeller reboots on exit - this line prevents that return 0; }This is the code for new.c, but I think it may be something more complicated. Is there a printout, or a .lst file or something that shows what is going on along the way? For instance, one difference between v3.0 and v3.3 is that I selected "8k cache" in the setup program, but I don't think I selected a cache on the first one. But that might not be the problem either. If one of those listings has a cache enabled and the other does not, how would you know from those listings?
You have not selected any cache option in either compile shown in your post above. If you are compiling your XMM utilities with the cache enabled, then you must compile your program with the same cache option enabled.
Most likely this is your problem. Either recompile your XMM utilities to not use the cache, or recompile your program with the same caching option.
Ross.
If it is then I am thinking of making an 8k cache the default. One would always want a cache, right?
Thanks Ross.
In some cases, this could make a perfectly valid program fail to run.
The only place I tend to use the cache is on boards that use Flash memory (where it is mandatory) - and even then I tend to only use a 1k cache for most purposes. The nature of caching is that adding more RAM to the cache over the minimum amount quickly becomes less beneficial.
Ross.
The cost is not that high is it? I mean, you might have a few k for the screen buffer, and there is the stack, and local variables, but that should still leave a lot left over. And with the ability to reload cogs from code precompiled into C arrays, cogs are not so precious any more.
How is the cache working? Is it that you might have some code, possibly it is a function, and without a cache, you are reading the code in over and over from something external (ram/flash etc). And with a cache, all of that function might end up in the cache so now a loop or whatever will run faster because each instruction is being read out of ram?
No, sorry - I didn't mean that the 8k cache in particular uses an extra cog. All the caches use 1 extra cog, regardless of size. Only the Hub Ram used changes between the different cache sizes.
Ross.
It depends on so many things that it is hard to be definitive. But the cost is likely to be unacceptably high if you are using a HiRes VGA option (which at the higher resolutions can take 8 - 10k of Hub RAM just for the screen buffer), or if you use the TV option plus graphics (which takes even more Hub RAM) and your program is very recursive (which takes a lot of stack space).
It is true that with the ability to load cogs dynamically, we are not so cog-bound as we used to be - but reloading cogs is only an option for things that are not constantly required. If you had (for example) some motors to control, you couldn't simply reload the motor cogs whenever you want to drive the motors - the response time would probably be too long.
The cache works like any other cache - when you request some data from XMM RAM, it reads not only that data but the whole page of data containing the data you requested - on the assumption that you are likely to request more data from the same page soon. This works very well for code, which is mostly sequential with only occasional jumps. It also works well for most data elements (e.g. strings, where you typically access the whole string byte by byte, and not just a random byte here or there).
Ross.
You can plug a standard LED right into the header between P13 and GND. No resistor necessary. It may be a little dim, but you should be able to see it.
On another subject - I just noticed your web address. Someone from that domain apparently donated to Catalina, but when I tried to send the Catalina Optimizer in return, or even just respond to the email, my emails just kept bouncing and I couldn't figure out who it was from!
Do you want a copy of the Optimizer? If so, send me a PM with an email address and I will send you a copy.
Ross.
Ok, the secret was in the caching. My IDE had not been updated to include that as a switch, and when I was recompiling in v3.3 I was adding caching but it was not in the command line.
Right now I can't see a reason not to add a cache, but obviously if I run out of memory or something I'll revisit that.
Can I ask you to please take a look at the command line my IDE generates and the one code::blocks is generating? I have a feeling that there are some settings that may not be used now, and/or maybe I do need to add them to code::blocks but I am not sure how.
This is the command line from my IDE
and this is the one from code::blocks
There seem to be a few differences eg plugin, x5, the size of the memory, and shared.
Your advice for each of these would be most appreciated.
Sure:
-x5 : this was the previous way of specifying the LARGE memory mode. It can still be used, but in Code::Blocks you now simply set the LARGE build option (and similarly, instead of -x2, in Code::Blocks you would now simply set the SMALL build option).
-M 512k : This is the same as selecting the Set Memory Size build option, and setting the MEM_SIZE custom variable to 512k. This is the recommended way of doing this in Code::Blocks.
-D SHARED_XMM : I don't think this is required on the DracBlade, and anyway if it is needed, this kind of thing is now done by adding it to the DracBlade_CFG.inc file - in this case, by including a line like the following:
Ok, I'm working on some boards now where I take the dracblade and turn it into a Gadget Gangster tower. I think that will make it easier to mix and match all the options that catalina now has - eg change the memory, then just change one GG board, not the whole thing.
While reading the manual I came across the description of the memory models:
And I was thinking about how the "small" model works, with code in external memory, and the data, stack and heap are in the hub.
With caching, this means the moving of the code from 'external storage' into the propeller is going to be a lot faster. So I was wondering if one could think about another model where you don't have external memory. The program sits in an sd card, and bits of it are cached into the hub for running the program. All variables are in the hub. All access to the sd card is going to be reads, no writes, so the sd card won't wear out. This could simplify the hardware as you don't need a memory chip(s). Would this work?
And then I was thinking of another model, where you take the above a bit further, and put the data in external memory, the stack and heap stay in the hub, and the code stays on the sd card.
Neither of these would be practical at all before caching came along, but with caching, does it open up these two as possible new models?
Yes, using the SD Card in place of XMM RAM would be easy. The result would be very similar to the FLASH modes (since the SD Card is really just a bunch of FLASH chips with fancy packaging). You could have both SMALL and LARGE modes.
I just have to find the time to code up a suitable XMM access module. Someone else is welcome to have a go at it - otherwise I will add it to my list of "things to do".
Ross.
Now I have Hello World on either a VGA or TV simply by setting a checkbox in code::blocks, I've found one thing is that on the TV screens I am getting a lot of shimmering on the screen with catalina, but not with kyedos. They are using the identical 40x13 TV driver, so I traced through the differences and it comes down to one line in mode Set that last bit to 1 and it shimmers, set it to 0 and it doesn't.
That last bit is the NTSC/PAL select. My little TVs autoselect and I've found NTSC looks better. But of course, here in Australia we are PAL. But then again, all the US is NTSC. I don't know if you feel strongly about this but I was wondering about making the default NTSC rather than PAL?
I don't think it would be a good idea to be contuously writing to SD (besides being extremely slow).
Or, do you mean using SD along with some other SRAM chip?
Ross, I did one (single, maybe not enough motivated) attempt at using the uSD on RamBlade as raw flash for code, while using another card on a companion board for disk services.
Tried to load a stripped copy of femtospi under that, as a low level driver to provide intialization, read_block and write_block, but probably is not the correct way (should be using it as a plugin maybe).
This because lately both my RamBlades have been misteriously failing with XMM stuff. :depressed:
I have an unrelated question: is the refresh of dynamic rams still supported?
As I understand, it should be managed by the cache driver, but the memory test reading seems to indicate that I still have a refresh problem, even including the cache (and calls to refresh function in the cache command loop).
@Ross... I have read over the LED demo several times just to get a handle on everything that is going on, but i have two(Maybe three) questions.
First being: The _dira/ outa commands can support ALL 32 I/O pins right? And the other question relating to that is: Can you use a binary value to send to the dira/outa registers, like you could in SPIN.. You know something like this:
Outa[%10000000] := 1
Or a numeric value like
Outa[12] := 1
I tried using the % and C didn't know what it was. I am not really sure what number system that the #define bitmask 0x00008000 uses? Is that hex? Sorry, i should probably know this stuff by now.
My last question was the += command(That the count variable uses)... I read online that that is a compound assignment operator for addition... So that would be the same as saying,
Count = count + some value
right?
Thanks for all the help so far...
That's exactly what they're for, yes.
If you can find one for less than the price of a small house... Be sure to get ANSI-C version
http://www.amazon.com/gp/offer-listing/0131103628/ref=dp_olp_used?ie=UTF8&condition=used
I paid $57.63 at B&N for a new copy not too long ago.
Jim
Jim