dgately, I'm trying your instructions on a new MacBook Air...
First problem was that there is no "local" folder, so using "/usr/lib/catalina" instead. Is that going to be a problem?
Next, "source use_catalina" doesn't work. There doesn't seem to be a "use_catalina" file...
Ray,
You can make your own /usr/local directory in the Terminal app. You'll need to do that as root or with the "sudo" command, like this "$sudo mkdir /usr/local". You can also make the entire tree with "$sudo mkdir /usr/local/lib"...
Or, you can just leave Catalina in /usr/lib/catalina and export your paths in your .profile file and source it...
# Add path to catalina proepeller compiler
export PATH=/usr/lib/catalina/bin:/usr/local/lib/catalina/include:/usr/lib/catalina/lib:$PATH
The use_catalina file may have been created during the build process. It goes into catalina's root directory (in your case "/usr/lib/catalina") and its content is (edited for your catalina path):
#!/bin/bash
#
# ===================
# SETTING UP CATALINA
# ===================
#
echo ""
echo "I hope you used 'source use_catalina' to execute this!"
echo ""
#
if [[ "$LCCDIR" == "" ]] ; then
PATH=.:/usr/lib/catalina/bin:$PATH; export PATH
else
PATH=.:$LCCDIR/bin:$PATH; export PATH
fi
catalina_env
Unfortunately, I was not able to attach the whole catalina tree that I built (size issue) and could only attach the /bin directory...
Hopefully, these instructions will help you get further!
You can make your own /usr/local directory in the Terminal app. You'll need to do that as root or with the "sudo" command, like this "$sudo mkdir /usr/local". You can also make the entire tree with "$sudo mkdir /usr/local/lib"...
Or, you can just leave Catalina in /usr/lib/catalina and export your paths in your .profile file and source it...
You can install Catalina anywhere you like - but on Unix-style systems such as Linux or OS X, if it is not installed in /usr/local/lib/catalina you will need to edit a few script files if you want to build it from source.
Most of the scripts used to actually use catalina depend on the the LCCDIR environment variable to tell them where Catalina is installed, so they will work correctly as long as you have this set up. This is the main purpose of the use_catalina script, so you should at least edit that file - or use another mechanism for setting the LCCDIR environment variable.
The scripts you will have to edit are the ones used to rebuild Catalina from source. Here is a list:
I just noticed there are two utility scripts (used on Linux installations only) that don't use the LCCDIR environment variable, so you will also have to edit these manually (I will fix this in the next release):
Forgive me for not following all of the Catalina post but can some one summarize what the procedure would be to compile the latest version under MAC OS X 10.6.8? (i.e. Snow Leopard)
Forgive me for not following all of the Catalina post but can some one summarize what the procedure would be to compile the latest version under MAC OS X 10.6.8? (i.e. Snow Leopard)
Thanks you much for any help.
rich
Building Catalina on OS X is fairly easy. You need to have gcc installed, and you probably need to be root.
Then:
Download any of the 3.11 distributions from SourceForge (they are all the same except for the binaries, which we will rebuild anyway!).
Create directory /usr/local/lib/catalina
cd to /usr/local/lib/catalina and unpack the 3.11 files into this directory
Download the Catalina_3.11_Errata.zip file from SourceForge
Unpack the errata file to a temporary directory somewhere.
Pick any of the sub-directories in the errata file (e.g. Linux32) and copy the contents of that subdirectory over the Catalina 3.11 distribution files.
Then execute the following commands:
cd /usr/local/lib/catalina
source ./bin/Set_Linux_Permissions
cd source/catalina
./build_all
cd ../openspin
./build_all
cd ../lcc
./build_all
cd ../lib
./build_all
The above commands build the core of Catalina - basically, the command-line compiler and all the libraries and utilitues. You can stop here if you want.
Then there are some optional steps:
cd ../srecord
./build_all
The above step builds the srecord utilities, which can save the compiled output into many different binary formats - but Catalina natively supports .binary and .eeprom formats (which are all most people need) so building srecord is optional - most people won't need it, and to build it you need the boost libraries installed.
The last step is to build Code::Blocks. To do this, download the sources for version 10.05 (it must be this version) from http://www.codeblocks.org/ - once you get this far, let me know and I'll point out some minor changes you need to make to that distribution.
I just realized I had not updated the Code::Blocks source code changes for Catalina since release 3.4, so I have now added this to SourceForge (as Catalina_3.11_CodeBlocks.zip). Keen eyed observers may also notice a new version of the Windows one touch installer (Catalina_3.11_Setup.exe). This is not a new version, I just did this so that it will still be the "newest" file on SourceForge (i.e. it will appear at the top of the list).
Ross, I'll try you instructions on my MacBook Air. It's good training for me....
Thanks, Rayman. The OSX build process actually seems simpler than for other platforms. For instance, I was a little surprised to find I didn't need to install any additional packages (like bison and flex) to build Catalina - but maybe this was because my virtual image (which is of unknown and probably disreputable origins!) already had them installed. Or maybe they are installed as part of gcc.
Anyway, I'll be interested to hear if you find any additional steps you need to complete the core "command line" compiler build (I know there are extra packages required to build Code::Blocks).
Ok, I spend half an hour on this... Had to learn a few things...
First, I figured out how to go to the /usr folder in Finder. It normally won't show it. But, if you do "command"+"shift"+"G" you can go to any folder.
Second, I had to change permissions on the folder. That "source" command did not seem to work. But, in Finder, you can do a "Get Info" and then click the lock symbol to be able to change for "everyone" to "read&write".
I think I was able to build everything except for the "srecord". Got a message saying I need to install "Boost" for that. Since you said I don't need it, I'll ignore that.
"source use_catalina" seems to work now. I suppose this lets me execute "catalina" from anywhere, right?
I think I will update the default payload timeout on *nix systems to 1000 ms in the next release. It seems to be necessary on a few systems (including one of mine) and won't cause others too much grief.
Also, I am working on an updated version of catdbgfilegen. This component is required for the debugger, and it is currently written in C#. It is the only remaining Catalina component that requires "mono" to be installed on *nix systems, so I will replace it with a workalike that doesn't.
I have been using 3.10 and tried moving to 3.11
I am using a Ramblade3 and moved all the appropriate files to the target directory. Compiling works fine, no errors.
I started with using -C OLD_SD so that it used the old sd card drivers. The application worked fine, using a 1 gb card.
So then I removed the OLD_SD flag, and compiled to a SDHC card. But when I tried to run the application, catalyst doesn't load it off the SD card, it just hangs.
I tried a few cards, but they all acted the same.
I was told a long time ago, that I didn't have to load a new version of Catalyst into the EEPROM of the Ramblade3 every time, so I am still using the catalyst.bin file from earlier (I believe it is from 3.06)
Does 3.11 require I make and load a new version of catalyst? All the earlier revs of catalina did not require it.
I have been using 3.10 and tried moving to 3.11
I am using a Ramblade3 and moved all the appropriate files to the target directory. Compiling works fine, no errors.
I started with using -C OLD_SD so that it used the old sd card drivers. The application worked fine, using a 1 gb card.
So then I removed the OLD_SD flag, and compiled to a SDHC card. But when I tried to run the application, catalyst doesn't load it off the SD card, it just hangs.
I tried a few cards, but they all acted the same.
I was told a long time ago, that I didn't have to load a new version of Catalyst into the EEPROM of the Ramblade3 every time, so I am still using the catalyst.bin file from earlier (I believe it is from 3.06)
Does 3.11 require I make and load a new version of catalyst? All the earlier revs of catalina did not require it.
Any assistance would be appreciated.
Bruce Prager
Hi Bruce,
Yes, you definitely need the recompile the version of Catalyst included in 3.11 (and reload it into EEPROM) to use SDHC cards, since Catalyst itself also includes the SDHC driver.
As you have found, any version of Catalyst prior to 3.11 will not be able to even read an SDHC card.
Yes, you definitely need the recompile the version of Catalyst included in 3.11 (and reload it into EEPROM) to use SDHC cards, since Catalyst itself also includes the SDHC driver.
As you have found, any version of Catalyst prior to 3.11 will not be able to even read an SDHC card.
Ross.
Ross, I recompiled catalyst and downloaded into the EEPROM, but still am stuck. With a 8gb SD card formatted as Fat32, I put a small C program in the BIN subdir and put the autoexec.txt file in the root. When I power up I get
Cannot open file Catalyst 3.1.1 It doesn't say what file it can't open so I'm not sure if it still isn't reading the card, or something else is wrong.
If I recompile using the -C OLD_SD option and put the file on a 1gb card, I still get Cannot open file Catalyst 3.1.1
But if I take the card out and put it into a board with a older version of catalyst, the program boots and runs fine. So it appears to be some issue with catalyst, and it does not matter whether the card is SD or SDHC.
Perhaps I am missing something when I recompile catalyst? I just went to the catalyst subdir and ran build_all RAMBLADE3. I had copied all the RAMBLADE3 files from a working target directory to the target directory
on the test pc.
Ross, I recompiled catalyst and downloaded into the EEPROM, but still am stuck. With a 8gb SD card formatted as Fat32, I put a small C program in the BIN subdir and put the autoexec.txt file in the root. When I power up I get
Cannot open file Catalyst 3.1.1 It doesn't say what file it can't open so I'm not sure if it still isn't reading the card, or something else is wrong.
If I recompile using the -C OLD_SD option and put the file on a 1gb card, I still get Cannot open file Catalyst 3.1.1
But if I take the card out and put it into a board with a older version of catalyst, the program boots and runs fine. So it appears to be some issue with catalyst, and it does not matter whether the card is SD or SDHC.
Perhaps I am missing something when I recompile catalyst? I just went to the catalyst subdir and ran build_all RAMBLADE3. I had copied all the RAMBLADE3 files from a working target directory to the target directory on the test pc.
Any help would be greatly appreciated.
Bruce
Hi Bruce,
I don't have a RAMBLADE3, but I just did this with a RAMBLADE, using an 8Gb SDHC card, formatted with 64k sectors (to answer another question you sent me via an email), and Catalyst works perfectly. I don't know what command you used, but I tried an AUTOEXEC.TXT file containing a simple dir command.
I assume you have tried the obvious things, like checking that the command in your AUTOEXEC.TXT file is actually correct? If so, try deleting this file altogether and instead let Catalyst boot into interactive mode and then enter the command manually. At least this will tell us whether Catalyst itself is working.
I have seen your "Cannot open file" message occasionally when rebooting my RAMBLADE - in my case what is happening is that when I reboot, some rubbish characters are seen by the serial port, which then passes them to Catalyst, which assumes you typed them in and then tries to find a file of that name. You can fix this by adding a short timeout (msleep), and a keyboard buffer clear (k_clear) to the Catalyst initialization code. For example, at the start of main() in catalyst.c, add the following:
msleep(100);
k_clear();
If this eliminates the message, just type dir when you see the > prompt, to ensure you see a directory listing. Then try the same thing by putting the dir command in the file AUTOEXEC.TXT file. Let me know who these steps go.
If even these simple steps don't work, my best guess would be that the new SD plugin needs some tweaking to work on the RAMBLADE3. I don't know how different the SD Card circuitry on this board is to that on the RAMBLADE I have - I'll try and find a schematic and have a look.
One thing you could check is that your CFG file (which should be called something like RamBlade3_CFG.inc) contains the following lines (these are from my RamBlade_CFG.inc file):
'
' SD must be activated before each use
#define ACTIVATE_EACH_USE_SD
'
' SD must be tristated (rather than just deactivated) after each use
#define TRISTATE_SD
'
' XMM pins are shared with other devices
#define SHARED_XMM
'
' Stop_IO after each request in Proxy Server
#define STOP_IO_PROXY
'
' Include XMM Memory support in Catalyst Loader (for loading XMM programs)
#define XMM_LOADER
If it does not, try adding these. Particularly the last one (#define XMM_LOADER). Offhand, I can't recall what version I added the need for this line to include the XMM loader code in Catalyst - but you may have been upgrading from a version before I made this a configurable option.
I've looked at the configuration files, the method for integrating drivers, and the architecture documents. In time (a lot of it), I could perhaps figure out how to adapt the memory card for Catalina - but for now, it's well over my head.
At $18, this is a cost-effective product for memory expansion, combining SRAM, flash, and SD. It may not perform as well as some other offerings with wider I/O (e.g., RamPage 2), but the form factor is nice, plugging directly into a breadboard or the Demo board.
I'm happy to do some work if someone can help guide me through the precipitous learning curve.
A new errata file (Catalina_3.11_Errata_2.zip) has been posted on SourceForge (here), and also attached to the second post in this thread. This errata file contains some minor changes made since the release of Catalina 3.11 that do not warrant a new release. It also contains all previous errata.
The main changes are:
A new version of payload (was also included in the previous errata)
A new version of catdbgfilegen (much faster, and no longer requires mono to run)
A new version of blackbox (fixes a bug displaying structures passed as parameters)
More details are given in the README.txt file in the errata file, and in the second post in this thread.
These errata will be included in the next version of Catalina, which will also contain support for the Human Interface Board for the QuickStart, and the Propeller Memory Card.
Comments
You can make your own /usr/local directory in the Terminal app. You'll need to do that as root or with the "sudo" command, like this "$sudo mkdir /usr/local". You can also make the entire tree with "$sudo mkdir /usr/local/lib"...
Or, you can just leave Catalina in /usr/lib/catalina and export your paths in your .profile file and source it...
The use_catalina file may have been created during the build process. It goes into catalina's root directory (in your case "/usr/lib/catalina") and its content is (edited for your catalina path):
Unfortunately, I was not able to attach the whole catalina tree that I built (size issue) and could only attach the /bin directory...
Hopefully, these instructions will help you get further!
dgately
You can install Catalina anywhere you like - but on Unix-style systems such as Linux or OS X, if it is not installed in /usr/local/lib/catalina you will need to edit a few script files if you want to build it from source.
Most of the scripts used to actually use catalina depend on the the LCCDIR environment variable to tell them where Catalina is installed, so they will work correctly as long as you have this set up. This is the main purpose of the use_catalina script, so you should at least edit that file - or use another mechanism for setting the LCCDIR environment variable.
The scripts you will have to edit are the ones used to rebuild Catalina from source. Here is a list:
I just noticed there are two utility scripts (used on Linux installations only) that don't use the LCCDIR environment variable, so you will also have to edit these manually (I will fix this in the next release):
Forgive me for not following all of the Catalina post but can some one summarize what the procedure would be to compile the latest version under MAC OS X 10.6.8? (i.e. Snow Leopard)
Thanks you much for any help.
rich
Building Catalina on OS X is fairly easy. You need to have gcc installed, and you probably need to be root.
Then:
The above commands build the core of Catalina - basically, the command-line compiler and all the libraries and utilitues. You can stop here if you want.
Then there are some optional steps: The above step builds the srecord utilities, which can save the compiled output into many different binary formats - but Catalina natively supports .binary and .eeprom formats (which are all most people need) so building srecord is optional - most people won't need it, and to build it you need the boost libraries installed.
The last step is to build Code::Blocks. To do this, download the sources for version 10.05 (it must be this version) from http://www.codeblocks.org/ - once you get this far, let me know and I'll point out some minor changes you need to make to that distribution.
Ross.
I just realized I had not updated the Code::Blocks source code changes for Catalina since release 3.4, so I have now added this to SourceForge (as Catalina_3.11_CodeBlocks.zip). Keen eyed observers may also notice a new version of the Windows one touch installer (Catalina_3.11_Setup.exe). This is not a new version, I just did this so that it will still be the "newest" file on SourceForge (i.e. it will appear at the top of the list).
Ross.
Thanks, Rayman. The OSX build process actually seems simpler than for other platforms. For instance, I was a little surprised to find I didn't need to install any additional packages (like bison and flex) to build Catalina - but maybe this was because my virtual image (which is of unknown and probably disreputable origins!) already had them installed. Or maybe they are installed as part of gcc.
Anyway, I'll be interested to hear if you find any additional steps you need to complete the core "command line" compiler build (I know there are extra packages required to build Code::Blocks).
Ross.
First, I figured out how to go to the /usr folder in Finder. It normally won't show it. But, if you do "command"+"shift"+"G" you can go to any folder.
Second, I had to change permissions on the folder. That "source" command did not seem to work. But, in Finder, you can do a "Get Info" and then click the lock symbol to be able to change for "everyone" to "read&write".
I think I was able to build everything except for the "srecord". Got a message saying I need to install "Boost" for that. Since you said I don't need it, I'll ignore that.
"source use_catalina" seems to work now. I suppose this lets me execute "catalina" from anywhere, right?
First, I had to use "cu" and not "tty". Second, I had to add "-t 1000".
Now, it seems to work.
Here's another way to do that, if you have the Terminal app running:
Type the following on the command line to open a directory in the Finder:
It will also display any file in a Finder window with the -R option
dgately
Oh and yeah, that should work now...
You can check to see where the shell (most likely, bash shell in Terminal app) thinks your executable is located:
dgately
I think I will update the default payload timeout on *nix systems to 1000 ms in the next release. It seems to be necessary on a few systems (including one of mine) and won't cause others too much grief.
Also, I am working on an updated version of catdbgfilegen. This component is required for the debugger, and it is currently written in C#. It is the only remaining Catalina component that requires "mono" to be installed on *nix systems, so I will replace it with a workalike that doesn't.
Ross.
I am using a Ramblade3 and moved all the appropriate files to the target directory. Compiling works fine, no errors.
I started with using -C OLD_SD so that it used the old sd card drivers. The application worked fine, using a 1 gb card.
So then I removed the OLD_SD flag, and compiled to a SDHC card. But when I tried to run the application, catalyst doesn't load it off the SD card, it just hangs.
I tried a few cards, but they all acted the same.
I was told a long time ago, that I didn't have to load a new version of Catalyst into the EEPROM of the Ramblade3 every time, so I am still using the catalyst.bin file from earlier (I believe it is from 3.06)
Does 3.11 require I make and load a new version of catalyst? All the earlier revs of catalina did not require it.
Any assistance would be appreciated.
Bruce Prager
Hi Bruce,
Yes, you definitely need the recompile the version of Catalyst included in 3.11 (and reload it into EEPROM) to use SDHC cards, since Catalyst itself also includes the SDHC driver.
As you have found, any version of Catalyst prior to 3.11 will not be able to even read an SDHC card.
Ross.
Ross, I recompiled catalyst and downloaded into the EEPROM, but still am stuck. With a 8gb SD card formatted as Fat32, I put a small C program in the BIN subdir and put the autoexec.txt file in the root. When I power up I get
Cannot open file Catalyst 3.1.1 It doesn't say what file it can't open so I'm not sure if it still isn't reading the card, or something else is wrong.
If I recompile using the -C OLD_SD option and put the file on a 1gb card, I still get Cannot open file Catalyst 3.1.1
But if I take the card out and put it into a board with a older version of catalyst, the program boots and runs fine. So it appears to be some issue with catalyst, and it does not matter whether the card is SD or SDHC.
Perhaps I am missing something when I recompile catalyst? I just went to the catalyst subdir and ran build_all RAMBLADE3. I had copied all the RAMBLADE3 files from a working target directory to the target directory
on the test pc.
Any help would be greatly appreciated.
Bruce
Hi Bruce,
I don't have a RAMBLADE3, but I just did this with a RAMBLADE, using an 8Gb SDHC card, formatted with 64k sectors (to answer another question you sent me via an email), and Catalyst works perfectly. I don't know what command you used, but I tried an AUTOEXEC.TXT file containing a simple dir command.
I assume you have tried the obvious things, like checking that the command in your AUTOEXEC.TXT file is actually correct? If so, try deleting this file altogether and instead let Catalyst boot into interactive mode and then enter the command manually. At least this will tell us whether Catalyst itself is working.
I have seen your "Cannot open file" message occasionally when rebooting my RAMBLADE - in my case what is happening is that when I reboot, some rubbish characters are seen by the serial port, which then passes them to Catalyst, which assumes you typed them in and then tries to find a file of that name. You can fix this by adding a short timeout (msleep), and a keyboard buffer clear (k_clear) to the Catalyst initialization code. For example, at the start of main() in catalyst.c, add the following:
If this eliminates the message, just type dir when you see the > prompt, to ensure you see a directory listing. Then try the same thing by putting the dir command in the file AUTOEXEC.TXT file. Let me know who these steps go.
If even these simple steps don't work, my best guess would be that the new SD plugin needs some tweaking to work on the RAMBLADE3. I don't know how different the SD Card circuitry on this board is to that on the RAMBLADE I have - I'll try and find a schematic and have a look.
One thing you could check is that your CFG file (which should be called something like RamBlade3_CFG.inc) contains the following lines (these are from my RamBlade_CFG.inc file):
If it does not, try adding these. Particularly the last one (#define XMM_LOADER). Offhand, I can't recall what version I added the need for this line to include the XMM loader code in Catalyst - but you may have been upgrading from a version before I made this a configurable option.
Ross.
http://parallax.com/product/40004
I've looked at the configuration files, the method for integrating drivers, and the architecture documents. In time (a lot of it), I could perhaps figure out how to adapt the memory card for Catalina - but for now, it's well over my head.
At $18, this is a cost-effective product for memory expansion, combining SRAM, flash, and SD. It may not perform as well as some other offerings with wider I/O (e.g., RamPage 2), but the form factor is nice, plugging directly into a breadboard or the Demo board.
I'm happy to do some work if someone can help guide me through the precipitous learning curve.
Thanks!
- Earl
Hi Earl,
I've ordered one of these cards. Should arrive soon. Give me a week or two.
Ross.
- Earl
A new errata file (Catalina_3.11_Errata_2.zip) has been posted on SourceForge (here), and also attached to the second post in this thread. This errata file contains some minor changes made since the release of Catalina 3.11 that do not warrant a new release. It also contains all previous errata.
The main changes are:
- A new version of payload (was also included in the previous errata)
- A new version of catdbgfilegen (much faster, and no longer requires mono to run)
- A new version of blackbox (fixes a bug displaying structures passed as parameters)
More details are given in the README.txt file in the errata file, and in the second post in this thread.These errata will be included in the next version of Catalina, which will also contain support for the Human Interface Board for the QuickStart, and the Propeller Memory Card.
Ross.