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 ...
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?
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.
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.
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!!!
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
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
Comments
Eventually, yes. At present, I am just porting code the easiest way I can. There's so much to do ...
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!
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.
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
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.
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.
Mike
Just rename SST.BIN as _BOOT_P2. BIX and the enable the autoboot from SD pullup/switch and it will boot on powerup
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!
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.
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.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.
Yes, that'll work for all the timeouts in the boot code.
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.
Ross.
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.
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 ...
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.
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.
Enjoy!
Mike