Catalyst 1.1 - a Catalina O/S for the TriBladeProp, Morpheus, DracBlade. Hybrid and RamBlade

RossH · 2010-04-19 10:37

@All,

Attached to this post are set of binary releases of Catalyst for various platforms. The source has also been released as part of Catalina 2.5, and is available in the Catalina thread (here).

I have included only platforms with XMM RAM (even though Catalyst itself does not require XMM RAM) because all the really-cool Catalyst programs do!

Here is a brief description of Catalyst:

Catalyst v1.1

Catalyst is an enhanced SD-card based program loader. It is mainly intended to enhance the capabilities of programs created with the Catalina C compiler, but it can also be used for loading and executing ordinary SPIN/PASM binaries.

Strictly speaking, Catalyst is JUST a program loader - it is not really an operating system because it does no resource management - however, it can be used to load programs that perform various resource management tasks - it even comes with a few - e.g. various utilities for doing SD card management.

However, when Catalyst is programmed into EEPROM, and when each loaded program resets the Propeller on termination (as Catalina programs now do), it can provide quite an effective single-user environment for self-hosted program development on the Propeller. Currently supported are BASIC, Pascal and Lua (and of course PASM/SPIN, using Sphinx). Self-hosted C development is NOT supported yet - but Catalyst is another step along the way!

Catalyst can be used on single-CPU systems (e.g. the Hydra, Hybrid, RamBlade, DracBlade, or Parallax Demo system) or on multi-CPU systems (e.g. Morpheus or the TriBladeProp). All it really requires is an SD card. It can be used with a local keyboard and TV or Video display, or by using a VT100 compatible PC terminal emulator (I recommend using 'putty').

Catalyst can be used to load normal SPIN/PASM as well as Catalina C programs. It can be used on any Propeller to load programs into Hub RAM, and (on platforms with XMM memory) to load Catalina programs up to 16Mb into XMM RAM.

Any command line parameters entered in Catalyst are automatically passed to the loaded program - i.e. the command line will appear in the C program's main function as argc and argv parameters. If the same program is loaded by another means (e.g. using Parallax Propellent or Catalina Payload) then they will execute normally, but the argv and argc parameters will be zero and a NULL string (respectively). Support for passing arguments when using Catalina Payload may be added in a future release of Payload.

A SPIN object that allows interpreting the Catalyst command line from within the loaded SPIN program is also provided.

Once a program is loaded and executed, Catalyst does not occupy any system resources - i.e. the loaded program has all Propeller resources available to it.

Catalyst provides the following built-in commands:

DIR - simple display of the files in the SD card root directory (only
files in the root directory can be loaded - but see the MKDIR and MV
external commands)
CAT - simple display of a text file
CLS - clear the screen
HELP - display some help

As well as built-in commands, Catalyst can execute external commands. When a command (such as 'mv') is entered that does not match an internal command, Catalyst will look for the file MV.BIN in the root directory of the SD Card, and execute it if found. Catalyst provides the following external commands. These commands do not require any XMM RAM, and will execute on any Propeller platform:

MKDIR - make a directory
RMDIR - remove a directory
MV - move or rename a file
RM - delete a file
CP - copy a file
LS - more sophisticated directory display than DIR

The following demo programs demonstrate the possibilities for self-hosted development on the Propeller. Note that they are large programs and require a Propeller platform with at least 512Kb of XMM RAM:

VI - the VI text editor
DBASIC - the Dumbo Basic interpreter
JZIP - an Infocom game interpreter
PCOM/PINT - Pascal P5 compiler/interpreter
SST - a version of Super Star Trek
LUA - an advanced scripting language.

For example, to create, compile and edit a pascal program, you might enter the following commands in Catalyst:

vi sample.pas               <- start vi, creating the file sample.pas
pcom sample.pas sample.p5   <- compile sample.pas using the Pascal P5 compiler
pint sample.p5              <- execute the compiled program using the Pascal P5 interpreter

Or to create and execute a basic program, , enter the following commands in Catalyst:

vi sample.bas         <-   start vi, creating the file sample.bas
dbasic sample.bas     <- start Dumbo Basic, executing sample.bas

Or to just have a little fun, , enter the following command in Catalyst:

