Shop Learn
Catalina — Parallax Forums

Catalina

RossHRossH Posts: 4,717
edited 2021-09-08 12:21 in Propeller 2
I have just added the release version of Catalina 4.7 to SourceForge. This release is for both Windows and Linux. This release fixes a few issues, adds the latest version of Dumbo Basic (which had already been released elsewhere), adds the new 8 port serial driver for the Propeller 2, and an updated version of the payload loader with improved Propeller 2 FLASH RAM support.

Here is an extract from the README.TXT file:
RELEASE 4.7

1. p2_asm now enables the -v33 option to p2asm by default. This enables the
   latest PASM assembly code, and would nearly always be what you want to do. 
   To revert to the previous behaviour, edit the file p2_asm.bat.

2. Dumbo basic updated to version 1.0, which implements much more of the
   original GWBASIC syntax. See the README.TXT file in the catalyst\dumbo
   directory for more details.

3. Added the 8 port serial driver. This driver is only supported on the
   Propeller 2. It supports up to 8 serial ports on the Propeller 2. See 
   the Catalina Propeller 2 Reference Manual for more details.

4. Fixed a bug in the 2 port serial driver that meant the second port would
   not receive characters correctly.

5. Fixed a bug in the serial2 and serial4 demo programs which meant they may 
   not have worked if they were compiled with threading enabled.

6. The build_all scripts in all the serial demo directories (i.e. serial2, 
   serial4 & serial8) will now only build the demos for the correct propeller. 
   The serial2 and serial8 libraries are only supported on the Propeller 2, 
   and serial4 is only supported on the Propeller 1.

7. Modified the catalina_cog.h include file to fix a name collision with
   propeller2.h. On the Propeller 2, library functions that are defined
   in propeller2.h are now not also defined in catalina_cog.h

8. Added smartpins.h to define the smartpins modes for the Propeller 2.

9. Added an implementation of _muldiv64(), to match the SPIN MULDIV64 function.

10. NATIVE mode is now the default memory layout on the Propeller 2. To
    reinstate the previous default (LMM), specify either -C TINY or -x0 on
    the catalina command line.

11. The payload loader has two new options:

    -o can be used to override the default propeller version detection. This
    option requires the propeller version to be explicitly specified i.e. as
    -o1 or -o2 (propeller 1 or propeller 2).

    -j can be used to completely disable lfsr checking (propeller 1 only).

    This allows payload to correctly use the 100ms serial window when loading
    programs to a Propeller 2. In particular, it allows programs to be loaded
    to the FLASH RAM on the P2_EVAL board and executed without requiring the
    microswitches on the PCB to be altered or the Propeller to be reset.
       
12. Code::Blocks is no longer supported under Linux, and precompiled binaries
    are no longer provided. However, the source code modifications and example
    workspaces for Code::Blocks version 17.12 are still provided for those 
    who want to compile Code::Blocks for themselves from source. Code::Blocks 
    remains supported under Windows, but this may not remain true for future 
    releases. Code::Blocks users under both Windows and Linux are encouraged 
    to migrate to the Catalina Geany IDE, which will remain supported on 
    both Linux and Windows.

13. Under Linux, the srecord utility used is now version 1.64. Under Windows
    srecord version 1.47 is still used. This utility is used if the -F option
    to catalina is used. Tests on various common output formats have shown
    no differences (e.g. Motorola, Intel formats) but exhaustive testing has 
    not been conducted on all formats

