Catalina 3.3
RossH
Posts: 5,462
All,
UPDATE: Catalina 3.4 has now been released - see here
Catalina 3.3 is now available on SourceForge (here). A Windows "one touch" installer is provided which installs both Catalina and Code::Blocks, as well as Linux (32 and 64 bit) tar/gzip files.
Release 3.3 is a full release of Catalina. Here is a brief overview of the changes:
Any problems or questions, please let me know.
Ross.
UPDATE: Catalina 3.4 has now been released - see here
Catalina 3.3 is now available on SourceForge (here). A Windows "one touch" installer is provided which installs both Catalina and Code::Blocks, as well as Linux (32 and 64 bit) tar/gzip files.
Release 3.3 is a full release of Catalina. Here is a brief overview of the changes:
- Support for the FlashPoint XMM boards (i.e. the SuperQuad and the RamPage). Although they are both XMM "add on" boards that must be connected to a suitable propeller platform, each has been assigned its own platform symbol (i.e. SUPERQUAD and RAMPAGE). However, if you don't want to use these names, the necessary details can easily be incorporated into the configuration files for another platform (e,g. CUSTOM). Since they are quite similar, the options for both boards are defined in the same configuration files (i.e. FlashPoint_DEF.inc, FlashPoint_CFG.inc, FlashPoint_HMI.inc and FlashPoint_XMM.inc). See FlashPoint_README.txt in the Catalina\target directory for more details on how these files can be used.
- Removed all platform-specific options from the plugins, and added a new CFG file for each platform (e.g. Hydra_CFG.inc) which contains all plugin configuration options for the platform. This makes it much easier to support new platforms without having to edit each plugin file.
- Included the RTC (CLOCK) functionality in the SD plugin now, if the SD plugin is loaded, the CLOCK plugin will not be loaded the CLOCK code embedded in the SD plugin will be used instead (if the SD plugin is not loaded, the CLOCK plugin will still be loaded as usual). This saves a cog in many cases on large complex programs. This is all automatic - no user intervention is required.
- Formalized the XMM API to include both Cache and Flash support. This was required since the quad-bit SPI Flash chips used by the FlashPoint modules could not be accommodated in the existing (but largely undocumented) Flash API, which could only cope with the type of single-bit SPI chips used by the C3 and Morpheus platforms. Now all platforms use a common XMM API, which is divided into three parts:
- the cached API, intended to be used only via the cache
- the direct API, intended for inclusion directly in the kernel
- the flash API, intended to be used when Flash support is required.
See the updated section on the XMM API in the Catalina Reference Manual for details on the individual functions required by each part of the API. Note that not all the parts are necessary - if you are happy to access the XMM RAM only via the cache, then the cached API can be used stand-alone. It requires only four simple PASM functions to be written (i.e. XMM_Activate, XMM_Tristate, XMM_ReadPage & XMM_WritePage). The direct API is just the existing XMM API (i.e. pre 3.3), and the flash API adds the functions required to erase and program Flash chips to allow them to be used as XMM RAM.
The only changes since the beta release of 3.3. were some very minor bug fixes and some documentation updates.Any problems or questions, please let me know.
Ross.
Comments
Then, I realized that I still had CodeBlocks open... So now, I'm not sure...
Does the uninstaller work? Or, did I mess it up by having CodeBlocks open?
Also, are all files installed by the Windows installer in the "Catalina" folder?
BTW: IT WORKS!
Just plugged in a RamPage module into a GG Propeller Platform USB and
have StarTrek playing over "PC" serial link to Propeller Serial Terminal.
Just had to modify the "FlashPoint_DEF.inc" to adjust the pins...
But, I'm not really happy with the way it looks in Propeller Serial Terminal. So, I think I'll try those changes to PropTerminal for 80-column display.
Glad you got it working! If you come up with a set of pin definitions that you think that others can use, just post them in this thread. I'll include them in the next release.
The uninstaller normally works ok - perhaps it crapped out when it found it could not uninstall some of the codeblocks files. Shouldn't matter though - the uninstall process is quite trivial, and yes - all files installed by Catalina are in the Catalina folder (e.g. Program Files (x86)\Catalina). You can uninstall just as well simply by deleting this directory and removing the program group from the start menu. Of course, don't forget to back up any customizations you have made (to pin definitions etc).
If you previously had the beta installed, just install 3.3 over the top and everything should be fine. I generally recommend uninstalling first since that way any files I have deleted from the new version will be removed - but in this case there are such minor changes between beta 3.3 and final 3.3 that it won't matter.
Ross.
Error: FlashPoint_XMM.inc (500, 35): Source register cannot exceed $1ff
shr XMM_Temp,#(4-Common#QSPI_SIO0) ' shift for output
^
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
Thanks, Rayman.
Code::Blocks detects whether the build succeeds or fails by parsing the messages spat out during the compile. It uses regular expressions to detect whether these are error messages, or just info or warning messages. It seems my regular expression parsing is missing this particular error (at first glance, it is probably because I was expecting a space between "Error" and ":") - so even though the compile fails, Code::Blocks doesn't realize it. I just need to update my regular expression. I'll check this out tonight.
I discover new cases every so often that I haven't catered for correctly - there's probably a few more left in there yet!
Ross.
Regarding your undetected error - I just remembered that in Code::Blocks you can fix this yourself.
In Code::Blocks, select the Settings->Compiler and Debugger... menu item. In the Global compiler settings dialog box, ensure the Catalina C compiler is the selected compiler, then below that select the Other Settings tab and then press the Advanced options... button (at the bottom of the tab).
Then in the Advanced compiler options dialog box, select the Output parsing tab. press Add and then enter the following as the parsing expression details:
- Description: Homespun Error (Catalina)
- Type: Error
- Regular Expression (I suggest you copy and paste this from here): ([Ee]rror[ ]*:[ ]*)(.*)
- Message: 2
It should now look something like this:Then press OK. Isn't Code::Blocks great?
Ross.
Maybe I don't understand something... I thought these two were roughly equivalent...
Does PropTerm also use physical pins for TV, etc.? I see these drivers being loaded... Maybe I have a pin conflict...
Or, maybe I'm running out of cogs again because it's trying to run all the HMI drivers as well as serial connection...
I'm trying to test on a Prop Platform USB board that has no inherent TV, VGA, keyboard or mouse.
I thought this was showing right before... But now, I just see spaces where the dots should be... Also, the Enterprise should appear like "<E>",
but it's showing up as "<*>"...
Ok, I think I see what's going on... There are two different Star Trek examples: "Startrek.c" and "sst.c".
Think I've figured out that I want the "sst" example and not the "Startrek" example.
Also, I had to look back to remember to pick "Large" and "Mem_size" options... (Somehow I thought I wanted "Small" and don't see why I need "mem_size").
PropTerm is not a general purpose serial terminal emulator. It's main purpose is to allow a "workalike" copy of the standard Propeller TV/Mouse/Keyboard drivers via the same devices on a PC. However, if your program is trying to drive it like a normal terminal (as Star Trek does), it will probably not work in the standard PropTerm mode. PropTerm has a "normal terminal" mode does looks a bit like a general purpose terminal emulator, but is not configurable - so you have to make sure you drive it correctly (i.e. correct line terminators etc).
PropTerm loads replacement TV/Keyboard/Mouse drivers that then connect serially to the PC. I would have to check this, but it is possible you may be running out of cogs again because it needs an extra cog to do the serial comms.
The best advice I can give you is to use a real terminal emulator (like putty) and the PC HMI option instead. You will get much better results. Even HyperTerm will give better results than PropTerm, unless you need it's specific capabilities (like being able to use the PC as a mouse on the Propeller).
I use putty on all my boards that have no HMI devices (e.g. the RamBlade). If you have trouble configuring it correctly, let me know.
Ross.
There are actually about 5 or 6 versions of Star Trek included with Catalina - including two C versions, a Pascal version and several Basic versions. This program is so ubiquitous that it makes an excellent test program, and that's what I use it for - it exercises nearly all of the standard plugins (screen, keyboard, mouse, clock, file system etc) and is much more fun to test with this than with a boring old test program like the Ram Tester.
The MEM_SIZE option is a bit of a holdover from my original XMM mode which was intended to execute from EEPROM. In such cases it was important to tell the compiler how much EEPROM space it had available, and not compile if the program size blew this limit. All it does is throw an error if your program exceeds this size. Now, you should just set it to the maximum size of your XMM RAM and forget about it. In the next release I may make this just a warning so that you can effectively ignore it, or I may even remove it.
Ross.
(It was a long and painful struggle, but I'm very happy now!)
I also have both modules working over the "PC" serial connection on a Propeller Platform USB board with SD access.
Now, I'll write up what to do so that Flashpoint owners can get these examples working in minutes.
One thing I figured out is that I had to edit the "FlashPoint_CFG.inc" file as well as "FlashPoint_DEF.inc" to un-C3 a lot of things...
Also, I've learned that "sst" has to be done in "large" mode which means it will only work on RamPage and not SuperQuad.
The other StarTrek example does work in "small" mode on either Flashpoint chip.
So, I'm now thinking that the "Catalyst" examples are ones that require "large" mode.
The "xmm" and "emm" examples look like they could run in "small" mode (?).
I was already familiar with putty. It works, but I think it'd be better if it would work with PST. But, my real goal was to have it work with VGA and real keyboard, so I'll give you a break there.
Of course, every bit of progress brings a slew of new questions for you... Maybe I should PM you, but I'll ask here in case that helps you from answering the same questions over and over...
It appears from the Flashpoint_Def.inc file that trying "large" mode on SuperQuad would produce an error message. But, it doesn't. What's up with that?
After I compile a program. How can I tell if it will run in "small" mode?
I see output like this for sst:
code = 270236 bytes
cnst = 30984 bytes
init = 1112 bytes
data = 5540 bytes
file = 498348 bytes
does everyting exept "code" have to fit in 32k?
Also, wow the file is huge! Am I doing something wrong?
One more question... The HighRes_VGA appears to be different from the Parallax HighRes Text VGA driver... Yours syncs as 640x480x72Hz. The other syncs as 1024x768x60Hz. One of my monitors doesn't really like 72Hz too much... How hard would it be to adjust refresh or switch drivers?
Ross.
Yes, it looks like I broke that with a late edit. In the file FlashPoint_DEF.inc, the lines: Should be replace with the lines: I'll fix this in the next release.
Ross.
I think you said that download was slow due to the need for error checking. But, most Prop implementations use the FTDI USB chip that has it's own error correction. So, any chance of offering a "fast" mode without the checking? Maybe just a final CRC check?
Also, is it possible to test the C code on a PC before downloading to the Prop? I.e., can sst be compiled and run with GCC?
One more thing... Can something like sst example be rigged to run automatically after a Prop reboot? How would you go about doing that?
@Ross hope to get time this week to uninstall and upgrade my Catalina this weekend.
David Betz was working on a faster loader. I don't know how that's going, but if you wanted to have a go as well, then by all means do so! However, I'm not sure that simply not calculating the LRC would save you much time (it probably takes much less than a millisecond per packet). In the case of Flash chips, more time is probably spent in the flash programming you have to do in between each packet.
You can compile any Catalina program using any ANSI C compiler - just avoid the Propeller-specific functions (e.g. _outa, _dira etc - or perhaps write a simple stub body for each of these functions and compile this in with the program).
To execute a program on boot is simple - for normal programs, you just compile them with the EEPROM loader and then program them into the EEPROM. For flash programs, you load them into Flash and then program the Flash_Boot utility into EEPROM.
Ross.
Yes, there is a Getting Started with CodeBlocks document, and an even shorter CodeBlocks QuickStart guide.
Ross.
Ross, Great! Does gcc come with Code:Blocks? I thought I saw it there as an option... Can I debug a program this way (within Code:Blocks)?
Does that EEPROM way only works for "tiny" programs? Can I program the "flash boot" utility to EEPROM within Code:Blocks?
Any TINY program can be programmed into any EEPROM. You don't need to do anything special.
A SMALL or LARGE program can be programmed into an EEPROM provided the EEPROM is large enough - i.e. > 32kb. To do this, you must use the EEPROM load option when compiling (e.g. -D EEPROM).
For booting Flash programs, the Flash_Boot utility can be programmed into any EEPROM. Just make sure you compile this program to include all the plugins the Flash program will need. Flash_Boot can be built within Code::Blocks. To Program it into EEPROM, open a Catalina Command Line window and type in (from any directory): If you want to do this from within Code::Blocks, just go Tools->Configure Tools. Then press Add and enter the following details:
Executable: payload.exe
Parameters: -e Flash_Boot
I think I like the "Configure Tools" thing in Code::Blocks. Perhaps I can write my own FlashPoint configurator utility to go in there...
But, say I foolishly decide to code in Visual Studio instead. I think that has the advantage of letting me build, execute, and debug the code within Windows before downloading to Prop.
I think something like the Star Trek example (sst) is all standard I/O right? There is no _outa in that code, right?
' explictly enable VGA
'#define ENABLE_VGA
' SD must be activated before each use
'#define ACTIVATE_EACH_USE_SD
' XMM pins are shared with other devices
'#define SHARED_XMM
I would like to just eliminate them as I think they are C3 specific. I can't imagine anybody using a Flaspoint module with C3, since C3 already has expanded memory. Are these save to delete?
Ross.
But yes, these lines should be deleted if you are not on a C3 (and they are not needed for your platform).
Ross.
Just had to remove the os2.c, linux.c and dos.c files from the project. They included these files:
#include <sys/ioctl.h>
#include <sys/termio.h>
These files don't actually seem to exist anywhere...
Are those files just there to help you compile with some other compiler?
Also, I had to change "randomize();" to "srand(0);". Is "randomize" an ANSI C ?
Anyway, it wasn't too hard (also had to tell it not to use precompiled header).
Maybe I should use GCC so that I could try compiling within Code::Blocks, but I'm afraid of it clashing with my Visual Studio setups...
So, I'm happy with this setup now because I can debug huge code in Windows and then transfer over to Prop.
I did notice that sst runs a bit faster on my PC that it did on the Prop though...
Update: I found "randomize()" in Catalina.c, so I think I see what's going on there...
Actually, adding "dos.c" to the Visual Studio project made everything better.
Is there already some way for a "large" program stored in flash and booted via eeprom flash_boot to load and run another large program stored on SD?
That's what you're meant to do when compiling under DOS. The file os2.c is for compiling under OS/2, and linux.c is for compiling under Linux (and of course catalina.c is for compiling under Catalina!).
Ross.
Catalina is not an OS - but it would certainly be possible to build a simple OS for the Prop using Catalina - or (even easier!) to port an existing OS.
Why anyone would want to do so is another question
Ross.
Yes, right there in plain sight it would seem.