I've just released Catalina 2.3. This release incorporates all the patches since release 2.2, plus some additional improvements (such as updates to the floating point libraries posted recently by Cam Thompson).
The only significant change in this release is that Catalina now supports the Code::Blocks Integrated Development Environment. However, I can't take much credit for this - Code::Blocks is an impressive piece of Open Source software that already supports all manner of C compilers with just a modest amount of configuration work. See the top of the thread for more details (and a picture).
I've also tidied up the various Catalina Curiosities and posted them in a zingle zip file in the second post in this thread.
Ross.
P.S. Cluso and Heater: Tubes? Far too modern! - I'm sure if we tried hard we could get a Propeller to emulate a Jacquard Loom.
I should probably have mentioned that I've only tested Code::Blocks under Windows. I can't install Code::Blocks on my Linux system till I update the kernel - and I probably won't get a chance to do this for a week or two.
However, I believe it should work ok on Linux - if anyone does try it out, please report the results.
Great work. I completely forgot about code::blocks. I just got 2.2 installed and recompiled, and now 2.3.
So on windows 7 things are in different places. To set up code::blocks the location is C:\Users\<user name>\AppData\Roaming\codeblocks. I am using Windows 7 64 bit, I would think it is safe to assume the location would be the same on 32 bit. The same issue applies on Windows 7 that I reported to you on vista as to the Program Files and Program Files (x86). I always rebuild it to work from d:\catalina anyways.
I just realized I could run a 'live' linux distribution without having to reinstall my kernel, so I have just confirmed that Code::Blocks also works ok under Linux (I used Fedora 12, but it should work on other distributions). In the process I had to do a bit of reconfiguration (e.g. some of the paths were specific to Win32, as well as the names of the executables), so I have included a better set of configuration data for Linux in the file 'linux_codeblocks.zip'. That file is attached to the linux binary post at the top of this thread. I also updated the README slightly, and included a better example workspace for linux users.
Also, I included a script called 'clean_target' which just cleans stuff out of the target directory which can cause compilations to fail if you run compilations as different users (because the next user can't overwrite the files left by the last user). Run this script (as root) if you get errors about being unable to write files in the target directory. Also, you have to make sure that the target directory is writeable by all users. I don't usually run Catalina as different users, so I never noticed this stuff before. I can see I'll have to do some work to improve support for multiple users.
Windows users don't need any of this - for them the original distribution will work fine.
Just added the following note about Release 2.3 to the top of this thread ...
IMPORTANT NOTE: There is a minor bug in Release 2.3 to do with include paths under Windows (it does not affect Unix users). The bug will be fixed in the next release, but there is a simple workaround - just make sure any user-defined include paths (i.e. specified on the command line with -I, or in an environment variable, or in a Code::Blocks setting) are terminated with a semicolon (which is what you normally do to include multiple include paths) - for example:
Nice addition. I've been using code blocks for a different project; it is a good platform.
Do you have an LMM debugger? Your docs mentioned POD, but LMM is a little different.
Sorry not to reply sooner - I've been away for a week. Happy New Year to you also.
Catalina includes a modified version of POD that works with LMM code - just start POD as usual (which requires the use of PropTerm, configured for 30 rows * 40 chars, as well as the special Catalina 'debug' target) then press CTRL+L - this tells POD to switch to LMM mode, where it will interpret Hub RAM as LMM code (instead of cog RAM as PASM code). It will automatically start the display of the disassembled LMM code at the C 'main()' function. You can add breakpoints and step through the LMM code as usual, and also switch between LMM code and normal PASM code - so you can trace through the kernel if you want to. Like many debuggers, it's a little buggy - but it got me out of a few tight corners when I was debugging the Catalina code generator.
However, POD only works for PASM and LMM programs - it can't cope with XMM programs.
There is work currently under way on another Catalina debugger (not by me) - there may be something workable in a few weeks.
MasterC has discovered that Catalina doesn't like Code::Blocks projects that use spaces in the target file name.
If you have already created a project with spaces in the target file name, and are getting errors such as 'cannot open ouptut file bin\Release\<target file name>.binary' then go to 'Project->Properties' in Code::Blocks and change the output filename on the 'build targets' tab to remove any spaces.
Ross,
I am interested in running Catalina on a standalone version of Cluso's SBC. I guess the the Sram driver will be the only difference. Any thoughts ?
I'd like to try getting Catalina working on the Dracblade. I think it should be fairly straightforward, particularly if we don't worry about the ram chip for the moment.
I did a compile of a hello world and the printout was very helpful in that it points to two files with all the settings - lmm_default.spin and Catalina.spin.
However, I've gone and got hopelessly confused with the ifdefs going back and forth between the two programs. I think lmm_default sets a whole lot of ifdefs, but then the pin definitions seem to be in the second file, Catalina.spin.
I think I might end up breaking it by trying to modify the wrong files, so can I just give you the list of pins?
VGA pin 16 to 23 (it also uses TV 16-19 but I'm not using TV right now. You either install one set of resistors or the other)
Keyboard 26,27
EEPROM 28,29
Terminal/serial port 30,31
SD card 12-15 (DO,CLK,DI,CS in that order)
I think all these are fairly standard except the SD card pins.
No mouse.
SD pins don't connect to anything else so no complex sharing code needed
RossH:
The RamBlade is essentially a TriBlade (Blade #2) but its hardware pinouts are different to gain more speed. I have a new driver for block access and the access routine per byte is different (and smaller). It's serial I/O pins are not P31/30 but P23/22.
Ok. That means my existing XMM code won't work, but it should be easy enough to modify - you can either do your own version of the XMM code based on the stuff I wrote for the TriBladeProp, or develop new code from scratch. My TriBladeProp code was based on your original code anyway, so you shouldn't have any problems. Just try to keep the size of the XMM code the same - there is a source level debugger being developed for Catalina at the moment (by Bob Anderson) and space in both the LMM and the XMM kernel is currently at a premium.
If you want me to incorporate your XMM drivers in each release of Catalina and also keep them up to date if Catalina itself changes, the easiest way is to send me an assembled board (I retest Catalina on every board I have before each release). Otherwise you can just send me copies of your own access routines and I will include them 'as is' (but without doing any testing).
Actually, I should make this offer apply generally, so ...
@All,
If anyone wants me to add Catalina support for their particular Propeller board, then for non-XMM boards that are compatible with the usual Parallax drivers then all I generally need is the pinouts and clock details. But if you have specific drivers (or need them developed) or require XMM support then I will need both full schematics plus an assembled, working board. If you choose to develop your own drivers and XMM access routines then you can send them to me and I will incorporate them in a future Catalina release - but without any testing.
Ok - let me know when you're ready and I'll send you my address details. I'm not going to get a chance to build your DracBlade configuration files tonight - I'll try and get to it tomorrow.
There seems to be a bug in the Generic Program Loader.
XMM programs always load ok, but some LMM programs fail to run when loaded from an SD card. The programs themselves are fine - they run correctly when loaded using the Parallax Propeller tool (which can be used to load any Catalina LMM program, but not XMM programs).
The problem is driver-dependent. The driver most affected seems to be the HiRes TV driver (which unfortunately is the default). If you experience this problem (i.e. the program loads, the screen initializes to blank but the program then freezes) try recompiling your program using the LoRes TV driver instead. I'll post a fixed version as soon as I can resolve it.
In the attached zip file is a preliminary Catalina target support package for the DracBlade. Simply unzip this over your existing Catalina 2.3 installation (it also supports all the existing platforms).
To use it you can do any of the following (but don't do more than one or you may end up with the same symbol defined multiple times):
add '-D DRACBLADE' to the catalina command line
use the DOS command 'set CATALINA_DEFINE=DRACBLADE' before using Catalina
set the platform variable in Code::Blocks to DRACBLADE
For example:
catalina -D DRACBLADE hello_world.c -lc
I have modified the files to use the pin definitions you provided, and to use a VGA display (with no mouse) by default. I assumed your crystal was 5Mhz - if tha's not the case you will need to edit Catalina_Common_Input.spin.
I have modified all the files that would normally contain XMM support code even though there is no such code written yet - this is to show you where the code needs to be included if you want to try writing it yourself (just search for the symbol DRACBLADE). Currently, if you try and compile a program for XMM it will generate a compile-time error.
IMPORTANT NOTE: I have not tested any of this on an actual DracBlade. But let me know if this works and I will include DracBlade support in future releases of Catalina (note that there will be a release shortly - I need to fix a bug in my generic program loader).
Ross.
Edit: Attachment removed - DracBlade support is now part of the main Catalina distribution.
Edit: updated to fix erroneous references to 'Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_No_Keyboard.spin' (which doesn't exist).
Hey, great! I can't wait to get home and check this out.
Also I have one of my earlier prototype boards (with a few wire links underneath) so I could send you one of those. I'll get it packaged up and send a PM.
I found that running use_catalina.bat from windows does not work. You have to run it from with a cmd dos shell otherwise it can't find catalina.exe in the bin file.
Next thing is setting everything up in the right menu. I think I am close but it is missing one file about half way through.
Case is important: '-d dracblade' is not the same as '-D DRACBLADE'
(more detail: '-d' means enter diagnostic mode, which spits out a lot of messages - also, '-d' has no parameters so Catalina is treating the next argument 'dracblade' as a filename and trynig to compile it).
And you're correct - when you use a command window, you have to execute 'use_catalina' each time you start it - or you can set up the path permanently in Windows. All you have to do is add 'C:\Program Files\Catalina\bin' (or wherever else you installed it) to your system environment variables.
But... I get an olive green screen with a light green cursor at the top left and no text.
The dracblade vga circuit is exactly the same as the demoboard, and I see the settings for the vga pin starting at pin 16 are the same as the demoboard in the catalina_common_input.spin file.
Are there some other settings somewhere that need tweaking?
The flashing cursor means the VGA driver is loaded and starting, but something must not be right. To try and narrow it down, please try each of the following and tell me if any of them work (i.e. you get some text appearing):
You are apparently using Catalina 2.2 - you need to be using Catalina 2.3 to use the patches I sent you. Please download release 2.3 and re-apply the patches.
I have just uploaded a slightly modified version of the DracBlade Support Package - please download the new version (see post earlier in this thread). This should fix the error you saw using command option 1. Command options 2 and 3 will be fixed by using Catalina 2.3 instead of Catalina 2.2.
Can you explain a bit more about your 'text in middle of screen' comment in command option 5 (or post a picture)? - the text should appear in the same place in all options.
Comments
I've just released Catalina 2.3. This release incorporates all the patches since release 2.2, plus some additional improvements (such as updates to the floating point libraries posted recently by Cam Thompson).
The only significant change in this release is that Catalina now supports the Code::Blocks Integrated Development Environment. However, I can't take much credit for this - Code::Blocks is an impressive piece of Open Source software that already supports all manner of C compilers with just a modest amount of configuration work. See the top of the thread for more details (and a picture).
I've also tidied up the various Catalina Curiosities and posted them in a zingle zip file in the second post in this thread.
Ross.
P.S. Cluso and Heater: Tubes? Far too modern! - I'm sure if we tried hard we could get a Propeller to emulate a Jacquard Loom.
I should probably have mentioned that I've only tested Code::Blocks under Windows. I can't install Code::Blocks on my Linux system till I update the kernel - and I probably won't get a chance to do this for a week or two.
However, I believe it should work ok on Linux - if anyone does try it out, please report the results.
Great work. I completely forgot about code::blocks. I just got 2.2 installed and recompiled, and now 2.3.
So on windows 7 things are in different places. To set up code::blocks the location is C:\Users\<user name>\AppData\Roaming\codeblocks. I am using Windows 7 64 bit, I would think it is safe to assume the location would be the same on 32 bit. The same issue applies on Windows 7 that I reported to you on vista as to the Program Files and Program Files (x86). I always rebuild it to work from d:\catalina anyways.
Greg
Thanks for the info. I'll update the documentation for the next release.
Ross.
I just realized I could run a 'live' linux distribution without having to reinstall my kernel, so I have just confirmed that Code::Blocks also works ok under Linux (I used Fedora 12, but it should work on other distributions). In the process I had to do a bit of reconfiguration (e.g. some of the paths were specific to Win32, as well as the names of the executables), so I have included a better set of configuration data for Linux in the file 'linux_codeblocks.zip'. That file is attached to the linux binary post at the top of this thread. I also updated the README slightly, and included a better example workspace for linux users.
Also, I included a script called 'clean_target' which just cleans stuff out of the target directory which can cause compilations to fail if you run compilations as different users (because the next user can't overwrite the files left by the last user). Run this script (as root) if you get errors about being unable to write files in the target directory. Also, you have to make sure that the target directory is writeable by all users. I don't usually run Catalina as different users, so I never noticed this stuff before. I can see I'll have to do some work to improve support for multiple users.
Windows users don't need any of this - for them the original distribution will work fine.
Ross.
Just added the following note about Release 2.3 to the top of this thread ...
IMPORTANT NOTE: There is a minor bug in Release 2.3 to do with include paths under Windows (it does not affect Unix users). The bug will be fixed in the next release, but there is a simple workaround - just make sure any user-defined include paths (i.e. specified on the command line with -I, or in an environment variable, or in a Code::Blocks setting) are terminated with a semicolon (which is what you normally do to include multiple include paths) - for example:
Nice addition. I've been using code blocks for a different project; it is a good platform.
Do you have an LMM debugger? Your docs mentioned POD, but LMM is a little different.
Happy New Year
Sorry not to reply sooner - I've been away for a week. Happy New Year to you also.
Catalina includes a modified version of POD that works with LMM code - just start POD as usual (which requires the use of PropTerm, configured for 30 rows * 40 chars, as well as the special Catalina 'debug' target) then press CTRL+L - this tells POD to switch to LMM mode, where it will interpret Hub RAM as LMM code (instead of cog RAM as PASM code). It will automatically start the display of the disassembled LMM code at the C 'main()' function. You can add breakpoints and step through the LMM code as usual, and also switch between LMM code and normal PASM code - so you can trace through the kernel if you want to. Like many debuggers, it's a little buggy - but it got me out of a few tight corners when I was debugging the Catalina code generator.
However, POD only works for PASM and LMM programs - it can't cope with XMM programs.
There is work currently under way on another Catalina debugger (not by me) - there may be something workable in a few weeks.
Ross.
MasterC has discovered that Catalina doesn't like Code::Blocks projects that use spaces in the target file name.
If you have already created a project with spaces in the target file name, and are getting errors such as 'cannot open ouptut file bin\Release\<target file name>.binary' then go to 'Project->Properties' in Code::Blocks and change the output filename on the 'build targets' tab to remove any spaces.
I will fix this in the next release.
Ross.
I am interested in running Catalina on a standalone version of Cluso's SBC. I guess the the Sram driver will be the only difference. Any thoughts ?
Ron
Isn't Cluso's SBC simply a TriBladeProp? If so, Catalina will work 'out of the box'. If not, then yes you may need to update the XMM code.
Can you give me more information about your SBC configuration?
Ross.
I have never looked at TriBlade so I don't know. I only use serial I/O (P31..30) to a Laptop running Tera Term(VT100 Emulator)
I will chase up Cluso and find out the differences if any, and let you know.
Thanks
Ron
I'd like to try getting Catalina working on the Dracblade. I think it should be fairly straightforward, particularly if we don't worry about the ram chip for the moment.
I did a compile of a hello world and the printout was very helpful in that it points to two files with all the settings - lmm_default.spin and Catalina.spin.
However, I've gone and got hopelessly confused with the ifdefs going back and forth between the two programs. I think lmm_default sets a whole lot of ifdefs, but then the pin definitions seem to be in the second file, Catalina.spin.
I think I might end up breaking it by trying to modify the wrong files, so can I just give you the list of pins?
VGA pin 16 to 23 (it also uses TV 16-19 but I'm not using TV right now. You either install one set of resistors or the other)
Keyboard 26,27
EEPROM 28,29
Terminal/serial port 30,31
SD card 12-15 (DO,CLK,DI,CS in that order)
I think all these are fairly standard except the SD card pins.
No mouse.
SD pins don't connect to anything else so no complex sharing code needed
I reckon this would be fun to get C working!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'll generate a set of updated target files to include the DracBlade when I get home tonight and post them here.
And yes, it is confusing - I probably should write a better document on how to add a new platform to Catalina and post that as well.
Ross.
The RamBlade is essentially a TriBlade (Blade #2) but its hardware pinouts are different to gain more speed. I have a new driver for block access and the access routine per byte is different (and smaller). It's serial I/O pins are not P31/30 but P23/22.
Postedit:
I am back in Qld, but on my return we must try and catch up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 1/19/2010 5:45:21 AM GMT
Ok. That means my existing XMM code won't work, but it should be easy enough to modify - you can either do your own version of the XMM code based on the stuff I wrote for the TriBladeProp, or develop new code from scratch. My TriBladeProp code was based on your original code anyway, so you shouldn't have any problems. Just try to keep the size of the XMM code the same - there is a source level debugger being developed for Catalina at the moment (by Bob Anderson) and space in both the LMM and the XMM kernel is currently at a premium.
If you want me to incorporate your XMM drivers in each release of Catalina and also keep them up to date if Catalina itself changes, the easiest way is to send me an assembled board (I retest Catalina on every board I have before each release). Otherwise you can just send me copies of your own access routines and I will include them 'as is' (but without doing any testing).
Actually, I should make this offer apply generally, so ...
@All,
If anyone wants me to add Catalina support for their particular Propeller board, then for non-XMM boards that are compatible with the usual Parallax drivers then all I generally need is the pinouts and clock details. But if you have specific drivers (or need them developed) or require XMM support then I will need both full schematics plus an assembled, working board. If you choose to develop your own drivers and XMM access routines then you can send them to me and I will incorporate them in a future Catalina release - but without any testing.
Contact me for more details.
Ross.
There has to be a cunning way of using all the ram memory...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes, you can send me a board minus the Prop chip, but please add an IC socket - my soldering days are long gone :scool:
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ok - let me know when you're ready and I'll send you my address details. I'm not going to get a chance to build your DracBlade configuration files tonight - I'll try and get to it tomorrow.
Ross.
There seems to be a bug in the Generic Program Loader.
XMM programs always load ok, but some LMM programs fail to run when loaded from an SD card. The programs themselves are fine - they run correctly when loaded using the Parallax Propeller tool (which can be used to load any Catalina LMM program, but not XMM programs).
The problem is driver-dependent. The driver most affected seems to be the HiRes TV driver (which unfortunately is the default). If you experience this problem (i.e. the program loads, the screen initializes to blank but the program then freezes) try recompiling your program using the LoRes TV driver instead. I'll post a fixed version as soon as I can resolve it.
Ross.
In the attached zip file is a preliminary Catalina target support package for the DracBlade. Simply unzip this over your existing Catalina 2.3 installation (it also supports all the existing platforms).
To use it you can do any of the following (but don't do more than one or you may end up with the same symbol defined multiple times):
- add '-D DRACBLADE' to the catalina command line
- use the DOS command 'set CATALINA_DEFINE=DRACBLADE' before using Catalina
- set the platform variable in Code::Blocks to DRACBLADE
For example: I have modified the files to use the pin definitions you provided, and to use a VGA display (with no mouse) by default. I assumed your crystal was 5Mhz - if tha's not the case you will need to edit Catalina_Common_Input.spin.I have modified all the files that would normally contain XMM support code even though there is no such code written yet - this is to show you where the code needs to be included if you want to try writing it yourself (just search for the symbol DRACBLADE). Currently, if you try and compile a program for XMM it will generate a compile-time error.
IMPORTANT NOTE: I have not tested any of this on an actual DracBlade. But let me know if this works and I will include DracBlade support in future releases of Catalina (note that there will be a release shortly - I need to fix a bug in my generic program loader).
Ross.
Edit: Attachment removed - DracBlade support is now part of the main Catalina distribution.
Edit: updated to fix erroneous references to 'Catalina_HMI_Plugin_HiRes_Vga_No_Mouse_No_Keyboard.spin' (which doesn't exist).
Also I have one of my earlier prototype boards (with a few wire links underneath) so I could send you one of those. I'll get it packaged up and send a PM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I found that running use_catalina.bat from windows does not work. You have to run it from with a cmd dos shell otherwise it can't find catalina.exe in the bin file.
Next thing is setting everything up in the right menu. I think I am close but it is missing one file about half way through.
So re the error "lcc: can't find dracblade" how do I fix that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Case is important: '-d dracblade' is not the same as '-D DRACBLADE'
(more detail: '-d' means enter diagnostic mode, which spits out a lot of messages - also, '-d' has no parameters so Catalina is treating the next argument 'dracblade' as a filename and trynig to compile it).
And you're correct - when you use a command window, you have to execute 'use_catalina' each time you start it - or you can set up the path permanently in Windows. All you have to do is add 'C:\Program Files\Catalina\bin' (or wherever else you installed it) to your system environment variables.
This is all documented in the Catalina tutorial.
Ross.
xtal freq is 5mhz = correct
It all compiles fine. Downloads fine.
But... I get an olive green screen with a light green cursor at the top left and no text.
The dracblade vga circuit is exactly the same as the demoboard, and I see the settings for the vga pin starting at pin 16 are the same as the demoboard in the catalina_common_input.spin file.
Are there some other settings somewhere that need tweaking?
Cheers, James Moxham
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/21/2010 11:18:36 AM GMT
The flashing cursor means the VGA driver is loaded and starting, but something must not be right. To try and narrow it down, please try each of the following and tell me if any of them work (i.e. you get some text appearing):
Also, is the program you are trying to run the 'hello_world.c' program (from the Catalina demo directory)?
Ross.
2 worked, three didn't:
Of these, option 1,2,3 failed to compile
Option 4 works (see photo)
Option 5 works (pale green on olive green screen, text in middle of screen)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ok - making progress!
You are apparently using Catalina 2.2 - you need to be using Catalina 2.3 to use the patches I sent you. Please download release 2.3 and re-apply the patches.
Ross.
I have just uploaded a slightly modified version of the DracBlade Support Package - please download the new version (see post earlier in this thread). This should fix the error you saw using command option 1. Command options 2 and 3 will be fixed by using Catalina 2.3 instead of Catalina 2.2.
Can you explain a bit more about your 'text in middle of screen' comment in command option 5 (or post a picture)? - the text should appear in the same place in all options.
Ross.