jzip-l30 -c40 zork3.dat    <- start the JZIP Infocom game interpreter using a screen of 30 lines and 40 columns, and play ZorkIII

Ross.

Post Edited (RossH) : 6/7/2010 10:08:18 AM GMT

Dr_Acula · 2010-04-19 11:07

This sounds interesting. I like the list of commands. Very CP/M like - but without the 'retro' stigma of an old operating system (DOS also suffers from that I guess).

I see COPY as a command. What does that copy to and from - eeprom to sd card or sd card to PC or something else?

At the moment a session developing a catalina program involves writing it on the PC and downloading it - to eeprom or ram? Say I download a program and it works really well - can I then 'save' it to the sd card instead?

And how do you store settings - eg whether you are using vga or TV? Is this done by rebuilding and downloading catalyst?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Cluso99 · 2010-04-19 11:14

Ross: This sounds fantastic

Another piece to the puzzle.

First, a quick request before release. Can you use a seperate extension for catalyst binaries other than ".BIN"? In Sphinx there is already a problem between programs that are Sphinx-aware (i.e. Sphinx commands like DIR, DEL, etc which are actually seperate small binaries) and programs that are true Propeller Binaries (non-OS aware). This will only make matters worse.

Propeller binaries (taking full control of the prop) should remain ".BIN". There have been a few suggestions for the Sphinx programs. I had thought of ".CMD" and ".EXE" but these would conflict with CPM if we ever mix them, so it·would be better to use something like ".BIX" for Binary Sphinx. Mike Green suggested ".SBN" although if we are going to get a number of different binaries the ".BI*" may be the best way to go.

So maybe you could use something like ".BIC" ???

Is there any way this can be combined with the SphinxOS effort?

I have done a few drivers that work via just one long at the top of hub. I am trying to shift all longs used in the OS down by 1 long so the top long can be used for the "lowest used hub address" for the rendezvous longs and any space required. e.g. rendezvous locations, SD buffer, screen buffer, etc. Any OS aware program should then support this limit when it loads an OS program.

Now a question..
You mention Pascal and Basic. Are these Catalina style compilers???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

RossH · 2010-04-19 11:14

@Dr_Acula,

The COPY command is just a file system copy - i.e. it copies from one file on the SD Card to another file on the SD Card.

I initially included an XFER command to do a simple serial transfer between a PC and the SD card - but I took it out because I really can't see the need when you can just take out the SD Card and insert it into the PC. I may resurrect it if there is sufficient demand.

I have no plans to make it possible to 'save' a program from Prop memory to SD Card. Actually, in general it is impossible to do so - Catalina programs on disk do not look like Catalina programs in RAM - e.g. XMM programs include an XMM loader that is discarded once the program is loaded.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

heater · 2010-04-19 11:18

Great stuff.

So, what I want to do is compile my C version of the ZPU interpreter with Catalina and run it on a TriBlade where it can then execute ZPU binaries..very slowly[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH · 2010-04-19 11:22

@Cluso,

I used the '.BIN' extension precisely because all Catalyst programs DO take full control of the Prop. They need have no Catalyst-specific code in them at all. At most, they may include a module to interrogate the command line - but they don't even need to do that. However, the extension means very little to me. I can change it at any time.

Catalina/Catalyst make slightly more complex use of upper RAM than SphinxOS. I'll look into converging the two when I get some time.

As to Basic and Pascal - no, they are not Catalina-style compilers - they are just slightly enhanced versions of the Dumbo Basic interpreter and P4 pascal compiler I have already released (as 'Catalina Curiosities').

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-04-19 11:25

@heater,

Still a way to go for self-hosted C development. I think I will eventually have to write my own PASM assembler to do that. Sphinx is not really up to the job of compiling a 100,000 line source file to produce a 500Kb PASM program just yet.

I hate to think how long a compile like that would take on a Prop I with an SD-card based file system - probably weeks!

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99 · 2010-04-19 11:26

RossH: re XFER. May save me some work on SphinxOS - I was doing mparks versions of GETC & PUTC as seperate programs. What protocol and error checking did you do? What is required on the PC end?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

RossH · 2010-04-19 11:41

@Cluso,

I've not implemented anything - I was just going to do an X/Y/ZMODEM type serial transfer.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99 · 2010-04-19 11:53

@RosS:

OK, then mparks FTF code is extremely simple and he has a PC C version that only does the transfer. Since we are using a local PC connection I think this is fine.

Now I understand that they (COPY, DIR, etc) are just straight binaries, that is fine. With Sphinx Michael has these programs returning to SPhinx without rebooting the prop which is a great advantage. So I guess Catalyst could then run under SphinxOS without any problems. This way we can use all the programs written for Sphinx such as DIR, LS, etc. Also GET & PUT (file transfer) under Sphinx. Likewise Xmodem can be done also.

BTW: There is a problem with just rebooting the prop and TriBlade/RamBlade and fsrw in that DO is not necessarily forced back to tristate. It was actually a more curious problem where while the RamBlade was booting from eeprom a reset/download sequence was started from the PC. Just thought I would mention it in case you found a problem. Not that this should cause a problem if the SD is accessed again.

I should have asked... What fsrw are you using?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

RossH · 2010-04-19 12:03

@cluso,

My loaders use an old version of fsrw - a modified version of 1.6.

I never bothered to upgrade, since Catalina does not actually use fsrw - Catalina has its own C-based version of DOSFS (a FAT12/FAT16/FAT32 file system designed specifically for embedded systems) built-in.

However, Catalyst uses fsrw to load binaries. When I get time, I'll upgrade to the current fsrw (it's on my increasingly long list of things to do!).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99 · 2010-04-19 12:34

