Catalina 2.9
RossH
Posts: 5,547
All,
I have just posted Catalina 2.9 to SourceForge (here). This is a complete release. I was originally intending to hold off this release till I had completed support for the C3, but this may take several more weeks, so I figured I would release it now.
There is a significant amount of changes and new functionality in this release - especially if you did not download release 2.8 (which was a beta release intended mainly for a few users who needed some particular functionality).
Here is a list of the new features since the last "official" release (2.7):
Changes included in Release 2.9:
Ross.
I have just posted Catalina 2.9 to SourceForge (here). This is a complete release. I was originally intending to hold off this release till I had completed support for the C3, but this may take several more weeks, so I figured I would release it now.
There is a significant amount of changes and new functionality in this release - especially if you did not download release 2.8 (which was a beta release intended mainly for a few users who needed some particular functionality).
Here is a list of the new features since the last "official" release (2.7):
Changes included in Release 2.9:
- Documentation updates. All documents have been updated for this release.
- Upgraded to Homespun version 0.30 - this means there is no longer an 'input' subdirectory in the target directory, since files no longer need to be preprocessed to include the symbol definitions. Also, the new include file capability means a lot of common code has been factored out and is now specified in various '.inc' files. Because preprocessing is no longer required, some of the command line options (e.g. the catbind '-p' option) are no longer required. The end result is a significantly faster, cleaner and simpler compilation process.
- Added a section for to Catalina_Common.spin for the ASC platform - thanks to Martin Hodge. To use it, specify -D ASC on the command line.
- Added statistics (segment and file sizes) generation. This prints the size of each C segment (code, cnst, init, data) as well as the final file size (which will usually be larger than the sum of all segments as it will also include non-C code such as plugins). The statistics generation can be disabled by the -k command line option.
- Added a new library variant - libcix - which can be used by specifying -lcix on the command line. This is an integer-only version of the extended library (libcx) - i.e. it includes fill file system support, but excludes any floating point support. This can reduce the size of programs that use the extended library by around 8kb.
- Added NO_FLOAT as a synonym for the existing command line symbol NO_FP. When defined on the command line, NO_FLOAT and NO_FP both do the same - i.e. they prevent the loading of any floating point plugins. For example, when the XMM kernel is used, it normally loads the floating point plugin Float32_A since the XMM kernel includes no built-in floating point support (due to lack of space). However, if your program does not use any floating point, this is unnecessary and wastes a cog. To prevent this, you would use a command such as:
catalina hello_world.c -x5 -lci -D NO_FLOAT
- Refactored code from the various targets into common include files. Now there is only one copy of many of the complex sections of code, which simplifies maintenance. For example, all the XMM access code now exists only in the file XMM.inc, and is included by other files as needed. The following include files contain code shared between multiple target files or utilities:
Constants.inc code to set constants for the Proxy and HMI plugins
FP.inc code to include the appropriate Floating Point plugins.
HMI.inc code to include the appropriate HMI plugin.
Kernel.inc code to include the appropriate kernel.
Loader.inc code to include the appropriate loader.
Other.inc code to include the appropriate other plugins.
XMM.inc PASM code for XMM access (all platforms)
FP.inc code to include the appropriate Floating Point plugins.
HMI.inc code to include the appropriate HMI plugin.
Kernel.inc code to include the appropriate kernel.
Loader.inc code to include the appropriate loader.
Other.inc code to include the appropriate other plugins.
XMM.inc PASM code for XMM access (all platforms)
- Added auto-execute processing to Catalyst. To auto-execute a command on boot, a file with the name specified by AUTOFILE (default is "AUTOEXEC.TXT") must be created in the root directory. If the file exists, it is read on startup, and the command it contains (up to the first zero terminator, or end of line character, or EOF) is executed. This command can be any valid Catalyst command, including the invocation of an external LMM, SMM or XMM program, and can include parameters to be passed to the program.
- Added execution from SPI SRAM on the Morpheus (CPU #1) and also on the C3. XMM code can be executed from the SPI SRAM. Support for executing from SPI Flash, and additional drivers for the C3, will be included in the next release.
- Added the libthreads Multithreading library. See the Catalina Reference Manual, or the descriptions of the threading functions in the header file catalina_threads.h for details.
- Added the libgraphics Graphics library. See the Catalina Reference Manual or the descriptions of the threading functions in the header file catalina_graphics.h for details.
- Added a NO_ARGS command line option. NO_ARGS prevents the inclusion of the CogStore object, and instead includes a simpler CogStopper object that will terminate cog 7 if CogStore is running in it. This is done to save space (and cogs) for programs that do not accept any arguments - even if the CogStore is loaded by the Catalyst program loader.
- Better granularity of malloc/realloc/calloc/free. For example, now the code for realloc() and calloc() are not included unless specifically used by the program (previously they were always included if malloc() was included).
- Better documentation about installing Code::Blocks if Catalina is not installed in the default location.
- Added a new SMM memory/load model. This is actually a new two-phase loader similar to the EMM memory/load model, but intended for use on platforms that have an SD card. It allows C programs to include up to 31kb of application code, by first loading the drivers, then the application code, and lastly the kernel. The first 32kb of the file is the program that loads the drivers (only 31kb can be used), the second 32kb is the application program (again, only 31kb can be used) and the last 4kb - starting at the64kb boundary - must be the kernel. Thus all SMM programs are exactly 66kb (67,584 bytes) in size. It is used by defining the symbol SDCARD on the command line.
- Catalyst now recognizes .lmm, .smm and .xmm as suffixes for Catalina program files (in addition to the normal .bin). The most important one is the ".smm" suffix, since Catalina must know that these functions do not get loaded into XMM RAM, even though they are larger than 32kb.
- Minor change to the library - all I/O now uses the functions low-level function catalina_getc() and catalina_putc() for character I/O to stdin, stdout and stderr. This means that these routines can easily be replaced with customized routines if required. Previously, these routines were only used in the standard C library (libc) and the integer library (libci) but were not used in the extended library (libcx).
- Added catalina_fs.h which describes low level "managed" and "unmanaged" file access routines. The "managed" routines are the traditional Unix low level routines, such as _open() and _close(). The "unmanaged" routines are similar, but have the advantage that they do not use malloc() or free() internally - instead, the caller passes these functions a block of memory for them to use. This makes the "unmanaged" routines smaller and also more suitable for use in an embedded environment. See catalina_fs.h for more details.
- Fixed a bug in the code generator, when passing a constant to a function, and the constant was < 0 or > 512.
- The _locate_registry() function was dependent on _registry() but this was not specified in the function - this means the symbol C__registry would be reported as undefined (unless the _registry() function was being imported by some other function).
- Added the RESERVE_COG option to all loaders and targets. This option allows a cog to be loaded at the start of the load process (e.g. before any XMM RAM is accessed) and this cog will not be disturbed during the remainder of the load process. This is intended to allow things such as a dynamic RAM refresh cog to be loaded and left running throughout the process of loading and starting a C program. The example program provided (Catalina_Reserved_Cog.spin) simply toggles an I/O pin as proof that it is started and left running. The reserved cog is currently set to be a single cog (cog 6). If more than one reserved cog is required, this can be set in Catalina_Common_Input.spin by reducing the value of LASTCOG. Note that it is the responsibility of the user (or the target) to ensure that only cogs 1 to 5 are loaded (e.g. by plugins) during the load process if the RESERVE_COG option is specified. Also note that (depending on what the reserved cog actually does) the RESERVE_COG may need to be specified on ALL loaders and also on the various Catalina utility programs - e.g. for the HYBRID:
cd catalyst build_all HYBRID RESERVE_COG cd ..\utilities build_all HYBRID RESERVE_COG cd ..\ram_test build_all HYBRID RESERVE_COG cd ..\demos build_all HYBRID RESERVE_COG ... etc ...
See the file Catalina_Reserved_Cog.spin for more details.
- Fixed a few problems with the batch files, and also a problem with the serial loader on multi-prop platforms (TRIBLADEPROP, MORPHEUS) support for serial load between cogs was accidentally disabled in the last release.
Ross.
Comments
I think You have problems on this Page. http://sourceforge.net/projects/catalina-c/files/documentation/.
It have 2 files that have same name -- Catalina Reference Manual.pdf but different file size. BUT in .zip version You have only one of them as ZIP can't add 2 files with same name.
Hi Sapieha,
It looks ok to me. Are you perhaps confusing the Catalina Reference Manual and the Catalyst Reference Manual?
Ross.
Maybe.
BUT still in .zip file are 8 files.On page without ZIP are 9 files
Now I have looked carefully.
It is this file that are not added to .ZIP --- Catalina Reference Manual.pdf
Thanks - I'll update it.
Ross.
Slightly OT; does anybody know a way to unpack this on linux without every single file having it's executable bit set?
-NVM-
I figured it out...
Hi Martin,
Sorry about that - I forgot to reset the permissions when I transferred the files to Linux from Windows. If it's causing you real grief then let me know and I'll post a script to fix it - otherwise I'll fix it in the next release (which could be as soon as a couple of weeks).
- Upgraded to Homespun version 0.30 - this means there is no longer an 'input' subdirectory in the target directory, since files no longer need to be preprocessed to include the symbol definitions. Also, the new include file capability means a lot of common code has been factored out and is now specified in various '.inc' files. Because preprocessing is no longer required, some of the command line options (e.g. the catbind '-p' option) are no longer required. The end result is a significantly faster, cleaner and simpler compilation process.
Yay!!!!- Refactored code from the various targets into common include files. Now there is only one copy of many of the complex sections of code, which simplifies maintenance. For example, all the XMM access code now exists only in the file XMM.inc, and is included by other files as needed. ...
Yay!!!!- Added the RESERVE_COG option to all loaders and targets. This option allows a cog to be loaded at the start of the load process (e.g. before any XMM RAM is accessed) and this cog will not be disturbed during the remainder of the load process. This is intended to allow things such as a dynamic RAM refresh cog to be loaded and left running throughout the process of loading and starting a C program. The example program provided (Catalina_Reserved_Cog.spin) simply toggles an I/O pin as proof that it is started and left running. The reserved cog is currently set to be a single cog (cog 6).
Yay!!!!Not necessary. I did me some learnin' and cypherin' and figured out a neat trick.
chmod -R 644 * find ./ -type d -exec chmod 755 {} \;First command clears exec on everything. Second one sets only directories back to exec
You'll also need to add exeute permission back on various scripts and executables (e.g. all the "build" scripts, and of course anything in the "bin" directory).
The only part that might not be obvious is that within the library source tree there are some scripts buried as well (only necessary if you plan to rebuild Catalina).
I'll generate a script to do it when I get time. It will be a useful tool for me anyway.
Ross.
That part was easy
Catalina 2.9 recompiled for ARM on the Zipit and compiling and payloading (with -t600) normally.
Goodness - that was quick! Let me know if you strike any problems.
Ross.
I have just emailed an updated version of the Catalina Optimizer (2.9) to all registered users. If you have purchased the Catalina Optimizer, but do not receive an update email shortly, then please let me know.
The only change in this release is a bug fix for a case of function inlining that could lead to Catalina thinking the function was undefined.
Thanks,
Ross.
As noted by Martin Hodge, when you install Catalina 2.9 under Linux. it sets the "execute" bit on ALL files, instead of only the files that actually need it. To fix this, save the following code in a file (e.g. Set_Permissions) and execute it (you will probably need to be root to do this).
Windows users need not worry - the permissions on the files should be correct.
#!/bin/bash # # This file sets the "execute" permission correctly on all files in # a Catalina installation. If your Catalina installation is not in # the usual place, then edit the following line: # cd /usr/local/lib/catalina # # remove all execute permissions from all files: # chmod -R a-x * # # now add it back on only those files and directories that need it: # chmod a+x -R bin chmod a+x catalyst utilities target demos custom custom_demo ram_test find . -name "build_*" -exec chmod a+x {} \; find . -name "copy_*" -exec chmod a+x {} \; find . -name "configure" -exec chmod a+x {} \; find . -name "genfiles" -exec chmod a+x {} \;Ross.Brilliant! Catalyst loading can now be automanted.
Seems like the required functions probably include:
XMM_Activate
XMM_Tristate
XMM_ReadLong
XMM_ReadMult
XMM_WriteLong
XMM_WriteMult
XMM_ReadPage
XMM_WritePage
Are any others required or are they just helper functions?
Thanks,
David
Hi David. Your list is correct. See the Catalina Reference Manual pp 90 ("A Description of the Standard Catalina XMM API").
I've posted a small update to Catalina 2.9 specific to the C3 in the C4 thread. If you have a C3, please download that update, otherwise you don't need it.
I will update the general 2.9 release once I finish getting all the C3 devices working.
Ross.
I've posted a another minor update to Catalina 2.9 specific to the C3 in the C4 thread. If you have a C3, please download that update, otherwise you don't need it.
This update adds full (Catlina and Catalyst) support for the SD card on the C3.
I will update the general 2.9 release once I finish getting all the C3 devices working.
Ross.
The third update to Catalina 2.9 for the C3 is attached to the first post of the C4 thread. This update adds blackbox and blackcat debugger support to the C3, as well as ALL OTHER PLATFORMS - i.e. I forgot to update the debugger support in the 2.9 release!
Sorry about that!
Ross
I had a crazy idea this morning. How about we run a Big Basic program on the propeller by translating Basic into Catalina? It sure ought to be easier than trying to write a Big Basic compiler from scratch. Or a Big Spin compiler for that matter.
So - BCX is for Windows http://bcx-basic.sourceforge.net/ with the help here http://www.bcxgurus.com/help/index.html
There is a translator for Linux as well http://www.basic-converter.org/
So here goes with a Basic program
and the output is below. It looks fairly long but most of that is definitions for different compilers and those could be stripped off. My question is - with the final bit of code it produced right at the end, would this be suitable to run through Catalina?
If so, I think we could have a full featured Basic compiler here. I might think about an IDE with a "one click" compile. Your thoughts?
// ********************************************************************* // Created with BCX32 - BASIC To C/C++ Translator (V) 6.1.6 (2010/08/02) // BCX (c) 1999 - 2009 by Kevin Diggins // ********************************************************************* // Translated for compiling with a C Compiler // ********************************************************************* #include <windows.h> // Win32 Header File #include <windowsx.h> // Win32 Header File #include <commctrl.h> // Win32 Header File #include <commdlg.h> // Win32 Header File #include <mmsystem.h> // Win32 Header File #include <shellapi.h> // Win32 Header File #include <shlobj.h> // Win32 Header File #include <richedit.h> // Win32 Header File #include <wchar.h> // Win32 Header File #include <objbase.h> // Win32 Header File #include <ocidl.h> // Win32 Header File #include <winuser.h> // Win32 Header File #include <olectl.h> // Win32 Header File #include <oaidl.h> // Win32 Header File #include <ole2.h> // Win32 Header File #include <oleauto.h> // Win32 Header File #include <conio.h> #include <direct.h> #include <ctype.h> #include <io.h> #include <math.h> #include <stdio.h> #include <string.h> #include <stddef.h> #include <stdlib.h> #include <setjmp.h> #include <time.h> #include <stdarg.h> #include <process.h> // *************************************************** // Compiler Defines // *************************************************** // C++ #if defined( __cplusplus ) #define overloaded #define C_EXPORT EXTERN_C __declspec(dllexport) #define C_IMPORT EXTERN_C __declspec(dllimport) #else #define C_EXPORT __declspec(dllexport) #define C_IMPORT __declspec(dllimport) #endif // Open Watcom defs #if defined( __WATCOM_CPLUSPLUS__ ) || defined( __TINYC__ ) #define atanl atan #define sinl sin #define cosl cos #define tanl tan #define asinl asin #define acosl acos #define log10l log10 #define logl log #define _fcloseall fcloseall #endif // Borland C++ 5.5.1 defs - bcc32.exe #if defined( __BCPLUSPLUS__ ) // ===== Borland Libraries ========== #include <dos.h> #pragma comment(lib,"import32.lib") #pragma comment(lib,"cw32.lib") // ================================== #endif // Microsoft VC++ #ifndef DECLSPEC_UUID #if (_MSC_VER >= 1100) && defined ( __cplusplus ) #define DECLSPEC_UUID(x) __declspec(uuid(x)) #else #define DECLSPEC_UUID(x) #endif #endif #if !defined( __LCC__ ) // ************************************************* // Instruct Linker to Search Object/Import Libraries // ************************************************* #pragma comment(lib,"kernel32.lib") #pragma comment(lib,"user32.lib") #pragma comment(lib,"gdi32.lib") #pragma comment(lib,"comctl32.lib") #pragma comment(lib,"advapi32.lib") #pragma comment(lib,"winspool.lib") #pragma comment(lib,"shell32.lib") #pragma comment(lib,"ole32.lib") #pragma comment(lib,"oleaut32.lib") #pragma comment(lib,"uuid.lib") #pragma comment(lib,"odbc32.lib") #pragma comment(lib,"odbccp32.lib") #pragma comment(lib,"winmm.lib") #pragma comment(lib,"comdlg32.lib") #pragma comment(lib,"imagehlp.lib") #pragma comment(lib,"version.lib") #else #pragma lib <winspool.lib> #pragma lib <shell32.lib> #pragma lib <ole32.lib> #pragma lib <oleaut32.lib> #pragma lib <uuid.lib> #pragma lib <odbc32.lib> #pragma lib <odbccp32.lib> #pragma lib <winmm.lib> #pragma lib <imagehlp.lib> #pragma lib <version.lib> // ************************************************* // End of Object/Import Libraries To Search // ************************************************* #endif // ************************************************* // User Global Initialized Arrays // ************************************************* // ************************************************* // Main Program // ************************************************* int main(int argc, char *argv[]) { printf("% G\n",(float)“HelloWorld”); return 0; // End of main program } // ************************************************* // Runtime Functions // *************************************************List of the string functions for BCX (see the help link above). There are many other functions.
Hi Dr_A,
It's not such a crazy idea (or if it is then we're both crazy!). But have you noticed just how many Windows (and DOS) header files BCX expects to include (e.g. #include "windows.h" etc)? Yes, the output of BCX is fairly close to being ANSI C - but it generates C that will only compile on a Windows-based C compiler!
I started work on producing a version of BCX that generated only ANSI C and also only used only the standard ANSI C header files, but I didn't get very far. I'd be happy for someone else to have a go at this - but be warned it isn't going to be easy. BCX relies heavily on various low level Windows and DOS functions to do all the work - and some of these are difficult to reproduce on any other platform.
Ross.
I guess it would be a matter of starting with that 'hello world" and then adding some instructions and seeing what .h files are actually needed. It might end up with a subset of the BCX full instruction set, but I think that would be still useful.
Where did you get stuck?
Hi Dr_Acula,
I can't recall - it was a few years ago now. I seem to remember not getting very far before the non-ANSI code that BCX emitted became a pain to convert. Try including a simple INPUT statement as well as a PRINT - you'll get more of an idea. Delete all but the ANSI headers and see if it will compile.
Ross.
dim a as integer for a=1 to 10 print "hello world"; print a next a ' file test copied from bcx examples print "Opening file for output" DIM MyFileHandle@ ' BCX Reserves @ for "C" FILE* data types OPEN "new.txt" FOR OUTPUT AS FP1 MyFileHandle@ = FP1 FPRINT MyFileHandle@, "This is a test" CLOSE FP1 print "Closing file"translates to
#include <stdio.h> static int a; static FILE *MyFileHandle; static FILE *FP1; void clearscreen() // white text on dark blue background { int i; for (i=0;i<40;i++) { t_setpos(0,0,i); // move cursor to next line t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100 } } // int main(int argc, char *argv[]) void main() { clearscreen(); for(a=1; a<=10; a+=1) { printf("%s","hello world"); printf("% d\n",(int)a); } printf("%s\n","Opening file for output"); if((FP1=fopen("new.txt","w"))==0) { fprintf(stderr,"Cant open file %s\n","new.txt");exit(1); } MyFileHandle=FP1; fprintf(MyFileHandle,"%s\n","This is a test"); if(FP1) { fclose(FP1); FP1=NULL; } printf("%s\n","Closing file"); while (1); }while compiles and runs. This is running in either internal or external memory - your choice, so this is the beginnings of Big Basic.
So Print is working.
'Input' is a nightmare as it creates a huge number of functions, most of which won't compile. And it creates a temporary array for the input that has over a million characters in the array! Find for windows, but not here. Strings also are being created with a default size of 2048. But both of these are easy to fix with a small program that replaces these with more meaningful numbers like 80 or 127.
Inkey$ has more subtle problems. This is just reading a keyboard input. Basic may work different to C here. With Basic, if you call Inkey$, it returns "" if there is nothing and a character if there was something. It is a bit unclear what "" actually is. I suspect it is a string with zero length, ie a C array with zero at the beginning? In any case, the BCX code is going off and doing windows calls. But in a similar way, Catalina seems to be going off and doing its special calls to
So either way, non C89 code is going to be needed here. Unless scanf or something else in stdio has a function that checks for keyboard input and returns if nothing is there.
Also - the code being produced by BCX is going to need to be reordered so the Main is at the end.
So writing Big Basic will be a matter of testing each function and seeing if it will compile. It will be a lot of work, but still probably easier than building a compiler from scratch.
Just a note to myself - the $SOURCE directive puts the original source code in as comments. This could be useful for any post processing.
#include <catalina_hmi.h> #include <catalina_cog.h> char *inkey(); // forward reference void wait(int); // forward reference /* * main : test the inkey function */ void main() { char * result; t_printf("Testing Inkey\n"); while (1) { result = inkey(); if (strlen(result) == 0) { t_printf("."); } else { t_printf("%s", result); } wait(100); } } /* * inkey : simulate a BASIC style INKEY$ function (currently no extended keys!) */ char *inkey() { static char _inkey[2] = {'\0', '\0'}; _inkey[0] = k_get(); return _inkey; } /* * wait : pause for a specified number of milliseconds */ void wait(int milliseconds) { _waitcnt(_cnt() + milliseconds *(_clockfreq()/1000)); }Why? C doesn't care - as long as any functions called by main() are declared in header files (or forward declared at the top of the file). See the example above.
Ross.
I'll need to test if BCX produces such forward references. Still some experiments to do. Hopefully soon I'll have an idea how many instructions are going to translate ok.
So this means we would just need to strip out all the Windows #includes etc
Some things work, some don't. The Basic ASC() function produced a line of C code that had UCHAR in it, which Catalina did not like.
BUT, I found a generic nifty way around functions that don't translate. You can include inline C code in your basic program with the $CCODE command. And, you can pass variables between that and Basic.
Dimension a global array in Basic, and the C code can alter this too.
What this means is that for any function that is not translating properly, instead of trying to post-edit what BCX produces, instead, include C functions to do the same thing. And if that makes your program too long, you can do this (copied from the manual)
When embedding a complete function in C into BCX one way to deal with the function prototype is to put it into a C header file(*.h), and #INCLUDE the C header at the beginning of the program.
Just name the C function as the same name as the Basic command and then it will be familiar to Basic programmers.
I think that also means we can use all the custom Catalina code, eg that keyboard code, without having to rewrite things. Eg, say INKEY$ simply is producing code that is so far from ever working that you can't use it. Instead, write a Basic subroutine. Maybe INKEY is a reserved word, so we might call it C_INKEY and then most of that subroutine is actually in C. If people want to use INKEY$ exactly as it is used in basic, maybe a preprocessor could go through searching for this keyword and replace it with an #include for the appropriate function, and change INKEY$ to a call to C_INKEY
I have a feeling that the string functions are going to need this because they are producing a lot of extraneous code. The second to last line on this runtime function will not compile with catalina. I'm not a C expert so I'm not sure if this is incorrect C89 syntax or something else, like another #include that is assumed.
// ************************************************* // Runtime Functions // ************************************************* char *BCX_TmpStr (size_t Bites) { static int StrCnt; static char *StrFunc[2048]; StrCnt=(StrCnt + 1) & 2047; if(StrFunc[StrCnt]) free (StrFunc[StrCnt]); return StrFunc[StrCnt]=(char*)calloc(Bites+128,sizeof(char)); } char *left (char *S, int length) { register int tmplen = strlen(S); if(length<1) return BCX_TmpStr(1); if(length<tmplen) tmplen=length; char *strtmp = BCX_TmpStr(tmplen); // catalina does not compile this line - multiple errors return (char*)memcpy(strtmp,S,tmplen); }Next step - test out program control flow as this is the sort of thing that can't be put into C functions.
Very nice work!
It is probable that UCHAR is simply a typedef (or possibly a #define) for unsigned char - so, simply add this to your header file as well: Ross.
Can you help with some maths. I get an error with "sin undefined"
#include <math.h> static double number1; printf("% .15G\n",(double)sin(number1));