Anyone who thinks Chip would have wasted a bit by using 20 bits for addressing if he thought he could get away with 19 either doesn't know Chip very well, or hasn't studied the Propeller chips in very much detail
Also, using the current methods of XMM on the P2 would be like using a Lamborghini to tow a hay cart. Yes, you could do it - but why would you?
We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.
As for XMM, I agree it would be insane for the P2 to execute limp from serial memory although that might be suitable for Spin2 perhaps, but then again a single Spin2 bytecode gets a lot more done than an XMM opcode, so it will never need the extra memory.
We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.
We have FPGA P2s that have 1MB or 16 cogs but current silicon couldn't squeeze all that in as the die was already quite large so 16 cogs got reduced to 8 and 1MB RAM got reduced to 512kB.
Remember Moore's Law? Check again in 18 months
Parallax is already using a fairly old process node, because the price goes up rapidly as the feature geometry shrinks.
So, less a matter of Moore's Law, and more a feature of supply and demand.
Chip was surprised at how much the next geometries had come down. But the ringframe would need to be re-done for 120nm or 90nm and that costs $$$.
IIRC Chip even mentioned 56nm??? Now that would be a P3 with 2-4MB and 32 cogs at 1+GHz
This is a full release that supports both the P1 and the P2. It includes both Windows and Linux releases, 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, because the P1 support has not been extensively tested (P1 users should continue using release 3.13.2).
Here are the latest changes (see the README.WhatsNew file for a complete list of all changes since release 3.13.2) ...
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.3
1. This is the fourth Propeller 2 release. It is partly an internal "clean
up" and bug fix release for the previous release (3.15.2), but it also
extends the P2 support.
2. Add P2 support for the BlackBox debugger. It now supports TINY (LMMM),
COMPACT, and NATIVE modes on the P2. The BlackBox debugger will detect
the P2 automatically, so it requires no new command-line options. The
debugger requires a serial port connection to the P2, which (by default)
is implemented on pins 50 & 52. This allows a PropPlug to be used on the
P2 EVAL board, plugged on to the top-right I/O pin header.
3. Fixed an issue with BlackBox on both the P1 and P2 that meant in COMPACT
mode, the contents of register r0 could not be displayed by name (i.e.
using a "read r0" command - it could be displayed by saying "read cog 0").
4. Add P2 support for the BlackCat debugger. The BlackCat debugger was
originally developed by Bob Anderson, and the functionality is very
similar to BlackBox, except that it has a graphical user interface.
Note that (unlike BlackBox) BlackCat is provided in binary form only, and
that BlackCat is a Windows-only application.
5. There is a new "flash_payload" utility, which programs the P2_EVAL Flash
with an auto-executing version of any Catalina program binary. This is
based on the Flash_Loader_1.2.spin2 program developed by ozpropdev.
The parameters accepted by the flash_payload utility are identical to
those for the "payload" utility, except that the first parameter MUST be
the filename to be loaded. For example:
flash_payload startrek -p4 -b230400 -z -i
Note that to program the FLASH on the P2_EVAL, you must first remove any
SD Card, and also make sure that the FLASH microswitch is turned OFF, or
payload will report that it cannot find the P2.
Once programmed, you must turn the FLASH microswitch ON to boot your
program automatically from FLASH (the P2 may also require a re-boot).
Turn it off again to boot from SD Card, or to load programs serially.
Note that FLASH programming sometimes fails. If it does not seem to
program correctly, try repeating the procedure.
6. Fixed some issues with the Catalina Optimizer P2 support that led to
some erroneous results or less than optimal optimization.
7. Added P2 clock definitions to catalina_cog.h, and updated the _clockinit(),
_clockmode() and _clockfreq() functions to work correctly for the P2,
and a new test program (test_p2_clock.c) in the "demos" folder that
demonstrates it.
8. Fixed a bug in the HMI plugin that caused some floating point operations
to fail in programs compiled in CMM (COMPACT) mode.
9. Fixed a bug that prevented the Propeller rebooting on program exit in
LMM & CMM modes.
10. Fixed a compiler bug that could lead to incorrect results in some
circumstances - e.g. when converting floating point values to integers
and vice-versa. This caused problems with programs like the "paranoia"
IEEE floating point test. Catalina now passes this test, with the
exception of some lack of precision in the pow() and exp() functions,
and some incorrect overflow handling related to "inf" values. These
defects should not affect most user programs.
Apart from a dearth of plugins, Catalina support for the P2 is now essentially complete. Unless there are major problems found in this release, I expect it will be the last release intended for the P2 only - I would like to return to having just a single stream of releases for both the P1 and the P2.
I really like the idea of a standard C library, like Eric's proposed. It would be awesome to have two C compilers, out of the gate, which cover the P2's hardware well.
I'm always behind the curve on C things, so please correct me if my thinking is wrong.
I really like the idea of a standard C library, like Eric's proposed. It would be awesome to have two C compilers, out of the gate, which cover the P2's hardware well.
I'm always behind the curve on C things, so please correct me if my thinking is wrong.
Yes, I'll release a version of the new P2 library for Catalina when we have finalized the definitions. Most of the functions are already there - it will just be a matter of tweaking the names etc.
Thanks for your efforts guys. I'm not much of a C programmer, but its great that this kind of thing is being considered in advance of the silicon arriving.
I just found a serious problem with Catalina's COMPACT memory model in the latest release. I have temporarily withdrawn it, and will post an amended release soon.
In the meantime, if you have already downloaded version 3.15.3, do not use the COMPACT memory model!
This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.
I have added Lua scripting to Catalina's payload program loader. Now with one command you can load a program and then automatically execute a Lua test script to validate that it executes correctly. Of course, the program currently has to use a serial interface to be verified, but I intend to add a similar capability to the Blackbox debugger so that scripts can be written to verify any program.
The number of modes and compilation options that Catalina supports was already getting crazy on the P1, and with the addition of the P2 the number of different possible compilation options for even a trivial "Hello, World!" type C program is now in the many, many dozens - it may even be in the hundreds.
Trivial errors had started to slip through my manual testing, so I knew I had to do something!
Here is a very simple program called "test_lua.c":
/*
* A simple program to test payload's new Lua scripting facility.
*
* Execute this program with a payload command like the following to
* automatically load and start both this program and the Lua script
* that verifies it generates the correct output:
*
* payload test_lua -z -b230400 -L test_lua.lua
*
*/
#include <stdio.h>
void main(void) {
int i;
char ch;
do {
ch = getchar();
} while (ch !='\n');
printf("program done!\n");
while(1) { };
}
And here is the Lua script ("test_lua.lua") that verifies it executes correctly:
--
-- Catalina adds four functions to Lua:
--
-- delay(milliseconds) : Just delay by the specified number of milliseconds.
--
-- send(string) : Send a string to the loaded program.
--
-- receive(count, timeout) : Receive up to 'count' characters from the loaded
-- program, with a timeout of 'timeout' milliseconds.
-- Reads are terminated by a linefeed, and the
-- characters received are returned as a string.
--
-- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded
-- program. The read is not terminated by a
-- linefeed, but will be terminated after 'timeout'
-- milliseconds. If 'prompt' is an empty string,
-- the read will be terminated by any character
-- (which will be returned).
--
-- NOTE: The script below uses the built-in Lua "error" function to report
-- errors - this is for testing only, as this immediately terminates the
-- script. Normally, it would be better to report the errors ourselves and
-- then terminate the script a bit more gracefully!
--
print("\nLua script started\n");
str1 = "Hello from Lua!\n";
str2 = "";
-- delay a few milliseconds (allows for the loaded program to start)
delay(250);
-- send a string to the loaded program
send(str1);
-- receive a string up to 100 characters, with a timeout of 1000 milliseconds
str2 = receive(100, 1000);
if (str1 == str2) then
print("Sent string echoed correctly:", str2);
else
error("Sent string NOT echoed correctly");
end
str1 = "done!"
str2 = "";
-- wait for a specified string, with a timeout of 1000 milliseconds
str2 = wait_for(str1, 1000);
if (str1 == str2) then
print("Received correct string:", str2, "\n");
else
error("Received incorrect string\n");
end
str2 = wait_for("\n", 1000);
if (str2 == "\n") then
print("Received expected linefeed character\n");
else
error("Received unexpected character\n");
end
print("Lua script completed - no errors detected!\n");
Here is an example of what you should see:
C:\>payload test_lua -z -b230400 -L test_lua.lua
Using Propeller (version 2) on port COM4 for download
Lua script started
Sent string echoed correctly: Hello from Lua!
Received correct string: done!
Received expected linefeed character
Lua script completed - no errors detected!
These example files, and a windows binary, is attached.
This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.
-- Catalina adds four functions to Lua:
-- delay(milliseconds) : Just delay by the specified number of milliseconds.
-- send(string) : Send a string to the loaded program.
-- receive(count, timeout) : Receive up to 'count' characters from the loaded program
-- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded program.
That's very nifty, can the Lua also reset the P2 and /or download different programs, or is that done in another more-outer shell ?
This will be coming in the next release, but I have found this to be so mind-bogglingly useful already that I thought I would release it early because others may be able to use it to help them test their P2 programs.
-- Catalina adds four functions to Lua:
-- delay(milliseconds) : Just delay by the specified number of milliseconds.
-- send(string) : Send a string to the loaded program.
-- receive(count, timeout) : Receive up to 'count' characters from the loaded program
-- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded program.
That's very nifty, can the Lua also reset the P2 and /or download different programs, or is that done in another more-outer shell ?
@RossH: a question about timing functions. None of the standard C time related functions (time(), clock(), etc.) seem to work on my P2 eval board. Looking at the source it seems that's because I don't have an RTC, which I can understand. It'd be nice if time() had a fallback of using _cnt() to calculate seconds elapsed, but that's a "nice to have". I'm a little more bummed about clock() not working; I would have expected clock() to return processor cycles elapsed, or some fraction of those, rather than relying on an external RTC for timing -- especially if no RTC is present!
In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
...
In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
That would roll over very often if using 32b, but IIRC P2 can deliver a 64b time, so supporting that would be a useful fallback.
If P2 is using a TCXO, the precision/stability of that would be very good, and P2 would need some means to get an absolute time reference.
Some RTC's give a UNIX time (seconds since some date) so that may be another form worth looking at ?
...
In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
That would roll over very often if using 32b, but IIRC P2 can deliver a 64b time, so supporting that would be a useful fallback.
If P2 is using a TCXO, the precision/stability of that would be very good, and P2 would need some means to get an absolute time reference.
Some RTC's give a UNIX time (seconds since some date) so that may be another form worth looking at ?
The C clock() function doesn't return wall clock time, it returns elapsed processor time in some implementation defined units. The function to return wall time is "time()". "clock()" is often high frequency (microsecond resolution is common) and expected to roll over. It's generally used just for timing pieces of code.
@RossH: a question about timing functions. None of the standard C time related functions (time(), clock(), etc.) seem to work on my P2 eval board. Looking at the source it seems that's because I don't have an RTC, which I can understand. It'd be nice if time() had a fallback of using _cnt() to calculate seconds elapsed, but that's a "nice to have". I'm a little more bummed about clock() not working; I would have expected clock() to return processor cycles elapsed, or some fraction of those, rather than relying on an external RTC for timing -- especially if no RTC is present!
In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
There is a real-time clock plugin that you have to enable by specifying -C CLOCK on the command-line. It is not enabled by default since it takes a cog, but if you are using the SD Card, the clock shares the same cog as the SD card driver.
I have never used Catalina or heard of it before. I have always used SimpleIDE.
How compatible is Catalina to SimpleIDE? Is all the Andy code in it?
Mike
What steps should be taken to transfer a SimpleIDE project to Catalina on Code:Blocks?
Kevin.
I'm not familiar with SimpleIDE. I just did a search, and it seems that might be a Parallax thing? Code::Blocks can import some projects from other tools (e.g. MS Visual Studio projects) but it may be easier just to create a new project from scratch.
I have not used Catalina either. I like SimpleIDE as well.
The problem here is none of the Andy libraries are available here. So none of the code that was previously developed will not work with Catalina. Catalina is its own compiler.
So if you plan to use any parallax devices such as servos, displays, sensors your out of luck. The Simple Libraries were not imported into the Catalina compiler.
I have not used Catalina either. I like SimpleIDE as well.
The problem here is none of the Andy libraries are available here. So none of the code that was previously developed will not work with Catalina. Catalina is its own compiler.
So if you plan to use any parallax devices such as servos, displays, sensors your out of luck. The Simple Libraries were not imported into the Catalina compiler.
Mike
Yes, Catalina is a C compiler. What are the "Andy libraries"? If they are written in C code, they should compile.
The Simple-libraries are all the code that is needed to talk to any of the Parallax components. All the tutorials and sample code on the Parallaxes site are in there. So to use a Servo360 one only needs to include that library #include "servo360.h" and they are good to go.
This is also the back bone for the BlocklyProp code development.
@iseries Thank you Mike. I will need to study Catalina and CodeBlocks then take a look at Simple-Libraries. My goal is to use BlackCat debugging. I much appreciate your advice.
Many thanks to everyone.
Kevin.
We're bit busy fighting bushfires (I think you call them "wildfires"?) here in Australia at the moment, but I just had a quick look. It seems to be fairly straightforward C code, so it should be able to be made to work with Catalina.
I will try compiling the libraries in the next few days. If they need to be modified, I will post a Catalina specific version.
@RossH Thank you Ross. That's much appreciated.
I can remember a time, many years ago, when we in New Zealand received smoke from Australia! So far the wind has not brought the smoke and the red sunsets have not occurred.
Cheers,
Kevin.
Comments
Also, using the current methods of XMM on the P2 would be like using a Lamborghini to tow a hay cart. Yes, you could do it - but why would you?
I will wait and see what eventuates.
As for XMM, I agree it would be insane for the P2 to execute limp from serial memory although that might be suitable for Spin2 perhaps, but then again a single Spin2 bytecode gets a lot more done than an XMM opcode, so it will never need the extra memory.
Remember Moore's Law? Check again in 18 months
Parallax is already using a fairly old process node, because the price goes up rapidly as the feature geometry shrinks.
So, less a matter of Moore's Law, and more a feature of supply and demand.
IIRC Chip even mentioned 56nm??? Now that would be a P3 with 2-4MB and 32 cogs at 1+GHz
This is a full release that supports both the P1 and the P2. It includes both Windows and Linux releases, 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, because the P1 support has not been extensively tested (P1 users should continue using release 3.13.2).
Here are the latest changes (see the README.WhatsNew file for a complete list of all changes since release 3.13.2) ...
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.3 1. This is the fourth Propeller 2 release. It is partly an internal "clean up" and bug fix release for the previous release (3.15.2), but it also extends the P2 support. 2. Add P2 support for the BlackBox debugger. It now supports TINY (LMMM), COMPACT, and NATIVE modes on the P2. The BlackBox debugger will detect the P2 automatically, so it requires no new command-line options. The debugger requires a serial port connection to the P2, which (by default) is implemented on pins 50 & 52. This allows a PropPlug to be used on the P2 EVAL board, plugged on to the top-right I/O pin header. 3. Fixed an issue with BlackBox on both the P1 and P2 that meant in COMPACT mode, the contents of register r0 could not be displayed by name (i.e. using a "read r0" command - it could be displayed by saying "read cog 0"). 4. Add P2 support for the BlackCat debugger. The BlackCat debugger was originally developed by Bob Anderson, and the functionality is very similar to BlackBox, except that it has a graphical user interface. Note that (unlike BlackBox) BlackCat is provided in binary form only, and that BlackCat is a Windows-only application. 5. There is a new "flash_payload" utility, which programs the P2_EVAL Flash with an auto-executing version of any Catalina program binary. This is based on the Flash_Loader_1.2.spin2 program developed by ozpropdev. The parameters accepted by the flash_payload utility are identical to those for the "payload" utility, except that the first parameter MUST be the filename to be loaded. For example: flash_payload startrek -p4 -b230400 -z -i Note that to program the FLASH on the P2_EVAL, you must first remove any SD Card, and also make sure that the FLASH microswitch is turned OFF, or payload will report that it cannot find the P2. Once programmed, you must turn the FLASH microswitch ON to boot your program automatically from FLASH (the P2 may also require a re-boot). Turn it off again to boot from SD Card, or to load programs serially. Note that FLASH programming sometimes fails. If it does not seem to program correctly, try repeating the procedure. 6. Fixed some issues with the Catalina Optimizer P2 support that led to some erroneous results or less than optimal optimization. 7. Added P2 clock definitions to catalina_cog.h, and updated the _clockinit(), _clockmode() and _clockfreq() functions to work correctly for the P2, and a new test program (test_p2_clock.c) in the "demos" folder that demonstrates it. 8. Fixed a bug in the HMI plugin that caused some floating point operations to fail in programs compiled in CMM (COMPACT) mode. 9. Fixed a bug that prevented the Propeller rebooting on program exit in LMM & CMM modes. 10. Fixed a compiler bug that could lead to incorrect results in some circumstances - e.g. when converting floating point values to integers and vice-versa. This caused problems with programs like the "paranoia" IEEE floating point test. Catalina now passes this test, with the exception of some lack of precision in the pow() and exp() functions, and some incorrect overflow handling related to "inf" values. These defects should not affect most user programs.Apart from a dearth of plugins, Catalina support for the P2 is now essentially complete. Unless there are major problems found in this release, I expect it will be the last release intended for the P2 only - I would like to return to having just a single stream of releases for both the P1 and the P2.
Ross.
I really like the idea of a standard C library, like Eric's proposed. It would be awesome to have two C compilers, out of the gate, which cover the P2's hardware well.
I'm always behind the curve on C things, so please correct me if my thinking is wrong.
Yes, I'll release a version of the new P2 library for Catalina when we have finalized the definitions. Most of the functions are already there - it will just be a matter of tweaking the names etc.
In the meantime, if you have already downloaded version 3.15.3, do not use the COMPACT memory model!
Ross.
I hope this is the last P2-only release, so I can get a chance to work on a combined P1 and P2 release!
Ross.
I have added Lua scripting to Catalina's payload program loader. Now with one command you can load a program and then automatically execute a Lua test script to validate that it executes correctly. Of course, the program currently has to use a serial interface to be verified, but I intend to add a similar capability to the Blackbox debugger so that scripts can be written to verify any program.
The number of modes and compilation options that Catalina supports was already getting crazy on the P1, and with the addition of the P2 the number of different possible compilation options for even a trivial "Hello, World!" type C program is now in the many, many dozens - it may even be in the hundreds.
Trivial errors had started to slip through my manual testing, so I knew I had to do something!
Here is a very simple program called "test_lua.c":
/* * A simple program to test payload's new Lua scripting facility. * * Execute this program with a payload command like the following to * automatically load and start both this program and the Lua script * that verifies it generates the correct output: * * payload test_lua -z -b230400 -L test_lua.lua * */ #include <stdio.h> void main(void) { int i; char ch; do { ch = getchar(); } while (ch !='\n'); printf("program done!\n"); while(1) { }; }And here is the Lua script ("test_lua.lua") that verifies it executes correctly:
-- -- Catalina adds four functions to Lua: -- -- delay(milliseconds) : Just delay by the specified number of milliseconds. -- -- send(string) : Send a string to the loaded program. -- -- receive(count, timeout) : Receive up to 'count' characters from the loaded -- program, with a timeout of 'timeout' milliseconds. -- Reads are terminated by a linefeed, and the -- characters received are returned as a string. -- -- wait_for(prompt, timeout) : Wait for the 'prompt' to be sent by the loaded -- program. The read is not terminated by a -- linefeed, but will be terminated after 'timeout' -- milliseconds. If 'prompt' is an empty string, -- the read will be terminated by any character -- (which will be returned). -- -- NOTE: The script below uses the built-in Lua "error" function to report -- errors - this is for testing only, as this immediately terminates the -- script. Normally, it would be better to report the errors ourselves and -- then terminate the script a bit more gracefully! -- print("\nLua script started\n"); str1 = "Hello from Lua!\n"; str2 = ""; -- delay a few milliseconds (allows for the loaded program to start) delay(250); -- send a string to the loaded program send(str1); -- receive a string up to 100 characters, with a timeout of 1000 milliseconds str2 = receive(100, 1000); if (str1 == str2) then print("Sent string echoed correctly:", str2); else error("Sent string NOT echoed correctly"); end str1 = "done!" str2 = ""; -- wait for a specified string, with a timeout of 1000 milliseconds str2 = wait_for(str1, 1000); if (str1 == str2) then print("Received correct string:", str2, "\n"); else error("Received incorrect string\n"); end str2 = wait_for("\n", 1000); if (str2 == "\n") then print("Received expected linefeed character\n"); else error("Received unexpected character\n"); end print("Lua script completed - no errors detected!\n");Here is an example of what you should see:
These example files, and a windows binary, is attached.
Probably most useful for people who build tools for the Propeller, but hopefully also useful for anyone who expect to sell Propeller-based software.
No, that's easier to do in a batch file.
In fact I would have expected clock() to be defined as _cnt(), and CLOCKS_PER_SEC to be defined as _clockfreq(). Is there some reason you didn't do it that way?
If P2 is using a TCXO, the precision/stability of that would be very good, and P2 would need some means to get an absolute time reference.
Some RTC's give a UNIX time (seconds since some date) so that may be another form worth looking at ?
The C clock() function doesn't return wall clock time, it returns elapsed processor time in some implementation defined units. The function to return wall time is "time()". "clock()" is often high frequency (microsecond resolution is common) and expected to roll over. It's generally used just for timing pieces of code.
There is a real-time clock plugin that you have to enable by specifying -C CLOCK on the command-line. It is not enabled by default since it takes a cog, but if you are using the SD Card, the clock shares the same cog as the SD card driver.
Ross.
What steps should be taken to transfer a SimpleIDE project to Catalina on Code:Blocks?
Kevin.
I'm not familiar with SimpleIDE. I just did a search, and it seems that might be a Parallax thing? Code::Blocks can import some projects from other tools (e.g. MS Visual Studio projects) but it may be easier just to create a new project from scratch.
Ross.
The problem here is none of the Andy libraries are available here. So none of the code that was previously developed will not work with Catalina. Catalina is its own compiler.
So if you plan to use any parallax devices such as servos, displays, sensors your out of luck. The Simple Libraries were not imported into the Catalina compiler.
Mike
Yes, Catalina is a C compiler. What are the "Andy libraries"? If they are written in C code, they should compile.
This is also the back bone for the BlocklyProp code development.
You can find the library here: Simple-Libraries
There is a lot of custom code there so some of the libraries may need to be modified to work with Catalina.
Mike
Many thanks to everyone.
Kevin.
Thanks.
We're bit busy fighting bushfires (I think you call them "wildfires"?) here in Australia at the moment, but I just had a quick look. It seems to be fairly straightforward C code, so it should be able to be made to work with Catalina.
I will try compiling the libraries in the next few days. If they need to be modified, I will post a Catalina specific version.
Ross.
I can remember a time, many years ago, when we in New Zealand received smoke from Australia! So far the wind has not brought the smoke and the red sunsets have not occurred.
Cheers,
Kevin.