@evanh said:
... Where does Catalina hubRAM use start at?
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
@evanh said:
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
@Wuerfel_21 said:
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example: flash_payload catalyst.bin -i
More details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
@evanh said:
Thanks. I've started poking but nothing strongly stood out.
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
@evanh said:
At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin.
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
@evanh said:
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
@RossH said:
... Also, what would be the equivalent on a P2 Edge board?
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example: flash_payload catalyst.bin -i
More details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
Just thought I'd add a postscript to this. I have been booting Catalyst exclusively from FLASH for over a week now, and running at 300Mhz and with an SD write delay of zero, and have seen no SD card lockups. I have tried two different SD cards (a Verbatim 8Gb and a Sandisk Extreme 32Gb). I have been running extensive Catalina and Cake compilations which make heavy use of the SD card file system, and which can run for up to an hour.
My tentative conclusion is that the SD card lockup occurs on booting from the SD card only.
Another benefit of booting from FLASH is that it speeds up Catalyst as a whole, particularly programs that rely heavily on script execution (such as Catalina itself). For example, here are my current Catalina compilation times on my P2-EC32MB:
I am yet to decide whether or not to make zero the default delay on SD writes - currently, it is still 10ms. I think I will leave it at that for the next release, but it is configurable on the Catalina command-line, so you can easily set it to zero.
This is a full release. It updates Cake, makes the SD Card write delay configurable, enhances Catalyst, and fixes a few minor issues.
Here is the relevant extract from the README.TXT:
New Functionality
-----------------
1. A version of dirent.h, which defines the functions opendir(), readdir(),
closedir() and realpath(). These functions are not part of any C standard,
but are required by Cake.
2. Cake has been updated to version 0.12.55.
3. Catalina now disables Cake's use of colors in error and warning messages
by default, because Geany does not support it. However, for command-line
or terminal emulator use, colors can be re-enabled by defining the Catalina
symbol CAKE_COLOR, e,g, by adding -C CAKE_COLOR to the Catalina command.
For example:
catalina hello_99.c -lci -C99 -C CAKE_COLOR
4. printf() (and fprintf() etc) now supports "ll" as a length specified, to
indicate a long long - for example "%llu" indicates an "unsigned long long".
Note that in Catalina long longs are the same as longs, so in practice both
"%lu" and "%llu" will now do the same thing, whereas in previous releases
the former would have printed 100 as "100", whereas the latter would have
printed it as "100ul". This change was required to support Cake.
5. The Propeller 2 SD card driver (/target/p2/cogsd.t) now allows the SD card
delay (in clock ticks) to be specified using the Catalina symbol SD_DELAY
during compilation. For example, to set it to zero use a command such as:
catalina -p2 -lcx program.c -C SD_DELAY=0
Defining the Catalina symbol NO_SD_DELAY also sets the SD_DELAY to zero,
but can be used in build_all scripts. Using NO_SD_DELAY overrides any
other specified SD_DELAY.
The default if not specified is 10ms, and the driver may not work properly
if this delay is altered.
6. In the Catalyst demos folder (demos/catalyst) there is now a build_p2_300
script, which builds Catalyst using a 300 Mhz clock speed (the default of
200Mhz is still used by the build_p2 script). So for example, building
Catalyst at 300 Mhz and with no SD_DELAY can be done with a command like:
build_p2_300 P2_EDGE PSRAM NO_SD_DELAY
Note that 300 baud and no SD_DELAY may not work for all programs, all SD
cards, or all Propeller 2 platforms.
7. Catalina no longer defines the symbols "win32", "_WIN32", "_M_IX86" "unix",
"i386", "linux" "__unix__", "_i386__", "__linux__", or "__signed__"
automatically on any platform. Not defining these symbols may make some
programs either not compile, or behave differently. If any of these symbols
are required, they can be defined on the command line (using -D).
For example:
catalina program.c -D__signed=signed
8. Catalina no longer defines the C symbols "__STRICT_ANSI__" or "__STDC__"
automatically because this can interfere with the use of Cake as the C
preprocessor. Not defining these symbols may make some programs either
not compile, or behave differently. If these symbols are required, they
can be defined on the command line (using -D). For example:
catalina program.c -D__STDC__=1
The C symbol _POSIX_SOURCE is still defined even though Catalina is not
fully POSIX compliant, because this symbol enables some necessary
definitions in the C header files.
9. The -u option to catalina means it does not delete intermediate files.
This is sometimes useful for debugging. On Catalyst (only) it now also
means to not run the pstrip utility, which 'strips' comments and blank
lines from the intermediate source code files (to reduce their size).
10. Allow -C USE_COLOUR to enable Cake's use of color (i.e. in addition to
-C USE_COLOR) and also use the Cake option -fdiagnostics-color=never to
disable the use of color.
11. The Catalyst "ls" command has been enhanced to add -a as a command line
option. This option includes ".", "..", volume ids and system and hidden
files in the listing output, which are now otherwise not included.
Also, directory contents are now listed for any directories specified by
the command line parameters (previously, a trailing "/" had to explicitly
be added to a directory name to print the contents of the directory).
Now including a trailing "/" means to list both the directory AND the
directory contents. So, for example:
ls /
will list the contents of the root directory and also the contents of
any subdirectories, whereas:
ls
will list just the contents of the root directory. Similarly:
ls -l bin/
will list the long details of the bin directory and also the long details
of the contents of the bin directory, whereas:
ls -l bin
will list just the long details of the contents of the bin directory.
Note that the -r flag can be used with or without a trailing "/" on the
directory names.
Fixed the column and line counting, so the "Continue?" prompt works
properly.
12. The Catalyst ls and cat utilities now autodetect the screen size if the
VGA, TV and VT100 compatible serial terminal HMI options are used (for
serial terminals other than a VT100 compatible terminal, screen size is
assumed to be 80x24).
Other Changes
-------------
1. The C include file limits.h (i.e. include/limits.h) was incorrectly
defining CHAR_MIN and CHAR_MAX as if chars were signed. Since chars are
unsigned in Catalina, these definitions were incorrect, and have been
changed to:
#define CHAR_MAX UCHAR_MAX
#define CHAR_MIN 0
Affected Windows, Linux and Catalyst.
2. Payload was incorrectly sending screen size in response to ESC[6n instead
of current cursor position when used in interactive mode. Affected Windows
and Linux.
3. Payload was misbehaving when "ESC [ nnn C" was sent and C was a very large
number (e.g. 999) when used in interactive mode. The linenoise library does
this to find the length of the line. Now, nnn is limited to the number of
character positions left on the current line. Affected Windows and Linux.
Ediit: I just noticed that in the README.TXT file I say "300 baud" where of course I meant "300 Mhz!" D'oh!
Ha! Logged into a new PC today, and found this old issue again, which I had forgotten about ...
In Windows 11, the default application to use when executing batch files etc now is the Terminal app, not the Windows command processor (i.e. cmd.exe).
The Terminal app is ok for simple command line use, but there are a few things (such as the payloadi batch script) that won't work correctly under the Terminal app. To make them work correctly, you can either go to "Settings" in the Terminal app, and set the "Default Terminal Application" to Windows Console Host (instead of Windows Terminal or Let Windows Decide).
Or ... you can open the properties of the "Catalina Command Line" desktop shortcut (and/or the Start menu entry) and change the Target (for Catalina 8.8.3) from: "C:\Program Files (x86)\Catalina_8.8.3\bin\catalina_cmd.bat"
to conhost.exe "C:\Program Files (x86)\Catalina_8.8\bin\catalina_cmd.bat"
Also, at least one of the Catalina Geany Build commands need updating. Change the Download and Interact command to:
conhost payloadi.bat %x "%p\%e" -b%b
Note the inclusion of the ".bat" suffix - this is required.
I will try and remember to fix this properly in the next release.
Windows Terminal isn't another shell - it's a new terminal emulator that's actually not broken in every conceivable way, unlike the ancient Console Host... It's a gem amidst all the other trash they've been adding to Windows. You can run cmd, PowerShell, WSL, or I think any other shell that will run on Windows inside of it.
Windows Terminal cannot be resized by an application running in it. This is the main functionality that conhost offers that Catalina's payload utility uses (when run in interactive mode).
Mostly on Windows, I just use the shell to run payload in non-interactive mode, and then use a proper terminal emulator, so I forgot about this annoying issue because I can do that from any of cmd.exe, Powershell or Terminal (or bash, for that matter).
Still, it can probably be fixed, so I will try to do so in the next release.
@RossH said:
Mostly on Windows, I just use the shell to run payload in non-interactive mode, and then use a proper terminal emulator, ...
Oh, how? Won't that tend to toggle DTR on the comport? Then you've lost the download.
PS: I've been avoiding using Payload on Linux because its interactive mode isn't terminal history friendly. I mostly use Loadp2 to download Catalina's binaries.
@RossH said:
Mostly on Windows, I just use the shell to run payload in non-interactive mode, and then use a proper terminal emulator, ...
Oh, how? Won't that tend to toggle DTR on the comport? Then you've lost the download.
PS: I've been avoiding using Payload on Linux because its interactive mode isn't terminal history friendly. I mostly use Loadp2 to download Catalina's binaries.
I have no problems with DTR.
On Windows, I use payload in simple interactive mode - i.e. with -i - for "load and run" tests, but if I want full terminal emulation I use payload with -Ivt100, which loads Catalina's full terminal emulator (i.e. comms.exe in VT100 mode) once the program is loaded.
Or you can use payload in non-interactive mode to just load the program and then use PuTTY. I have a saved PuTTY session called "Propeller" that specifies the port (in my case COM8 on Windows or /dev/ttyUSB0 on Linux), the baud rate (230400) and also selects the "Implicit CR in every LF" terminal option.
So, for instance, on Windows:
cd %LCCDIR%\demos\games
catalina -p2 -lci othello
then either:
payload -o2 othello -i
or
payload -o2 othello -Ivt100
or
payload -o2 othello
putty -load Propeller
On Linux you can either use payload in interactive mode or use PuTTY. So, for instance:
cd $LCCDIR\demos\games
catalina -p2 -lci othello
then either:
payload -o2 othello -i
or
payload -o2 othello
putty -load Propeller
Note: the payload -Ivt100 option on Linux tries to use minicom which I am sure used to work, but I could not make it do so just now - something in minicom must have changed, or there is a difference between Ubuntu and Debian Linux (I used to use minicom on Ubuntu). But PuTTY works on Debian.
EDIT: Just got minicom working again - it seems I had forgotten to de-select the "Hardware Flow Control" option, which I think must be set by default. So on Linux you CAN also say:
My main objective is to avoid any sort of self contained terminal emulation so then the local console's scroll back history can be used as capture, inline with the compile history.
Apologies for not making that clear. Loadp2 has worked in most situations. There was one compiler config that needed Payload ... don't remember at the moment.
@evanh said:
My main objective is to avoid any sort of self contained terminal emulation so then the local console's scroll back history can be used as capture, inline with the compile history.
So you want payload to load a program and then enter a "dumb" mode where it just keeps the serial port open and spits out whatever the program sends until you terminate it?
I can add that fairly easily, but if loadp2 already does it, then use that in the meantime.
Ok! That turned out to be easier than I thought, so here is a new version (8.8.4) of payload that implements a "dumb" terminal capability. I have included a windows binary, but on Linux or Pi OS you will have to compile it yourself - just unzip this stuff into Catalina's source/catalina directory (and either copy the binary to Catalina's bin directory or execute build_all)
To use it, you just specify dumb as the external terminal type (i.e. using the -I option, such as -I dumb). Here, I used the game of othello as an example (on Windows):
In dumb mode, payload does not do any terminal emulation - it just transfers characters between the Propeller program and the terminal window in which it is executing. If the Propeller program does any "clever" stuff (e.g. cursor movement, screen manipulation, applying colors etc) this will work if that capability is implemented by the terminal window in which it is executing. In general, this means many things will work quite smoothly (in Windows) using cmd.exe, conhost or the terminal app, or (in Linux) in any window type derived from an xterm - but some of these are even as complete a terminal emulator as payload's simple internal one, let alone a proper external terminal emulator. So while many things will work, some will not. If you need everything to work, use the -I vt100 payload option on Windows (which uses Comms) or PuTTY on Linux.
To exit dumb mode (and return to the terminal window), press CTRL-D twice. There is a known issue with programs that use the linenoise library (such as Catalyst) which means this may not work at the beginning of a line - if it does not, just first enter a space (or any other character) and then press CTRL-D twice.
Payload turns echo off when it enters dumb mode, and restores it when it exits. If it fails to exit gracefully, echo may still be turned off in the terminal window. On Linux, you can turn it back on by entering stty echo (even if you can't see what you are typing!). On Windows I do not know of an equivalent command - you may need to close the window and open another.
Comments
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
Ross.
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example:
flash_payload catalyst.bin -iMore details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
...
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Scratching my head a little here.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
Here's the supply volts for the power cycle that succeeds in resetting that SD card:
And the one that doesn't succeed:
Neither of them are even close to achieving the SD spec for power cycling. Which is to fall below 0.5 Volt for at least 1.0 millisecond.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
Ross.
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.
Just thought I'd add a postscript to this. I have been booting Catalyst exclusively from FLASH for over a week now, and running at 300Mhz and with an SD write delay of zero, and have seen no SD card lockups. I have tried two different SD cards (a Verbatim 8Gb and a Sandisk Extreme 32Gb). I have been running extensive Catalina and Cake compilations which make heavy use of the SD card file system, and which can run for up to an hour.
My tentative conclusion is that the SD card lockup occurs on booting from the SD card only.
Another benefit of booting from FLASH is that it speeds up Catalyst as a whole, particularly programs that rely heavily on script execution (such as Catalina itself). For example, here are my current Catalina compilation times on my P2-EC32MB:
program lines time (approx) (mm:ss) ========= ======== ======= hello 5 3:25 othello 500 3:53 startrek 2200 13:49 chimaera 5500 33:20 dbasic 13500 52:10I am yet to decide whether or not to make zero the default delay on SD writes - currently, it is still 10ms. I think I will leave it at that for the next release, but it is configurable on the Catalina command-line, so you can easily set it to zero.
Ross.
Catalina 8.8.3 has been released on GitHub and SourceForge.
This is a full release. It updates Cake, makes the SD Card write delay configurable, enhances Catalyst, and fixes a few minor issues.
Here is the relevant extract from the README.TXT:
New Functionality ----------------- 1. A version of dirent.h, which defines the functions opendir(), readdir(), closedir() and realpath(). These functions are not part of any C standard, but are required by Cake. 2. Cake has been updated to version 0.12.55. 3. Catalina now disables Cake's use of colors in error and warning messages by default, because Geany does not support it. However, for command-line or terminal emulator use, colors can be re-enabled by defining the Catalina symbol CAKE_COLOR, e,g, by adding -C CAKE_COLOR to the Catalina command. For example: catalina hello_99.c -lci -C99 -C CAKE_COLOR 4. printf() (and fprintf() etc) now supports "ll" as a length specified, to indicate a long long - for example "%llu" indicates an "unsigned long long". Note that in Catalina long longs are the same as longs, so in practice both "%lu" and "%llu" will now do the same thing, whereas in previous releases the former would have printed 100 as "100", whereas the latter would have printed it as "100ul". This change was required to support Cake. 5. The Propeller 2 SD card driver (/target/p2/cogsd.t) now allows the SD card delay (in clock ticks) to be specified using the Catalina symbol SD_DELAY during compilation. For example, to set it to zero use a command such as: catalina -p2 -lcx program.c -C SD_DELAY=0 Defining the Catalina symbol NO_SD_DELAY also sets the SD_DELAY to zero, but can be used in build_all scripts. Using NO_SD_DELAY overrides any other specified SD_DELAY. The default if not specified is 10ms, and the driver may not work properly if this delay is altered. 6. In the Catalyst demos folder (demos/catalyst) there is now a build_p2_300 script, which builds Catalyst using a 300 Mhz clock speed (the default of 200Mhz is still used by the build_p2 script). So for example, building Catalyst at 300 Mhz and with no SD_DELAY can be done with a command like: build_p2_300 P2_EDGE PSRAM NO_SD_DELAY Note that 300 baud and no SD_DELAY may not work for all programs, all SD cards, or all Propeller 2 platforms. 7. Catalina no longer defines the symbols "win32", "_WIN32", "_M_IX86" "unix", "i386", "linux" "__unix__", "_i386__", "__linux__", or "__signed__" automatically on any platform. Not defining these symbols may make some programs either not compile, or behave differently. If any of these symbols are required, they can be defined on the command line (using -D). For example: catalina program.c -D__signed=signed 8. Catalina no longer defines the C symbols "__STRICT_ANSI__" or "__STDC__" automatically because this can interfere with the use of Cake as the C preprocessor. Not defining these symbols may make some programs either not compile, or behave differently. If these symbols are required, they can be defined on the command line (using -D). For example: catalina program.c -D__STDC__=1 The C symbol _POSIX_SOURCE is still defined even though Catalina is not fully POSIX compliant, because this symbol enables some necessary definitions in the C header files. 9. The -u option to catalina means it does not delete intermediate files. This is sometimes useful for debugging. On Catalyst (only) it now also means to not run the pstrip utility, which 'strips' comments and blank lines from the intermediate source code files (to reduce their size). 10. Allow -C USE_COLOUR to enable Cake's use of color (i.e. in addition to -C USE_COLOR) and also use the Cake option -fdiagnostics-color=never to disable the use of color. 11. The Catalyst "ls" command has been enhanced to add -a as a command line option. This option includes ".", "..", volume ids and system and hidden files in the listing output, which are now otherwise not included. Also, directory contents are now listed for any directories specified by the command line parameters (previously, a trailing "/" had to explicitly be added to a directory name to print the contents of the directory). Now including a trailing "/" means to list both the directory AND the directory contents. So, for example: ls / will list the contents of the root directory and also the contents of any subdirectories, whereas: ls will list just the contents of the root directory. Similarly: ls -l bin/ will list the long details of the bin directory and also the long details of the contents of the bin directory, whereas: ls -l bin will list just the long details of the contents of the bin directory. Note that the -r flag can be used with or without a trailing "/" on the directory names. Fixed the column and line counting, so the "Continue?" prompt works properly. 12. The Catalyst ls and cat utilities now autodetect the screen size if the VGA, TV and VT100 compatible serial terminal HMI options are used (for serial terminals other than a VT100 compatible terminal, screen size is assumed to be 80x24). Other Changes ------------- 1. The C include file limits.h (i.e. include/limits.h) was incorrectly defining CHAR_MIN and CHAR_MAX as if chars were signed. Since chars are unsigned in Catalina, these definitions were incorrect, and have been changed to: #define CHAR_MAX UCHAR_MAX #define CHAR_MIN 0 Affected Windows, Linux and Catalyst. 2. Payload was incorrectly sending screen size in response to ESC[6n instead of current cursor position when used in interactive mode. Affected Windows and Linux. 3. Payload was misbehaving when "ESC [ nnn C" was sent and C was a very large number (e.g. 999) when used in interactive mode. The linenoise library does this to find the length of the line. Now, nnn is limited to the number of character positions left on the current line. Affected Windows and Linux.Ediit: I just noticed that in the README.TXT file I say "300 baud" where of course I meant "300 Mhz!" D'oh!
Ha! Logged into a new PC today, and found this old issue again, which I had forgotten about ...
In Windows 11, the default application to use when executing batch files etc now is the Terminal app, not the Windows command processor (i.e. cmd.exe).
The Terminal app is ok for simple command line use, but there are a few things (such as the payloadi batch script) that won't work correctly under the Terminal app. To make them work correctly, you can either go to "Settings" in the Terminal app, and set the "Default Terminal Application" to Windows Console Host (instead of Windows Terminal or Let Windows Decide).
Or ... you can open the properties of the "Catalina Command Line" desktop shortcut (and/or the Start menu entry) and change the Target (for Catalina 8.8.3) from:
"C:\Program Files (x86)\Catalina_8.8.3\bin\catalina_cmd.bat"to
conhost.exe "C:\Program Files (x86)\Catalina_8.8\bin\catalina_cmd.bat"Also, at least one of the Catalina Geany Build commands need updating. Change the Download and Interact command to:
conhost payloadi.bat %x "%p\%e" -b%bNote the inclusion of the ".bat" suffix - this is required.
I will try and remember to fix this properly in the next release.
Really?! So with PowerShell that's three M$ supplied shells for Windoze that hardly anyone uses.
Windows Terminal isn't another shell - it's a new terminal emulator that's actually not broken in every conceivable way, unlike the ancient Console Host... It's a gem amidst all the other trash they've been adding to Windows. You can run cmd, PowerShell, WSL, or I think any other shell that will run on Windows inside of it.
Ha, didn't know Windoze had such distinctions. I guess that begs the question of what does Catalina need from Conhost?
Windows Terminal cannot be resized by an application running in it. This is the main functionality that conhost offers that Catalina's payload utility uses (when run in interactive mode).
Mostly on Windows, I just use the shell to run payload in non-interactive mode, and then use a proper terminal emulator, so I forgot about this annoying issue because I can do that from any of cmd.exe, Powershell or Terminal (or bash, for that matter).
Still, it can probably be fixed, so I will try to do so in the next release.
Ross.
Oh, how? Won't that tend to toggle DTR on the comport? Then you've lost the download.
PS: I've been avoiding using Payload on Linux because its interactive mode isn't terminal history friendly. I mostly use Loadp2 to download Catalina's binaries.
I have no problems with DTR.
On Windows, I use payload in simple interactive mode - i.e. with -i - for "load and run" tests, but if I want full terminal emulation I use payload with -Ivt100, which loads Catalina's full terminal emulator (i.e. comms.exe in VT100 mode) once the program is loaded.
Or you can use payload in non-interactive mode to just load the program and then use PuTTY. I have a saved PuTTY session called "Propeller" that specifies the port (in my case COM8 on Windows or /dev/ttyUSB0 on Linux), the baud rate (230400) and also selects the "Implicit CR in every LF" terminal option.
So, for instance, on Windows:
then either:
or
or
On Linux you can either use payload in interactive mode or use PuTTY. So, for instance:
then either:
or
Note: the payload -Ivt100 option on Linux tries to use minicom which I am sure used to work, but I could not make it do so just now - something in minicom must have changed, or there is a difference between Ubuntu and Debian Linux (I used to use minicom on Ubuntu). But PuTTY works on Debian.
EDIT: Just got minicom working again - it seems I had forgotten to de-select the "Hardware Flow Control" option, which I think must be set by default. So on Linux you CAN also say:
Ross.
My main objective is to avoid any sort of self contained terminal emulation so then the local console's scroll back history can be used as capture, inline with the compile history.
Apologies for not making that clear. Loadp2 has worked in most situations. There was one compiler config that needed Payload ... don't remember at the moment.
So you want payload to load a program and then enter a "dumb" mode where it just keeps the serial port open and spits out whatever the program sends until you terminate it?
I can add that fairly easily, but if loadp2 already does it, then use that in the meantime.
Ross.
Cool, thanks. No rush.
Ok! That turned out to be easier than I thought, so here is a new version (8.8.4) of payload that implements a "dumb" terminal capability. I have included a windows binary, but on Linux or Pi OS you will have to compile it yourself - just unzip this stuff into Catalina's source/catalina directory (and either copy the binary to Catalina's bin directory or execute build_all)
To use it, you just specify dumb as the external terminal type (i.e. using the -I option, such as -I dumb). Here, I used the game of othello as an example (on Windows):
Here is what you see:
A few things to note:
In dumb mode, payload does not do any terminal emulation - it just transfers characters between the Propeller program and the terminal window in which it is executing. If the Propeller program does any "clever" stuff (e.g. cursor movement, screen manipulation, applying colors etc) this will work if that capability is implemented by the terminal window in which it is executing. In general, this means many things will work quite smoothly (in Windows) using cmd.exe, conhost or the terminal app, or (in Linux) in any window type derived from an xterm - but some of these are even as complete a terminal emulator as payload's simple internal one, let alone a proper external terminal emulator. So while many things will work, some will not. If you need everything to work, use the -I vt100 payload option on Windows (which uses Comms) or PuTTY on Linux.
To exit dumb mode (and return to the terminal window), press CTRL-D twice. There is a known issue with programs that use the linenoise library (such as Catalyst) which means this may not work at the beginning of a line - if it does not, just first enter a space (or any other character) and then press CTRL-D twice.
Payload turns echo off when it enters dumb mode, and restores it when it exits. If it fails to exit gracefully, echo may still be turned off in the terminal window. On Linux, you can turn it back on by entering stty echo (even if you can't see what you are typing!). On Windows I do not know of an equivalent command - you may need to close the window and open another.
Let me know of any issues.
Ross.