Catalina 3.11 - now 100% open source!
RossH
Posts: 5,462
I've just posted a new release of Catalina (3.11) to SourceForge. I've posted the usual Windows "one touch" installer (here). Linux 32 bit and 64 bit versions are also available (here). See also any "errata" that appear in the following post. This release makes Catalina 100% open source.
Catalina also now supports OS X, but there is no binary distribution - it has to be build from source (use either of the Linux distributions).
Catalina also includes BlackCat and BlackBox source-level debuggers (note BlackCat is not open source) the Code::Blocks graphical IDE, and the Payload program loader - which can now load any program, whether to Hub RAM, EEPROM, SRAM or FLASH.
Here is a brief list of the main improvements in this release. For a full list, see the README.WhatsNew file or the Catalina Reference Manual.
Ross.
Catalina also now supports OS X, but there is no binary distribution - it has to be build from source (use either of the Linux distributions).
Catalina also includes BlackCat and BlackBox source-level debuggers (note BlackCat is not open source) the Code::Blocks graphical IDE, and the Payload program loader - which can now load any program, whether to Hub RAM, EEPROM, SRAM or FLASH.
Here is a brief list of the main improvements in this release. For a full list, see the README.WhatsNew file or the Catalina Reference Manual.
- By default, Catalina now uses the openspin spin/pasm compiler to assemble the PASM code generated by the compiler. Full sources for this compiler are included, and it is MIT licensed. The openspin compiler has been modified to support some Homespun features needed by Catalina. The openspin compiler has been tested with all Catalina sources, but Homespun is still provided in case any problems are discovered.
- There is a new SD card plugin, which supports SDHC cards (i.e. SD cards over 2Gb in size). This new plugin is used by default. The old plugin is still provided in case any problems are discovered.
- Catalina now supports PASM instructions inline with C code. For instance:
void main() {
PASM ("mov R0, #1");
PASM ("mov outa, R1");
}
- Added support for the RamPage 2 board, via the command line symbol RP2. See the file RP2_README.txt in the Catalina target directory for more details.
- Catalyst is now entirely a C program - this has been made possible by Catalina's COMPACT (CMM) mode, which means C programs use only about the same amount of memory as Spin programs. All the Catalyst utilities (mkdir, rmdir, cp, ls, cat, rm etc) are also C programs. In some cases, the C versions of the utilities have additional options. Catalyst supports all platforms supported by Catalina, suports SDHC cards, and supports loading programs from SD Card into Hub RAM. or XMM FLASH or SRAM. On multi-CPU propeller systems (e.g. TriBladeProp, Morpheus) it also supports loading programs into other CPUs. The main advantage of converting Catalyst to C is that Catalina and Catalyst both now only use DOSFS for all file system access - no need to mess with any others any more.
- Included binaries for the LMM/XMM version of the Catalina Optimizer (the CMM version was already included). The source code will be released once I have had time to tidy it up.
- Quite a few minor bug fixes!
catalina program.c -lc -C OLD_SDOne reason I have decided to release it with this bug unresolved is that I half suspect it is due to some peculiarity of my TriBladeProp, and I'd like to see if anyone else has a problem on other platforms, or with other SD cards.
Ross.
Comments
Update 1: This version of payload also allows the port names to be explicitly specified on the command line via the -p and -s command line options (this is in additon to being able to specify them by number). For example:
You can still specify ports by just specifying a number alone:
This is particularly useful on Mac OS X, where the names of the USB ports are impossible to predict in advance. For example:
Update 2: The errata file now also contains a new version of the blackbox debugger (which fixes a bug to do with displaying structures when passed as parameters to a function) and a new version of the catdbgfilegen utility (used by Catalina to generate debugging information used by both blackcat and blackbox). The new version of catdbgfilegen is much faster at generating debugging information. Also, with this version (which is now written in C++) Catalina no longer requires mono to be installed on non-Windows systems (mono is a set of utilities to allow C# programs to run on other systems).
Finally, the errata file contains fixes for a number of updated makefiles and batch utilities to enable Catalina to be compiled under OS X (note no binaries for OSX are included - Catalina must be recompiled from source. Instructions on how to do this are included in the Catalina Reference Manual).
Jim
I am going to download it and play with it.
Takes a few minutes to propagate, I think. It is showing it now.
Also - Could someone give me a hand adapting the configuration for the new Propeller Memory Card from Parallax? Ross mentioned it might be similar conceptually to the RamPage2 config.
http://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/ProductID/927/List/1/Default.aspx?SortField=UnitCost,ProductName
I'm willing to get in here and do what I can - but I have a feeling some of it is over my head...
Thanks!
- Earl
Hi OFR,
Did you get an error message during the compile? IF so, please post your Code::Blocks build log.
Also, try doing a complete rebuild of the project (i.e. Build->Rebuild).
Ross.
I have had previous reports of payload running slow on some machines - most likely the cause here is the "auto-detect" function of Payload which has to identify which port you are using. To verify if this is the case, try compiling and loading a file from the command line. Open a Catalina Command Line window (use the shortcut installed to do so) and type something like:
Don't worry whether it ouptuts anything - I just want the download time. If this works but takes a long time, note the COM port that payload uses (it will tell you this), then specify this explicitly via the -p parameter. For instance, if payload said was using "COM22:" then try:
Let me know how you go. We can modify your Code::Blocks download command if you always use the same COM port.
Ross.
Ok - I will try and think of another way to see what is going on. It definitely should not take a minute to load a program that small. I'm not a USB expert, but could your computer have a USB 1.0 port? All mine are at least USB 2.0. Another possibility is that the load speed is just very USB-chip specific. Any chance you could try using the same binary and propeller board, but from a different PC?
Ross.
I'm glad you were able to use OpenSpin here, one issue though. Your changes a pretty significant and it would probably be best to call the exe openspin-catalina.exe (or something else you prefer) instead of openspin.exe. If people have the current version of OpenSpin from google code installed and catalina installed it's possible they'll get the wrong exe running for catalina or for non-catalina stuff. Maybe in the future as features are added to OpenSpin and you no longer need your customizations then it won't matter.
I've been looking over the diffs, and I am curious why you did a few of them, like undoing the preprocessor state set by sub objects (seems really broken and undesirable to me), and the changes to the compiling of the @ operator (not even sure why its needed?). As for listing files, I have different and more comprehensive plans for listings, so I won't be bringing your version over.
Roy
I did not have another machine but I did switch to a different USB port and the load time dropped to 7-8 seconds. My machine is a custom made gaming system with supposedly the latest in hardware, I-7 8 core cpu, SSD, etc., so I don't think I have any USB-1 ports. However, the port I was using was blue, while all the other ports are white or black. using either white or black gave me the reduced load time. Does the 7 second load fall in line with what you are expecting?
Hal
Yes! Thanks.
If you can find any specs that might tell us the difference between the ports, it would help others who are also apparently seeing the "slow download" problem. I could never reproduce this problem on any of my machines!
Ross.
Can you try another USB port? See post above!
Ross.
Hey no fair! - I actually had openspin before you guys did! But I'll change it next release - the name of the executable doesn't matter to me.
As to why some of the changes exist - it is usually for compatibility with Homespun. Over time I may get a chance to eliminate these differences. Some of them are pretty obscure.
My listing code is a real hack! I don't expect you to use it, but I needed something. If you come up with better code then I'll adopt it.
Ross.
How odd! I have a USB 3 port on one of my machines - I've never used it for my Propeller comms. But I just naturally assumed USB 3 would be faster, not slower!
I'll try it tonight and see if I can see the "slow load" problem.
Thanks, Roy.
When you say you needed something for listing files, do you mean catalina is using them for something or you just needed to see the output structured in some way? If you just need to view a binary file disassembled or as a listing file like view, I use PropList. Inside the PATCH.ZIP file in this message: http://forums.parallax.com/showthread.php/96211-Spin-Bytecode-Disassembler?p=744399&viewfull=1#post744399 You may already have that, just sharing in case you don't.
USB 3 is much faster than USB 2, but it requires a different cable/connector. They made the plug capable of accepting a USB 2 connector and work as USB 2 in that case. It's probably an issue with the ftdi drivers.
It certainly sounds like a USB 3 issue - now that I know what it is, it should be easy to find and fix.
Ross.
I looked more carefully at the @ operator change, and I think I agree with you. If I understand correctly, it allows you to use @ on asm local symbols (e.g. @:symbol). I think I'll just include that as a "fix".
The $1FF vs $1F0 change is to allow you to compile stuff that would write into the shadow registers at cog load time, right? I think this probably needs to be enabled by an option, because it could cause issues for someone who doesn't understand how that stuff works in detail.
For the preprocessor, as I understand it in my version parent objects do not "see" #defines from their child objects. The child objects "see" the #defines of their parent and the #defines of other children compiled before them. With your changes, the child objects only "see" the #defines of the parent and *not* the #defines of the child objects compiled before them. My version is more like the way C/C++ preprocessing works, but missing one key part. The parent should "see" the #defines from it's children. That would match how I think it should work, #defines being "global" from the time they are parsed until they are #undef'd or preprocessing ends. Of course, this is treating OBJ stuff like they are #include's which is not really right either. So one could argue that OBJ's should be treated like a separate compile and thus shouldn't see any #defines from it's parent or children. It seems more useful to allow children to see their parent's #defines and parents to see their children's #defines, but children should probably not see their sibling's #defines. That isn't possible without changes to the preprocessor state handling.
I think I'll just keep mine working as it is now, because I think it works like BSTC does (though I'm not 100% certain of that anymore), and add an option to do it like homespun does.
Thoughts?
Roy
I can store values in unused "special" registers.