Comments

  • RossHRossH Posts: 4,717
    edited 2020-10-03 22:36
    Catalina 4.5 has been superseded by release 4.6. See the previous post for details.
  • RossHRossH Posts: 4,717
    Catalina 4.6 has been released. See the top post for details.
  • RaymanRayman Posts: 12,185
    @RossH Thanks for keeping Catalina going. It's nice to have options...

    I just installed the latest version to see if it could run this MicroMax Chess code...

    It compiles and run, but just like FlexC, it hangs if you hit enter when it is supposed to look for a move.
    You can manually move pieces by entering moves like "e2e4", but also just like FlexC, there is something wrong with the black pawns... They don't move, for example.

    Anyway, don't expect you to do anything about it, just letting you know I'm testing out Catalina.

    This code was designed to use as few a characters as possible, which seems very silly to me... I imagine why that is why compilers might have a hard time with it...
  • RaymanRayman Posts: 12,185
    edited 2020-10-10 22:26
    This chess code seems to work, except that the function GetMillisecs() needs fixing because I hacked it to make it compile.
    The interface asks how many seconds to give computer. If you say "0", it moves right away. If you say "1", it thinks longer that I could wait for...

    Also, it can't find the opening book file even though I put it on the uSD card of the Eval board...

    I did the compile and load like this:
    catalina NGplay_61.c -p2 -lc -C P2_EVAL -C NATIVE
    payload -i -z -b230400 NGplay_61.bin
    
    c
    c
  • RossHRossH Posts: 4,717
    Rayman wrote: »
    @RossH Thanks for keeping Catalina going. It's nice to have options...

    I just installed the latest version to see if it could run this MicroMax Chess code...

    It compiles and run, but just like FlexC, it hangs if you hit enter when it is supposed to look for a move.
    You can manually move pieces by entering moves like "e2e4", but also just like FlexC, there is something wrong with the black pawns... They don't move, for example.

    Anyway, don't expect you to do anything about it, just letting you know I'm testing out Catalina.

    This code was designed to use as few a characters as possible, which seems very silly to me... I imagine why that is why compilers might have a hard time with it...

    Seems to work ok for me. But I must admit I only played a few moves, because each move takes a looooonnnnnggg time!

    What are you running it on, and what command did you use? I ran it on a P2, and used the command:
    catalina -p2 micromax.c -lci -ltiny -C P2_EVAL -C TTY -C NATIVE -C NO_FLOAT
    
  • RossHRossH Posts: 4,717
    Rayman wrote: »
    This chess code seems to work, except that the function GetMillisecs() needs fixing because I hacked it to make it compile.
    The interface asks how many seconds to give computer. If you say "0", it moves right away. If you say "1", it thinks longer that I could wait for...

    Also, it can't find the opening book file even though I put it on the uSD card of the Eval board...

    I did the compile and load like this:
    catalina NGplay_61.c -p2 -lc -C P2_EVAL -C NATIVE
    payload -i -z -b230400 NGplay_61.bin
    

    I haven't looked at the code, but to use the SD Card you need to use -lcx instead of -lc
  • RossHRossH Posts: 4,717
    Hi @Rayman

    I was interested as to why the MicroMax chess program is so slow, so I did some measurements on it. I only did a couple of runs, but the reason becomes clear almost immediately - most of the work is done by one function (D), which is recursive. This very complex function gets called anywhere between 200,000 and 500,000 times while searching for the best move, and it recurses to a depth of 25 or so calls.

    I think the author was concentrating on program size, not speed! :)

    Ross.
  • RaymanRayman Posts: 12,185
    @RossH i think you are right. Although it seems to have been ported to microcontrollers. The code is very obtuse though. I think I like the look of ngplay better.
  • RaymanRayman Posts: 12,185
    edited 2020-11-09 14:35
    I tried out MicroMax again after seeing it in Gameduino...

    This code seems to work with Catalina. Rigged for computer vs computer.

    Had to bypass the millis() function though.
    In FlexProp, there is now _getms().
    Not sure this is really used by the chess engine itself, so I didn't bother to fix it.

    BTW: Is there a way to escape from the payload terminal and get back to command line?
  • RossHRossH Posts: 4,717
    Rayman wrote: »
    BTW: Is there a way to escape from the payload terminal and get back to command line?

    CTRL-D
  • RossHRossH Posts: 4,717

    Catalina 4.7 has been released (currently, Windows only). See the first post in this thread for details.

  • RaymanRayman Posts: 12,185

    Just installed... Windows complained a lot, but was able to get it to install.

    Seem to be missing the "Catalina Command Line" shortcut in the start menu. But, I found it in the install folder.

  • RaymanRayman Posts: 12,185

    It does still build a chess program I tried before with Catalina, NGplay_61.c, so that's good.

    Tried to compile lvgl (https://github.com/lvgl/lvgl), but it's not finding the include files...
    There are about a thousand include files...
    Catalina does not seem to be finding them.
    I'm sure I'm doing something wrong...

    This is asking a lot, but if you want to see what I'm looking at...
    The build.bat file in the attached tries to compile lvgl_test1.c
    It looks like it finds include files in the current directory, but not in the \src directory tree...

  • RossHRossH Posts: 4,717

    Hi Rayman

    Will have a look tomorrow.

    rossh

  • RossHRossH Posts: 4,717
    edited 2021-09-05 23:52

    @Rayman said:

    Tried to compile lvgl (https://github.com/lvgl/lvgl), but it's not finding the include files...
    There are about a thousand include files...
    Catalina does not seem to be finding them.
    I'm sure I'm doing something wrong...

    There is something wrong with your directory structure. Here is first error message I get, with an example of the problem:

    cpp: ./lv_conf_internal.h:41 ./src/misc/lv_log.h:16 ./lvgl.h:25 lvgl_test1.c:3 Could not find include file "../../lv_conf.h"

    So, decoding that:

    lvgl_test1.c includes ./lvgl.h at line 3
    ./lvgl.h includes ./src/misc/lv_log.h at line 25
    ./src/misc/lv_log.h includes ./lv_conf_internal.h at line 16
    ./lv_conf_internal.h includes ../../lv_conf.h at line 41

    But from the location you are compiling lvgl_test1.c there is no ../../lv_conf.h - however, there is one at ./lv_conf.h

    rossh

  • RossHRossH Posts: 4,717

    @Rayman said:
    Just installed... Windows complained a lot, but was able to get it to install.

    Seem to be missing the "Catalina Command Line" shortcut in the start menu. But, I found it in the install folder.

    Odd. Works ok for me. What version of Windows are you using?

    rossh

  • RaymanRayman Posts: 12,185

    @RossH said:

    @Rayman said:
    Just installed... Windows complained a lot, but was able to get it to install.

    Seem to be missing the "Catalina Command Line" shortcut in the start menu. But, I found it in the install folder.

    Odd. Works ok for me. What version of Windows are you using?

    rossh

    Latest Win10. I still had the last version installed though. Maybe that messed it up somehow…

  • RaymanRayman Posts: 12,185

    Thanks for looking at the code issue. Looks like an easy fix.

  • RossHRossH Posts: 4,717

    I have updated payload to allow it to be used to program FLASH RAM on the P2 without needing to reset the microswitches on the P2_EVAL board. This required a modification to the Propeller version detection code (basically, you can now override it and manually specify your Propeller version). This update allows payload to correctly use the 100ms serial window on the Propeller 2.

    Attached is a zip file containing the new version of payload and the updated README_P2.TXT file. This version will be included in Catalina 4.7 when I have finished testing the current beta release. Here is an extract from the updated README_P2.TXT file:

    There is also a a payload-based utility that can program the FLASH RAM on the
    P2_EVAL board:

    flash_payload program.bin [ other payload options ]

    e.g:

    flash_payload othello.bin -b230400 -z -i

    Note that you must have the microswitches on the P2_EVAL PCB set correctly to
    program the FLASH. Here is one way to do it:

    FLASH set to ON
    P59^ set to ON
    P59v set to OFF

    Then, execute the flash_payload command, and once all the LEDs have gone out
    (which indicates the FLASH programming has completed) set the P59^ microswitch
    to OFF and reset the P2 to execute the loaded program from FLASH.

    Another way to do this is possible, which does not require microswitch changes.
    However, this method only works if you override payload's normal autodection
    of whether it is talking to a Propeller 1 or a Propeller 2 using the -o option.
    Set the microswitches as follows:

    FLASH set to ON
    P59^ set to OFF
    P59v set to OFF

    Now, by executing the flash_payload command with the -o2 option, you can load
    the FLASH RAM and then execute the program from FLASH in one command without
    needing to change any of the microswiches. For example:

    flash_payload othello.bin -b230400 -o2 -i

    rossh

  • RossHRossH Posts: 4,717

    I have just uploaded a validated (i.e. non-beta) release of Catalina 4.7 to sourceforge. This release is for both Linux and Windows. There are a few changes from the beta release:

    • NATIVE is now the default mode for the Propeller 2.
    • there is a new version of the payload loader, with improved support for FLASH RAM on the Propeller 2.
    • Code::Blocks is no longer supported on Linux (it remains supported on Windows).

    See the first post in this thread for more details.

    rossh

  • RossHRossH Posts: 4,717

    I've just uploaded Catalina 4.8 to Sourceforge. There aren't many differences to 4.7, so I've also uploaded some small "patch" files to the errata directory (https://sourceforge.net/projects/catalina-c/files/errata/) which you can use to upgrade an existing 4.7 release to 4.8 without having to download and install the whole new release.

    The differences are very minor (mostly some missing documentation updates and an update to the inline PASM function).

    Here is an extract from the README.TXT:

    RELEASE 4.8

    1. Updates to the reference manuals and the command summaries to include the
      changes made to payload in release 4.7.

    2. A bug introduced in release 4.7 when making NATIVE the default memory
      model on the P2 has been fixed.

    3. The definition of the PASM() function (used to include inline PASM in C
      code) has been modified to indicate it can return an int rather than a void.
      This prevents Catalina from overwriting return values (i.e. the value
      present in r0 when the PASM code finishes execution). The new definition is:

      extern int PASM(const char *code);

      This should not make any difference to existing code that does not use the
      return value of the PASM function. New PASM example program called
      test_inline_pasm_3.c and test_inline_pasm_4.c have been added to the
      examples in the demos\spinc folder to illustrate the use of the return value.

    4. Updated the build_all scripts in the demos\spinc folder to only build demo
      programs appropriate to the propeller type (i.e. 1 or 2).

    5. The file flash_led.obj was missing from the demos\spinc folder.

    The bug mentioned in point 2 was very minor and is unlikely to have affected anyone's C programs except mine (the compiler was defining both __CATALINA_NATIVE and __CATALINA_TINY in some cases when it should have defined just __CATALINA_NATIVE).

    Ross.

  • RossHRossH Posts: 4,717

    I have no plans for another release of Catalina just yet, but I have a question ...

    I recently dropped support for the Code::Blocks IDE under Linux (I can no longer get it to compile), and I expect to do so in Windows soon (same reason - it is becoming almost impossible to compile). Also, Code::Blocks is far too complex for the type of projects we typically build on the Propeller.

    The Catalina Geany IDE (which will remain supported) is much simpler and easier to use.

    However, one advantage Code:Blocks did have is that you didn't have to have a make utility installed - it has an equivalent built in. Geany does not have this - it can build simple projects very easily, but complex projects must use an external Makefile, and therefore (on Windows) this requires you to also install a version of make.

    So ... here is the question ...

    Would it be ok to assume Windows users can install and use a version of make (e.g. from http://gnuwin32.sourceforge.net/packages/make.htm) to build all the example programs and demos? Doing so would mean that I would no longer have to support different batch scripts on Windows and Linux - I could just use a common Makefile.

    Obviously, I am thinking 'yes' because it would save me quite a lot of work - but I am interested in hearing other opinions before I finally decide.

    Rossh

    P.S. Also, just an early warning - the next version of Catalina will probably remove the -F compiler option, which allowed the binary output to be produced in different formats (e.g. Motorola S record or Intel Hex format). You will of course still be able to generate the standard Parallax formats - .bin on the P2, or .binary or .eeprom on the P1. If anyone still needs this capability (I can't even remember now who originally requested it) then the srecord utility (which is what -F invokes) has a stand-alone version you can use to do the same job. It no longer seems necessary to have this capability embedded within Catalina. Again, comments welcome.

    Ross.

  • Would CodeLite be a replacement worth looking at? I think it's a maintained fork of Code::Blocks. Otherwise, is there any accessible/reusable portion of LccWin32?

Sign In or Register to comment.