OK, so are you using the sdspiFemto.spin to do the low level SD access? Otherwise, how are you controlling the SPI interface to the SD card?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

Bill Henning · 2010-04-19 12:52

REALLY NICE WORK!!!!

Now this will be a lot of fun to play with.

First suggestion:

How about a "BIN" directory for the commands like MKDIR etc?

RossH said...
@All,

I'm nearly ready to post Catalyst v 1.0. Before I do, I'd like to get some feedback on which fundamental "dos" or "unix" style commands Catalyst should support. Details of Catalyst are given below, with my current proposal for fundamental operations. Some trivial Catalyst demo programs are attached (source only - the binaries require the Catalyst loader to execute!).

Any requests for additional Catalyst built-in or external commands? I'll try and include them in the first release if I can.

Ross.

Catalyst v1.0

Catalyst is an enhanced SD-card based program loader. It is mainly intended to enhance the capabilities of programs created with the Catalina C compiler, but it can also be used for loading and executing ordinary SPIN/PASM binaries.

Strictly speaking, Catalyst is JUST a program loader - it is not really an operating system because it does no resource management - however, it can be used to load programs that perform various resource management tasks - it even comes with a few - e.g. various utilities for doing SD card management.

However, when Catalyst is programmed into EEPROM, and when each loaded program resets the Propeller on termination (as Catalina programs now do), it can provide quite an effective single-user environment for self-hosted program development on the Propeller. Currently supported are BASIC and PASCAL (and of course PASM/SPIN, using Sphinx). Self-hosted C development is NOT supported yet - but Catalyst is another step along the way!

Catalyst can be used on single-CPU systems (e.g. the Hydra, Hybrid, RamBlade, DracBlade, or Parallax Demo system) or on multi-CPU systems (e.g. Morpheus or the TriBladeProp). All it really requires is an SD card. It can be used with a local keyboard and TV or Video display, or by using a PC terminal emulator.

Catalyst can be used to load normal SPIN/PASM as well as Catalina C programs. It can be used on any Propeller to load programs into Hub RAM, and (on platforms with XMM memory) to load Catalina programs up to 16Mb into XMM RAM.

Any command line parameters entered in Catalyst are automatically passed to the loaded program - i.e. the command line will appear in the C program's main function as argc and argv parameters. If the same program is loaded by another means (e.g. using Parallax Propellent or Catalina Payload) then they will execute normally, but the argv and argc parameters will be zero and a NULL string (respectively). Support for passing arguments when using Catalina Payload may be added in a future release of Payload.

A SPIN object that allows interpreting the Catalyst command line from within the loaded SPIN program is also provided.

Once a program is loaded and executed, Catalyst does not occupy any system resources - i.e. the loaded program has all Propeller resources available to it.

