The reason othello ran in the previous release was that it does not use either the SRAM or the SD card - that program should in fact run on any Prop that uses pins 22 and 23 for serial I/O. This is why it seems to work fairly reliably at 104Mhz - although I have had it fail occasionally on my RamBlade.
But the fact that everything else also works this time means that we are making progress! I recompiled all the Catalyst programs to run at 100MHz, but the Catalyst loader should still correctly cope with loading programs that run at any clock speed. However, I have to admit I have not tested this code recently - so it may be that in all my messing about I have broken something and the loader no longer correctly reconfigures the prop using the clock information specified in long[noparse][[/noparse] 0 ] and long[noparse][[/noparse] 1 ] of the loaded program.
However, since you say you have recompiled ZiCog to run at 100Mhz anyway, I don't think this is the problem. If you have a binary version of ZiCog which is known to run on your RamBlade at 100Mhz then please post it and I will figure out why it doesn't load under Catalyst.
Now that I seem to have tracked down the major problems , I hope to go back to working on Catalina itself - so the next release should be a full source release of both Catalina and Catalyst, an you can compile all the programs for yourself for any clock speed. But in the meantime if you let me know what clock speed(s) you normally use, I will recompile the binaries for you.
Ross.
I see, I tought othello was XMM just by the larger file size [noparse]:)[/noparse]
No, I didn't recompile Zicog for 100MHz, I meant·that the 104M Zicog works at 100M with no serial problem, provided that·the other·end is a PC or FTDI chip and not another MCU (blasphemy! a MicroVGA module!!! ). I figured it·probably depends on 16x sampling of start bit that happen in most real UARTs,·so 4% speed difference·still permit to receive a byte correctly.
So after a second thought, releasing MOST RamBlade binaries compiled for 100M could be the best option, theoretically they should still work on 96M and 104M too.
Alessandro
Sorry guys, I am out of action for a few days yet. The problem does not seem to be overclocking, but rather some form of timing access, so a software fix is required once I track the problem. I have a RamBlade failing at 5MHz that works at 6.5MHz. I suspect it is just an interaction timing between SRAM and SD card.·I am sure once I find the problem it will be simple to resolve.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
So what exactly is this? If catalina is a C compiler for the Propeller, then is this an OS on the Propeller will run that can compile and run C code? I'm confused.
And as a second thought, why is it called "Catalyst"? A Catalyst is a material that speeds up a chemical reaction without getting used up in it, so does Catalyst OS speed up C development without using any resources?
Sorry for all the dumb questions, but I've heard things about this and had to see what it was.
The major component of Catalyst is an SD-card based program loader - this will work on any Prop platform supported by Catalina. This loader can load normal SPIN/PASM programs into Hub RAM, but it's main use is for loading Catalina C programs into either Hub RAM or XMM RAM. On multi-CPU platforms like Morpheus or the TriBladeProp, it can also load programs into the various different CPUs.
Catalyst also includes a set of utility programs for managing the contents of the SD card - these look a lot like simple Unix or DOS commands - i.e. dir, ls, rm, mkdir, rmdir, mv etc.
The last part of Catalyst is some programs for self-hosted Propeller development. All these programs require XMM RAM. These include the vi text editor, a BASIC interpreter, a Pascal interpreter and (just in case you get bored!) the JZIP Infocom game interpreter.
Various Catalyst components have been included in previous Catalina releases, but not as a unified set of components intended to work so closely together. Also, Catalyst adds new functionality previously unavailable to Catalina programs, such as the ability to pass command line arguments to the program on startup.
As for the name - I thought it was both cute and appropriate - a catalyst is a substance that facilitates a chemical reaction without itself being consumed. Catalyst the loader facilitates the loading and execution of Catalina programs, without itself consuming any Propeller resources.
I am working on a first full (non-alpha) release of Catalyst at the moment. A new release of Catalina will also coincide with this release. New features of Catalyst will include:<ul>
[*] A complete ISO compliant Pascal compiler, based on the P5 compiler (the current one is based on P4, which supports only a subset of the language).
[*] Speed improvments for Dumbo BASIC.
[*] The Lua language (for creating simple programs using a C-like scripting language)
[*] Anything else that I think might be fun (and have time to fit in!).
[/list]
While it is still a long term goal to support the Catalina compiler itself on the Propeller (for self-hosted C development) this is not currently possible. The problem is not with either Catalyst or Catalina (the Catalina compiler can compile itself, and Catalyst could load the result) - it is that there are no Propeller platforms with enough Hub RAM to actually run the compiler. The Prop II may change this, so I have deferred more work on self-hosted C development until that chip comes along.
I am working on a first full (non-alpha) release of Catalyst at the moment. A new release of Catalina will also coincide with this release. New features of Catalyst will include:
A complete ISO compliant Pascal compiler, based on the P5 compiler (the current one is based on P4, which supports only a subset of the language).
Speed improvments for Dumbo BASIC.
The Lua language (for creating simple programs using a C-like scripting language)
Anything else that I think might be fun (and have time to fit in!).
While it is still a long term goal to support the Catalina compiler itself on the Propeller (for self-hosted C development) this is not currently possible. The problem is not with either Catalyst or Catalina (the Catalina compiler can compile itself, and Catalyst could load the result) - it is that there are no Propeller platforms with enough Hub RAM to actually run the compiler. The Prop II may change this, so I have deferred more work on self-hosted C development until that chip comes along.
When compiled with itself, the Catalina executable is about 2Mb (this is from memory, I haven't compiled it recently) - so it could be loaded on a Morhpeus. During a compilation it uses a fair amount of heap space (say another 0.5 Mb for a reaonably large program) - still not too bad, and still possible on a Morhpeus. But the real killer is stack space - the stack has to be in Hub RAM for speed, and both the compiler and the binder are quite heavy on stack space. I don't have any actual figures, but the binder is particularly expensive since the process for resolving undefined symbols is recursive - I think it could reach the 32kb hub space limit even on a program containing only around 1000 symbols. And of course Catalina does not really have all 32kb of Hub RAM available to use for stack space - on some platforms it may only be about half that, since it has to share that RAM with various drivers etc.
If I had to guess, I'd say even a C program of only a few thousand lines could not be compiled successfully on the Prop I. Still worth doing, and I expect eventually to be able to support it - but I think true usable self-hosted C development will have to wait on the Prop II.
@Microcontrolled,
C is a good language for anyone to learn - especially if you intend to do much embedded programming. Also, once you become proficient in C you will begin to realize just how much of the processing power (and memory) that is sitting right in front of you is needlessly consumed by 'bloated' languages and operating systems.
If a microcontroller-based board smaller than a postage stamp and costing a few dollars can now run programs larger and faster than the original IMB PC of 30 years ago, then why does the computer sitting in front of you right now - which probably has a million times more processing power, memory and disk space - still run like a furry quadruped?
I have released the first complete version of Catalyst. Binaries for various platforms are at the top of this thread. Sources are part of Catalina 2.5, available in the Catalina thread (here).
I did not have time to include Kye's latest FATEngine - it will have to wait for a subsequent release. However, some of the Catalyst commands reproduce the same functionality.
Comments
No, I didn't recompile Zicog for 100MHz, I meant·that the 104M Zicog works at 100M with no serial problem, provided that·the other·end is a PC or FTDI chip and not another MCU (blasphemy! a MicroVGA module!!! ). I figured it·probably depends on 16x sampling of start bit that happen in most real UARTs,·so 4% speed difference·still permit to receive a byte correctly.
So after a second thought, releasing MOST RamBlade binaries compiled for 100M could be the best option, theoretically they should still work on 96M and 104M too.
Alessandro
I just compiled both PropCmd and ZiCog to run on my RamBlade at 100Mz (i.e. using a 6.25Mh crystal) - both programs load using Catalyst.
I no longer try to run my RamBlade at anything above 100Mhz.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
And as a second thought, why is it called "Catalyst"? A Catalyst is a material that speeds up a chemical reaction without getting used up in it, so does Catalyst OS speed up C development without using any resources?
Sorry for all the dumb questions, but I've heard things about this and had to see what it was.
Thanks,
Micro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
The major component of Catalyst is an SD-card based program loader - this will work on any Prop platform supported by Catalina. This loader can load normal SPIN/PASM programs into Hub RAM, but it's main use is for loading Catalina C programs into either Hub RAM or XMM RAM. On multi-CPU platforms like Morpheus or the TriBladeProp, it can also load programs into the various different CPUs.
Catalyst also includes a set of utility programs for managing the contents of the SD card - these look a lot like simple Unix or DOS commands - i.e. dir, ls, rm, mkdir, rmdir, mv etc.
The last part of Catalyst is some programs for self-hosted Propeller development. All these programs require XMM RAM. These include the vi text editor, a BASIC interpreter, a Pascal interpreter and (just in case you get bored!) the JZIP Infocom game interpreter.
Various Catalyst components have been included in previous Catalina releases, but not as a unified set of components intended to work so closely together. Also, Catalyst adds new functionality previously unavailable to Catalina programs, such as the ability to pass command line arguments to the program on startup.
As for the name - I thought it was both cute and appropriate - a catalyst is a substance that facilitates a chemical reaction without itself being consumed. Catalyst the loader facilitates the loading and execution of Catalina programs, without itself consuming any Propeller resources.
I am working on a first full (non-alpha) release of Catalyst at the moment. A new release of Catalina will also coincide with this release. New features of Catalyst will include:<ul>
[*] A complete ISO compliant Pascal compiler, based on the P5 compiler (the current one is based on P4, which supports only a subset of the language).
[*] Speed improvments for Dumbo BASIC.
[*] The Lua language (for creating simple programs using a C-like scripting language)
[*] Anything else that I think might be fun (and have time to fit in!).
[/list]
While it is still a long term goal to support the Catalina compiler itself on the Propeller (for self-hosted C development) this is not currently possible. The problem is not with either Catalyst or Catalina (the Catalina compiler can compile itself, and Catalyst could load the result) - it is that there are no Propeller platforms with enough Hub RAM to actually run the compiler. The Prop II may change this, so I have deferred more work on self-hosted C development until that chip comes along.
Ross.
I can't wait until I have time to use it.
How big is the compiled Catalina XLMM executable?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
When compiled with itself, the Catalina executable is about 2Mb (this is from memory, I haven't compiled it recently) - so it could be loaded on a Morhpeus. During a compilation it uses a fair amount of heap space (say another 0.5 Mb for a reaonably large program) - still not too bad, and still possible on a Morhpeus. But the real killer is stack space - the stack has to be in Hub RAM for speed, and both the compiler and the binder are quite heavy on stack space. I don't have any actual figures, but the binder is particularly expensive since the process for resolving undefined symbols is recursive - I think it could reach the 32kb hub space limit even on a program containing only around 1000 symbols. And of course Catalina does not really have all 32kb of Hub RAM available to use for stack space - on some platforms it may only be about half that, since it has to share that RAM with various drivers etc.
If I had to guess, I'd say even a C program of only a few thousand lines could not be compiled successfully on the Prop I. Still worth doing, and I expect eventually to be able to support it - but I think true usable self-hosted C development will have to wait on the Prop II.
@Microcontrolled,
C is a good language for anyone to learn - especially if you intend to do much embedded programming. Also, once you become proficient in C you will begin to realize just how much of the processing power (and memory) that is sitting right in front of you is needlessly consumed by 'bloated' languages and operating systems.
If a microcontroller-based board smaller than a postage stamp and costing a few dollars can now run programs larger and faster than the original IMB PC of 30 years ago, then why does the computer sitting in front of you right now - which probably has a million times more processing power, memory and disk space - still run like a furry quadruped?
Ross.
I have released the first complete version of Catalyst. Binaries for various platforms are at the top of this thread. Sources are part of Catalina 2.5, available in the Catalina thread (here).
I did not have time to include Kye's latest FATEngine - it will have to wait for a subsequent release. However, some of the Catalyst commands reproduce the same functionality.
Ross.