Catalina 3.6
RossH
Posts: 5,511
All,
I've just uploaded a new version of Catalina 3.6 here. Windows "one touch" installer and Linux versions are provided. Here is a summary of the major new features (details of other minor changes are in the README.WhatsNew file attached, which is also contained in the distribution):
Ross,
P.S. Note that the existing Catalina Optimizer will not work with this version of Catalina. If you have paid for the Catalina Optimizer, I will shortly be sending you a new version by email.
I've just uploaded a new version of Catalina 3.6 here. Windows "one touch" installer and Linux versions are provided. Here is a summary of the major new features (details of other minor changes are in the README.WhatsNew file attached, which is also contained in the distribution):
- Added a new Payload option (-q) to control the interpretation of line termination characters sent by the Propeller program to the Payload interactive terminal emulator:
-q1 : ignore CR
-q2 : ignore LF
-q3 : ignore both CR and LF
-q2 : ignore LF
-q3 : ignore both CR and LF
The option -q1 is useful when running programs that use DOS line termination (i.e. CR LF) with the Payload terminal emulator, since the CR effectively causes these lines to be erased as soon as they have been displayed.
- A new binary image format has been implemented, which typically saves around 300 bytes of HUB Ram for all memory modes (LMM or XMM). Also, the binary formats for Flash programs are much smaller - around the same size as the non-flash versions.
- Payload has been modified to load all programs faster. In some cases, it can even load TINY (LMM) programs faster than the Parallax loader! All XMM programs load much faster, especially those that use Flash RAM. In most cases, the load of an XMM version of a program is now as fast - or faster - than loading the equivalent non-XMM version.
- Catalina now compiles files "in place", and no longer needs to write temporary files to the target directory. This makes it posible to have multiple users using Catalina at once, and it also makes Catalina more commpatible with Windows 7 and Vista, which do not like programs that write to the Program Files folders. The target directories can therefore now be made "read only", and users no loger need to have Administrative rights just to compile C programs.
- There is now only one XMM kernel debugger overlay for all XMM platforms. Previously, a different overlay was required for each platform, which complicated the development of new XMM platforms. Now, full source level debugger support is automatic for any new platforms that provide the standard set of XMM API functions.
- Added support for direct access to the special cog registers. This is in addition to the existing access method (.e. via fuinction calls like _ina() etc). The new include file <propeller.h> defines the variables PAR, CNT, INA, DIRA etc as external volatile variables, and they can then be used like any C variable. For instance:
#include <propeller.h>
#define BIT 0 // bit number to toggle
#define BITMASK (1<<BIT)
void main(void) {
unsigned count = CNT+CLKFREQ;
DIRA |= BITMASK;
OUTA &= BITMASK;
while (1) {
OUTA ^= BITMASK;
WAITCNT(count, CLKFREQ);
}
}
The <propeller.h> file also contains other useful definitions to assist Spin programmers who want to try C.
- A new serial plugin and HMI option have been added, based on the Full Duplex Serial driver. To use this driver as the HMI option, define the symbol TTY (i.e. by adding the option -C TTY to the command line). For example:
catalina hello_world.c -C TTY
This plugin can also be used as a stand-alone serial port driver (e.g. in addition to another HMI option). Access functions are provided in the library libtty. This works in exactly the same way as the "4 port serial" plugin - all you need to do is link your program with libtty (i.e. by adding the option -ltty to the command line). For example:
catalina test_tty.c -ltty
Note that the default pin configuration for the TTY plugin may conflict with the default pin configurations used by the PC and PROPTERMINAL HMI options. If you use one of these HMI options, you can change the pins used by the new serial port plugin by editing the file Extras.inc - or if you do not need a HMI, simply define the symbol NO_HMI on the command line. For example:
catalina test_tty.c -C NO_HMI -ltty
The main advantage of using the TTY HMI option over the PC HMI option is that it saves one cog. The main disadvantage is that it cannot be proxied (which would only matter in a multi-CPU system).
- The default FG and BG colors used in all the supported TV and VGA drivers are now specified in Catalina_Common.spin. This makes them much easier to configure, and they can be configured differently for each driver type (e.g. TV, HIRES_TV, LORES_VGA etc). The default in all cases is set to White text on a Dark Blue background. Note that the way colors are specified differs between different driver types - refer to the low level drivers for more details (e.g. TV.spin, VGA.spin etc).
- Several other minor bug fixes and enhancements.
Ross,
P.S. Note that the existing Catalina Optimizer will not work with this version of Catalina. If you have paid for the Catalina Optimizer, I will shortly be sending you a new version by email.
Comments
Here is the original version, modified only to reduce the number of nodes it can handle (as described in the program itself, to allow it to run on small computers) - small_lisp.c
Save the above version over the existing one in the Catalina\demos folder. Then here are sample commands to compile, load and run the program on the C3:
Ross.
If you use Flash RAM, you will REALLY notice the difference!
Ross.
Are you using the stock standard FullDuplexSerial ? Is it easily replaced with my modified version FullDuplexSerial_rr004 that permits easy changes to the buffer size?
Hi Cluso,
As with most Catalina plugins, there is no change to the PASM, and the modifications to the SPIN "wrappers" are minor and fairly mechanical.
If your revised Full Duplex plugin has essentially the same "Spin interface" as the original then simply replacing the current PASM with your amended PASM will do the job.
One of the reasons I wish we could all agree to adopt a "language independent" convention for Spin objects is that every time I take an object out of the OBEX to include in Catalina, I find someone has already invented a "new improved" version
Ross.
Hi David,
The Catalina 3.6 source should compile and run on a Mac (note you will need Mono for the Mac to run homespun). However, the various makefiles may require "tweaking" to cope with differences in path names etc. I have no access to a Mac, so I can't assist directly - but I'd be happy to offer advice if you strike a problem.
Ross.
Underneath all the frippery, OSX is basically a Unix clone, so you would start with the instructions for building Catalina under Linux - see Building Catalina under Linux on page 98 of the Catalina Reference Manual.
Ross.
I added -D__linux__ to the CFLAGS in the main makefile in the catalina source directory and that causes everything to build but I get lots of warnings about 64 bit pointer values being truncated to 32 bits. Is that normal?
I'll take a look at the Linux section of the reference manual to see if that answers my questions.
Thanks,
David
HI David,
In Catalina 3.6, you're actually working with the Windows sources, which do not have the appropriate permissions set for Linux (this is actually the only difference between the Linux and the Windows sources!).
However, there is a Linux script called Set_Linux_Permissions in the bin directory that should (as the name says) set the permissions of everything appropriate for Linux). You wouldn't normally have to do that if you were starting with the Linux sources, but I haven't released those yet (I haven't tested 3.6 on Linux yet).
As for the 32 bit vs 64 bit stuff - I compile under both 32 bit and 64 bit versions of GCC under Windows and Linux with no problems, and I thought I had eliminated all the warning messages (someone complained about these previously). But perhaps OSX is slightly different. However, there is a gcc option to force 32 bit compilation - add -m32 to your gcc options.
Ross.
I'll try the -m32 option later. Off to an appointment now. Thanks!
Sorry, I just assumed that because the thread you are posting in is specifically about Catalina 3.6.
Chances are that when you untarred the Linux sources, you did not specify the -p parameter. This is described in the Installing Catalina section of the Reference Manual (see the footnote about using tar). However, the Set_Linux_Permissions batch file should fix things.
Ross.
I'll try again. I posted to this thread because I wanted to try 3.6 but when I went to look for files I could install on my Mac I couldn't find them so I settled for 3.5.
Hi Cluso,
Yes, this is a real problem. Most people (like me) just pick the first one they find in the OBEX - especially if that one appears to originate from Parallax. We many never realize there are later and greater versions.
Ross.
Hi David,
I'll try and get a chance to post Linux versions this weekend. As I mentioned, the sources are always the same - the differences are only in file names (Linux is case sensitive, Windows is not) and perhaps some bash scripts I have forgotten to update.
Ross.
Here is FDX_rr004 with 256 byte buffers (only a single change to set the size in the CON section - 256 is the max size!). Just noticed I did this in AUg 2009.
FullDuplexSerial_rr004.spin
Hi Ray,
Catalina used to use 3 cogs for this, so I'm not surprised it was not fast enough for some purposes. The new version uses only 2 (if you use stdio) or 1 (if you use the new plugin directly), and should be much faster. But I'll check out the consequences of using your version instead. It may be a simple "cut and paste".
Ross.
Oops! You have indeed found a bug - but the bug is that <dirent.h> should not be there. It's a hangover from the Amsterdam Compiler Kit (which is where Catalina gets most of its ANSI C library). I thought I'd removed all the non-ANSI stuff, but I missed this one.
<dirent.h> is not an ANSI header file because it is so O/S-dependent. It is a POSIX header file, but POSIX compliance relates to the O/S, not the compiler (and even if the Propeller does one day get an O/S, it won't be a POSIX compliant one!).
In Catalina, the equivalent would be <dosfs.h> - the functionality required to implement a <dirent.h> style interface is exposed here if you need it. Some wrapper functions could be used to make <dosfs.h> emulate <dirent.h> more clostely. In the absence of a Propeller O/S, I'm not sure how far down the POSIX path it is worth venturing, but I supose you could pick a few of the more useful POSIX headers and just implement those.
However, unless there are any volunteers for this, I will probably just remove <dirent.h> from the next release.
Ross.
Hi Dave,
These functions map directly to DOSFS functions (i.e.. DFS_Opendir, DFS_GetNext) which are available in Catalina. I seem to recall reading somewehere that PropGCC also uses DOSFS, so the PropGCC code for this should also work with Catalina.
When I get time I may check this out. I agree it would be good if we all provided the same file system interface. On a related point - I have already had to modify DOSFS a couple of times to get ANSI compliance. How does PropGCC handle the functions that are missing from DOSFS? Do you have you own modified version of DOSFS? Seems silly to maintain two different versions of the same third-party library.
Ross.
Hi Dave,
It would probably be a good idea to check your version of DOSFS against Catalina's - there are some changes that never seem to have been officially released that fix some bugs.
Ross.
I then built my program with the following options:
I then loaded it using the following command:
Unfortunately, the program didn't even print its startup banner. I then tried a simple hello world type program that just contained a simple printf and nothing else and that didn't work either. What am I doing wrong?
I tried adding -n200 to my payload command line but that didn't help.
Hi David,
You certainly need to specify the same caching options when building the utilities as when building your program (I make the same mistake myself sometimes - I'll try and come up with a way that you don't need to remember to do this. Perhaps I should get Payload to check this during the load itself, and automatically choose the correct XMM.binary to use).
Another thing to check is that you actually have sufficient Hub RAM to allow the use of an 8k cache (which is what the CACHED option specifies). You are not specifying LARGE mode when compiling, so your Hub RAM will have to be able to hold not only the cache, but also all driver buffers, stack, heap and any data segments your program needs. You might want to start out specifying both CACHED_1K and LARGE, and then increasing the cache size in stages.
If you are confident you have sufficient Hub RAM, then the "no sync received" type error does indeed look like a loader problem - but this is odd because I've loaded many large programs on the C3 with the new loader. To make absolutely sure you are using the right version of XMM.binary, can you please manually copy this file from the utilities directory to your current working directory? Payload will always use that one in preference to anything else.
By the way, is this on a Mac or Linux? Another thing that can cause the "no sync received" is a simple timing problem. On Linux, I sometimes add -t 1000 to extend the read timeout, and also use nice on the payload command to elevate its priority - you may need to do the same on a Mac. For instance, try something like:
Ross.
I've uploaded Linux versions of Catalina 3.6 to SourceForge (see link in the first post in this thread) and also fixed a few minor issues in the beta version - anyone who downloaded the beta should delete it and download the new non-beta release.
A complete list of changes is given in the README.WhatsNew file attached to the first post in this thread.
Ross.