Catalyst provides the following built-in commands:
   DIR  - simple display of the files in the SD card root directory (only 
          files in the root directory can be loaded - but see MKDIR and MOVE 
          external commands)
   TYPE - simple display of a text file (alias CAT also accepted)
   CLS  - clear the screen
   HELP - display some help
As well as built-in commands, Catalyst can execute external commands. When a command (such as 'move') is entered that does not match an internal command, Catalyst will look for the file MOVE.BIN in the root directory of the SD Card, and execute it if found. Catalyst provides the following external commands. These commands do not require any XMM RAM, and will execute on any Propeller platform:
   MKDIR - make a directory
   RMDIR - remove a directory
   MOVE  - move or rename a file (alias MV also accepted)
   DEL   - delete a file (alias RM also accepted)
   COPY  - copy a file (alias CP also accepted)
   MORE  - more sophisticated text file display than TYPE
   LS    - more sophisticated directory display than DIR
The following demo programs are provided:
   DEMO.SPIN - a demo of how to use the Catalyst command line from SPIN
   DEMO.C    - a demo of how to use the Catalyst command line from C
The following demo programs demonstrate the possibilities for self-hosted development on the Propeller. However, they are large programs and require a Propeller platform with at least 512Kb of XMM RAM:
   VI        - the VI text editor
   DBASIC    - the Dumbo Basic interpreter
   JZIP      - an Infocom game interpreter
   PCOM/PINT - Pascal compiler/interpreter
   STARTREK  - a version of Super Star Trek
For example, to create, compile and edit a pascal program, enter the following commands in Catalyst:
   vi sample.pas      <- start vi, creating the file sample.pas
   pcom sample.pas    <- compile sample.pas using the Pascal P4 compiler
   pint               <- execute the compiled program using the Pascal P4 interpreter
Or to create and execute a basic program, , enter the following commands in Catalyst:
   vi sample.bas      <- start vi, creating the file sample.bas
   dbasic sample.bas  <- start Dumbo Basic, executing sample.bas
Or to just have a little fun, , enter the following command in Catalyst:
   jzip -l30 -c40 zork3.dat    <- start the JZIP interpreter using a sreen of
                                  30 lines and 40 columns, and play Zork III

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

jazzed · 2010-04-19 17:23

@RossH this is a nice addition! I was wondering why you were relatively quiet [noparse]:)[/noparse] I like the fact that you can launch any Propeller .bin file. I honestly don't see real advantages in having an "O/S" stay resident for propeller today (that will change later), but a C like parameter startup certainly has value. Having a serial x/y/z protocol would be useful for remote updates of course. SD swap "sneakernet" does not work very well for remote updates [noparse]:)[/noparse]

By the way Catalyst is a big Cisco product. The original CatOS is still in use although it has been hidden over time in new products. I'm not suggesting changing the name, it's just an FYI.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

Christof Eb. · 2010-04-19 17:46

Hi Ross,
my actual project uses Sphinx. This is because later the system will be in another room, not beneath my PC.

During programming/development of the project I found, that selfhosting is not that interesting at this moment. I have a big monitor screen at my PC and I use BST which gives very nice overview...
(I do not see the sense of a PC as terminal....)

* The download/upload feature (put/get) without starting a different application has proven to be very essential!!
* Very good: That you can restart the operating system directly from SD-card by the programm. This is faster than rebooting.
* A stronger editor would be good.

My personal opinion is, that it is very attractive to use the propeller with only little added hardware, if you want to use it as a microCONTROLLER. Therefore I think it is a very good idea, that your system does not need external memory. An optional (only optional!) real time clock would be good sometimes for time stamps of files.

Good luck,
Christof

Cluso99 · 2010-04-19 19:53

