Thanks all. I will keep the CPM updates coming via the ZiCog and TriBladeProp threads.
Anyone who wants to seriously get Catalina running on the TriBladeProp PM me. The same goes for the pasm compilers.
I am about to announce another preassembled solution for the masses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm impressed with your TriBlade Prop, and would love to have a go at getting Catalina up and running on it. But it will have to be after the next Catalina beta release - that should be out later this week.
The next version of Catalina rewrites the code generator quite substantially. It fixes a few bugs in the existing code generator and has major optimizations to reduce the final code size. I will also release what I hope will be the 'final' Catalina LMM Kernel, plus a new 'alternate' kernel, which has free space intended for user customizations (e.g. kernel support for the TriBlade Prop!)
Some other goodies are also coming in the next release - such as a debugger with built-in support for Catalina LMM PASM - it can disassemble LMM, set LMM breakpoints, single step through LMM and switch between cog debug mode and LMM debug mode.
Glad to hear bst does not have the limitations of the Parallax Propeller tool - bst is definitely my preferred option for compiling PASM. For one thing it produces great listings that make debugging LMM code much easier! But there is one nice feature in the Parallax Propeller tool when compiling LMM code - when it tries to compile a file larger than 32k it tells you exactly how many longs over the limit the resulting object would be - very handy when you are trying to squeeze a 32.1k C program into 32k!
Most peculiar. Which version are you running?
For quite a while now it's produced this :
Untitled - Binary too large for RAM by 6777 Longs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I'm not at home at the moment so I can't check the exact version of bst I use, but it is fairly recent. I don't see the message you describe when I call bst from within lcc, but this may be due to the way I am invoking it. Some of the bst output seems to get obliterated by mutiple messages about the memory limits being exceeded (I can't recall the exact wording off the top of my head - I'll PM you an example when I get home). I'll try invoking bst manually and see if I get the message you describe.
I'm not at home at the moment so I can't check the exact version of bst I use, but it is fairly recent. I don't see the message you describe when I call bst from within lcc, but this may be due to the way I am invoking it. Some of the bst output seems to get obliterated by mutiple messages about the memory limits being exceeded (I can't recall the exact wording off the top of my head - I'll PM you an example when I get home). I'll try invoking bst manually and see if I get the message you describe.
Ross.
I'll bet the problem is related to single object files. In the "link" phase I check for oversize and report an error, but if a single object file exceeds 32k I probably just blow up. Let me look at it a bit closer and see if I can make the error message a little more informative. It's somewhat academic anyway as it'll produce an error in any case.
As much as I love my compiler, I've never written one before and the error handling is a little agricultural (at best). This is evidenced by the not-infrequent null pointer dereferences people see when they bend it in ways it's not designed to be bent.
If I ever get the time to re-architect it, I'd hope it was a bit better. mpark put me onto Jack Crenshaw's "Lets build a compiler", but unfortunately I'd already finished mine before I even read his papers (and we both wrote ours in the same language). Mine is uglier. I wager Michaels blows up less.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
The second beta release of Catalina is finally ready. See the first post in this thread for updated documentation, and the second and third posts for new linux and win32 source code and binaries.
Here's a summary of what's new in beta 2:
Many code generation fixes – Catalina now successfully passes all the C tests included with the lcc compiler itself (note that some of the test programs need to be split into parts small enough to run on the Propeller);
Register passing and trivial peephole optimization has been added - typical code sizes have been reduced by ~20% (up to 50% in some cases);
A new alternate kernel is provided which has 100 longs free space (to encourage experimentation);
New targets have been added that that use the debug kernel and the alternative kernel;
The HMI plugin now implements tabs (tabs fixed at size 8);
The HMI plugin now interprets Ctrl-D entered on the keyboard. Ctrl-D now returns EOF (-1);
Case sensitivity for C identifiers – since this has complicated the internal names used for identifiers, the Catalina binder now prints both the mangled and unmangled names of all identifiers;
The Catalina binder now differentiates between undefined symbols and redefined symbols. Redefined symbols can occur (for example) if a library is specified more than once in the lcc command – previously this would cause the binder to report that all the symbols in the library were undefined (when in fact they were multiply defined);
New HMI utility function t_printf – an alternative to the C89 printf for printing strings, integers, unsigned, float or characters using printf-style formatting, but which requires significantly less code space than printf;
Support for Catalina LMM PASM programs (disassembly of LMM code in hub RAM, set breakpoints, single step etc) has been added to POD.
Well someone has to comment on this before the day is out.
I just downloaded the Linux version and gave it a try, no idea if the generated code works yet as my home made demo board is a bit sick again, but it builds a hello world which I can load into bst and inspect/compile just fine.
Only have to figure out how to fire up the ZiCog Z80 emulator PASM from C now. Can I really replace all the surrounding Spin with C?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not sure I'd bother replacing Spin with C just to get ZiCog running - in any case you wouldn't be eliminating the need for Spin since Catalina uses it itself during startup. It's handy to bootstrap from Spin since it gives you an opportunity to use existing Spin objects in conjunction with C programs (Catalina allows this as long as the Spin objects don't use VAR space at runtime).
But if you do get your Demo board working again, I'd appreciate it if you could let me know of the "demo" Catalina target works ok - I only have a Hydra, and have never been able to test it.
Apologies all - I have had to re-release beta 2 as I found a couple of bugs - C programs with identifiers longer than about 24 characters would fail to assemble, and programs using floating point may crash. Both problems have now been fixed and new source and binary files have now been uploaded.
A little problem: When logged in as non root on linux I can't compile.
ddt:~$ lcc hello.c -Wl-tdemo_tv
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 22:54:26 on 2009/02/23
Found a USB Serial Device
Loading Object lmm_demo_tv
Loading Object Catalina
Loading Object Catalina_LMM
Loading Object Catalina_HMI_Plugin_Tv_d
Loading Object Catalina_comboKeyboard
Loading Object Catalina_mouse
Loading Object Catalina_TV_Text
Loading Object tv
An unhandled exception occurred at $08050F85 :
EInOutError : Access denied
$08050F85
$0804F49F
$0804D9F2
$080481E2
This is odd because I am in the correct group to access my USB serial adapter, BST has worked just fine. Also if I change ownership and or permissions of my /dev/ttyUSB0 so that anyone can read/write it still fails.
Why is BSTC wanting to access this just to compile anyway ?
Edit: Hmm.. looks like it's not the USB device that is the prob. If I log in as root and remove read/write access to my /dev/ttyUSB0 entirely I can still compile as root but not as user.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll try and reproduce this when I get home. Looks like bstc is having permision problem writing its output file. I'm afraid I tend to test while logged in as root (my bad!) so I have not noticed it. I assume that the user you are logged in as has write permission on the directory you are working in?
You could try running bstc independently of lcc to get some more clues. Try something like the following:
The "Wl-a" option tells lcc to compile and bind but not assemble (i.e. don't run bstc from within lcc). After running bstc manually you should get a file called "error.binary". Note this binary cannot be executed - it does not include Catalina Kernel - but at least it would tell us whether it is a bstc or an lcc problem. If it is bstc I may have to rely on BradC for help.
Of course, having run this as root there is an a.out.binary in the user directory that is owned by root. Changing ownership of that or deleting it gets us going again.
So busy thinking about what goes on in /usr/local/lib/catalina I didn't think to look at home.
Still curious as to why bstc is worrying about /dev/tty....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Apparently bstc can also be used to load the resulting image to the Propeller - a feature I've never used, but that's probably why it's looking for a serial port. Use bstc -h to see all the options.
Well there is one reason I may want to use C in conjunction with the ZiCog emulator. That is to be able to use a FAT32 file system on SD cards for storing the CP/M disk images.
Just for fun I compiled this FAT32 implementation elm-chan.org/fsw/ff/00index_e.html with Catalina. Just the FS layer no SD driver or application.
The resulting binary for the demo board target is 1650 longs to big to fit.
Compiling with -S results in a an assembler output of 8424 lines. So give or take the labels in there about 33.5K bytes of instructions.
So this is not really feasible. Putting the PASM into XMM would do it I guess but at a cost in speed and size of RAM disk we have in mind for CP/M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't really think this would get the size down anywhere near far enough, but you could try customizing your target and removing the HMI drivers (e.g. mouse) which you probably don't need. Alternatively, compile your program using the "no_hmi" target.
Apparently bstc can also be used to load the resulting image to the Propeller - a feature I've never used, but that's probably why it's looking for a serial port. Use bstc -h to see all the options.
Ross.
Absolutely right. bstc scans the serial ports on startup whether you requested a propeller load or not. I should change that I guess....
I kinda wrote bstc to be sort of propellent compatible. So it had to be able to auto-locate a propeller, plus compile for it on all supported OS's including those many bodgy hacks from Redmond... (Win95->) I might not have thought things through completely before I wrote them however as it's been years since I had to deal with those train wrecks..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
The third beta release of Catalina is finally ready. This release adds XMM support, so C programs can now be larger than 32K.
The only XMM platform currently supported is the Hydra Xtreme 512K SRAM card, but I expect Cluso99 to provide me with a TriBladeProp sometime soon.
Many thanks to Michael Park for his Homespun compiler, which can now compile PASM programs larger than 32K.
See the top of this thread for details and for new documentation, demos, sources and binaries. Only the Windows binaries are there at the moment - I'll add the linux binaries later today.
Thought I would take this for a spin. Ran build_demos.bat ...
things seem ok except for "too many arguments to _dira" and looking for bstc.
C:\Catalina\catalina_demos>lcc test_leds.c -lc -o test_leds -Wl-tno_hmi
test_leds.c:8: too many arguments to `_dira'
test_leds.c:9: too many arguments to `_outa'
test_leds.c:13: too many arguments to `_outa'
This is my first attempt at using Catalina. Do I need bstc ?
Reading your docs, you mention using HAM for XMM stuff.
Are you able to generate an intel-hex file?
I have a hex loader I was using with ICC for doing serial XMM downloads.
Maybe you can use that ... beats the heck out of programming eeproms.
It seems you have a mix of old and versions of Catalina. Using an older version the catalina.exe program would explain the 'unrecognized switch' problem - the '-x' swich is new to this version. And using an old version of the library explains the 'too many arguments' problem - I added a new argument to these functions in this release.
It all works for me here. I may have stuffed up my zipping - I'll check and report back. In the meantime, if you had an older version of Catalina installed, please delete it and install the new one from scratch.
You're right. I did have an old version. No idea why the old one was being run ... didn't see anything in the environment. Shrug shoulders. I had put the new copy in C:\Catalina. I'm set now. I'm still scratching my head over using HAM though ... enough for today. Bed time.
I though maybe I had forgotten to update one of the zip files, but I just deleted my Catalina directory, downloaded the win32 binaries and demos from the links at the top of this thread, installed them and then compiled the demos again. All works fine for me. Perhaps when you grabbed the binary zip file you were still getting a cached copy of the last release.
You could try flushing your browser cache, reloading the page from source (hold down the CTRL key while pressing the REFRESH button - but this doesn't work on all browsers) and download and install again.
If you still have problems after that then let me know.
You don't really need HAM (for those who don't know what HAM is - it's the Hydra Asset Manager, designed to allow the use of the eeprom space on the Hydra platform above the normal 32K that gets loaded into the Propeller on boot).
Perhaps I should make that clearer in the documentation that any program that can put the program images produced by Catalina into an eeprom would do. And if you want to modify the Catalina XMM Loader, you could have the images stored anywhere. Cluso99 pointed out that I could easily replace the Basic I2C driver with an SPI driver, and thereby have SDRAM support as well - I'll investigate this for the next release.
But at the moment the only XMM platform I have for testing any of this stuff is my Hydra/Xtreme combo, so for me HAM is the obvious solution.
I'm finding I'm spending way too much time on the non-core parts of Catalina (for example, I just spent 2 days trying to get Mike's Basic I2C driver working - still not exactly sure why it wouldn't work - so instead I ended up rewriting it as a PASM driver).
I have updated the linux source and binaries with the latest release.
NOTE: I have included homespun.exe in the linux binary distrubutions, as homespun is supposed to run on Linux under the 'wine' Windows emulator - but I have been unable to get it to run myself. I will update the release (if necessary) when I solve this problem, but I am releasing the distributions anyway since bstc can also be used as the PASM compiler. To use bstc, download it, install it, and then put a link to it called 'bstc' in the main Catalina directory. Then compile programs with the -Wl-b option to LCC. This is more fully explained in the documentation. Note that XMM support is not available when using bstc.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
BradC said...
No it won't. Wine is for running Win32 binaries. homespun is a .Net application and you need to run it with Mono (and the resulting 100MB download).
Ah!. Thanks Brad - I was trying to install .Net under wine, which wasn't working.
I'll test it again tonight and update the documentation.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
mpark said...
"Fruit Machine"?? Just what are you working on, Brad?
I wanted to learn how to blit so I wrote a slot machine simulator. It loads 8 bitmaps off SD card, then creates 3 virtual rolls from these 8 images in random positions. Then it scrolls them round the screen just like a slot machine would, coming to rest completely randomly in left to right order. It was also my introduction to writing TV drivers and using multiple cogs to render to the same driver [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I've uploaded new sources and binaries for the Linux release of beta 3.
No functional changes, but Homespun is now invoked correctly under the "mono" open source dotnet runtime. A new "README.Linux" file has been added describing the mono packages that need to be installed - they take about 10Mb disk space in total (BradC's "100MB" is true only if you download all the mono development libraries).
None of these changes affect the Windows release. There were a couple of linux script changes, and a few problems caused by Linux being case sensitive in places where Windows is not. I also added some scripts for building the demos under linux - please download the catalina_demos.zip file again to get these.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
How does the Catalina compiler compare to ImageCraft's C compiler (not necessarily the IDE) in terms of performance and features? (versus being free and running on Mac/Linux, which is awesome!)
Is it the 'same' thing since they are both based on LCC?
To be honest, I'm not really sure. I've been far too busy to find out [noparse]:)[/noparse] But here goes with what I do know ...
Both Catalina and ImageCraft are based on LCC, so they will be very similar in the 'dialect' of C they support - unless ImageCraft has added their own extensions to the language. Catalina has no extensions - it is just plain old ANSI C.
However - and I'm simplifying outrageously here! - all LCC really gives you is the ability to parse A C program into a syntax tree. The code generation of the two compilers is completely different, as are things like the stack model, the parameter passing mechanism, memory management, cog management etc etc.
Our LMM Kernels take completely different approaches, since I concentrated on building in things like floating point support from day one, whereas this was absent in the early versions of the Imagecraft compiler and added later (I don't know if is in part of the ImageCraft Kernel or not). Catalina provides the ability to choose between zero, one or two cogs dedicated to floating point. On the other hand, I believe Imagecraft concentrated on improving execution speed generally by sticking closely to Bill Henning's (and others) original LMM proposals, including the ability to cache small amounts of hub ram in the kernel cog to speed up execution of small loops. However, to compensate I suspect Catalina offers better support for register variables (including floating point register variables). So I would expect Catalina to be faster in some areas such as floating point, but slower in other areas. I have not run any comparisons, but if you (or anyone) cares to, I'd be happy for you to post the results here.
Our approach to integrating with PASM and SPIN is probably different. Catalina uses SPIN during initialization, which makes it fairly easy to include existing drivers (with some restricitons and modifications) and it can also include other PASM programs by defining 'plugins' accessible from C (a 'plugin' is basically a program running in another cog). I have no idea what Imagecraft does in this area.
Catalina offers a rich variety of Human Machine Interface (HMI) options - various combinations of Hires and Lores TV, Hires and Lores VGA, Mouse and Keyboard support for any platform with the appropriate hardware. Catalina provides a platform-independent execution environment for the C program by defining 'targets' that encapsulate all the platform dependent HMI issues. The HMI gets completely loaded and initialized before the C program starts up. This gives the C program a standard interface to the HMI no matter what the platform. The early versions of ImageCraft offered fairly basic support for the HMI, but they may have added more drivers in their recent releases.
Our approach to linking is significantly different. I think ImageCraft uses a traditional compile-assemble-link paradigm. When I started Catalina there seemed to be no language independent linker available for the Propeller (I subsequently found out about OwenS's work, but have still not had time to investigate this thoroughly). Since I did not want to spend time writing my own asembler and linker - a major job in itself - I used a compile-bind-assemble paradigm. Much simpler, and perfectly suited to an embedded enviroment where every program has to end up as a stand-alone binary image. This means that things like the Catalina C libraries exist in source form (PASM, not C) and not object form. The Catalina Binder does source level manipulation to combine the various components into a final source file - and then uses existing Propeller tools (such as the Parallax Propeller Tool, bstc, or Homespun) to turn the resulting program into binary form. For most purposes, users will never see any difference - but this probably makes Catalina slower to compile. However, it means Catalina can rely on the good work of others to do much of the hard stuff [noparse]:)[/noparse]
Our libraries themselves are different. Catalina uses a public domain C89 libarary, whereas I believe ImageCraft uses a C99 library - but in an embedded environment that would probably make very little difference to most people.
Again, I have not run any tests, but I think that Imagecraft would produce more compact code than Catalina. However, Catalina offers an XMM option to allow programs larger than 32K to execute from external RAM, so this is not such an issue. I am unaware of ImageCraft offering XMM support, but I believe they have been working on it, so if they don't offer one already I'm sure they soon will. The Propeller's 32K onboard RAM is enough for an interpeted language like SPIN, but is simply not enough for largish C programs. However, when the Prop II arrives .... !
I would encourage ImageCraft (or anyone who uses ImageCraft) to respond to your question here as well. Since Catalina is completely open source, everyone has an opportunity to examine the guts of Catalina in all it's gory details - so I'm sure ImageCraft and others will know more about the differences than I do.
Since others will no doubt bring it up again, I should mention the licensing. Parts of Catalina (including the Kernel and the Binder) are currently issued under the GNU Public Licence (GPL). This doesn't mean you can't use them in commercial products and charge money for products that use them, but it does mean that if you use them you must (a) acknowledge their origin and (b) make your source code available. I have already said that when I'm ready to take Catalina out of beta status I may revisit this (at least for the Kernel, so you don't have to release your products source code), but that is how things stand at present. Partly, this is my choice to avoid undercutting the good work that ImageCraft have done.
Finally, ImageCraft is a finished product, whereas Catalina is an ongoing work still very much in beta release. However, since my acquisition of a new TriBladeProp has been delayed (which means I can't do much more on XMM support at present) I may take this opportunity to go back, finish things like the implementation of the C89 library, polish things up generally and issue a first 'official' release.
In summary, if you want a C compiler for commercical use, then at the moment you should probably buy ImageCraft's compiler. If you are still experimenting or are a hobbyist, you may find Catalina suits you better. And it's free!
Hope this helps,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
Anyone who wants to seriously get Catalina running on the TriBladeProp PM me. The same goes for the pasm compilers.
I am about to announce another preassembled solution for the masses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm impressed with your TriBlade Prop, and would love to have a go at getting Catalina up and running on it. But it will have to be after the next Catalina beta release - that should be out later this week.
The next version of Catalina rewrites the code generator quite substantially. It fixes a few bugs in the existing code generator and has major optimizations to reduce the final code size. I will also release what I hope will be the 'final' Catalina LMM Kernel, plus a new 'alternate' kernel, which has free space intended for user customizations (e.g. kernel support for the TriBlade Prop!)
Some other goodies are also coming in the next release - such as a debugger with built-in support for Catalina LMM PASM - it can disassemble LMM, set LMM breakpoints, single step through LMM and switch between cog debug mode and LMM debug mode.
Ross.
Most peculiar. Which version are you running?
For quite a while now it's produced this :
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I'm not at home at the moment so I can't check the exact version of bst I use, but it is fairly recent. I don't see the message you describe when I call bst from within lcc, but this may be due to the way I am invoking it. Some of the bst output seems to get obliterated by mutiple messages about the memory limits being exceeded (I can't recall the exact wording off the top of my head - I'll PM you an example when I get home). I'll try invoking bst manually and see if I get the message you describe.
Ross.
I'll bet the problem is related to single object files. In the "link" phase I check for oversize and report an error, but if a single object file exceeds 32k I probably just blow up. Let me look at it a bit closer and see if I can make the error message a little more informative. It's somewhat academic anyway as it'll produce an error in any case.
As much as I love my compiler, I've never written one before and the error handling is a little agricultural (at best). This is evidenced by the not-infrequent null pointer dereferences people see when they bend it in ways it's not designed to be bent.
If I ever get the time to re-architect it, I'd hope it was a bit better. mpark put me onto Jack Crenshaw's "Lets build a compiler", but unfortunately I'd already finished mine before I even read his papers (and we both wrote ours in the same language). Mine is uglier. I wager Michaels blows up less.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
The second beta release of Catalina is finally ready. See the first post in this thread for updated documentation, and the second and third posts for new linux and win32 source code and binaries.
Here's a summary of what's new in beta 2:
Ross.
I just downloaded the Linux version and gave it a try, no idea if the generated code works yet as my home made demo board is a bit sick again, but it builds a hello world which I can load into bst and inspect/compile just fine.
Only have to figure out how to fire up the ZiCog Z80 emulator PASM from C now. Can I really replace all the surrounding Spin with C?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not sure I'd bother replacing Spin with C just to get ZiCog running - in any case you wouldn't be eliminating the need for Spin since Catalina uses it itself during startup. It's handy to bootstrap from Spin since it gives you an opportunity to use existing Spin objects in conjunction with C programs (Catalina allows this as long as the Spin objects don't use VAR space at runtime).
But if you do get your Demo board working again, I'd appreciate it if you could let me know of the "demo" Catalina target works ok - I only have a Hydra, and have never been able to test it.
Ross.
Ross.
ddt:~$ lcc hello.c -Wl-tdemo_tv
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 22:54:26 on 2009/02/23
Found a USB Serial Device
Loading Object lmm_demo_tv
Loading Object Catalina
Loading Object Catalina_LMM
Loading Object Catalina_HMI_Plugin_Tv_d
Loading Object Catalina_comboKeyboard
Loading Object Catalina_mouse
Loading Object Catalina_TV_Text
Loading Object tv
An unhandled exception occurred at $08050F85 :
EInOutError : Access denied
$08050F85
$0804F49F
$0804D9F2
$080481E2
This is odd because I am in the correct group to access my USB serial adapter, BST has worked just fine. Also if I change ownership and or permissions of my /dev/ttyUSB0 so that anyone can read/write it still fails.
Why is BSTC wanting to access this just to compile anyway ?
Edit: Hmm.. looks like it's not the USB device that is the prob. If I log in as root and remove read/write access to my /dev/ttyUSB0 entirely I can still compile as root but not as user.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/22/2009 4:40:11 PM GMT
I'll try and reproduce this when I get home. Looks like bstc is having permision problem writing its output file. I'm afraid I tend to test while logged in as root (my bad!) so I have not noticed it. I assume that the user you are logged in as has write permission on the directory you are working in?
You could try running bstc independently of lcc to get some more clues. Try something like the following:
lcc hello.c -Wl-a -o error.spin
bstc error.spin -b
The "Wl-a" option tells lcc to compile and bind but not assemble (i.e. don't run bstc from within lcc). After running bstc manually you should get a file called "error.binary". Note this binary cannot be executed - it does not include Catalina Kernel - but at least it would tell us whether it is a bstc or an lcc problem. If it is bstc I may have to rely on BradC for help.
Ross.
So busy thinking about what goes on in /usr/local/lib/catalina I didn't think to look at home.
Still curious as to why bstc is worrying about /dev/tty....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Glad you figured it out.
Apparently bstc can also be used to load the resulting image to the Propeller - a feature I've never used, but that's probably why it's looking for a serial port. Use bstc -h to see all the options.
Ross.
Just for fun I compiled this FAT32 implementation elm-chan.org/fsw/ff/00index_e.html with Catalina. Just the FS layer no SD driver or application.
The resulting binary for the demo board target is 1650 longs to big to fit.
Compiling with -S results in a an assembler output of 8424 lines. So give or take the labels in there about 33.5K bytes of instructions.
So this is not really feasible. Putting the PASM into XMM would do it I guess but at a cost in speed and size of RAM disk we have in mind for CP/M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't really think this would get the size down anywhere near far enough, but you could try customizing your target and removing the HMI drivers (e.g. mouse) which you probably don't need. Alternatively, compile your program using the "no_hmi" target.
Ross.
Absolutely right. bstc scans the serial ports on startup whether you requested a propeller load or not. I should change that I guess....
I kinda wrote bstc to be sort of propellent compatible. So it had to be able to auto-locate a propeller, plus compile for it on all supported OS's including those many bodgy hacks from Redmond... (Win95->) I might not have thought things through completely before I wrote them however as it's been years since I had to deal with those train wrecks..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
The third beta release of Catalina is finally ready. This release adds XMM support, so C programs can now be larger than 32K.
The only XMM platform currently supported is the Hydra Xtreme 512K SRAM card, but I expect Cluso99 to provide me with a TriBladeProp sometime soon.
Many thanks to Michael Park for his Homespun compiler, which can now compile PASM programs larger than 32K.
See the top of this thread for details and for new documentation, demos, sources and binaries. Only the Windows binaries are there at the moment - I'll add the linux binaries later today.
Ross.
Thought I would take this for a spin. Ran build_demos.bat ...
things seem ok except for "too many arguments to _dira" and looking for bstc.
C:\Catalina\catalina_demos>lcc test_leds.c -lc -o test_leds -Wl-tno_hmi
test_leds.c:8: too many arguments to `_dira'
test_leds.c:9: too many arguments to `_outa'
test_leds.c:13: too many arguments to `_outa'
Trying out build_test_suite_xmm.bat gives:
C:\Catalina\catalina_demos>lcc test_suite.c -lc -Wl-x2 -o test_suite_xmm -Wl-w-e
unrecognized switch: -x2
Same for Startrek and Othello.
My platform is Windows XP SP3 with .net 3.0.
This is my first attempt at using Catalina. Do I need bstc ?
Reading your docs, you mention using HAM for XMM stuff.
Are you able to generate an intel-hex file?
I have a hex loader I was using with ICC for doing serial XMM downloads.
Maybe you can use that ... beats the heck out of programming eeproms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
It seems you have a mix of old and versions of Catalina. Using an older version the catalina.exe program would explain the 'unrecognized switch' problem - the '-x' swich is new to this version. And using an old version of the library explains the 'too many arguments' problem - I added a new argument to these functions in this release.
It all works for me here. I may have stuffed up my zipping - I'll check and report back. In the meantime, if you had an older version of Catalina installed, please delete it and install the new one from scratch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I though maybe I had forgotten to update one of the zip files, but I just deleted my Catalina directory, downloaded the win32 binaries and demos from the links at the top of this thread, installed them and then compiled the demos again. All works fine for me. Perhaps when you grabbed the binary zip file you were still getting a cached copy of the last release.
You could try flushing your browser cache, reloading the page from source (hold down the CTRL key while pressing the REFRESH button - but this doesn't work on all browsers) and download and install again.
If you still have problems after that then let me know.
Ross.
Post Edited (RossH) : 5/18/2009 7:37:15 AM GMT
Glad you got it sorted.
You don't really need HAM (for those who don't know what HAM is - it's the Hydra Asset Manager, designed to allow the use of the eeprom space on the Hydra platform above the normal 32K that gets loaded into the Propeller on boot).
Perhaps I should make that clearer in the documentation that any program that can put the program images produced by Catalina into an eeprom would do. And if you want to modify the Catalina XMM Loader, you could have the images stored anywhere. Cluso99 pointed out that I could easily replace the Basic I2C driver with an SPI driver, and thereby have SDRAM support as well - I'll investigate this for the next release.
But at the moment the only XMM platform I have for testing any of this stuff is my Hydra/Xtreme combo, so for me HAM is the obvious solution.
I'm finding I'm spending way too much time on the non-core parts of Catalina (for example, I just spent 2 days trying to get Mike's Basic I2C driver working - still not exactly sure why it wouldn't work - so instead I ended up rewriting it as a PASM driver).
Ross.
I have updated the linux source and binaries with the latest release.
NOTE: I have included homespun.exe in the linux binary distrubutions, as homespun is supposed to run on Linux under the 'wine' Windows emulator - but I have been unable to get it to run myself. I will update the release (if necessary) when I solve this problem, but I am releasing the distributions anyway since bstc can also be used as the PASM compiler. To use bstc, download it, install it, and then put a link to it called 'bstc' in the main Catalina directory. Then compile programs with the -Wl-b option to LCC. This is more fully explained in the documentation. Note that XMM support is not available when using bstc.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
No it won't. Wine is for running Win32 binaries. homespun is a .Net application and you need to run it with Mono (and the resulting 100MB download).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Ah!. Thanks Brad - I was trying to install .Net under wine, which wasn't working.
I'll test it again tonight and update the documentation.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I wanted to learn how to blit so I wrote a slot machine simulator. It loads 8 bitmaps off SD card, then creates 3 virtual rolls from these 8 images in random positions. Then it scrolls them round the screen just like a slot machine would, coming to rest completely randomly in left to right order. It was also my introduction to writing TV drivers and using multiple cogs to render to the same driver [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I've uploaded new sources and binaries for the Linux release of beta 3.
No functional changes, but Homespun is now invoked correctly under the "mono" open source dotnet runtime. A new "README.Linux" file has been added describing the mono packages that need to be installed - they take about 10Mb disk space in total (BradC's "100MB" is true only if you download all the mono development libraries).
None of these changes affect the Windows release. There were a couple of linux script changes, and a few problems caused by Linux being case sensitive in places where Windows is not. I also added some scripts for building the demos under linux - please download the catalina_demos.zip file again to get these.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Is it the 'same' thing since they are both based on LCC?
Kindly,
graham
To be honest, I'm not really sure. I've been far too busy to find out [noparse]:)[/noparse] But here goes with what I do know ...
Both Catalina and ImageCraft are based on LCC, so they will be very similar in the 'dialect' of C they support - unless ImageCraft has added their own extensions to the language. Catalina has no extensions - it is just plain old ANSI C.
However - and I'm simplifying outrageously here! - all LCC really gives you is the ability to parse A C program into a syntax tree. The code generation of the two compilers is completely different, as are things like the stack model, the parameter passing mechanism, memory management, cog management etc etc.
Our LMM Kernels take completely different approaches, since I concentrated on building in things like floating point support from day one, whereas this was absent in the early versions of the Imagecraft compiler and added later (I don't know if is in part of the ImageCraft Kernel or not). Catalina provides the ability to choose between zero, one or two cogs dedicated to floating point. On the other hand, I believe Imagecraft concentrated on improving execution speed generally by sticking closely to Bill Henning's (and others) original LMM proposals, including the ability to cache small amounts of hub ram in the kernel cog to speed up execution of small loops. However, to compensate I suspect Catalina offers better support for register variables (including floating point register variables). So I would expect Catalina to be faster in some areas such as floating point, but slower in other areas. I have not run any comparisons, but if you (or anyone) cares to, I'd be happy for you to post the results here.
Our approach to integrating with PASM and SPIN is probably different. Catalina uses SPIN during initialization, which makes it fairly easy to include existing drivers (with some restricitons and modifications) and it can also include other PASM programs by defining 'plugins' accessible from C (a 'plugin' is basically a program running in another cog). I have no idea what Imagecraft does in this area.
Catalina offers a rich variety of Human Machine Interface (HMI) options - various combinations of Hires and Lores TV, Hires and Lores VGA, Mouse and Keyboard support for any platform with the appropriate hardware. Catalina provides a platform-independent execution environment for the C program by defining 'targets' that encapsulate all the platform dependent HMI issues. The HMI gets completely loaded and initialized before the C program starts up. This gives the C program a standard interface to the HMI no matter what the platform. The early versions of ImageCraft offered fairly basic support for the HMI, but they may have added more drivers in their recent releases.
Our approach to linking is significantly different. I think ImageCraft uses a traditional compile-assemble-link paradigm. When I started Catalina there seemed to be no language independent linker available for the Propeller (I subsequently found out about OwenS's work, but have still not had time to investigate this thoroughly). Since I did not want to spend time writing my own asembler and linker - a major job in itself - I used a compile-bind-assemble paradigm. Much simpler, and perfectly suited to an embedded enviroment where every program has to end up as a stand-alone binary image. This means that things like the Catalina C libraries exist in source form (PASM, not C) and not object form. The Catalina Binder does source level manipulation to combine the various components into a final source file - and then uses existing Propeller tools (such as the Parallax Propeller Tool, bstc, or Homespun) to turn the resulting program into binary form. For most purposes, users will never see any difference - but this probably makes Catalina slower to compile. However, it means Catalina can rely on the good work of others to do much of the hard stuff [noparse]:)[/noparse]
Our libraries themselves are different. Catalina uses a public domain C89 libarary, whereas I believe ImageCraft uses a C99 library - but in an embedded environment that would probably make very little difference to most people.
Again, I have not run any tests, but I think that Imagecraft would produce more compact code than Catalina. However, Catalina offers an XMM option to allow programs larger than 32K to execute from external RAM, so this is not such an issue. I am unaware of ImageCraft offering XMM support, but I believe they have been working on it, so if they don't offer one already I'm sure they soon will. The Propeller's 32K onboard RAM is enough for an interpeted language like SPIN, but is simply not enough for largish C programs. However, when the Prop II arrives .... !
I would encourage ImageCraft (or anyone who uses ImageCraft) to respond to your question here as well. Since Catalina is completely open source, everyone has an opportunity to examine the guts of Catalina in all it's gory details - so I'm sure ImageCraft and others will know more about the differences than I do.
Since others will no doubt bring it up again, I should mention the licensing. Parts of Catalina (including the Kernel and the Binder) are currently issued under the GNU Public Licence (GPL). This doesn't mean you can't use them in commercial products and charge money for products that use them, but it does mean that if you use them you must (a) acknowledge their origin and (b) make your source code available. I have already said that when I'm ready to take Catalina out of beta status I may revisit this (at least for the Kernel, so you don't have to release your products source code), but that is how things stand at present. Partly, this is my choice to avoid undercutting the good work that ImageCraft have done.
Finally, ImageCraft is a finished product, whereas Catalina is an ongoing work still very much in beta release. However, since my acquisition of a new TriBladeProp has been delayed (which means I can't do much more on XMM support at present) I may take this opportunity to go back, finish things like the implementation of the C89 library, polish things up generally and issue a first 'official' release.
In summary, if you want a C compiler for commercical use, then at the moment you should probably buy ImageCraft's compiler. If you are still experimenting or are a hobbyist, you may find Catalina suits you better. And it's free!
Hope this helps,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina