Catalina - Unplugged!

RossH

All,

Attached is a tutorial-style introduction to Catalina Targets, Plugins and the Registry. It is intended mainly for people interested in developing new plugins for Catalina, using existing Catalina plugins in other language environments, or developing Catalina-compatible plugins for use with both Catalina and other language environments.

It is suitable for Catalina 2.6 or later (Windows or Linux).

Several people have commented that Catalina is complex - and they are correct. However, what they usually mean is that the default Catalina Target Support Package is complex. This is not surprising - Catalina now supports so many platforms, so many plugins, so many memory models, so many kernels and so many different loaders that it can be difficult (even for me!) to figure out how it all actually works, or how to add anything new.

And yet the principals involved are not that difficult.

The attached zip file contains a new minimalist Target Support Package. This package supports only LMM programs. It supports only one kernel variant. It supports only one plugin. It supports only one target, and that target supports only two platforms - the HYDRA, and a CUSTOM platform which you can tailor to suit your hardware (if you do not have a HYDRA).

But best of all, it consists of only a few files - so figuring out how it works (which is also described in the enclosed tutorial document, as well as in various README.txt files) is easy.

The main purpose of this package is to demonstrate how to develop a new Catalina plugin, how to create a target that knows how to load it, and how to write some C code that knows how to use it. But for some users - those who have a specific embedded application, and don't need XMM RAM, 5 different kinds of video drivers, 2 different kinds of keyboard and mouse drivers, SD card support, serial I/O, proxy drivers (and all the other stuff supported by the default Target Support Package) this minimalist target support package may provide all they will ever want or need to use Catalina. Or if they need only one or two of those additional plugins, then starting out from this minimalist base and then adding in only what they need may be a much better option.

The attached zip file contains a fully documented and working example of a fairly generic plugin, plus a simple demo program that shows it being loaded and used. The enclosed tutorial also describes the registry in detail, since this is important in understanding how C programs interact with such plugins.

Finally, a more complex demo program is also included - this example shows how a C program can dynamically load and unoad plugins at run-time.

Ross.

Dr_Acula

Reading it now...

jazzed

@Ross, This is a fair, fresh re-start.
I look forward to abusing it the way I see fit.

Thanks.
--Steve

RossH

jazzed wrote: »

@Ross, This is a fair, fresh re-start.
I look forward to abusing it the way I see fit.

Thanks.
--Steve

Absolutely! - it was always intended that people create their own targets for their own purposes - but the complexity of the standard targets made this seem much more difficult than it actually was.

I will continue to maintain the standard targets (since I use them all the time) but I will also include a new "unplugged" target (just thought of this name - gosh, am I slow!) as a component of Catalina.

The real problem is that it is far too easy to get sidetracked by all the interesting and bizarre things people do with Propellers in these forums, and forget that many of the applications for microcontrollers like the Propeller can be done in just a few hundred lines of code - C, SPIN, BASIC or PASM!

Ross.

Dr_Acula

I'm going to see if this can be combined with the thread potatohead has just started on 64 color tiles.

Tiles are great but they consume lots of hub ram. Catalina in external ram could come to the rescue as it frees up hub ram.

The generic plugin could be potatohead's new code. Some very interesting synergies could be possible. Maybe a graphical operating system that looks a bit like an ipad?

potatohead

It's my intent to make the video stuff be binary loadable. Fetch it, setup it's parameters in RAM somewhere, then COGNEW it, telling it where those are.

Getting close to trying that. Seems to me, that approach would extend what is possible on SD card by a considerable amount. My thought was to just build where I know how to, and that's the Prop tool for me at this time. Make it run, then write a small program to just build things, and write the binary off to the SD as a .cog file. From there, people do what they want to do, and the little program can just be maintained with the original.

@Ross I stand in awe over what you and others have done to pry off the address space lid in the Prop. Big grin over here!

Humanoido

Excellent addition!

Heater.

potatohead,

It's my intent to make the video stuff be binary loadable. Fetch it, setup it's parameters in RAM somewhere, then COGNEW it, telling it where those are.

Zog will love you for that.

Even when everything is in HUB Zog could load up keyboard/serial/whatever drivers and this video driver from "binary blobs" in HUB. Then start running C code from the ZPU interpreter, recycling all the space that the blobs lived in for program memory, stack and video buffer.

Dr_Acula

Hi Ross,

I'm incorporating this into the IDE. At the moment it opens up the proptool with the spin part, and also opens up the C part so you can have them side by side. I think the debugging process is going to be a lot easier if you can be changing both code at the same time. I may try to automate this further with a compile and xmodem transfer to the sd card (can the proptool compile with a commandline?)

Anyway I've run into a problem with directories. Is the plugin demo supposed to be in a particular special directory?

Or - is it just generic c code, so does it belong in the \demos directory with all the other demo files?

RossH

Dr_Acula wrote: »

Hi Ross,

I'm incorporating this into the IDE. At the moment it opens up the proptool with the spin part, and also opens up the C part so you can have them side by side. I think the debugging process is going to be a lot easier if you can be changing both code at the same time. I may try to automate this further with a compile and xmodem transfer to the sd card (can the proptool compile with a commandline?)

Anyway I've run into a problem with directories. Is the plugin demo supposed to be in a particular special directory?

Or - is it just generic c code, so does it belong in the \demos directory with all the other demo files?

You have to set your Target directory apropriately before you can compile the generic plugin - e.g:

cd custom_demo
set CATALINA_TARGET=C:\Program Files\Catalina\custom
catalina simple_test.c utilities.c generic_plugin.c -D PLUGIN

... or just enter ...

cd custom_demo
build_all

More detail is given in the document.

Ross.

Dr_Acula

Ok thanks, that makes sense.

I'm looking at the dual serial port and seeing if it could become a plugin. There are many things that need changing. First step is to get code all alongside each other on the proptool. To this end, I have the original serial driver, the catalina serial driver plugin, the dual serial port and the generic plugin. Very helpful to compare and contrast each one.

I now appreciate more and more that your other plugins are works of art!