Shop OBEX P1 Docs P2 Docs Learn Events
Catalina and the P2 - Page 5 — Parallax Forums

Catalina and the P2

12357

Comments

  • RossHRossH Posts: 5,334
    ersmith wrote: »
    Rather than use a lookup table you can use cordic instructions directly; you'll get more accuracy that way. Use qrotate for sin/cos, qexp for exp, qlog for log, and qsqrt for sqrt.

    Eventually, yes. At present, I am just porting code the easiest way I can. There's so much to do ... :(
  • RossHRossH Posts: 5,334
    Making good progress on Catalina - I now have floating point working, and can compile and load most of my old demo programs from my P1 days - but I seem to be stuck getting the SD Card on the P2_EVAL board to work. None of the programs I have found here in the forums seem to work (I have tried various version of fsrw etc). The SD cards I am using seem to be fine, in that they can be mounted via TAQOZ - but that's as far as I can get.

    I am not really sure what I am doing wrong. Does anyone have some SD card read/write code (preferably in PASM) that is known to work on the P2_EVAL board?

    Thanks!
  • The P2 uses a few stages of registers on both inputs and outputs. Your SPI driver may not be allowing for that. You could try adding a delay after toggling the clock line and reading the input. Or you could try using the SPI drivers from taqoz or the monitor.
  • RossHRossH Posts: 5,334
    Dave Hein wrote: »
    The P2 uses a few stages of registers on both inputs and outputs. Your SPI driver may not be allowing for that. You could try adding a delay after toggling the clock line and reading the input. Or you could try using the SPI drivers from taqoz or the monitor.

    That could be it. Is the source code to the monitor available somewhere? That might at least give me a clue as to what I am doing wrong.
  • Cluso99Cluso99 Posts: 18,066
    Have you tried loading/running a file from the SD card using the monitor?


    Attached: P2 ROM source and listing attached and SD SPI timing on P2

    Note with the current P2 silicon, an output will appear 3 clocks after the end of the out instruction, and an input will be sampled 1 clock before the testp instruction begins (ie 3 clocks prior to the end of this instruction). So, an OUT followed by an IN will sample before the data has been output!!!
  • RossHRossH Posts: 5,334
    Cluso99 wrote: »
    Have you tried loading/running a file from the SD card using the monitor?


    Attached: P2 ROM source and listing attached and SD SPI timing on P2

    Note with the current P2 silicon, an output will appear 3 clocks after the end of the out instruction, and an input will be sampled 1 clock before the testp instruction begins (ie 3 clocks prior to the end of this instruction). So, an OUT followed by an IN will sample before the data has been output!!!

    Thanks Cluso!

    Yes, I can load and run programs from the SD card using the monitor. I am aware of the timing issues on the P2, but clearly I am doing something else wrong :(
  • Cluso99Cluso99 Posts: 18,066
    Ross,
    Would you like to post your low level SPI send & receive routine if that is where you think the problem is ???
  • RossHRossH Posts: 5,334
    Cluso99 wrote: »
    Ross,
    Would you like to post your low level SPI send & receive routine if that is where you think the problem is ???

    Hi Cluso. Thanks for that. I found at least one of the problems - my source code preprocessor was silently "eating" lines of source code under certain circumstances - and the line happened to be right in the middle of the SD code! :(

    Now that I have fixed that, I have "read" working. I will post the code if I can't get the "write" working.

    Ross.
  • RossHRossH Posts: 5,334
    edited 2019-04-27 08:16
    Another small milestone on the way to Catalina on the P2 ...

    I now have a simple SD card plugin working, which gives Catalina DOS file system support. To demonstrate it, here is "Super Star Trek" - a much larger and much more advanced version of the classic Startrek game, and one that requires disk support. It used to require XMM support on the P1, but runs easily on the P2 in native mode.

    You can save and load games to the SD card (using the "freeze" command), and the help file (invoked via the "help" command) is also loaded from the SD card.

    To run it on the P2_EVAL board, just put the attached SST.BIN and SST.DOC files on your SD card and run SST.BIN from the monitor program. You need to set your PropTerminal baud rate to 230_400.

    Ross.

    NOTE: the attached file has been updated to include a fix for the SD code, which contained a bug.
    zip
    693K
    sst.zip 692.9K
  • What? no Zork or Pirates Adventure (Pirates Cove).

    Mike
  • Cluso99Cluso99 Posts: 18,066
    Ross,
    Just rename SST.BIN as _BOOT_P2. BIX and the enable the autoboot from SD pullup/switch and it will boot on powerup
  • RossHRossH Posts: 5,334
    iseries wrote: »
    What? no Zork or Pirates Adventure (Pirates Cove).

    Mike

    Funny you should say that ...

    Just put the attached files on an SD card, plug it into your P2_EVAL board, set your baud rate in PropTerminal to to 230_400, and enjoy! :)

  • RossHRossH Posts: 5,334
    Cluso, there is a bug in the SD code included in the P2 boot rom. The timeout processing of simply getting the current counter and adding a value to it does not take into account that the result might already be less than the current count due to wraparound. Hence on random occasions the code thinks a timeout has occurred immediately.

    Ross.
  • cgraceycgracey Posts: 14,131
    RossH wrote: »
    Cluso, there is a bug in the SD code included in the P2 boot rom. The timeout processing of simply getting the current counter and adding a value to it does not take into account that the result might already be less than the current count due to wraparound. Hence on random occasions the code thinks a timeout has occurred immediately.

    Ross.

    Cluso99, I recall that you fixed this in the new ROM for the next silicon, right?
  • RossHRossH Posts: 5,334
    cgracey wrote: »
    RossH wrote: »
    Cluso, there is a bug in the SD code included in the P2 boot rom. The timeout processing of simply getting the current counter and adding a value to it does not take into account that the result might already be less than the current count due to wraparound. Hence on random occasions the code thinks a timeout has occurred immediately.

    Ross.

    Cluso99, I recall that you fixed this in the new ROM for the next silicon, right?

    The source that Cluso posted (above) was possibly prior to the fix.
  • cgraceycgracey Posts: 14,131
    RossH wrote: »
    cgracey wrote: »
    RossH wrote: »
    Cluso, there is a bug in the SD code included in the P2 boot rom. The timeout processing of simply getting the current counter and adding a value to it does not take into account that the result might already be less than the current count due to wraparound. Hence on random occasions the code thinks a timeout has occurred immediately.

    Ross.

    Cluso99, I recall that you fixed this in the new ROM for the next silicon, right?

    The source that Cluso posted (above) was possibly prior to the fix.

    I know there was something about a timeout issue in Cluso's code. I'm hoping this is it.

    I'm remembering... sometimes, due to the wrap-around, things would stall for 2^31 clocks before timing out. That got fixed. Maybe this early timeout problem was part of the same bug.
  • Cluso99Cluso99 Posts: 18,066
    I’ll check but not on my computer atm.
  • Cluso99Cluso99 Posts: 18,066
    Ross,
    This was the fix for the timeout bug
    '+-----------------------------------------------------------------------------+
    '+      READ REPLY: R1/R1+R3/R1+R7/R1+token                                    +
    '+-----------------------------------------------------------------------------+
    _getreply       call    #@_recvbyte                     ' recv R1 byte
                    cmp     reply,            #$FF      wz  ' reply=$FF=busy ?
            if_nz   jmp     #.doneR1                        ' n:
    
    ' timeout set in CMD0(for CMD0,8,55,A41,58,16) and CMD9,10,17(readblock)
                    getct   replyR1                         '\ timeout ?
                    cmpm    timeout,          replyR1   wc  '| c if timeout < replyR1                       \ --tweek4--
            if_nc   jmp     #@_getreply                     '| n: try again                                 /
            _RET_   MODCZ   _set,_clr                   wcz '/ timeout C & NZ = fail                        ] --tweek2--
    '+=============================================================================+
    
    and here is the latest boot code.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    RossH wrote: »
    cgracey wrote: »
    RossH wrote: »
    Cluso, there is a bug in the SD code included in the P2 boot rom. The timeout processing of simply getting the current counter and adding a value to it does not take into account that the result might already be less than the current count due to wraparound. Hence on random occasions the code thinks a timeout has occurred immediately.

    Ross.

    Cluso99, I recall that you fixed this in the new ROM for the next silicon, right?

    The source that Cluso posted (above) was possibly prior to the fix.

    I know there was something about a timeout issue in Cluso's code. I'm hoping this is it.

    I'm remembering... sometimes, due to the wrap-around, things would stall for 2^31 clocks before timing out. That got fixed. Maybe this early timeout problem was part of the same bug.

    The code I posted was v33i which is the first silicon "ES" ROM.

    Code just posted is what I have for P2 respin v33j but I may not have the latest TAQOZ in it ???
    We were working frantically on the 20 Feb 2019 to get it ready for OnSemi and I just don't seem to have a definitive version cataloged :(
    The timeout tweek4 was the last change to the SD Boot but I did a lot of work on refining the SD code between "ES" and "respin" versions including a fix for DO not releasing. A minor tweek for DO did not make the cut but it's really minor.
    The MONITOR did not change and is in the precise HUB locations too.

    I was working on a last minute additional tweek to the SD code but it did not make the cut.

    @Chip,
    Could you post or email me the final "respin" code please? I'll compile with P2ASM and post the listing.
  • RossHRossH Posts: 5,334
    edited 2019-04-29 08:43
    Cluso99 wrote: »
    Ross,
    This was the fix for the timeout bug
    '+-----------------------------------------------------------------------------+
    '+      READ REPLY: R1/R1+R3/R1+R7/R1+token                                    +
    '+-----------------------------------------------------------------------------+
    _getreply       call    #@_recvbyte                     ' recv R1 byte
                    cmp     reply,            #$FF      wz  ' reply=$FF=busy ?
            if_nz   jmp     #.doneR1                        ' n:
    
    ' timeout set in CMD0(for CMD0,8,55,A41,58,16) and CMD9,10,17(readblock)
                    getct   replyR1                         '\ timeout ?
                    cmpm    timeout,          replyR1   wc  '| c if timeout < replyR1                       \ --tweek4--
            if_nc   jmp     #@_getreply                     '| n: try again                                 /
            _RET_   MODCZ   _set,_clr                   wcz '/ timeout C & NZ = fail                        ] --tweek2--
    '+=============================================================================+
    

    Yes, that'll work for all the timeouts in the boot code.
  • RossHRossH Posts: 5,334
    edited 2019-05-05 03:17
    I have just uploaded Catalina 3.15 to SourceForge (https://sourceforge.net/projects/catalina-c/files/releases/3.15/Catalina_3.15_Setup.exe/download).

    This is a full release that supports both the P1 and the P2, although the P2 support is still in the "bleeding edge" stage. It is a Windows-only release, and is intended for those with a P2 EVAL board.

    This release does not add any significant P1 functionality, and is not recommended for those using only a P1.

    Here is the P2 README file ...
    Catalina 3.15 - Propeller 2 Support
    ===================================
    
    Version 3.15 of Catalina is the first version to provide support the new 
    Propeller 2 chip. Specifically, it provides support for the Propeller 2 on 
    a P2 EVAL board. While other boards can be supported by modifying the file
    "Catalina_platforms.inc" in the "target_p2" directory, this document assumes
    you have a P2 EVAL board. In this release, the only supported HMI option is 
    a serial terminal, and the baud rate is specified (in Catalina_Platforms.inc)
    as 230400 for all programs. The default clock speed is 180Mhz.
    
    If you have used a previous version of Catalina (i.e. for the P1), you should 
    refer to the file "README.WhatsNew" which contains more details on all the 
    changes in this release. If not, this document summarizes the main things you
    need to know to get up and running using Catalina for the P2.
    
    As there is not yet any Code::Blocks support, compiling P2 programs requires
    that you use Catalina from the command line. Once you have installed Catalina,
    simply select the "Catalina Command Line" entry from the Start Menu options.
    A Windows terminal will open, set up to use Catalina. The main commands you
    need to know at this point are:
    
       catalina   - invoke the catalina C compiler
       payload    - invoke the payload program loader and interactive terminal 
    
    In the finest tradtions of C, let's open a Catalina command window and build
    and run the traditional "Hello, World!" C program. First, please remove any 
    SD cards you have in your P2 EVAL board (this seems to make the serial program
    loading unreliable). Then execute the following commands (the options used are
    explained in detail a bit later):
    
       cd demos
       catalina -p2 -lc hello_world.c
       payload -i -b230400 hello_world.bin
    
    You should see a friendly "Hello, World" message!
    
    The main command-line option you need to know about is '-p2', which specifies 
    to Catalina that you are building a program for the P2, not the P1 (which is
    the default). To specify the P2 EVAL board, you would normally define the
    Catalina symbol P2_EVAL, but as this is currently the default, it is not
    strictly necessary. However, there are a few other Catalina symbols you need
    to know about, which are used to select the memory model to use:
    
       TINY    - this model is identical to the TINY LMM model on the P1. This is
                 the default model, although on the P2 "tiny" is no longer really
                 an appropriate name since the Hub RAM on the P2 is 512Kb. For
                 historical reasons this memory model is the default. This memory
                 model can be specified by using the option -x0 or -C TINY on the
                 command line. Note that on the P2 you would usually want to use
                 the NATIVE memory model described below.
     
       COMPACT - this model is identical to the COMPACT model on the P1. This
                 can be specified by using the option -x8, or -C COMPACT on the
                 command line. Using this option also specifies that the library
                 is prefixed with "compact_", so if you specify all of -p2, -lc
                 and -C COMPACT the library that is actually used will be 
                 "compact_lib_p2\libc"
    
       NATIVE  - this model is new for the P2. This is specified by using the 
                 option -x11, or -C NATIVE on the command line. This option is 
                 automatically selected in many of the "build_all" batch files.
                 Using this option also specifies that the library is prefixed
                 with "native_", so if you specify all of -p2, -lc and -C NATIVE, 
                 the library that is actually used will be "native_lib_p2\libc"
    
    So, for instance, to compile the othello.c program in the "demos" directory
    for the P2_EVAL in NATIVE mode, you might use a command like:
     
       catalina othello.c -lc -p2 -C P2_EVAL -C NATIVE
    
    Note that the -C option defines a Catalina symbol, which is different to a
    C symbol which is defined using the -D option. There is more about this in
    the Catalina documentation. For now, just remember that Catalina specific 
    configuration options are generally specified using -C, not -D
    
    To run the program and use it you can use the Catalina payload program loader
    and interactive terminal. You need to specify the baud rate to use, which is
     230400 baud:
    
       payload othello.bin -i -b230400
    
    If you get tired of specifying the baud rate every time, you can specify it
    once using an environment variable, and it will be used in subsequent payload
    commands:
    
       set PAYLOAD_BAUD=230400
    
    However, the best way to demonstrate Catalina on the P2 is to use the Catalyst 
    program.  A version of Catalyst and some accompanying example programs already
    compiled for the P2 EVAL board is provided in the file "P2_EVAL.ZIP" in the 
    main Catalina directory. Just unzip this file, copy all the enclosed files 
    onto an SD Card, insert it into a P2 EVAL board and reboot. You can interact 
    with Catalyst using a serial terminal emulator. Catalyst and all its programs
    are compiled to use 230400 baud and a VT100 compatible terminal emulator.
    
    For instance, you can use the Catalina payload program as your terminal 
    emulator - you will need to specify the baud rate and port to use. For
    instance, if your P2 EVAL board is connected to COM4, you might use the
    following payload command:
    
       payload -i -z -q1 -b230400 -p4
    
    Here is what the parameters mean:
    
       -i  means to use the interactive terminal, which is a simple VT100 emulator
    
       -z  improves the reliability of detection of a P2, especially when an 
           SD card is inserted (this requires more investigation!)
    
       -q1 specifies the line termination handling (in this case, to ignore CR)
    
       -p4 specifies to use port 4 (i.e. COM4 on Windows). If you are loading
           a program then payload can autodetect the port to use and also the
           type of Propeller, but if you are just using the interactive terminal,
           you need to explicity specify the port.
       
    You can also use the Parallax Serial Terminal as your terminal emulator. 
    Catalyst itself and most of the example programs will work correctly, except 
    for vi text editor (which requires a VT100 compatible terminal emulator).
    
    When using the Parallax Serial Terminal you will need to set the baud rate 
    (to 230400), the port, and also to ignore line feed characters (not CRs!).
    
    Line termination handling can be a complex issue when you are using C programs
    that originated from multiple sources, and terminal emulators that handle line
    terminations in different ways - this is exacerbated when some of the programs
    were originally DOS programs and some of them were UNIX programs.  As a 
    compromise, all the Catalyst programs are compiled to send both a CR and an LF
    as line terminators, allowing you to select which one to process or ignore 
    depending on which works best in your particular terminal emulator. The
    command used to compile Catalyst (in the "catalyst" subdirectory) was:
    
       build_all P2_EVAL TTY VT100 CR_ON_LF
    
    Now, let's get started with Catalyst ...
    
    First of all, note that there is a "Catalyst Reference Manual" that will have
    been installed when you installed Catalina - it contains more details. But 
    here are the highlights ...
    
    First, you should start payload in interactive mode. Then. when you reboot 
    your P2 EVAL board, you should see a prompt like:
    
       Catalyst 3.15
       >
    
    Type the command "dir" and press return. You should see something like:
    
       Directory ""
       ------------ ------------ ------------
       PROP2        ELIZA   .BAS STARTREK.BAS
       TREK15  .BAS UT-TREK .BAS CAT     .BIN
       CATALYST.BIN CP      .BIN DBASIC  .BIN
       JZIP    .BIN LS      .BIN LUA     .BIN
       LUAC    .BIN MKDIR   .BIN MV      .BIN
       PCOM    .BIN PINT    .BIN RM      .BIN
       RMDIR   .BIN SST     .BIN VI      .BIN
       _BOOT_P2.BIX ZORK1   .DAT ZORK2   .DAT
       ZORK3   .DAT FACT    .LUA FIB     .LUA
       HELLO   .LUA SORT    .LUA SST     .DOC
       BASICS  .P5  STARTREK.P5  BASICS  .PAS
       HELLO   .PAS MATCH   .PAS ROMAN   .PAS
       STARTREK.PAS CATALYST.TXT HELP    .XVI
    
    This confirms that Catalyst is working and the Catalyst programs are loaded
    onto the SD card. The most important things that Catalyst adds to the simple
    program loader implemented on the P2 itself are some simple file management
    commands, and the ability to use command-line arguments when executing 
    programs.
    
    The basic Catalyst commands are unix-like - e.g. cp, ls, rm, rmdir - and work
    as you might expect.
    
    Here are some other commands you can try:
    
      vi catalyst.txt        - the vi editor (:q to exit!)
      sst                    - a C version of the Super Star Trek game
      dbasic eliza.bas       - a friendly therapist who wants to help you
      dbasic startrek.bas    - a Basic version of the Star Trek game
      pint startrek.p5       - a Pascal version of the Star Trek game
      pint basics.p5         - Tiny Basic, written in Pascal and implemented in C!
      jzip zork1.dat         - lose yourself in the world of Zork
      lua fact.lua           - generate factorials with the Lua scripting language
    
    So, what's NOT yet working on the P2? Well, the major ones are support for
    multi-threading (multi-cog programs are supported) and support for most of
    the P1 plugins. 
    
    Here is a more complete list ..
    
      - multithreading
      - EEPROM and Flash support
      - XMM support (there are no XMM boards for the P2 yet!)
      - multi-CPU support (there are no multi-CPU P2 boards yet!)
      - Code::Blocks support
      - USB keyboard/mouse plugins
      - HDMI plugins
      - SPI plugins
      - sound plugins
      - graphics plugins 
    
    Some of these will be forthcoming in the next release.
    

    Enjoy!

    Ross.
  • Thanks Ross! Nice to see that Icon back on the Desktop.
  • RossHRossH Posts: 5,334
    I just refreshed the Catalina 3.15 installer on Sourceforge - just a few minor documentation changes. Not worth downloading again if you have already done so - just get a copy of the file attached here.

    Ross.
  • RossHRossH Posts: 5,334
    edited 2019-05-19 02:34
    I have just released Catalina 3.15.1 on SourceForge (http://catalina-c.sourceforge.net/)

    Catalina 3.15.1 is the second release of Catalina supporting the Propeller 2. It adds Linux support, Code::Blocks 17.12 support, and Catalina Optimizer support, as well as some minor Catalyst improvements, some clean up and many bug fixes.

    However, it adds no new Propeller 1 functionality. It is primarily intended for those experimenting with or developing for the Propeller 2.

    If you have a Propeller 1, you should continue to use release 3.13.2 until further notice.

    Here is the updated WhatsNew file:
    Catalina release 3.15.1 is a full release. You can install this over an 
    existing version of Catalina, but it is recommended that you instead uninstall 
    any previous Catalina release before installing, or install this release to a 
    different location. 
    
    If you are installing under Linux, you should execute the following command 
    to set your permissions correctly after installing (this command is a script 
    in the Catalina bin directory):
    
       Set_Linux_Permissions
    
    The following changes have been made since the previous release of Catalina. 
    If you have not used a previous release of Catalina, you can ignore the
    following list:
    
    RELEASE 3.15.1
    
    1. This is the second Propeller 2 release. It is primarily an internal "clean
       up" and bug fix release for the previous release (3.15) and it significantly
       extends the P2 support - but it does not add much new functionality.
    
    2. Code::Blocks is now fully supported for both the Propeller 1 and 2, and
       under both Linux and Windows. The version of Code::Blocks is now 17.12, but
       this should not make any difference to existing Code::blocks projects or
       workspaces. Note that on Linux you may need to build Code::Blocks from
       source - the required source code changes are minimal, and are provided in 
       this release.
    
    3. Linux is now fully supported for both the Propeller 1 and 2.
    
    4. The Catalina Optimizer now supports all the Propeller 2 memory models - i.e. 
       TINY, COMPACT and NATIVE.
    
    5. Payload now tries to load both ".bin" and ".binary" files if no extension
       is specified.
    
    6. Various minor improvements in Catalyst:
    
       - better key handling in the vi text editor
       - the 'cat' command has been vastly speeded up
       - improve the 'dir' built-in command
    
    7. Since the Propeller 1 and 2 binaries are incompatible, Catalina no longer
       includes any precompiled binary files for any platform, although the
       documentation may still say otherwise. 
    
    8. Some sanity testing has been done on the Propeller 1 support, and this 
       release should now correctly compile all Propeller 1 programs (the original 
       3.15 release had some problems in this area). However, not all Propeller 1 
       platforms and variants have been tested yet, so it is still recommended
       that the previous Catalina release (3.13.2) be used for the Propeller 1.
    
       Note that you can have multiple versions of Catalina installed - you just
       need to install each to a different location, and set your LCCDIR 
       environment variable according to which one you want to use.
    
    9. The release previous 3.15 notes (below) have been updated where required 
       for the 3.15.1 release, and are still relevant:
    
    RELEASE 3.15
    
    1. This is the initial Propeller 2 (aka Prop2, P2 or p2) release. 
    
       The support for the original Propeller (aka Propeller 1, Prop1, P1 or p1) 
       is essentially unchanged, and should still work the same as in the previous
       release - but this has not been extensively tested. This release is intended
       for those who wish to preview Catalina's P2 support. If you only have a P1
       chip, you would be best advised to use the previous release of Catalina 
       (3.13.2).
    
       To compile C programs for the p2, you just specify the option -p2 to 
       Catalina (note the lower case 'p' - upper case P means something else). 
       The other Catalina command line options remain essentially unchanged, 
       although not all of them are currently supported on the P2. A summary
       of the command line options relevant to the P2 is contained in the 
       document "Catalina P2 Command Summary"
    
       For example, to compile "hello_world.c" for the P2_EVAL board, you might
       use a command such as:
    
          catalina -p2 hello_world.c -lc -C P2_EVAL
    
       As usual with Catalina, an option like "-C P2_EVAL" is used to specify the 
       board support package to use for various things (such as pin definitions
       and clock speeds) - in this case for the P2_EVAL board. See the file
       "Catalina_platforms.inc" in the target_p2 directory for details on the
       supported platforms.
    
       The -p2 option does the following ...
    
       -  automatically appends "_p2" to the target directory to use. So in this
          case the command would use "target_p2" instead of "target" (which is 
          the default target for the P1).
    
       -  automatically appends "_p2" to any libraries specified. So in this case
          the command would use the library "lib_p2/libc" instead of "lib/libc" 
          (which is the standard C library for the P1).
    
       -  predefines the Catalina symbol P2, and the C symbol __CATALINA_P2, which
          can be used in various source files to indicate the program is being
          compiled for the P2.
    
       -  selects p2asm as the assembler to use.
    
       The catbind program also accepts the -p2 option (this option is passed
       automatically when catbind is invoked via the catalina command).
    
       All of the supported "build_all" batch files will automatically add the -p2
       and also the -C NATIVE command line options if a symbol starting with the
       letters P2 (e.g. P2_EVAL or P2D2) is specified as the first parameter. For
       example, in the "demos" subdirectory, you can use a command like: 
    
          build_all P2_EVAL
    
       All the "copy_all" batch files will detect if a ".bin" file has been 
       produced (which is the default on the P2) instead of a ".binary" file
       (which is the default on the P1) and copy the appropriate binaries.
    
       You should also refer to the file "README_P2.TXT", which provides a quick 
       overview of the status of the P2 support, and getting started with the
       P2_EVAL board.
    
    
    2. There are three memory models currently supported on the P2:
    
       TINY    - this model is identical to the TINY LMM model on the P1. This is
                 the default model, although on the P2 "tiny" is no longer really
                 an appropriate name since the Hub RAM on the P2 is 512Kb. This 
                 memory model can be specified by using the option -x0 or -C TINY 
                 on the command line. Note that on the P2 you would usually want
                 to use the NATIVE memory model described below.
     
       COMPACT - this model is identical to the COMPACT model on the P1. This
                 can be specified by using the option -x8, or -C COMPACT on the
                 command line. Using this option also specifies that the library
                 is prefixed with "compact_", so if you specify all of -p2, -lc
                 and -C COMPACT the library that is actually used will be 
                 "compact_lib_p2/libc"
    
       NATIVE  - this model is new for the P2. This is specified by using the 
                 option -x11, or -C NATIVE on the command line. This option is 
                 automatically selected in many of the "build_all" batch files.
                 Using this option also specifies that the library is prefixed
                 with "native_", so if you specify all of -p2, -lc and -C NATIVE, 
                 the library that is actually used will be "native_lib_p2/libc"
    
    3. The default assembler used for the P2 is a slightly modified version of
       p2asm - so the output of the compilation is now a ".bin" file, instead 
       of a ".binary". There is no support for ".eeprom" output on the P2 yet.
    
       The only changes to p2asm required for Catalina are two definitions in 
       the file symsubs.h:
    
             #define MAX_SYMBOLS    8000
             #define MAX_SYMBOL_LEN   65
    
    4. The Catalina optimizer is supported for all the memory models on the P2.
       
    5. The payload program loader now automatically detects if a Propeller 2 is
       present, and uses the Propeller 2's built-in serial loader if so. There is 
       therefore no need for an option to specify the p2 (which is just as well,
       because payload uses the -p option to select the port to use). If you have
       both P1 and P2 chips connected, you will need to specify the port to use.
    
       Note that the p2 detection seems to require the payload '-z' option for 
       best results, so a command to download a program to a p2 and then invoke 
       the terminal emulator at 230400 baud would be something like:
    
             payload -b 230400 -i -z startrek.bin
    
       It is also now possible to use the interactive mode of payload even if
       no files are loaded - in this case the port must be explicitly specified
       (and some of the other options are ineffective). For example:
    
             payload -i -p4 -b 230400
    
       The payload loader will automatically try both ".bin" and ".binary"
       extensions if none is specifed on the command line.
    
    6. P2 platform-specific definitions are all specified in the one file, 
       (called "Catalina_platforms.inc") in the target_p2 directory. This is 
       significantly different from the approach used on the p1, which had so 
       many platforms and plugins supported that it seemed best to use separate 
       files for each one. This may change in future, but for the moment just 
       add any new platforms to Catalina_platforms.inc - see the examples in 
       that file.
    
       The P2 target files are also significantly simpler overall those than for 
       the P1 - because the P1 used a mixture of SPIN and PASM to specify and 
       load various plugins, whereas for the P2 everything is done in PASM. The
       P1 also required all kinds of tricks to get programs of any size to load
       and run, which are (as yet!) not required on the P2. This means there is
       as yet no need for a P2 equivalent of the P1's "basic" and "minimal" 
       targets, although this also may change in future releases.
    
    7. There is no multi-threading support on the P2 yet, so the demos in the 
       "demos\multithread" subdirectory will not yet run on the P2.
    
    8. There is no debugger support on the P2 yet, so the demos in the 
       "demos\debug" subdirectory will not yet run on the P2.
    
    9. There are no plugins other than a simple serial driver, so the demos in
       the following subdirectories will not yet run on the P2:
          demos\debug
          demos\graphics
          demos\vgraphics
          demos\spi
          demos\serial4
          demos\sound
          demos\tty
          demos\tty256
    
    10. The "demos\spinc" directory has not yet been updated for the P2 yet.
    
    11. There is no multi-CPU or proxy driver support on the P2 yet.
    
    12. There is no XMM support on the P2 yet.
    
    13. There are no EEPROM or FLASH loaders on the P2 yet.
    
    14. There is no specific SDCARD loader support on the P2, since this is no 
        longer required. Any .bin program can be loaded from the SD Card. To
        access the SD card, compile with one of the 'extended' version of the 
        standard C library (e.g. using the option -lcx instead of -lc).
    
    15. Fixed a problem in Dumbo Basic that caused startrek.bas to fail.
    
    16. Note that by default, the "super star trek" (sst) program uses CR LF as 
        line terminators. To make this program display correctly in the payload 
        interactive mode, the -q1 option to payload needs to be used. 
        For instance:
    
          payload -b460800 -i -z -q1 sst.bin
    
    17. Minor change to xvi to take into account the faster clock speed of the P2.
        Also, for the moment the VT100 option is automatically selected when
        building xvi for the P2, since there are no other HMI options available
        than a simple serial VT100 style terminal that will make this program work
        correctly (e.g. the one used by payload if the -i option is used).
    
    18. Added row and column options to the payload interactive terminal. For
        instance, to set the terminal size to 80 columns and 50 rows, you can
        now use a command like:
    
           payload -i -g80,50 program.bin
    
        You can also specify the values in the environment variables PAYLOAD_ROWS
        and PAYLOAD_COLS if you don't want to specify them on every command.
        If values are specified on the command line, they override the environment
        variables. For example:
    
           set PAYLOAD_ROWS=50
           set PAYLOAD_COLS=80
           payload -i program.bin
    
    19. Added an option set the payload baud rate using a PAYLOAD_BAUD environment
        variable. For instance, to set the baud rate to 230400 baud for all
        payload command, you use a command like:
    
           set PAYLOAD_BAUD 
           payload program.bin
    
        If a baud rate is also specified on the command line, it overrides the 
        environment variable.
    
    20. Two new utilities have been added:
    
            bindump - dumps binary files in various useful text formats,
                      which can then be used in other Spin or C programs.
    
            spinpp  - a C-like preprocessor specifically for Spin files. 
    
    

    NOTE for Linux users: Please make sure you read the README.Linux file - since there is no installer provided for Linux, this file contains important information about installing both Catalina and Code::Blocks correctly.
  • RossHRossH Posts: 5,334
    edited 2019-06-15 10:43
    I have just posted Catalina 3.15.2 to SourceForge (https://sourceforge.net/projects/catalina-c).

    Catalina 3.15.2 is the third release of Catalina supporting the Propeller 2. It adds interrupt support, as well as some clean up and many bug fixes. However, it adds no new Propeller 1 functionality. It is primarily intended for those experimenting with or developing for the Propeller 2.

    Note that this is currently a Windows only release. A Linux version of this release will be forthcoming shortly.

    If you have a Propeller 1, you should continue to use release 3.13.2.

    Here is an extract from the README.WhatsNew file ...
    RELEASE 3.15.2
    
    1. This is the third Propeller 2 release. It is partly an internal "clean
       up" and bug fix release for the previous release (3.15.1), but it also 
       extends the P2 support.
    
    2. Added the ability to have C functions as interrupts. New demo programs
       have been added in the "demos\interrupts" subdirectory. Interrupts can
       be used in all the supported P2 memory models - i.e. COMPACT, TINY and 
       NATIVE. There is a new header file (catalina_interrupts.h) that defines
       all the interrupt related functions, and a new C library (libinterrupts)
       must be specified on the command line - see the demos\interrupts 
       subdirectory for examples.
    
    3. Fixed a few issues with the Catalina Optimizer, which could lead to errors
       (e.g. undefined symbols) during compilation, and/or sub-optimal optimization
       in some cases.
    
    4. Fixed an issue with P1 support, that meant that COMPACT programs on the P1
       could not be compiled with the Catalina Optimizer. The Homespun assembler 
       support is still broken in this scenario, but Spinnaker (which is the 
       default assembler for the P1) now works correctly.
    
    5. Fixed an issue with spinpp, which could have caused programs to fail
       because C macro substitution was being performed in hex constants like 
       $C1 - so if (for example) you had such a constant in your program and
       then defined the symbol C1, the code generated would contain $1 for this
       constant instead of $C1.
    
    6. The semantics of the _lockset() function on the P1 have been modified. The 
       difference is that _lockset() now returns 1 (i.e. TRUE) on success, whereas 
       it used to return 0 (FALSE) which was in line with the SPIN semantics, but 
       misleading for C programs. On the P2, lockset has always returned 1 on 
       success. The ACQUIRE and RELEASE macros in catalina_cog.h have been updated
       accordingly, so programs which used these rather than calling _lockset() and
       _lockclr() directly will not be affected.
    
    
  • RossHRossH Posts: 5,334
    Just a quick update ...

    I now have the Catalina C source level debugger working on the P2. You can debug all the P2 modes - i.e. LMM, Compact and the new Native mode.

    I use a separate serial interface for the debugger. On the P2 EVAL board this can be the main USB port (if it is not being used by the program itself), the second USB port (if the board is modified to enable it), or a PropPlug plugged into any of the I/O pin breakout headers.

    Crossing this item off my list means Catalina for the P2 is now essentially complete. By this I mean that Catalina is now as functional on the P2 as it was on the P1. Of course on the P2 Catalina does not yet include the many plugins that were supported on the P1, but these are not actually a part of Catalina - they were part of the many board support packages. In most cases an equivalent does not even exist for the P2 yet.

    Also, I have decided to do without XMM support, at least for now - I may revisit that in the future, but I currently expect that Parallax will release a range of P2 chips with larger Hub RAM sizes once the initial P2 is complete. This would make XMM unnecessary.

    I will issue a new release that includes the debugger in a few days.

    Ross.
  • Cluso99Cluso99 Posts: 18,066
    Ross, don’t expect to see any P2s with more than 1MB of hub ram as 20 bits is heavily baked into the instructions. Also it would need a finer geometry than 160nm and the I/o ring frame is baked to 160nm too, which makes moving to a finer geometry another expensive exercise from what I understand.
    So any move beyond 1MB will be P3.
  • jmgjmg Posts: 15,140
    RossH wrote: »
    Also, I have decided to do without XMM support, at least for now - I may revisit that in the future, but I currently expect that Parallax will release a range of P2 chips with larger Hub RAM sizes once the initial P2 is complete. This would make XMM unnecessary.
    Cluso99 wrote: »
    Ross, don’t expect to see any P2s with more than 1MB of hub ram as 20 bits is heavily baked into the instructions. Also it would need a finer geometry than 160nm and the I/o ring frame is baked to 160nm too, which makes moving to a finer geometry another expensive exercise from what I understand.
    So any move beyond 1MB will be P3.

    On top of that, the P2 is die-limited at 512k and the current process, so that rather excludes even the possible step to 1MB, without a change in package and/or process.

    What may be possible, as a P2.5, is Verilog to support XIP, on external memory. That would be same-package, same process smaller step.
    For now, 1 COG could be used to emulate that XIP operation, and that may prove good enough.
  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    RossH wrote: »
    Also, I have decided to do without XMM support, at least for now - I may revisit that in the future, but I currently expect that Parallax will release a range of P2 chips with larger Hub RAM sizes once the initial P2 is complete. This would make XMM unnecessary.
    Cluso99 wrote: »
    Ross, don’t expect to see any P2s with more than 1MB of hub ram as 20 bits is heavily baked into the instructions. Also it would need a finer geometry than 160nm and the I/o ring frame is baked to 160nm too, which makes moving to a finer geometry another expensive exercise from what I understand.
    So any move beyond 1MB will be P3.

    On top of that, the P2 is die-limited at 512k and the current process, so that rather excludes even the possible step to 1MB, without a change in package and/or process.

    What may be possible, as a P2.5, is Verilog to support XIP, on external memory. That would be same-package, same process smaller step.
    For now, 1 COG could be used to emulate that XIP operation, and that may prove good enough.

    As I understand it, the ring frame can be trimmed/expanded. This is how Chip expects to be able to do smaller P2's which of course will have a different package/footprint. So I would also expect the converse is true - the frame could be expanded for a larger die to include 1MB. Maybe that would be a QFP144 with ~10mm2 die?

    But beyond 1MB we get into the instruction set issues where 20 bits has been baked into the design.
  • we need a a20 gate!

    Enjoy!

    Mike
Sign In or Register to comment.