Catalina 4.0 is now available
RossH
Posts: 5,462
Catalina 4.0 is now available on Sourceforge - https://sourceforge.net/projects/catalina-c/
Catalina 4.0 is the latest release of Catalina, supporting both the Propeller 1 and the Propeller 2. It replaces all previous releases and is validated on the Propeller 2 P2_EVAL board for all memory model, library, optimization level and floating point combinations. It is also validated on many Propeller 1 platforms.
This release adds a new library for the 2 Port Serial plugin on the Propeller 2, XEPROM support (i.e. execute XMM code from EEPROM) for the Propeller 1, and several significant bug fixes for the Propeller 1 and Propeller 2. It also improves the Code::Blocks support for the Propeller 2, which had been lagging behind the command line support. However, the main purpose of this release is that it is the first release for the Propeller 2 that also updates the documentation. All documents have been updated to reflect the Propeller 2 support, and there is a new Catalina Reference Manual specific to the Propeller 2.
This release is intended to provide a baseline release for further incremental updates, which will mainly now concentrate on adding new plugins to Catalina's Propeller 2 support, until Catalina on the Propeller 2 has as rich a range of plugins as Catalina already has on the Propeller 1.
Catalina 4.0 includes both Windows and Linux releases.
This release will be supported for both the Propeller 1 and the Propeller 2.
Here is the README.WhatsNew
Catalina 4.0 is the latest release of Catalina, supporting both the Propeller 1 and the Propeller 2. It replaces all previous releases and is validated on the Propeller 2 P2_EVAL board for all memory model, library, optimization level and floating point combinations. It is also validated on many Propeller 1 platforms.
This release adds a new library for the 2 Port Serial plugin on the Propeller 2, XEPROM support (i.e. execute XMM code from EEPROM) for the Propeller 1, and several significant bug fixes for the Propeller 1 and Propeller 2. It also improves the Code::Blocks support for the Propeller 2, which had been lagging behind the command line support. However, the main purpose of this release is that it is the first release for the Propeller 2 that also updates the documentation. All documents have been updated to reflect the Propeller 2 support, and there is a new Catalina Reference Manual specific to the Propeller 2.
This release is intended to provide a baseline release for further incremental updates, which will mainly now concentrate on adding new plugins to Catalina's Propeller 2 support, until Catalina on the Propeller 2 has as rich a range of plugins as Catalina already has on the Propeller 1.
Catalina 4.0 includes both Windows and Linux releases.
This release will be supported for both the Propeller 1 and the Propeller 2.
Here is the README.WhatsNew
Catalina release 4.0 is a full release. You can install this over an
existing version of Catalina, but it is recommended that you instead uninstall
any previous Catalina release before installing, or install this release to a
different location.
If you are installing under Linux, you should execute the following command
to set your permissions correctly after installing (this command is a script
in the Catalina bin directory):
Set_Linux_Permissions
The following changes have been made since the previous release of Catalina.
If you have not used a previous release of Catalina, you can ignore the
following list:
RELEASE 4.0
1. Updated Code::Blocks to include the XEPROM option. Now you can select
XEPROM in the Catalina Project Wizard (by selecting the menu entry for
File->New->Project and then selecting "Catalina Project") and you can
also use 2 new tools for loading XEPROM projects (by selecting the
Tools menu entry)
2. Added a new named platform to Catalina_platforms.inc. This is the P2_CUSTOM
platform, which by default is identical to the P2_EVAL platform, but which
is intended to be customized for new Propeller 2 boards.
3. Because the support for the Propeller 2 is (at least at present!) much
simpler than that for the Propeller 1 (e.g. it does not require XMM support
to run large C programs, and complex loaders to load them), the Catalina
Reference Manual now has two versions - one specifically for the original
Propeller 1 (which removes most of the details that are relevant only to
the Propeller 2), and another for the Propeller 2 (that removes most of the
details that are only relevant to the Propeller 1). All other documents
have also been updated to reflect the functionality now available in
Catalina 4.0.
4. Moved the inline PASM demos to the spinc folder, and updated the README.TXT
in that folder. Also added the program "test_inline_pasm.c" as a project in
the Code::Blocks "Spinc Demos" workspace.
5. Added tty_txcheck() functions to the tty and tty256 libraries, to match the
s4_txcheck() function recently added to the s4 library. These functions all
return the number of spaces left in the transmit buffer. The important
point is that if they ever return 0, it means a call to the corresponding
tx function may block.
6. Fixed a bug that affected Propeller 1 XMM programs that used the cache.
Typically, it meant that a program would work with a smaller cache size
(e.g 1K, 2K or 4K) but not with a larger cache size (e.g. 2K, 4K or 8K)
even though there was enough Hub RAM to accommodate the larger cache.
7. The batch files p2_asm.bat and p2_asm have been modified to include the
-v33 flag to the p2asm assembler. This enables the differences in the
instructions set in the latest (and hopefully last) version of the
Propeller 2 chip used in the rev B version of the P2_EVAL board. Note
that Catalina itself does not use the different instruction sets, but
some plugins or user programs may do so. If it is ever necessary to
revert to the previous instruction set (e.g. to run a program on a revA
version of the P2_EVAL board), these files must be edited to remove this
flag.
8. Fixed a bug where the plugin type of the kernel cog was being overwritten
during registry initialization, so the cog would appear to be unused.
9. Added the 2 port serial driver as a plugin, and a library (libserial2)
to use it. The 2 port serial driver is only supported on the Propeller 2.
The functions in the 2 port serial library are similar to the existing
libtty, libtty256 and libserial4 functions. Catalina will load the 2 port
serial plugin automatically if you compile your program with the -lserial2
option. Note that you should not use the 2 port serial driver with the
TTY HMI option - they will conflict. This means that when compiling with
-lserial2 you should also either specify -C NO_HMI, or use another
supported HMI option. For instance:
catalina -p2 test_serial2.c -lci -lserial2 -C NO_HMI
10. Fixed a problem with the Code::Blocks "Download to Hub Ram and Interact at
230400 baud" tool, which was not setting the directory correctly, and so
would sometimes not find the file to download. After installing, you may
need to run the "Reset_CodeBlocks" script (found in the Catalina bin
directory).
11. Made some small changes to the test_dosfs.c program in the "validation"
subdirectory, to allow more variants of the program to run on P1 platforms
with very limited XMM SRAM (such as the C3). On such platforms, this test
program may still fail to run when compiled in LARGE mode unless the FLASH
option is also used, because 64kb of XMM SRAM is simply insufficient in
some cases (e.g. if the program is compiled with the libx library variant).
However, this is not a Catalina failiure, and the test program now runs
correctly in most cases.
Comments
Odd! I must have packaged the wrong version
I'll investigate.
Hello Jon
I've investigated, and the version of codeblocks installed by the Catalina 4.0 installer is definitely 17.12.
And yes, Catalina installs its own version of Code::Blocks - this should not interfere with any other version you already already have installed, except possibly for any settings saved in your local "default.conf" file (such as the Tools menu entries). However, those other versions of codeblocks will not include the Catalina-specific extensions, and it probably means that if you just start codeblocks from the command line, you may be getting the wrong version (this will depend on your path settings). You must start Catalina's version using the Start Menu, which knows where it is installed.
If doing so is starting version 13.12 of Code::Blocks, it could be that you installed Catalina 4.0 over an older version, and for some reason it did not update the codeblocks files. If this is the case, please try completely uninstalling the previous version of Catalina before installing version 4.0.
Let me know how you go.
Ross.
-- https://sourceforge.net/projects/catalina-c/
... is connected to version 3.13.2. I missed this when I downloaded. I had to manually navigate to Files/Releases/4.0 to get the correct installer.
Just a note: Windows defender was not happy. I installed anyway and my very-high horsepower machine went full blast for a while. Everything seems now. I ran from Start menu and everything is in place.
Ah! I have no control over that. There must be a delay before it switches to the latest release. I will delete some of the older releases - this may help, and they are very out of date anyway.
Odd. I run Windows and it installs without comment. I did see this once before (months ago!) but it seemed to go away again. There is a process you can use to tell Microsoft this is a false detection, but I can't remember what it is. I will try and look it up.
What does Windows Defender say on your machine? That may help me identify which file is causing the problem.
Ross.
Next time, I will try and remember to wait for this before announcing it
Ross.
The Catalina 4.0 Linux release contains an old version of the Catalina "New Project" wizard script. Easy to fix - just overwrite the existing version with the one attached. NOTE: the Windows installer installs the correct version.
If you installed codeblocks to the recommended location under Linux, the original file will be found in:
The new version adds XEPROM support (to the wizard only - XEPROM support can still be specified on the command-line, or manually selected within Code::Blocks).
Ross.
I accidentally left the pin definitions for the second serial port on the P2_EVAL board set to 50 & 52 (which I test with a PropPlug) instead of 56 and 57 (which are the pins intended to be used by the 2nd USB port, if you have it enabled). This might cause some head scratching because the second serial port would not work as expected "out of the box" with the 2 port serial plugin.
This is fixed in the attached file, which applies to both Windows and Linux (I have left the pins set to 50 & 52 in the P2_CUSTOM platform).
Also, I have now added CUSTOM and P2_CUSTOM as synonyms for the configuration intended to be modified to support other boards. This is because the many of the batch files now set the -p2 flag automatically if the platform name starts with P2 (e.g. P2_EVAL, P2D2), whereas in other cases (e.g. in Code::Blocks) it is still assumed this platform will just be called CUSTOM. So now you can use either one.
Just copy the attached file over the existing version in your catalina/target_p2 directory.
Ross.
I have to say upfront that I am born and raised to be a COBOL programmer and I have never liked C. I was threatened to use the net framework and C# when migrating things from big iron to PC hardware, but - hmm- was able to avoid C, mostly in my life.
But besides Mainframes I like those micro controllers. Just for fun. Since you stated at some time that you used my 2-port driver serial, I sort of HAD to install Catalina. Not that I need it but, gosh a SERIOUS product for the Propellers and my 2-port-driver used? I still am to shy to ask @ersmith to put that into flexgui and you are using it. COOL.
So I HAD to install it.
I am seriously impressed by Catalina and the Code Blocks integration. Really nice done. Just WOW.
I never used Catalina on the P1, I was just fine with PASM and SPIN, but I think I missed out somehow there. You even support my Ramblade from @Cluso99, incredible!
so a big THANK YOU for doing that, even if I do not need C but, hell YES you did a good job and someone has to say that.
Enjoy!
Mike
I may make a C programmer out of you yet!
But if you would be able to add some POSIX stuff I might be able to run GnuCOBOL, it does transpile COBOL to C but does even have a hard time to run on Windows without mingw or a virtual whatever.
Anyways, VERY cool what you did.
And, YES I did wrote a small C program just to test Catalina. I sort of had to.
guess what, it even worked on P1 and P2 eval A.
Mike
I really, really, REALLY don't want to ever see the C code that results from that process!
Ross.
I do really like the GnuCobol project, but it is quite Linux centric, and I am not.
Enjoy!
Mike
A compiled version using base pin 56 is attached (this is the default because it also flashes the LEDs on the P2_EVAL board).
Ross.
I don't know if Propeller 2 users have been following recent developments of Catalina on the Propeller 1, so I thought I'd post an update here.
Catalina 4.1 will be released soon, and will incorporate a new "multi-memory model" feature which allows the concurrent execution of programs that use different memory models (e.g. COMPACT and XMM on the P1, or COMPACT and NATIVE on the P2). For instance, on the Propeller 1, it can be used to launch COMPACT programs as needed from XMM RAM, saving valuable Hub RAM.
On the Propeller 2, Catalina doesn't support XMM RAM yet, but it allows you to do the same thing using the SD Card - i.e. to launch COMPACT, LMM or NATIVE programs from the SD Card, all from within a program itself compiled as any supported type. This works on both the Propeller 1 and the Propeller 2, but is especially useful on the Propeller 2.
One consequence of this is that a Propeller program can now be of essentially any size even without XMM RAM, provided it is structured as a primary program that loads multiple secondary programs as overlays.
And it is all as easy as ABC! Well, perhaps as easy as ABCDEFGHIJKL ... etc ...
All the concurrent programs share the registry and any plugins. They can each be multi-threaded or single-threaded. They can all communicate. See the attached README_MMM.TXT file for more details.
Attached is a fully working example for the P2, with program source code and binaries. You can run the binaries, but won't be able to compile the source until Catalina 4.1 is released. The demo can be executed on the P2 simply by copying all the files to an SD Card and rebooting the P2. It uses a serial terminal at 230400 baud. It is compiled for a VT100 emulator (I use 'putty') but if you use the Parallax Serial Terminal, just disable Line Feed processing, and if you use the Catalina payload terminal, just include the command line option '-q1'
The example includes the Catalyst program loader. At the Catalyst command line, enter one of the following commands:
In each case, the program you run will simply execute the "dining philosophers" program 3 times, loaded each time from a different overlay file - one compiled as COMPACT, one as LMM, and one as NATIVE. None of them will run to completion - the primary program only allows each secondary to run for 10 seconds and then kills it (this is only a demo!). Note that you have to press ENTER each time the primary starts a secondary program - this is really only to demonstrate that all the programs (primary or secondary) are sharing the same serial comms plugin.
The important point is that it demonstrates that the primary program and secondary program can be any combination of memory model, and any combination of threaded and unthreaded. This allows different portions of the program to be compiled for SPEED (i.e. compile them as NATIVE) or to save SPACE (i.e. compile them as COMPACT). You can now mix and match to suit!
For those interested in the gory details, here are all the commands I actually used to build the demos (this will only mean anything to you after you have read the README file):
Note that the "dining_philosophers.c" program is nothing special - it is actually the one already included in Catalina as a multi-threaded demo program. And the "run_dining_philosophers.c" program is quite trivial - apart from all the messages it prints out as it executes, it is really only a few lines long.
You can thank Covid-19 for this new capability. I am finding I have a lot of spare time on my hands at the moment
Ross.
While working on the multithreading aspects of the new Multi-Memory Model support, I noticed that some of the programs in the demos\multithread folder don't work on the P2 RevB silicon (they worked on the P1 and the P2 RevA).
The problem is that the following code (or something similar) should be included at the start of any multi-threading program, before any other thread functions are called:
Some of the demo programs had it, some didn't. I will fix this in release 4.1, or you can simply edit the demo programs now.
Ross.
But had to migrate to c and later to .net c#
I would love to have a c# like thing on p2
I am not a Cobol programmer. I believe there may be some who visit these forums, but I can't remember who they were.
As for C# ... well, I doubt we will ever see C# on the Propeller, but if you want to try porting it and there is anything you can use in Catalina, be my guest!
Ross.
I have to admit that I've never used Catalina for the P1. I've just read the feature list... "Full debugger support (source code and/or assembly level debugging)" This really already works for the P2? That would be awesome! I already use Code::Blocks for PC software development, BTW.
The source level debugger certainly works for both the P1 and the P2. There is a command line version for Windows and Linux (BlackBox) and a Windows-only GUI version (BlackCat). I use those myself occasionally, and have updated them for the P2.
I have to admit I haven't used the assembly level debugger for quite a while! The P1 version was based on the POD debugger, and there is no P2 equivalent that I am aware of. I will update the documentation for the P2 to say there is only source level debugging, unless someone can point me to an assembly level debugger for the P2?
Ross.
Hardware: P2
Platform: P2EVAL
XMM Board: none
Standard C Library (with float)
HMI: TTY (serial)
memory: NATIVE
filename extension: .bin
Something is wrong with the file name - "HelloWorld.bin.bin". Did you by chance call your project "HelloWorld.bin"?
I am not at my normal computer at the moment, but I think doing that may cause problems on Windows. I will investigate further when I get a chance, but you may want to try it calling the project just "HelloWorld".
Also, since a "hello world" program probably uses the normal serial I/O port, note that when you do get it compiled that the source-level debugger will require a separate serial port to that used by the stdio functions - it cannot share the same port.
The pins used for the debugger's serial port are configured in the "Catalina_platforms.inc" file in the "target_p2" directory, and (depending on your hardware) you may need a PropPlug or equivalent.
#define pinDTX 62 #define pinDRX 63 #define pinMTX 11 #define pinMTE 12 #define pinMRX 13 #define baudRate1 230_400 // serial debug port #define baudRate2 1_000_000 // RS485 port static struct __using("FullDuplexSerial2.spin") com; void main() { clkset (... com.start2 (pinDRX, pinDTX, 0, baudRate1, pinMRX, pinMTX, 0, baudRate2);My board is a custom one but it's compatible to the P2EVAL. At least it has a 20MHz crystal, an SPI flash ROM and the first serial port on the same pins.Then I must have a bug in the "new project" script. I will investigate.
In the meantime you can fix it manually by right clicking on the project, and selecting "Properties" (or selecting the Project->Properties menu item). In the Properties dialog box select the "Build targets" tab, and then remove the ".bin" from the "Output filename".
Yes, it is possible to use the same port for programming and debugging, provided you don't also use the same pins for serial I/O. To make sure that the TTY HMI plugin is not being loaded, select "No HMI" in the build options, or specify -C NO_HMI manually.
In the target_p2\Catalina_platforms.inc file, find the platform you are using (I am guessing it would be either P2_EVAL or CUSTOM) and modify the BlackCat pins (also used for BlackBox) to be as follows:
Ok, that worked and now I'm able to compile. But when I choose Tools->Download to HUB RAM and interact at 230400bd I get this message: I have my board connected with a standard (P1) ProgPlug which has proven to work with loadp2. The LEDs on the ProgPlug are blinking shortly for half a second. I can see from the LEDs of the P2 board that it does a reset and loads the program that was previously stored in the flash ROM (not the hello world program).
My board has the standard boot pin connections:
TX/RX to P62/P63
SO, SI, CK, /CS to P58 to P61
10k pullup on /CS
no SD card or anything else connected, schematic available here
Try executing that payload command manually (i.e. in a Catalina Command Line). You can add -d and it should print diagnostic information which might tell you something. You can also try removing the -z, or adding one or more of the following, which extend various timeouts:
I know some of these are necessary on Linux (notably -t 1000), but they are not usually necessary on Windows.
However, at the end of the day, you don't need to use payload at all, even when debugging. If loadp2 works for you, you can continue to use that and any suitable serial terminal emulator (or the Catalina debuggers).