CodeBlocks, Catalina, and Star Trek on C3
Rayman
Posts: 14,865
I'm attempting to run the Catalina Star Trek game on a C3, but having some problems.
(Hoping Ross or whoever will have pity and not tell me to read the manual.)
I have figured out how to run the Hello World examples. One thing I think I've learned is not to use the CodeBlocks "Run" command, but instead use "Tools->Download to HUB Ram" from the menu.
Also, I know to pick "C3" and "VGA HighRes Text" options in the "Build Options" menu.
I can build fine, just can't get it loaded on the C3...
I think Star Trek needs XMM.
First tried "Tools->Download to XMM RAM", but that didn't work.
Then, tried "Tools->Build XMM tools" first and that seemed to help, but it still doesn't work.
Getting this error: "stderr>Error: too many retires for addr 0008000"
I also tried "Tools->Build Catalyst". I'm not sure what this is about, it seems the same as "Build XMM tools". But anyway, that didn't help either.
I'm sure I'm doing something obviously wrong...
Any help out there?
(Hoping Ross or whoever will have pity and not tell me to read the manual.)
I have figured out how to run the Hello World examples. One thing I think I've learned is not to use the CodeBlocks "Run" command, but instead use "Tools->Download to HUB Ram" from the menu.
Also, I know to pick "C3" and "VGA HighRes Text" options in the "Build Options" menu.
I can build fine, just can't get it loaded on the C3...
I think Star Trek needs XMM.
First tried "Tools->Download to XMM RAM", but that didn't work.
Then, tried "Tools->Build XMM tools" first and that seemed to help, but it still doesn't work.
Getting this error: "stderr>Error: too many retires for addr 0008000"
I also tried "Tools->Build Catalyst". I'm not sure what this is about, it seems the same as "Build XMM tools". But anyway, that didn't help either.
I'm sure I'm doing something obviously wrong...
Any help out there?
Comments
I have never tried to load this program but I think you might need to load catalyst.bin with payload into eeprom. Catalyst is a program loader located in the catalina/catalyst/bin folder. Its possible you may need some options to load Startrek. Cant remember where I saw how to load this program, think it was here on the forums. I will try later today and see what I get!
Sorry not to be more help....
But, I just tried loading Catalyst.binary into EEPROM with the Prop tool and tried again, but it gave the same error.
I tried to set a project for the Startrek but couldn't even get it to build on my C3. Had undefined symbols in build messages under Code Blocks. Couldn't even get it done under the command line.
Perhaps tonight Ross will chime in! *Hint, Hint)
Launching tool 'Download to XMM RAM': payload.exe XMM sst (in C:\Program Files (x86)\Catalina\catalyst\bin)
stderr> Using Propeller (version 1) on port COM4 for first download
stderr> Using Secondary Loader on port COM4 for subsequent download
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Error: too many retries for addr 00008000
Tool execution terminated with status 0
It just fails for some reason I don't understand...
Will keep trying!!!
It looks to me that the problem is that the Flash loader has been specified when building the XMM utilities, but not when building the executable itself - the addressing scheme changes when Flash memory is in use, and so in this case I think payload is trying (and failing) to program FLASH data to an SRAM address.
The various flash and cache related options must be identical between the utilities (such as the XMM loader) and the executables. This is a common error (even I get it wrong sometimes!) - I will see if I can simplify this in a future release so that it is not so easy to get this wrong :frown:.
Anyway, I just did a clean install of Catalina, and then compiled, loaded and ran the Super Star Trek demo on the C3 using low resolution VGA (High Resolution VGA will not work because it runs out of cogs). There are many different ways to do this, but because you wanted to use VGA, here is the method I chose (with a few things to note highlighted in red):
- Start Code::Blocks, and open the workspace containing Super Star Trek and the other Catalyst demos (i.e. select File->Open and specify the file catalyst_demos.workspace in the folder C:\Program Files (X86)\Catalina\codeblocks). We won't actually use Catalyst - we will instead load the programs using Payload - but this just happens to be where the project files are.
- Select Tools->Build XMM Utilities. You will be presented with a series of platform-related questions. Here are the answers I gave:
- When asked for the platform, I typed C3 (note this must be in capitals!)
- When asked if I wanted to use Flash memory, I typed Y
- When asked for the cache size, I typed 1
- When asked for other options, I typed LORES_VGA SD CLOCK (note the prompt implies you should instead type VGA_LORES here - this is a typo which I will fix in the next release!)
- Activate the sst project by right clicking on it in the projects pane and selecting Activate Project
- Edit the build options for the sst project by right clicking on it in the projects pane and selecting Build Options
- In the Build Options dialog, make sure you have the main node (sst) selected in the leftmost pane. You should see the following options checked on the Compiler Settings tab (you will need to srcoll up and down to see all the options):
- libcx
- libma
- LARGE
- Set Memory Size
- Disable Mouse Driver
- Clock Driver
- Note that there is no platform specified yet - when we specified the C3 (in step 2 above), it was only for building the various XMM utilities. In each project (or in the global compiler settings) we also need to specify the platform, and for platforms that use Flash (such as the C3) we must also specify the flash and cache options. Also, in this case we want to specify the VGA option. So, on the Compiler Settings tab, select the following additional options:
- C3 platform
- FLASH Loader
- 1K Cache
- VGA (Low Resolution)
- Next, select the Custom Variable tab - you will see a line that says MEM_SIZE=384k. We need to adjust this since using the FLASH Loader makes the executable slightly bigger. Select this line and press Edit, and modify the value to be 512k instead (make sure to include the trailing "k"). The executable is not actually that large - we just have to make sure this number is bigger than the final executable code size, and it turns out that 384k is slightly too small!
- Close this dialog and then rebuild the project by selecting Project->Rebuild
- Download the project to the Propeller by selecting Tools->Download to XMM RAM
Let me know how you go!Ross.
P.S. The Build XMM Utilities and the Build Catalyst tools in Code::Blocks are not the same - they just look similar since they both ask similar platform related questions before they do their job. The first one builds the XMM loaders and various other utilities (such as the Flash_Boot utility), and the second one builds Catalyst itself and the various Catalyst demo programs.
EDIT: I have modified this post to specify Low Resolution VGA. Because the C3 requires the use of the Cache, it does not have enough cogs to use the High Resolution VGA HMI option. The best option for running this program on the C3 is actually to use the PC HMI option, since neither the Low Resolution VGA nor the TV HMI options have enough screen width.
Also, (sorry if this is a dumb question) is the program being first loaded into SPI flash and then copied to SPI SRAM and run from there?
If so, can it be directly copied to SRAM and run, without involving flash?
Is it also possible to use the SD card instead of the flash chip?
But, I've got no video output...
I'm trying to figure out what a "Catalina Command Window" is and how to open one...
I see that by "Catalina Command Window" you mean what I call "DOS prompt".
Anyway, I did "use_catalina", presumably to set some path environment variables.
Then, did "payload Flash_Boot" and now have Star Trek running!
The programming incredibly slow though! What baudrate is it? It felt like minutes to download...
Anyway to speed that up?
I tried editing the "Download to XMM RAM" command and adding "-b 230400". It tries to download at this speed, but fails. Would I need to build Catalyst in a new way to do this?
Thanks!!!
So in this case (since you want to use VGA), the HIRES_VGA option is necessary when building the Flash_Boot utility. However, you can also rebuiild Flash_Boot utility to load another HMI driver if you want - for instance, in this case you could run the Star Trek program but use the TV output, without having to reload the program into Flash. No, SPI SRAM is not involved during the load process - for one thing, on most platforms there is not enough SPI flash to do this. So I just program the Flash sector by sector as the stuff arrives from the PC (or is loaded from the SD Card if you are using Catalyst). Actually, yes - on the C3 you do not need to use Flash at all - you can load and run programs from the SPI SRAM (just leave out the symbol FLASH when compiling). However, the C3 has 1Mb of Flash, but only 64k of SRAM - so you cannot (for instance) run Star Trek from the SRAM! Possibe, yes - but I have not written the code necessary to do this.
Ross.
Sorry Rayman - look in the Catalina group in your Start Menu and select Catalina Command Line
Good!
This is a common complaint by people who don't realize the complexities of what's actually going on. It is not the baudrate that is the limiting factor. There are two other more significant factors:
- I had to put in a simple error detection and retransmission protocol. The simple protocol that Parallax uses (to load a maximum of 32k) is completely unsuitable when you may be downloading up to 8Mb. One single bit error anywhere in the download means you have ruined the entire download. The need to check each packet and retransmit slows things down. Some of my boards seem more prone to comms failures than others - on one particular board I could only successfully download about one time in three until I implemented this protocol.
- On Flash platforms (such as the C3) the need to program each sector into Flash also slows things down. I currently program the Flash comms packet by comms packet, since there is not enough RAM to load the whole image first. I could download a few packets and then program block by block - but then the code would become too large to fit in a single cog :frown:.
You can do this (although as I explained above, it won't make as much difference as you might hope). However, you also need to change the baud rate specified in the board definitions file (e.g. C3_Def.inc) and then recompile your program so that you are changing the baud rate on both ends of the loader comms link.Ross.
You are most likely inlcuding the libraries twice - check your build log file and look at the actual Catalina command. The final Catalina comand in the log file will look something like this:
Note the -lma -lcx part. If you don't see this then you have not selected any library options, so the symbols are undefined. If you see one or more of the libraries mentioned twice, then you have selected multiple conflicting library options.
The most common way this happens is that you can set library options for each node in the Build Options dialog, and also again in the Global Compiler Settings. Open the Build Options dialog and select first the sst node, then the Release node, and check that you do not have conflicting options set in both places.
This is one of the most confusing aspects of Code::Blocks - and a trap I fall into myself quite regularly. However, whenever things don't work as I expect, I just check the build log and examine the actual command that was executed.
The different workspaces were just to break things up a little. For instance, some people have no interest in Catalyst (e.g. if their propeller has no SD card) so I kept those separate. But (as you have seen) the Catalyst demo programs are just Propeller programs - the main problem with them is that they tehnd to be very large - and (as Rayman commented) if you are loading them serially instead of from the SD card, they take a vvvveeerrrryyyyy long time to load!
No Catalyst components are required to load the programs if you are loading them serially - Catalsyst and Payload are just different mechanisms for getting the program into the Propeller. The main advantages of Catalyst are that it is faster, and also it allows you to add command line parameters that you can retrieve from within the C program once it has loaded.
Ross.
I've had a chance to look at why Super Star Trek won't start when using the HiRes VGA on the C3, and it is simple - it is running out of cogs!
The reason it appeared to start when I used the Flash_Boot utility is also simple - I forgot to add in all the necessary drivers.
Here is a summary the cogs this program requires when compiled with HiRes VGA on the C3:
- Kernel (1 cog)
- Cache (1 cog)
- Float32A plugin (1 cog)
- HMI plugin (1 cog)
- HiRes VGA driver (2 cogs)
- Keyboard driver (1 cog)
- Clock plugin (1 cog)
- SD Card plugin (1 cog)
TOTAL = 9 cogs (oops!)It will run successfully on a platform that does not need to use the cache, or when using any other HMI option - but the combination of cache and HiRes VGA is not currently possible with this program.
When building the XMM utilities (including the Flash_Boot utility) I should have specified HIRES_VGA CLOCK SD (instead of just HIRES_VGA) - this would cause it not to run, but it would not have fooled me into thinking it should!
The best way to run this game on the C3 (since the LoRes VGA and TV drivers don't have enough screen width) is to use the PC HMI option and a terminal emulator.
At some point, I'm thinking about rewriting the SD Card plugin (to speed it up) but since both it and the Clock plugin are quite small, I may be able to combine the two - this would save a cog.
I've updated my earlier post on this issue, so as not to confuse anyone else who has the same problem.
Ross.
Maybe the SD cog wasn't working...
I guess I've figured out that catalyst is for loading off of SD card. Maybe I should have been using the non-catalyst version...
BTW: Low resolution is a really bad choice for this game. It really needs 80 columns...
Yes, it really does need an 80 column terminal - that's why I suggested using the serial PC HMI option and a terminal emulator.
When using HiRes VGA on the C3 the game will run fine until it needs a resource provided by the plugins that have not been loaded - e.g. the SD card (if you use the "help" function, or try to load or save a game) or the system time. Then (depending on the code) it may either fail or just freeze.
I'm not sure what you mean by "catalyst" or "non-catalyst" versions - there ain't no such animals! I just bundle all the large demo programs together since I figured people would compile them together and load them using Catalyst - because (as you have discovered!) they take so long to load serially. But the programs themselves are not Catalyst-specific versions. Catalyst is just a loader which loads from SD card the same binaries you could load serially using Payload if you wanted.
NOTE: there is one special load option/format that only Catalyst understands - this is the SDCARD load option - this enables a two-phase load process even on normal Propellers (i.e. Propellers with no XMM RAM). This effectively frees up the 16k (nearly half the available Hub RAM!) that would otherwise be unusable as C program code space since it is required to store the various plugins and drivers (and the Catalina kernel itself). However, none of the Catalyst demos use this load format since they are all larger than 32k anyway (and therefore must use one of the XMM load options, which are all two-phase).
Ross.
But, I think we need to find a way to reduce cogs. I suppose it would be nice actually to have the SD cog running...
Does the "clock" actually need it's own cog. Is this just a synthetic RTC? If so, I think it could easily be combined with one of the other drivers.
I'm not quite sure what the "HMI" cog is doing. Do we need that one?
Question: if I dint specify a cache when defining the project will that free up a cog or does the cache always run?
Thanks Ross!!
Hi Ken,
It has to be that the library is included twice, somehow. Can you post your build log?
Ross.
Hi Rayman,
The SD cog is necessary for the help functions (the help text is in a file on the SD card, but if you load the program serially it is probably not there anyway) and also to load and save games - if you don't need these functions you can leave it out.
Yes, the clock is a simulated real-time clock, since many platforms don't have a real clock chip. I can't recall if the clock is really necessary in this game - you would have to check the code.
The HMI plugin is a wrapper around the various native Propeller drivers (screen, keyboard, mouse) - the VGA drivers in particular do not have enough available code space to turn them into a plugin on their own, plus the HMI "wrapper" adds some necessary functionality not provided by the native drivers themselves (e.g. processing special characters).
Ross.
To use serial Flash or RAM you must have the cache enabled. There is not enough space in the kernel itself to drive such complex chips, so I have to put the code in the cache cog.
Ross.
Ross, Any chance of combining the HMI cog with the clock cog?
No, the HMI cog is jam packed full of useful stuff - in some ways it is almost like a library cog for HMI functions. I have already had to sacrifice some functionality in this cog because I ran out of room.
There is probably enough space in the keyboard cog. The problem (as always) is finding the time ...
Ross.
It's not too hard, just add an extra "task" to be done during blanking and add an extra "parameter" to the input.
It could also be added to TV drivers easily.
Another approach would be to use Bill Henning's 80-column 1-cog driver, but that requires a 6.25 MHz crystal...
BTW: Do I understand it that the cache driver wouldn't be required if running from SRAM (like that in Flashpoint Rampage)? I guess that would also save a cog. Never mind, I just read you're earlier post.
(But, it sounds like Nethack would require both Flash and SRAM, so I'd still like to free a cog...)
Please let me know what I am doing wrong!
Build: Release in sst
Compiling: ..\..\catalyst\sst\ai.c
1 file(s) moved.
Catalina Compiler 3.2
Compiling: ..\..\catalyst\sst\battle.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\catalina.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\events.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\finish.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\moving.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\planets.c
1 file(s) moved.
Catalina Compiler 3.2
Compiling: ..\..\catalyst\sst\reports.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\setup.c
Catalina Compiler 3.2
1 file(s) moved.
Compiling: ..\..\catalyst\sst\sst.c
Catalina Compiler 3.2
1 file(s) moved.
Linking console executable: ..\..\catalyst\bin\sst
Undefined or Redefined symbols:
abs redefined
fabs redefined
sqrt redefined
abs redefined
pow redefined
fabs redefined
sqrt redefined
sin redefined
cos redefined
atan2 redefined
printf redefined
_cnt redefined
srand redefined
k_wait redefined
fflush redefined
__stdout redefined
sqrt redefined
ctime redefined
time redefined
strlen redefined
strcmp redefined
fgets redefined
printf redefined
fprintf redefined
fopen redefined
fclose redefined
__stdin redefined
strcmp redefined
abs redefined
pow redefined
fabs redefined
sqrt redefined
log redefined
sin redefined
cos redefined
atan2 redefined
abs redefined
strlen redefined
strncmp redefined
abs redefined
floor redefined
sqrt redefined
putc redefined
printf redefined
__stdout redefined
strlen redefined
strchr redefined
strcat redefined
strcpy redefined
srand redefined
sqrt redefined
fwrite redefined
fread redefined
printf redefined
fopen redefined
fclose redefined
clock redefined
toupper redefined
tolower redefined
strlen redefined
strstr redefined
strncmp redefined
strcmp redefined
strcat redefined
strcpy redefined
exit redefined
rand redefined
log redefined
putc redefined
gets redefined
fputs redefined
fgets redefined
sscanf redefined
sprintf redefined
printf redefined
Process terminated with status 1 (0 minutes, 15 seconds)
75 errors, 0 warnings
Build log saved as:
[URL]file://C:%5cProgram%20Files%5cCatalina%5ccodeblocks%5csst%5csst_build_log.html[/URL]