Catalina - ANSI C for the Propeller 1 & 2

currentc

@RossH

Thank you for the fast reply and solution.
And thank you for creating Catalina C.

Charles.

RossH

Catalina 6.5.3 has been released here.

This release contains only a few small enhancements and bug fixes. However, since one of those bugs affected some of the C library functions, a patch release would be unwieldy - doing a full release is simpler.

Here is the relevant extract from the README.TXT:

RELEASE 6.5.3

New Functionality
-----------------

1. The default behaviour of the Catalina Geany "Catalina Command Line" menu
   entry (on the Build menu) is to open the window in the current project
   directory instead of the user's home directory. Affects Windows only 
   (on Linux, Geany already did this).

2. When using fymodem, if no filename is specified to receive, the filename 
   in the initial received packet is used but not the path, which means the 
   received file will always end up in the current directory. This resolves 
   the Windows issue that arose when specifying a file name to send using 
   a path as well as a file name, since Windows paths and Catalyst paths 
   use different path separator characters (i.e. '\' vs '/' respectively).

Other Changes
-------------

1. The C interrupt library functions _clr_int_X() - (where X = 1,2,3) - did 
   not compile correctly because they used "iretX" instead of "retiX". 
   Affected the Propeller 2 only. Affected both Linux and Windows.

2. Fixed a bug in the dynamically loaded XMM Kernel which meant that SMALL
   mode programs may not have executed correctly if the kernel was loaded
   dynamically. Affected the Propeller 2 only. Affects both Windows and 
   Linux.

3. A spurious "drvl #57" debug instruction was left in the RTC clock plugin.
   Affected the Propeller 2 only. Affected both Windows and Linux.

4. On the Propeller 2, the XMM Kernel now has the floating point comparison 
   function internal to the kernel to improve performance. Affects the 
   Propeller 2 only. Affects both Windows and Linux.

5. On the Propeller 2, the XMM Kernel now uses XMM_ReadLong and XMM_WriteLong
   to read and write longs instead of XMM_ReadMult and XMM_WriteMult to
   improve performance. Affects the Propeller 2 only. Affects both
   Windows and Linux.

6. The Propeller 2 cache API now includes two new page functions for reading 
   and writing pages as longs rather than bytes, provided the buffers are 
   long aligned and the length of the buffers is a multiple of 4. These 
   new functions are called XMM_ReadLongPage and XMM_WriteLongPage. 
   This will potentially improve performance on future Propeller 2 platforms,
   but is already the case on current XMM API implementations (i.e. PSRAM on 
   the P2 EVAL and P2 EDGE boards). Affects the Propeller 2 only. Affects both 
   Windows and Linux.

RossH

Just a tweak, not even worth a patch release.

Attached are a couple of updated Lua scripts, which add -i options to the Catalyst freq and find commands to make them case insensitive. For example, you can now say:

find -i print *.bas
or
freq -i *.txt

Native implementations of all the basic Catalyst commands (i.e. ls, rm, mkdir, rmdir, cp, mv, cat etc) will continue to exist because they work on all platforms with or without XMM RAM, and on the Propeller 1 they are much faster than their Lua equivalents, but on the Propeller 2 Lua is fast enough to make it worthwhile exploiting Lua's ability to make it trivially easy to add new functionality. I intend to gradually add enhanced Lua equivalents for all the basic Catalyst commands (for example, a partial Lua equivalent to ls.bin already exists as list.lua). Such commands will also work on a Propeller 1 platform equipped with XMM RAM, but they will be much slower.

Ross.

currentc

@RossH

I just installed 6.5.3 and it looks like it overwrote my patched version of the "clr_intX.s" files with the old version that used "iretX".
Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
Please let me know what other information you might need.

Charles

RossH

@currentc said:
@RossH

I just installed 6.5.3 and it looks like it overwrote my patched version of the "clr_intX.s" files with the old version that used "iretX".
Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
Please let me know what other information you might need.

Charles

Odd. My reference installation works fine - it looks like I may have botched the packaging of release 6.5.3.

I'm out for the next few hours, but will fix it later today.

Ross.

RossH

@currentc said:
@RossH

Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
Charles

Ok. Had time to do a bit more investigation. Two things to note:

1. Interrupts are supported by the NATIVE, COMPACT and TINY memory models. But release 6.5.3 does not have the correct files in it for the COMPACT and TINY mode, only NATIVE mode. I can issue a patch release, but would prefer to issue a whole new release to replace 6.5.3.

2. Interrupts are not supported by the XMM memory models (i.e. SMALL or LARGE). However, I will at least make Catalina issue a compiler error if you attempt to compile interrupt code in an XMM program.

If you want to use interrupts in conjunction with a program that has to use XMM RAM (e.g. for size reasons) you must compile the interrupt processing components using one of the memory models that supports interrupts (e.g. NATIVE) and then use Catalina's multi-model support to run this in parallel with the XMM components. The XMM and non-XMM components can share plugins and Hub RAM, but will run on different cogs. There is no specific example of doing this with interrupts, but I can easily add one - it will be similar to the multi-threaded examples in the demos\multimodel folder - XMM does not support multi-threading either, so in that example the single-thread program run_dining_philosophers.c is compiled as an XMM program and it then runs the multi-threaded program dining_philosophers.c (compiled in this case as TINY or COMPACT).

I can get a fix out quickly since I already have the correct files - I just need to package them correctly But writing the XMM interrupt demo will take a little longer. Let me know how urgently you need a fix.

Ross.

currentc

@RossH said:

@currentc said:
@RossH

Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
Charles

Ok. Had time to do a bit more investigation. Two things to note:

1. Interrupts are supported by the NATIVE, COMPACT and TINY memory models. But release 6.5.3 does not have the correct files in it for the COMPACT and TINY mode, only NATIVE mode. I can issue a patch release, but would prefer to issue a whole new release to replace 6.5.3.

2. Interrupts are not supported by the XMM memory models (i.e. SMALL or LARGE). However, I will at least make Catalina issue a compiler error if you attempt to compile interrupt code in an XMM program.

If you want to use interrupts in conjunction with a program that has to use XMM RAM (e.g. for size reasons) you must compile the interrupt processing components using one of the memory models that supports interrupts (e.g. NATIVE) and then use Catalina's multi-model support to run this in parallel with the XMM components. The XMM and non-XMM components can share plugins and Hub RAM, but will run on different cogs. There is no specific example of doing this with interrupts, but I can easily add one - it will be similar to the multi-threaded examples in the demos\multimodel folder - XMM does not support multi-threading either, so in that example the single-thread program run_dining_philosophers.c is compiled as an XMM program and it then runs the multi-threaded program dining_philosophers.c (compiled in this case as TINY or COMPACT).

I can get a fix out quickly since I already have the correct files - I just need to package them correctly But writing the XMM interrupt demo will take a little longer. Let me know how urgently you need a fix.

Ross.

I don't currently need interrupts in XMM mode. I've been using NATIVE mode, but while troubleshooting a different problem, I decided to see if I could compile in TINY. When that failed, I tried the other modes to see what worked.

RossH

@currentc said:

I don't currently need interrupts in XMM mode. I've been using NATIVE mode, but while troubleshooting a different problem, I decided to see if I could compile in TINY. When that failed, I tried the other modes to see what worked.

Thanks. NATIVE mode should be fine. I'll fix TINY and COMPACT mode in the next release.

Ross.

RossH

Catalina 6.5.4 has been released here.

This is a full release since it includes updated libraries, but it has only a few small enhancements and bug fixes to the Propeller 2 interrupt and multi-model support.

Here is the relevant extract from the README.TXT:

RELEASE 6.5.4

New Functionality
-----------------

1. Catalina now issues an error message if interrupt code is included in a 
   program compiled in XMM (SMALL or LARGE) mode.

2. A new multi-model demo has been added for the Propeller 2 which shows
   how a primary program (which can be an LMM, CMM, NMM or XMM program) 
   can execute a secondary program (which can be an LMM, CMM or NMM program) 
   that uses interrupts. Also, the Makefile has been updated to build the
   XMM demos on Propeller 2 platforms that have XMM RAM.

Other Changes
-------------

1. The C interrupt library functions _clr_int_X() - (where X = 1,2,3) - did 
   not compile correctly for programs compiled in COMPACT or TINY mode. 
   Affected the Propeller 2 only. Affected both Linux and Windows.

2. The multi-model support for the Propeller 2 had an issue if the primary 
   program was an XMM LARGE program (XMM SMALL programs worked correctly).
   Affected the Propeller 2 only. Affected both Linux and Windows.

Just what everyone wanted for Christmas, I'm sure!

Ross.

RossH

Attached is an updated SD card plugin for Catalina release 6.5.4. You probably only need this if you have a Sandisk Extreme uSD card.

Here are the details:

This folder contains an updated version of Catalina's SD plugin for the
Propeller 2 (cogsd.t) released with 6.5.4, which has an issue with some uSD 
cards, such as Sandisk Extreme. 

It should work with other cards, but note that neither the version of cogsd.t 
issued with 6.5.4 nor this version work reliably with the only Sandisk Ultra 
uSD card I have access to, and I am yet to discover why.

You do not need to recompile Catalina to use the new plugin. Just recompile 
your C programs. 

To just TRY the new plugin, simply unzip it into the same directory as your 
C program - it will be used in preference to the one found in the Catalina 
installation.

To permanently replace the one in the Catalina installation, unzip this
folder into Catalina's target\p2 directory, over the existing one.

I will include this in the next full release.

RossH

Catalina 6.5.5 has been released here.

This is a full release since it includes updated libraries, but it has only a few small enhancements, the new SD card plugin, and a bug fix for the Propeller 2 interrupt support.

Here is the relevant extract from the README.TXT:

RELEASE 6.5.5

New Functionality
-----------------

1. An additional implementation of malloc has been added to the library which 
   always allocates from Hub RAM. It is intended to be used primarily in XMM 
   LARGE programs, where the normal malloc allocates from XMM RAM. In other 
   memory models, including XMM SMALL programs, the normal malloc allocates 
   from Hub RAM anyway, so this new hub version would not provide any benefit. 

   The following functions are defined in a new include file (hmalloc.h), 
   which mirror the usual malloc related function definitions (defined in 
   stdlib.h):

   void   *hub_calloc(size_t _nmemb, size_t _size);
   void   hub_free(void *_ptr);
   void   *hub_malloc(size_t _size);
   void   *hub_realloc(void *_ptr, size_t _size);

   To support the hub malloc functions, there are also new functions hbrk() 
   and _hbrk() which are analogous to the usual sbrk() and _sbrk() functions, 
   but which allocate from Hub RAM instead of XMM RAM.

   An example of using the new malloc is provided in "demos\hub_malloc". The
   program provided can be compiled to use either standard malloc or the new
   hub malloc. See the README.TXT file in that folder for more details.

   An XMM LARGE program can use both malloc and hub_malloc freely, but other
   programs should use only one or the other. Also, note that some library 
   functions (notably the stdio and posix thread functions) use malloc 
   internally, and so programs other than XMM LARGE programs should not 
   use the hub malloc functions unless the library is first recompiled to 
   ALSO use hub malloc - this can be done by defining the Catalina symbol 
   HUB_MALLOC when compiling the library. This may speed up XMM LARGE 
   programs that make very heavy use of stdio.

   Note that using the hub malloc functions reduces the amount of stack space
   (which is always in Hub RAM in every memory mode) available to the program.

   For an example of using HUB_MALLOC to compile the library, see the 
   build_all scripts provided in the folder "demos\catalyst\catalina". Using
   this option has been tested, but since it reduces the available Hub RAM 
   for ALL programs it is not enabled by default.

   Note that you can use the two types of allocated memory freely without 
   knowing what type of memory it is, but that memory allocated using the 
   normal malloc functions MUST be re-allocated or freed using realloc
   and free, and memory allocated using the hub malloc functions MUST be 
   reallocated or freed using hub_realloc and hub_free. 

2. The Catalyst time utility has been updated to allow the time to be set
   using local time (the previous versions required it to be set using UTC
   time, which can still be done provided the -u or -w flag is specified). 

   Note that to set time using local time, both time AND date must always
   be specified, since otherwise the program does not know whether or not
   to adjust the local time for daylight savings. 

   The following are acceptable ways to set the date and/or time:

   time -u 11:11:12 PM              -- set UTC time only (12 hour) 
   time -w 23:11:12                 -- set UTC time only (24 hour)
   time -u 01/01/2000               -- set UTC date only
   time 01/01/2000 11:11:12 PM      -- set both LOCAL date and time
   time 01/01/2000 23:11:12         -- set both LOCAL date and time

3. A new lua script is included with Catalyst called attrib.lua. This script
   allows the current text attributes (i.e. effects and color) to be specified
   on the Catalyst command line when using a serial HMI option and a terminal 
   emulator. 

   The syntax of the command is:

   attrib [-d] [ [effect ...] [ color ] [ on ] [ color ]

   Here are some examples:

   attrib yellow                     -- yellow fg
   attrib on blue                    -- blue bg
   attrib underscore                 -- set underscore effect only
   attrib blink blue                 -- set blink and blue fg
   attrib red on green               -- red fg on green bg
   attrib red green                  -- same as previous
   attrib reverse bright red on green -- green fg on bright red bg
   attrib normal                     -- reset effects and fg and bg colors 

   However, note that which text attributes are supported and what they will
   do depends on the terminal emulator in use, and not on this program. For 
   instance, Catalina's external VTxx emulators do not support italic, and 
   they interpret bright as meaning both bright and bold. Catalina's payload 
   internal terminal emulator does not support setting any attributes at all.

4. The Lua scripts find.lua, freq.lua and wild.lua are now in the folder
   demos/catalyst/core, with all the other Lua scripts used by Catalyst.
   The find.lua and freq.lua now both support a -i flag to specify that
   they should be case insensitive. For example:

   find -i print *.bas                -- find 'print', 'PRINT', 'Print' etc
   freq -i *.txt                      -- count word frequency ignoring case

5. The Comms program "paste" functionality has been improved (note that this
   change does not affect Catalina itself, only the Comms terminal emulator). 

   Previously, it was easy to paste text that would overflow either the 
   program's own paste buffer (which was only 256 characters) or else it
   would overflow the keyboard buffer in the recipient program. Now, the 
   size of the paste buffer is configurable, and after sending every group of 
   characters (default is 15, but this is also configurable), the program waits
   until the recipient stops sending characters back - however, the program 
   assumes that more than just the pasted characters will be sent by the 
   recipient - e.g. in the case of text editors such as "vi" that use DEC 
   escape sequences, the number of echoed characters may be much, much larger
   than the number of character sent, so the program cannot just check that 
   the character itself has been echoed, or wait for a certain number of
   characters - it must wait for some time after each character to see if it 
   has received the last one (if any) before sending more. This time is 
   also configurable. 

   To configure the paste functionality, three new command-line options have 
   been added to the Comms program:

     /PasteSize=nnn
     /PasteGroup=nnn
     /PasteDelay=nnn

   PasteSize is the maximum size of the paste buffer. Default is 2048.
   This represents the largest number of characters that can be pasted in
   each single paste operation.

   PasteGroup is the maximum number of characters sent in each group when
   processing the paste operation. The default is 15, to accommodate serial
   HMI options with small keyboard buffers (such as TTY). If the recipient 
   program has an even smaller keyboard buffer, this number can be reduced 
   to as low as 1, in which case the program will wait after each character
   sent.

   PasteDelay is the delay in milliseconds to wait to ensure the last 
   character has been received after sending each group. Default is 250. 
   At low baud rates, this number can be increased, but if the PasteGroup 
   size is reduced, it may be able to be reduced.

   The default values have been selected to perform well when using the Comms
   program to talk to the Catalyst "vi" text editor on a Propeller 2 at 230400
   baud, using either the TTY or SIMPLE serial HMI options. They may need to 
   be tweaked in other circumstances (e.g. when using a Propeller 1 at 115200
   baud, it may be necessary to both reduce PasteGroup to 8 and increase 
   PasteDelay to 500).

Other Changes
-------------

1. The Propeller 2 version of the sd card plugin (cogsd.t) did not work with 
   Sandisk SD cards which do not implement CMD1 correctly, such as some newer
   Sandisk Extreme cards. This has been fixed. The version of the SD plugin 
   in this release should work with all SD cards. 

   However, note that for Sandisk Ultra cards it is recommended not to boot 
   the Propeller 2 from the SD card itself - instead, boot the Propeller 2 
   from FLASH (e.g. load Catalyst into FLASH and boot it from there). Then the 
   SD card access works reliably even on these SD cards. 

   Affect both Windows and Linux. Affects the Propeller 2 only.

2. The _set_int_X() functions (where X = 1, 2 or 3) did not take into account
   that EACH COG has independent interrupts, so if the same functions were
   called from multiple cogs they were overwriting the interrupt configuration
   data, so only the last such interrupt would work. This has been fixed by
   allocating enough space to store the interrupt configuration for each cog
   separately.

   Affect both Windows and Linux. Affects the Propeller 2 only.

Oops - I just noticed my README still says it is ok to use Sandisk Ultra cards on the P2 if you boot from Flash rather than from the SD. This is now known to be not true - Sandisk Ultra cards should be avoided altogether.

Another documentation Oops - I just noticed the README.TXT in the demos\hub_malloc folder contains the following sentence:

The first version uses the normal stdlib malloc functions (which for an XMM
LARGE program will allocate memory from XMM RAM) whereas the second one uses
the new hub malloc functions (which always allocate memory from XMM RAM).

What it should say is:

The first version uses the normal stdlib malloc functions (which for an XMM
LARGE program will allocate memory from XMM RAM) whereas the second one uses
the new hub malloc functions (which always allocate memory from HUB RAM).

The release is ok in both cases, it is just my proof-reading that is faulty

RossH

Just finished a first round of testing of an alloca() function for Catalina. I have tested it in all the memory models on the P2, but am yet to test it on the P1. This will take a little longer because it requires a small kernel change, and finding even one extra long in the P1 kernel is difficult.

Note that alloca is not part of the ANSI standard, but it is available in most C compilers, and is described here.

The last release of Catalina (6.5.5) added a hub-specific version of malloc called hub_malloc, but both of these are large and slow compared to alloca, which is tiny in code size (just a few instructions) and consequently very fast.

In many cases alloca suits the Propeller better because of the Propeller's unique memory architecture - but the other memory management options will of course remain available.

The main thing you have to be careful about with alloca is passing around pointers to memory because that memory is local to the stack of the function that allocated it, and such pointers will no longer be valid (i.e. the memory will be re-used) once the function exits.

You can use alloca in any memory model. In an XMM LARGE program, you can use all the memory options provided in the same program:

• malloc and free to allocate from XMM RAM. This memory remains valid for the lifetime of the program
• hub_malloc and hub_free to allocate from Hub RAM. This memory remains valid for the lifetime of the program
• alloca to allocate from the local function stack (which is always in Hub RAM). A corresponding free function is not required because that happens automatically when the function exits.

This is not the case in other memory models. In those, you can use alloca, but only ONE of malloc or hub_malloc. This is because in the other memory models they will both try to allocate memory from the same memory range and will conflict (and so there is no reason to do this anyway!).

Ross.

Electrodude

Since, as far as I understand, the hardest part of implementing C's variable-length arrays is that it internally needs something like alloca, and since VLAs are part of the C standard, unlike alloca, would you consider implementing VLAs as well?

RossH

@Electrodude said:
Since, as far as I understand, the hardest part of implementing C's variable-length arrays is that it internally needs something like alloca, and since VLAs are part of the C standard, unlike alloca, would you consider implementing VLAs as well?

Yes, it is true that they are similar internally. However, Catalina will probably never support VLAs. VLAs were an blunder in the history of C. They were introduced in one C standard (C99 from memory) and then dumped again (i.e. made optional) in a later standard (C11 from memory) mainly because some computer architectures cannot implement them efficiently. I believe C23 changed them yet again to try and address this. I don't actually know what their current state is, but I do know that if you need to write portable C, you stay away from both VLAs and alloca and just stick to malloc/free.

But I had a particular need to fill for Catalina XMM LARGE programs which was that there was no easy way to specifically allocate Hub RAM directly from C (you had to do it from PASM). An issue with C on unusual architectures like the Propeller is that C doesn't naturally support different types of memory. Various compilers have added various ways of addressing this but they are all non-portable (and some of them are also really ugly!).

I experimented with two methods of addressing this need - hub_malloc and alloca. They both work but they have different advantages and disadvantages, so I ended up implementing both.

Using hub_malloc is portable in that you can just redefine the hub_malloc routines to use the malloc ones.

Using alloca is not portable - but it should work on nearly all C compilers. And it is quite an elegant solution.

RossH

The new alloca function is now working on the P1 (all memory models) as well as the P2.

Here is a simple example program that demonstrates alloca():

/******************************************************************************
 *     A simple program to test the new 'alloca()' built-in function.         *
 *                                                                            *
 * Works in all memory models, on the P1 and P2. Compile this program with a  *
 * command like:                                                              *
 *                                                                            *
 *  catalina test_alloca.c -lc                                                *
 *  catalina test_alloca.c -lci -C COMPACT                                    *
 *  catalina test_alloca.c -lcix -p2                                          *
 *  catalina test_alloca.c -lcx -p2 -C P2_EDGE -C LARGE                       *
 *  (etc)                                                                     *
 *                                                                            *
 ******************************************************************************/

#include <stdio.h>
#include <alloca.h>

// this handy macro returns the current frame pointer in any memory model
// on the P1 or P2 ...
#define FP PASM("#ifdef COMPACT\n word I16B_PASM\n#endif\n alignl\n mov r0, FP\n")

// this handy macro returns the current stack pointer in any memory model
// on the P1 or P2 ...
#define SP PASM("#ifdef COMPACT\n word I16B_PASM\n#endif\n alignl\n mov r0, SP\n")

// this function just uses alloca() twice, and then returns.
void do_alloca(int n) {
  void *x;
  void *y;

  printf("in function do_alloc... \n");
  printf("FP is %08X\n", FP);
  printf("SP is %08X\n", SP);
  printf("allocating %d bytes for x\n", n);
  x = alloca(n);
  printf("x is %08X\n", (int)x);
  printf("SP is %08X\n", SP);
  printf("allocating %d bytes for y\n", n);
  y = alloca(n);
  printf("y is %08X\n", (int)y);
  printf("SP is %08X\n", SP);
  printf("... do_alloc done \n");
}

// the main function calls the do_alloca() function, as well as doing some 
// allocation of its own before and after.
void main() {
  void *a;
  void *b;
  int n = 511;

  printf("in main ...\n");
  printf("FP is %08X\n", FP);
  printf("SP is %08X\n", SP);
  printf("allocating %d bytes for a\n", n);
  a = alloca(n);
  printf("a is %08X\n", (int)a);
  do_alloca(99);
  printf("in main again ...\n");
  printf("SP is %08X\n", SP);
  printf("allocating %d bytes for b\n", n);
  b = alloca(n);
  printf("b is %08X\n", (int)b);
  printf("SP is %08X\n", SP);
  printf("...main done\n");
  while(1);
}

And here is the result when that program is compiled for a P1 in LARGE mode:

in main ...
FP is 000074B8
SP is 000074AC
allocating 511 bytes for a
a is 000072AC
in function do_alloc...
FP is 000072A0
SP is 00007288
allocating 99 bytes for x
x is 00007224
SP is 00007224
allocating 99 bytes for y
y is 000071C0
SP is 000071C0
... do_alloc done
in main again ...
SP is 000072AC
allocating 511 bytes for b
b is 000070AC
SP is 000070AC
...main done

The main thing to note here is that the memory allocated by alloca is in Hub RAM, even though the program was compiled as an XMM LARGE program, which means the heap (and hence memory allocated by malloc etc) is in XMM RAM and not Hub RAM.

Catalina now passes all my current test programs, but because implementing alloca required a small kernel change, I need to spend more time adding some new tests to my test suite. But I expect to release in the next few days.

Ross.

RossH

Catalina 7.0 has been released here.

This is a full release, but it has only one significant enhancement, which is support for the C alloca function.

Please note that kernel changes in this release means that code compiled with it is not compatible with code compiled by any previous release. Which just means you must recompile from the C sources any object files or libraries you may use. Binary files compiled using prior releases are fine.

Here is the relevant extract from the README.TXT:

RELEASE 7.0

New Functionality
-----------------

1. Catalina now supports the alloca() function. This function is supported
   in all memory models, and on both the Propeller 1 and Propeller 2. Note
   that alloca is not part of the ANSI C standard, but it is commonly
   available in C compilers.

   For an overview of alloca, see https://linux.die.net/man/3/alloca

   The main advantage of alloca is that it is a very efficient alternative 
   to malloc. It is particularly suited to C on the Propeller, where the heap 
   and stack can use different types of RAM. The C language does not cater 
   very well for architectures that can have different types of RAM. 

   Note that there are limitations of using alloca, which are described
   in the link above - the main one is that (unlike memory allocated via
   malloc) memory allocated via alloca must not be referenced once the 
   function in which it was allocated returns to its caller. However, it
   is worth remembering that such memory allocated in the C main function 
   will remain valid for the duration of the program. But this also 
   illustrates another limitation of alloca - which is that there is no way 
   to DE-allocate such memory once allocated other than by exiting the 
   function in which it is allocated.

   To see a situation in which alloca is particularly useful on the Propeller, 
   consider an XMM LARGE program. In these programs the stack is in Hub RAM, 
   but the heap is in XMM RAM, and the malloc functions always operate only
   on the heap. Prior to having alloca available, there was no simple way of 
   allocating an arbitrary amount of Hub RAM. While Catalina release 6.5.5 
   added hub_malloc functions specifically to do this, these functions (like
   malloc) are large in code size and also very slow when compared to alloca.

   For an example of using alloca, see the demos\alloca folder.

   NOTE: the reason for releasing this version of Catalina as 7.0, rather
   than 6.x is that implementing alloca efficiently required a minor kernel 
   change, which means that code compiled with Catalina 7.x MUST NOT BE 
   COMBINED with code compiled by Catalina 6.x or earlier. For instance, 
   object files or libraries compiled with Catalina 6.x must be recompiled 
   before using them with Catalina 7.x.

Other Changes
-------------

1. The Posix threads functions were returning the correct error values, but 
   not setting the system errno variable, so programs that used errno rather
   than the function return value, or used the perror function to print the 
   error, may not have detected or printed the error correctly. Affects both 
   Windows and Linux. Affects the Propeller 1 and Propeller 2.

2. The hub_malloc functions introduced in Catalina 6.5.5 did not work on the
   Propeller 1. In this release they also now work on the Propeller 1 for
   programs compiled in XMM LARGE mode (which is the only mode in which they
   offer any benefit over the normal malloc functions). Affects both Windows 
   and Linux. Affect the Propeller 1 only.

3. Minor updates to the Catalyst build scripts to prevent building Catalyst
   programs that are not supported on the Propeller 1, such as the real-time
   clock programs. Affects both Windows and Linux. Affects the Propeller 1 
   only.

4. Various changes in this release have had minor impacts on the code size, 
   execution speed and stack requirements for C code. For example, the default
   stack size allocated to a posix thread has been increased from 100 longs 
   to 120 longs, and the default stack size used by the spinc utility has been 
   increased from 80 bytes (20 longs) to 100 bytes (25 longs). If the stack 
   size is manually specified it may need to be increased slightly in a 
   similar manner. This is true for stack space allocated to any C code 
   executed using Catalina's multi-processing support (i.e. multi-threading, 
   multi-cog or multi-model support). If a program that uses multi-processing 
   worked under a previous release of Catalina but does not work correctly 
   in this release, try a small increase in the size of any stacks manually 
   allocated. Affects both Windows and Linux. Affects the Propeller 1 and 
   Propeller 2.

Apologies for this release taking longer than anticipated. Catalina is now so complex and has so much unique functionality packed in that I had underestimated the time required to make even a small kernel change. Testing all the combinations of all the functionality - something I had not had to do for a long time because the kernels had been very stable - can take days. And then double that because almost everything has to be tested on both the Propeller 1 and the Propeller 2. The annoying part was that I really didn't need to change the kernels - it just made the code slightly more efficient to do it that way. I certainly won't be making that mistake again anytime soon!

Ross.

RossH

The file README_P2.TXT in the Catalina distribution contains some spurious characters where double quotes should have appeared. See the attached file for a corrected version.

RossH

Just a quick status update ...

The next version of Catalina/Catalyst will add the ability for self-hosted Catalina to build XMM (SMALL and LARGE) programs on a Propeller 2 equipped with an SD Card and suitable XMM RAM (such as the P2-EC32MB).

Currently, self-hosted Catalina can only build NATIVE, COMPACT or TINY programs - it cannot build XMM programs even though it requires XMM RAM to run. There was no technical reason for this omission - it was only ever due to laziness.

Interestingly, building XMM programs can actually take LESS time than building non-XMM programs, because I have also added a new option to allow you to pre-build XMM targets (which contains the run-time environment but no program code) and then re-use them in multiple program compilations. This makes sense in a self-hosted environment where you will typically only ever compile programs for the same target - i.e. the one you are compiling on. I am currently looking at doing the same for ALL programs, which would significantly reduce ALL the self-hosted compilation times. This will happen eventually, but it may or may not make it into the next release.

Ross.

RossH

Ok! It has (as usual) taken a lot more work than I expected, but I now have some actual compile times for a non-trivial C program (500 lines) using Catalina's new Quick Build option on the self-hosted version of Catalina:

NATIVE QUICK BUILD  = 12 mins
NATIVE NORMAL BUILD = 14 mins
XMM QUICK BUILD     = 12 mins
XMM NORMAL BUILD    = 27 mins

So ... not exactly going to set the world on fire - but the interesting points are (1) that Quick Build speeds everything up, and (2) XMM programs now take no longer to compile than NATIVE programs.

it's another small step to making self-hosted development on the Propeller 2 a practical reality.

Ross.

Christof Eb.

@RossH said:

it's another small step to making self-hosted development on the Propeller 2 a practical reality.

Ross.

Just a sidenote: For my easter egg thingy I have now practically switched over to use my local editor for Forth. The source code to control the motors, do some VGA graphics and generate the ornamental patterns is 620 lines and is compiled within 3 seconds, thanks to the simplicity of a Forth compiler and to Peters optimisations of TAQOZ Forth for P2. Load source code into editor and save to SD takes about 8 additional seconds. Overall the convenience of the "IDE" is good enough, that I was not tempted to switch back to using Notepad++ as editor. So I only transfer the source to PC for backup now. The editor does have some features which make it actually better in some aspects than Notepad++ for this specific task making up for some disadvantages like no mouse.

Is there a chance to do essential parts of the compilation in parallel to editing the source code? As far as I understand this was a crucial element of the success of Turbo Pascal. I also wonder, if a reduced version of the compiler would make sense. The compiler of "SWIEROS" seems to be very much faster than your full blown system? It would need external RAM though. I think, that overall the Edit-Compile-Test cycle has to be more convenient for the programmer when done locally, that you will really switch over to self hosted development.
Christof

RossH

@"Christof Eb." said:

@RossH said:

it's another small step to making self-hosted development on the Propeller 2 a practical reality.

Ross.

Just a sidenote: For my easter egg thingy I have now practically switched over to use my local editor for Forth. The source code to control the motors, do some VGA graphics and generate the ornamental patterns is 620 lines and is compiled within 3 seconds, thanks to the simplicity of a Forth compiler and to Peters optimisations of TAQOZ Forth for P2. Load source code into editor and save to SD takes about 8 additional seconds. Overall the convenience of the "IDE" is good enough, that I was not tempted to switch back to using Notepad++ as editor. So I only transfer the source to PC for backup now. The editor does have some features which make it actually better in some aspects than Notepad++ for this specific task making up for some disadvantages like no mouse.

Is there a chance to do essential parts of the compilation in parallel to editing the source code? As far as I understand this was a crucial element of the success of Turbo Pascal. I also wonder, if a reduced version of the compiler would make sense. The compiler of "SWIEROS" seems to be very much faster than your full blown system? It would need external RAM though. I think, that overall the Edit-Compile-Test cycle has to be more convenient for the programmer when done locally, that you will really switch over to self hosted development.
Christof

Fair enough. I probably should have said "self-hosted C development". Forth does my head in

A reduced version of C is not really an option - I need ANSI C.

Compiling in parallel with editing would be possible, but not with Catalina - it would require the compiler and IDE to be written together from the ground up, as I understand was the case with Turbo Pascal. A nice project for someone - but not me.

Also, Pascal is not C - Pascal is a simpler language to compile, but even so Turbo Pascal had significant limits on the programs it could compile. There was a Turbo C that came along later, but it was both slower and needed more processing power and memory than Turbo Pascal, and it also had limitations - I routinely use Catalina to compile C programs for the Propeller that Turbo C would not have been able to compile.

There are two main bottlenecks in Catalina's compilation process - one is the C preprocessor, and the other is the PASM assembler. Both were designed with the power of a micro processor in mind, not a micro controller. The compilation process itself - i.e. the stuff between these two bottlenecks - is quite reasonable. There is not much more I can do about the assembler except hope that someone eventually writes a faster one I can use - but I will look at replacing the preprocessor (mccp looks like a good option - I will run some timing tests to see if it is any faster than the one Catalina currently uses ).

There is scope for further simplifying the run-time environment - Catalina was designed as a cross compiler (which again Turbo Pascal and Turbo C were not) but in the self-hosted version you only need to support a single target. I have partly addressed this in the forthcoming release by adding a Quick Build option that means Catalina does not need to recompile the run-time environment on every compile, but more is possible. I am gradually redesigning the internals of Catalina to make this easier to do, but Catalina has so much functionality and so many options now that this is a slow process. And it is also not a core requirement for Catalina - I am not entirely convinced self-hosted development is necessary or will ever get much real-world use - I added it mainly because it showcases how functional Catalina is. And also, a compiler written in the language it compiles that can't compile itself would not really be much of a compiler, would it?

So, as I probably should have said - this is another small step to making self-hosted C development on the Propeller 2 a practical reality. But I certainly won't claim it is there yet!

Ross.

ersmith

@RossH said:

A reduced version of C is not really an option - I need ANSI C.

Someone should take a stab at porting the Tiny C Compiler to the P2. It might be able to fit in HUB RAM, and it supports C89 C (and I think is now up to C99 plus some GCC extensions). It used to be able to compile the Linux kernel, so it is pretty complete.

(The predecessor of Tiny C was a 2048 byte compiler for a subset of C that was able to compile itself, and won the 2002 Obfuscated C contest. Fabrice Bellard is an amazing programmer!)

RossH

@ersmith said:

@RossH said:

A reduced version of C is not really an option - I need ANSI C.

Someone should take a stab at porting the Tiny C Compiler to the P2. It might be able to fit in HUB RAM, and it supports C89 C (and I think is now up to C99 plus some GCC extensions). It used to be able to compile the Linux kernel, so it is pretty complete.

I looked at Tiny C a while ago. At the time (this would have been back in P1 days) it was not suitable. LCC was a better choice because LCC was designed to be a portable cross-compiler, which is what was needed. Tiny C is not a cross-compiler and was never intended to be portable to other architectures - it is heavily tied to the x86 architecture (like both Turbo Pascal and OTCC, which is the obfuscated Tiny C Compiler you mentioned) - so more difficult to port than LCC. And since self-hosted C development was never a realistic prospect on the P1, it would have been a lot of extra work for no extra benefit.

On the P2 it might be possible to port Tiny C, but the results would probably be disappointing - remember it was developed when Pentium PCs were already available, so while it might be fast on a 2.4Ghz PC with megabytes of fast RAM (which is what it was tested on) it would be much, much slower on a P2. The quickest way to port it would probably be to develop an X86 emulator for the P2. Would the end result be faster than Catalina? Maybe.

Again, a nice project for someone - but not me!

Ross.

RossH

Catalina 7.1 has been released here.

This is a full release. It has only one significant enhancement - support for building XMM programs when using the self-hosted version of Catalina (which runs under Catalyst on the Propeller 2). It also fixes an issue with spp - the stand-alone Spin language preprocessor.

Here is the relevant extract from the README.TXT:

RELEASE 7.1

New Functionality
-----------------

1. The Catalyst (i.e. self-hosted) version of Catalina now supports compiling
   XMM SMALL and XMM LARGE programs on the Propeller 2. Just add -C SMALL or
   -C LARGE to the catalina command, or add the symbol SMALL or LARGE to the
   CATALINA_DEFINE environment variable. Note that XMM compiles take longer
   than NATIVE, COMPACT or TINY compiles, so it is recommended that Quick 
   Build (see point 2, below) be used when possible. For example, to compile
   the othello.c demo program on the Propeller 2 in LARGE mode, you could
   use a Catalyst command such as:

      catalina -v othello.c -lci -C LARGE

2. Add support for Quick Build, which means in cases where the target is built
   separately to the program (i.e. XMM SMALL and LARGE memory models) then if 
   a target file of the correct name already exists, it is used instead of 
   building it. Quick Build is only supported on the Propeller 2.

   For LMM, CMM or NMM programs, enabling Quick Build changes the compilation
   process to build a separate target and program file instead of doing the 
   usual monolithic compilation. This can speed up the compilation process, 
   but it makes such binaries 64 kb larger than normal. It is therefore 
   mainly recommended on the self-hosted version of Catalina.

   Care needs to be taken that any existing target file is appropriate for
   the current compilation. If in doubt, simply do not enable Quick Build 
   and Catalina will not use any existing target files.

   Quick Build is enabled by adding the command line option -q or defining 
   the Catalina symbol QUICKBUILD. Enabling Quick Build also means the target 
   file is left after the current compilation completes, rather than being 
   deleted. Note that a target file may also exist because the -u (untidy) 
   option was used in the previous compile.

   Things that affect the target file is anything other than the compiled
   C program code itself (plus any C library code that code uses, except as 
   noted below). This includes:

   - the platform selected (e.g. via -C C3, -C P2_EDGE etc)
   - the plugins selected (e.g. via -C CLOCK, -C RTC, -C VGA, -C TTY etc)
   - the clock selected (e.g. via -f, -e and -E, or -C MHZ_200 etc)
   - the memory model selected (via -x or -C TINY, -C NATIVE, 
     -C COMPACT, -C SMALL or -C LARGE) 
   - the floating point option selected (via -lm, -lma, -lmb or -lmc)
   - whether NO_PLUGINS, NO_ARGS or NO_ENV is specified
   - whether multi-threading is selected (via -lthreads)
   - whether an SD Card plugin is selected (via -lcx, -lcix or -C SD)
   - whether debugging is selected (via -g or -g3)
   - using custom memory sizes and/or addresses (via -M, -P or -R)

   If any of these options need to change, do not use Quick Build. The
   results will be unpredictable.

3. The interpretation of the -v and -d options in catalina, catbind and bcc
   has been made more consistent. These options are now completely disjoint, 
   and now neither one implies the other, whereas previously -d implied -v. 
   The types of messages enabled by these options is now as follows:

   -v  enables messages that indicate WHAT the compiler is doing.

   -d  enables messages that indicate HOW the compiler is doing it, or 
       that show intermediate results which may assist in diagnosing 
       what happened when something goes wrong.

   To see all the messages that were previously output by -d, use BOTH 
   -d and -v. 

   Using -v -v does not now display any additional messages, but there are 
   still cases (e.g. in bcc and binbuild) where using multiple -d options 
   enables more detailed diagnostic output.

Other Changes
-------------

1. The Spin Pre-Processor (spp) was also processing C style comments,so it 
   was treating the Spin '//' operator as if it was introducing a comment 
   and truncating the rest of the line. Did not affect the use of spp by
   Catalina (which never generated this operator), but may have affected
   Spin/PASM programs if used stand-alone, Affected Windows, Linux and 
   Catalyst.

2. Minor documentation updates concerning specifying the memory layout using
   the -x option, and additional documentation of the Propeller 1 -x10 option,
   which means use the COMPACT memory model and kernel, and the SDCARD loader.
   Affected both the Propeller 1 and Propeller 2 on Windows or Linux.

3. The file README_P2.TXT in the Catalina directory contains some spurious 
   characters where double quotes should have appeared.
   Affected Windows and Linux.

4. In the self-hosted version of Catalina, the -B command line switch (for
   baud rate) was not resulting in the correct C symbol definition. Affected
   The Propeller 2 on Catalyst only.

5. The multicog 'dynamic_kernel.c' has been updated to use pin 38 instead of
   pin 0 when built for the P2_EDGE platform. Affected the Propeller 2 only.

6. Tidied up the structure of the Propeller 2 target files, to eliminate
   unnecessary duplication. The plugin support code is now in one file
   (plugsup.inc) and the plugins themselves are included in another file
   (plugins.inc). Affected the Propeller 2 only.

7. The Catalina binder (catbind) now uses external utilities for the binary 
   build and statistics commands (see binbuild.c and binstat.c).

Here are some actual C compile times which show the benefits of the new Quick Build option, which is most pronounced when building XMM programs:

500 lines of C ...

NATIVE QUICK BUILD  = 12 mins
NATIVE NORMAL BUILD = 15 mins
XMM QUICK BUILD     = 12 mins
XMM NORMAL BUILD    = 27 mins

5000 lines of C ...

NATIVE QUICK BUILD  = 122 mins
NATIVE NORMAL BUILD = 126 mins
XMM QUICK BUILD     = 121 min
XMM NORMAL BUILD    = 152 min

So enabling Quick Build can improve compile times for all programs slightly - but most significantly it makes compiling XMM programs (i.e. SMALL or LARGE programs) take the same time as compiling NATIVE programs.

Ross.

RossH

Ha! I was just about to add a new Catalyst feature to allow you to permanently set the screen colours vi uses, when I discovered vi already has this ability - you just use the EXINIT environment variable (Propeller 2 only). Note that you need to be using a suitably capable VT100 terminal emulator, such as Catalina's comms program (payload's internal terminal emulator doesn't support colours).

For example:

set EXINIT="set colour=2|set statuscolour=13"
vi catalina.txt

You include multiple command in EXINIT by separating them with |

Here are what the numbers mean:

0 - black
1 - red
2 - green
3 - yellow
4 - blue
5 - magenta
6 - cyan
7 - white

Add 10 to these numbers for bright colours. Note that these are all foreground colours, and that bright black (10) is grey. Ordinary black (0) is only useful if you have set another colour as the background colour via the terminal emulator (you cannot set background colours in vi).

Another thing worth noting when using vi with the comms terminal emulator - vi works best if you unset the Screen and View Locked option on the Options->Advanced menu. Otherwise if you scroll the window while using vi, you are likely to end up with a very confused looking screen (but fixable via Control-L). The next release of Catalina will have this option disabled by default.

Ross.

RossH

I found a silly bug in Dumbo Basic's square root function (SQR). While testing the fix, I also found a couple of bugs in some demo programs (not mine - they seem to have been in the original source code of these programs).

Not really worth a release, but I hate having buggy versions out there, so attached is a patch for Catalina 7.1. Apply the patch and then recompile Catalyst from source.

Here is the relevant extract from the README.TXT

RELEASE 7.1.1

New Functionality
-----------------
1. The startrek.bas program has been updated to better use a VT100 terminal,
   and also to randomize the game on startup, based on how long the user 
   takes to respond to an initial prompt to start the game.

Other Changes.
--------------

1. Dumbo Basic had a bug in the square root (SQR) function - it would throw
   an error if the argument to the SQR function was zero (which is a valid
   argument). Affected both the Propeller 1 and Propeller 2 on Windows or 
   Linux.

2. The startrek.bas BASIC program (startrek.bas), and also the C version of
   the same program (startrek.c) contain a bug which appears to have been 
   inherited from the original basic source code and which is not compatible 
   with GW Basic (and therefore not compatible with Dumbo Basic). Affected 
   both the Propeller 1 and Propeller 2 on Windows or Linux.

Ross.

RossH

Catalina 7.1.2 has been released here.

Note that this is not a full release - it is a patch release that has to be applied over an existing installation of Catalina 7.1 or 7.1.1.

It contains a new version of the Comms program (for Windows only), and some Dumbo Basic improvements and bug fixes (for Windows, Linux or Catalyst).

While Dumbo Basic is perfectly usable on a PC or a Propeller 2 (it is supported on a Propeller 1 but is quite slow) there are many better implementations of BASIC available, so it is primarily a novelty Catalina demo. But it is quite an interesting implementation of "classic" BASIC (if you are into that kind of thing) and it had not received much attention recently (e.g. it had not been updated to include XMM support for the Propeller 2) so I thought it worth a refresh.

But what Dumbo Basic has mostly turned out to be is an exercise in discovering what a truly terrible language "classic" BASIC was - very poorly defined with features badly "bolted on" to what was originally a perfectly simple language, with the result that it became very difficult to parse and ended up with many incompatible variants, and the resulting programs were typically very difficult to understand and to debug because they had to resort to clever "tricks" to make them work at all. I am constantly amazed at how many bugs exist in many classic BASIC programs - I have had to track many of them down just to check whether they were actually bugs in the original BASIC programs, or were bugs in Dumbo Basic. So far, we are about even!

Here is the relevant extract from the README.TXT:

RELEASE 7.1.2

New Functionality
-----------------

1, Catalina's VT100 terminal emulator (comms.exe) now accepts setting the 
   Terminal Emulator LockScreenAndView option from the command line, using 
   the option:

     /[No]LockScreen

   Also, this option is now disabled by default. Previously, it was enabled 
   by default and had to be disabled via the Options->Advanced menu.  

2. Dumbo Basic's assembly language interface has been updated to support 
   the Propeller 2 in XMM SMALL and LARGE mode, and add better support for
   COMPACT mode. Also, a better method of compiling PASM programs to be
   included in Basic programs has been added (see example.pasm for details). 
   Also, specific examples to demonstrate using NATIVE, COMPACT and LARGE 
   modes on the Propeller 2 have been added (see ex_call1.bas, ex_call2.bas 
   and ex_call3.bas) and LARGE mode on the Propeller 1 (see ex_call4.bas).

3. Dumbo Basic's USING clause (used in PRINT, PRINT # and LPRINT statements)
   now matches GW Basic much more closely. The main difference remaining is 
   that Dumbo Basic always prints a '-' sign for negative numbers, whereas 
   GW Basic does not print the '-' sign unless a '+' appears in the USING 
   clause, and does not print a leading sign when a '$' sign is specified. 
   Catalina's approach is much more useful and less error prone, but the 
   option to exactly duplicate GW Basic functionality may be added in a 
   later release.

4. Two new basic demo programs have been added - poker.bas and blackjck.bas.
   These have been modified from the original sources to correct various 
   errors in the original programs, and should run on any Propeller 1 or 2
   platform that supports Dumbo Basic.

5. Various improvements in the Dumbo Basic example programs. The originals
   were often straight out of the GW Basic manual, but were not particularly 
   user friendly. Also, the example programs (and data files) intended only
   to demonstrate specific Basic statements are no longer included in the 
   Catalyst image. Only complete Basic demo programs (such as eliza.bas 
   and startrek.bas) are now included. The others can be manually copied to
   the SD card if required. Note also that executing Basic programs on the
   Propeller 1 requires XMM RAM, and the C3 may not have enough to run the
   larger demos (however, the C3 CAN run eliza.bas or the new poker.bas and
   blackjck.bas - albeit slowly, due to the unique implementation of XMM RAM 
   on the C3!).

Other Changes.
--------------

1. The Catalina Reference Manual for the Propeller 2 has been updated to 
   include a description of the NMM Kernel. Affected the Propeller 2 only.

2. Dumbo Basic's PUT statement was not correctly extending the file when a 
   record was PUT that was beyond the current end of the file. Affected both 
   the Propeller 1 and Propeller 2 on Catalyst. This was due to a limitation 
   of DOSFS and while it has been fixed in Dumbo Basic, it may affect other 
   programs, so a note has been added to the Catalin Reference manuals in
   the section on File System support.

3. Dumbo Basic's OPEN statement was not using the correct file mode for "R" 
   or "RANDOM" files. One consequence of this was that the file would not be
   created if it did not already exist. Affected both the Propeller 1 and 
   Propeller 2 on Catalyst, Windows or Linux.

4. Dumbo Basic's CALL statement was not working correctly - an attempt
   to use it would result in a "Bad subscript" error. Affected both the 
   Propeller 1 and Propeller 2 on Catalyst. 

5. Dumbo Basic was not allowing a line number to follow a THEN or ELSE
   clause, which is permitted in GW Basic. It would only allow a line
   number after a GOTO clause. Affected both the Propeller 1 and 
   Propeller 2 on Catalyst, Windows or Linux.

6. Dumbo Basic was failing to correctly parse some complex IF statements 
   that included multiple statements on the same line separated by colons,
   or when IF statements were nested. Affected both the Propeller 1 and 
   Propeller 2 on Catalyst, Windows or Linux.

7. Dumbo Basic now correctly detects if there are extra tokens on a Basic
   line when it is expecting an end of line. Previously, it would either
   ignore such tokens, or possibly get into an infinite loop attempting
   to process them. Now it correctly reports "Unexpected character follows 
   statement". Affected both the Propeller 1 and Propeller 2 on Catalyst,
   Windows or Linux.

8. Dumbo Basic's token parser was not recognizing the VAL keyword. Affected 
   both the Propeller 1 and Propeller 2 on Catalyst, Windows or Linux.

RossH

Catalina 7.2 has been released here.

The main purpose of this release is to consolidate all the recent changes to Dumbo Basic, fix a few bugs, and also improve the compile times of the self-hosted version of Catalina.

All the self-hosted compile times have been reduced, but the headline is that the minimum self-hosted compile time for a "Hello, World!" program is now down to 5 minutes. Dumbo Basic (which is 12,000 lines of C code) can also now be compiled on a Propeller 2 - but this still takes 2.5 hours!

Here is the relevant portion of the README.TXT:

RELEASE 7.2

New Functionality
-----------------

1. The sources of Dumbo Basic are now included as a demo C program for
   Catalyst because it can now be compiled by the Catalyst version of 
   Catalina. To support this, some file names had to be changed to make 
   them DOS 8.3 compatible:

      dumbo_basic.c   -> dbasic.c
      tokenizer.c     -> tokens.c
      tokenizer.pl    -> tokens.pl (not required to compile Dumbo Basic)

   Note that Dumbo basic is around 12,000 lines of C code, and therefore 
   takes a long time to compile using the Catalyst version of Catalina. 
   For instance, the Catalyst command:

      catalina -v dbasic.c basic.c token.c -lcx -lm

   takes around 2 hours and 30 minutes to complete!   

2. The Catalyst version of the Propeller assembler (p2asm) has had its 
   capacity increased to 20,000 symbols (from 5,000). This allows the self-
   hosted version of Catalina to be used to compile larger C programs, such 
   as Dumbo Basic, and it also speeds up smaller compilations because the 
   symbol table (which is a hash table) ends up less densely populated, 
   which results in fewer hash table collisions.

   The compile times achieved by the Catalyst version of Catalina depends 
   on many factors, including the platform, the clock frequency, the command
   line options specified, the libraries used, and the speed of the SD card, 
   but some typical times (on a 200MHz P2 EDGE) in NATIVE mode are as follows:

      C Program    Lines      Compile Time     Compile Time
                   (approx)   (normal build)   (quick build)
      ==========   ========   ===============   ===============
      hello      :      5   : 8  mins         : 5  mins
      othello    :    500   : 10 mins         : 8  mins
      startrek   :  2,000   : 40 mins         : 37 mins
      chimaera   :  5,000   : 2 hours         : 1 hour 50 mins
      dbasic     : 12,000   : 2 hours 30 mins : 2 hours 20 mins

   Note that the quick build feature is not expected to speed up NATIVE mode
   compilations by much - quick build is primarily designed to speed up XMM 
   SMALL and XMM LARGE mode compilations.

3. Catalina now defaults to using the name of the first input file without
   any extension as the output name if no output name is explicitly specified 
   (using the -o command line option). For example:

      catalina -p2 -c hello.c         -> generates hello.obj
      catalina -p2 -lci hello.obj     -> generates hello.bin

   Previously, Catalina would include the extension, so the second command 
   above would try to create "hello.obj.bin" - this worked ok when compiling 
   for the Propeller 1, but failed when compiling for the Propeller 2, due 
   to the differences in the assembler used (p2asm vs spinnaker).

4. The Catalyst version of Catalina now has a -N command line option, which
   disables the inclusion of IF commands in the generated script that test 
   the exit code of each compilation step. This can speed up the execution of 
   the resulting script, but it means the script will continue to execute even
   if an error is detected. Including the tests is useful to terminate long
   compilations that may take hours, but is less useful for short compilations 
   where the user can easily terminate the script if required.

Other Changes.
--------------

1. The speed of Catalysts auto-execution capability (i.e. the auto execution
   of commands in the files AUTOEXEC.TXT or EXECONCE.TXT on boot) has been 
   increased. This also results in significantly faster Catalyst script 
   execution times (which the Catalyst version of Catalina uses). Affected 
   the Propeller 1 and Propeller 2 versions of Catalyst.

2. The Dumbo Basic VALLEN function was not working correctly. VALLEN is not
   a GW Basic function, it comes from Mini Basic, and was supposed to return
   the number of characters in the argument that a VAL statement would 
   interpret when called on the same string argument. For example:

      VAL("1234XXXX") = 1234
      VALLEN("1234XXXX") = 4

   Affected Dumbo Basic on the Propeller 1, Propeller 2, and also on Windows 
   and Linux.

3. The C include files were DOS format files on Windows, and Unix format files
   on Linux. This was ok on both of those platforms, but it caused problems
   with Catalyst - when Catalyst was built on Windows it ended up with Windows
   format include files when it was expecting Linux ones. To fix this, all 
   include files are now in Linux format files on all platforms. Affected the
   Propeller 2 version of Catalyst only.

4. The Catalyst version of the Propeller 2 Assembler (p2asm) now dynamically 
   allocates its Symbol Table array. This makes no functional difference, but
   it significantly reduces the size of the p2asm binary. Affected the 
   Propeller 2 version of Catalyst only.

5. The Catalyst version of Catalina now only includes only the generic and
   Propeller specific code generation back-ends, and not Alpha, MIPS, OSX or
   X86 etc. This significantly reduces the size of the rcc binary. Affected
   the Propeller 2 version of Catalyst only.

6. The Catalyst version of Catalina now deletes only the output files before 
   the compile if untidy mode is specified, not any of the intermediate 
   files. Affected the Propeller 2 version of Catalyst only.

7. The Catalyst version of Catalina now correctly produces a .obj file if
   the -c command line option is specified, instead of a .s file. Affected
   the Propeller 2 version of Catalyst only.

8. The Catalyst version of Catalina was incorrectly invoking the Spin 
   preprocessor (spp) on .obj files. Affected the Propeller 2 version of 
   Catalyst only.

9. Dumbo Basic's PRINT statement was printing floats with precision zero
   unless a USING clause was specified - this bug was introduced in release 
   7.1.1. Affected both the Propeller 1 and Propeller 2 on Catalyst, Windows 
   or Linux.

10. The code Catalyst uses to detect if an executing script is to be
    terminated (which prompts with "Continue auto execution (y/n)?" if 
    it detects a key held down when it executes each line of the script) 
    worked ok if the answer was 'n' but did not continue correctly if the 
    answer was 'y'. Affected Catalyst on the Propeller 1 and Propeller 2.

RossH

How annoying ...

A new Dumbo Basic demo program poker.bas has been included in the last couple of releases. It has the following first line:

1 DEFINT A-Z : LINE INPUT "PRESS ENTER TO BEGIN"; A$ : RANDOMIZE TIMER

I copied this line from another program as a way to seed Basic's random number generator - otherwise every game would be exactly the same. There is no easy way to do this on a Propeller 1 (at least AFAIK - if anyone knows of one, please post it!). But the DEFINFT A-Z should not be there. Delete that statement so the line reads:

1 LINE INPUT "PRESS ENTER TO BEGIN"; A$ : RANDOMIZE TIMER

With the DEFINT in there, the game appears to work normally, but you cannot enter 0.5 as a bet (which is what you enter to 'check').

Ross.

evanh

Isn't that just using the system ticks variable, after waiting on human input, to produce a seed? That shouldn't be hard to replicate.