@Christof: The restart is actually a spin reboot command [noparse]:([/noparse]

@jazzed: The advantage of leaving the O/S stay resident (actually it is only in the cogs plus the rendezvous longs and any buffers) but not any other hub code is that you can change your hardware I/O on the fly. This means you can replace the serial with a keyboard and TV or VGA using either the same pins or different pins. The new binaries no longer need to be compiled for the specific hardware.
This also means I can take my SD card from one system to another and boot via the eeprom. The program in my eeprom only knows what pins the SD card is on. There is a little more to determining the hardware by the OS but I am sure you get the idea.

Provided you enter a date/time when the OS loads (and provided it is allowed to keep the cog(s) running, the date/time can be done in one of the existing cogs. It looks as though the later fsrw has this inbuilt.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

Post Edited (Cluso99) : 4/19/2010 7:59:03 PM GMT

jazzed · 2010-04-19 20:13

Cluso99 said...

@jazzed: The advantage of leaving the O/S stay resident (actually it is only in the cogs plus the rendezvous longs and any buffers) but not any other hub code is that you can change your hardware I/O on the fly. ...

Thanks for explaining that. It adds value if you need it. I've been down that road before and settled for other solutions since they were easier to accept for most situations. Also having the drivers remain in COG can be useful to save space for applications programs, but a good loader will do that anyway.

@RossH, do you have a loader strategy for putting drivers in COGs for user applications? You do something like that with EMM right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

RossH · 2010-04-19 23:17

@jazzed,

Thanks for the "heads up" about Cisco Catalyst. Somehow I don't think they'll sue - Catalyst is actually quite a common name - because it's so cool!

@christoff,

Yes, I'm not all that convinced that self-hosting is all that useful. I just think it's fun - when I get Cluso's RamBlade up and running I will eventually have a completely self-contained ANSI C development environment in a matchbox.

@jazzed,

All Catalina drivers and other plugins get loaded into cogs. For LMM programs any Hub RAM they occupied is then returned to the user application as additional heap or stack space before the main functions starts up. EMM is slightly different - after loading the plugins, the EMM loader then allows the whole of Hub RAM to be overlaid with new code, allowing programs to use the full 32k of Hub RAM as code space if they want to. Most people don't seem to realze that this makes it possible to run much larger C programs without resorting to XMM (XMM is different again, with all Hub RAM being reallocated as data space).

Considering how little Hub RAM the Prop has, it is surprising that SPIN is so wasteful in its memory management. To me, this indicates that despite all the complaints, very few people are actually memory limited on the Propeller. Which is why I mostly ignore those who complain about the posible size of C programs. If they bothered to learn a bit about it, they will find (as I do) that there are ways and means to accomplish just about anything you want to do.

As to the O/S "reserving" capacity for it's own use - resources on the Prop are scarce enough without dedicating cogs or Hub RAM to the O/S - in some cases this would cripple the usabillity of the Propeller. I'm constantly fighing to find enough cogs and hub RAM to do what I want, and I would be very annoyed if I discovered it was the operating system itself (which is supposed to be there to help me!) that was the cause. Other people have other opinions, and for their purposes they are probably correct. But my choice for Catalyst is that it should use no cogs, and only use Hub RAM that is already unavailable to Catalina programs (essentially, about 100 longs of upper Hub RAM which is used by the kernel, the debugger and the various plugins).

Cluso's point about the O/S managing hardware resources for you is perfectly valid - if you are using SPIN, which requires you to modify source whenever your hardware changes. but Catalina already implements a Hardware Abstraction Layer that allows for most hardware changes to be accomodated without requiring source code modifications - it doesn't need the O/S to implement another. For my purposes, I treat the Prop is a dedicated microcontroller, and I am quite happy to recompile programs if the hardware changes.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

jazzed · 2010-04-20 00:06

RossH said...

EMM is slightly different - after loading the plugins, the EMM loader then allows the whole of Hub RAM to be overlaid with new code, allowing programs to use the full 32k of Hub RAM as code space if they want to. Most people don't seem to realze that this makes it possible to run much larger C programs without resorting to XMM ....

This is exactly what I was talking about Ross. It's fine to let the user do anything they want to do, and I support that fully since the user application can be tailored for their needs, but most users as you point out either don't know how to do it or don't need to do it. I guess it's a point of style preference and whatever time you or others have to dedicate, but think about the possibilities for a user application space and kernel service space.

You know how BSD and Linux work of course and it's a fair system without too much overhead. In Linux for example, you can "insmod" a driver from·the filesystem·after startup and use ioctl, open, close, read, and write to access the driver. This driver can be loaded into a reusable HUB buffer and be started with COGNEW and buffers do not need to have some predefined variable space. This is slightly different from EMM in that the new drivers do not have to be a part of the boot image, but the result is the same: more memory available for user application programs.

Of course you can build the greatest theme park in the world and still fail to attract customers. Most educated CS people understand POSIX and may use it to their benefit if given the chance; everyone else may just say "that's nice" [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

RossH · 2010-04-20 00:19

jazzed said...
Of course you can build the greatest theme park in the world and still fail to attract customers.

Exactly. This not a case of "if you build it, they will come" - it's more a case of "if you spend years building it, some forum members may poke at it from a distance with a stick"

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

jazzed · 2010-04-20 01:00

Well, I got around to requesting a feature

Maybe I can ask for a reasonable one later [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

Baggers · 2010-04-20 07:37

silly question but is there a CD? you can mkdir and rmdir I'm guessing it's just that you missed it off the list?

other than that, fantastic work.

I've been so busy with legal stuff at work I'm missing sooooooo many advancements on the prop.
I can't wait to get free from it all and start playing prop again very soon!

Baggers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

RossH · 2010-04-20 08:03

@Baggers,

No, there is no CD - but that's not a mistake. There is no concept of a "current directory". The version of fsrw I use can only load from the root directory. Other directories can be created, but only for organizational purposes - there seems no point in being able to "CD" to them. There is no way to either pass this context to a program, or even "remember" it between instances of Catalyst. Maybe I coulde write it to the SD itself.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-04-27 15:35

@All

Here is an alpha release of Catalyst. The enclosed file contains a full set of Catalyst binaries for the TriBladeProp (blade #2).

More platforms will be forthcoming shortly. Building and testing each one takes me some time.

Note that this is a binary only release. Releasing the source of Catalyst at this point would not do anyone any good because it requires a new (and as yet unreleased) version of Catalina.

The enclosed zip file contains a binary called 'catalyst.bin' that should be programmed into the EEPROM of the TriBladeProp CPU #2 (you may need to rename it to 'catalyst.binary' to do this). The other contents of the zip file should be put on a Micro SD Card formatted as FAT16. Then reboot the Prop and enjoy Catalyst!

Note that Catalyst itself, the built-in commands (dir, cls, cat etc) and the external commands (rm, cp, mkdir, rmdir, ls, mv etc) do NOT require any XMM RAM to run. But most of the demo programs (vi, pcom, pint, dbasic, jzip etc) require 512Mb of external XMM RAM.

All the binaries in this release (as well as Catalyst itself) are built to use a VT100 compatible PC terminal emulator. I recommend 'putty' (which is free). The vi editor now works using the PC HMI option, although editing files this way is quite slow. In fact, everything is quite slow at this point - but quite functional.

See the enclosed CATALYST.TXT document for more details on each command (there are some minor updates to the original blurb at the top of this thread).

Here are some example commands you could try:

cat sample.pas             <---- list a text file
pcom sample.pas            <---- compile a pascal program
pint                       <---- run the compiled program
vi catalyst.txt            <---- edit a text file
dbasic startrek.pas        <---- run a basic program
mkdir my_dir               <---- make a directory
vi my_dir/my_file.txt      <---- edit a file in a directory
ls my_dir                  <---- list the contents of a directory
rm my_dir/my_file.txt      <---- remove a file from a directory
jzip zork3.dat             <---- play a game of Zork
sst                        <---- play a game of Super Star Trek
dbasic eliza.bas           <---- get some psychiatric help

Have fun!

Ross.

EDIT: Attachment removed. All the alpha release binaries are now attached to the first post in this thread.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Post Edited (RossH) : 4/28/2010 1:22:07 PM GMT

pullmoll · 2010-04-27 15:53

I wanted to give it a try, but it seems it doesn't find my SD card on the DracBlade. Is there anything to patch or to recompile? Do you somehow (try to) detect the target system?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

RossH · 2010-04-27 22:54

Hi pullmoll,

This set of binaries will only work on the TriBladeProp. I'll issue some binaries tonight for a few more platforms, including the DracBlade (I just ran out of time last night).

The sources will be released along with the next release of Catalina. Catalyst is a combination of SPIN and C - but even the SPIN components depend on some of the Catalina modules to work correctly.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-04-28 13:29

@All,

I have attached alpha binary releases of Catalyst for the TriBladeProp, Morpheus, DracBlade and Hybrid to the top of this thread.

All the normal Catalina HMI options are avalable to Catalyst programs, whether they are implemented in SPIN or C.

For example:

The TriBladeProp and Morpheus versions expect to be used via a VT100 compatible PC terminal emulator.
The Morpheus version uses a proxy HMI because the SD Card is connected to a different CPU to the XMM RAM.
The DracBlade version uses a local HiRes VGA display and keyboard.
The Hybrid version uses a local HiRes TV display and keyboard.

Source code will be forthcoming with the next Catalina release.

Ross.

P.S. I should point out that Catalyst currently uses both fsrw Kye's FATEngine. I am currently thinking I will transition Catalina away from fsrw, which means that the final version of Catalyst will be able to have the equivalent of a PATH, and execute programs from arbitrary subdirectories.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

pullmoll · 2010-04-29 00:17

I tried it now, and it works fine with the DracBlade. My LCD monitor always shuts down for a couple of seconds when the video signal goes away, so starting programs is always taking a little longer than necessary. xvi.bin is really slow

What kind of code do you use for the VT100 (I guess?) terminal emulation on the VGA? I will give a some of the binaries I usually load to prop RAM or EEPROM a try. I couldn't get Sphinx + the RamBlade to load them, probably because they are too large, so I'm curious to see if your loader loads them.

Nice job and well done!

Juergen

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

RossH · 2010-04-29 09:13

@all,

Somehow when I posted the alpha release binaries I seem to have lost the original SPIN demo program I posted - I have re-attached it (as spin_demo.zip) to the first post in this thread.

This means you don't have to wait for the next release Catalina to write programs for Catalyst - you can write them in SPIN, and load and run them using the alpha release of Catalyst. See the demo program for more details.

@pullmoll,

Thanks. Yes, vi is very slow - especially on the DracBlade. Performance improvements to the whole of Catalina/Catalyst are on my list of things to do.

I only use VT100 emulation when the PC HMI option is used (e.g. on the Morpheus or TriBlade), and it is very trivial - it only uses about 5 VT100 functions. On the DracBlade I write to the screen directly. But I just did a "quick and dirty" port of xvi, and didn't implement the scrolling functions at all - which makes it much slower than it needs to be to redraw the screen. Yrt another thing to add to my "to do" list!

The Catalyst loader can load normal programs (i.e. SPIN/PASM or LMM C) up to 31kb in size, or XMM C programs up to 2Mb. I may need to increase the latter limit at some point, but I can't see anyonw reaching that limit for a while!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-04-29 12:39

@all,

I just noticed there were two 'vi' binaries in the Catalyst_DracBlade.zip alpha release - 'vi.bin' and 'xvi.bin'.

The correct one is actually 'xvi.bin'. I have fixed the zip file, but you don't need to download it again - just delete 'vi.bin' and rename 'xvi.bin' to 'vi.bin'.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

pullmoll · 2010-04-29 15:00

RossH said...
The Catalyst loader can load normal programs (i.e. SPIN/PASM or LMM C) up to 31kb in size, or XMM C programs up to 2Mb. I may need to increase the latter limit at some point, but I can't see anyonw reaching that limit for a while!

Geez, too bad: it doesn't work. I'm not over 31kb it seems... 31468 bytes. Perhaps something else is going wrong? The attached cpm.bin starts up and also initializes the VGA, but it does not clear the frame buffer, which can only happen when it dies somewhere before initializing a cog with the code to handle i/o on behalf of the Z80. So it starts up half way through and then dies.

What would happen if a program is larger than 31kb? Would you cut off the remaining 1kb? And is 31kb the exact limit, i.e. 31*1024?

The code needs all cogs and in the last step grabs cog #0 with a coginit(0, ...) - could this be a problem source?

PS: to run this bin there must be some files on the SD card on the DracBlade: BOOT.DSK, A.DSK, B.DSK and C.DSK. You can use any files for this, as it hangs before running relevant code that would make use of the contents of the files.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

Post Edited (pullmoll) : 4/29/2010 3:06:49 PM GMT

Catalyst 1.1 - a Catalina O/S for the TriBladeProp, Morpheus, DracBlade. Hybrid and RamBlade

Comments