Ken, FWIW, I can reproduce your issue by having "libcx" selected both for the sst project and the sst\Release build.
Maybe you could check that.... In the "Project Build Options" window, there is a tree control on the left side.
The root of the tree control is "sst". There is a "Release" branch under the root.
Click on the "Release" branch and make sure no compiler flags are set.
I think Ross wants us to select compiler flags only under the "sst" root.
Ken, FWIW, I can reproduce your issue by having "libcx" selected both for the sst project and the sst\Release build.
Maybe you could check that.... In the "Project Build Options" window, there is a tree control on the left side.
The root of the tree control is "sst". There is a "Release" branch under the root.
Click on the "Release" branch and make sure no compiler flags are set.
I think Ross wants us to select compiler flags only under the "sst" root.
Hi Ray, Ken ...
It doesn't matter where you set these options - but it is usually best to set them only in one place consistently - either in the root project node, or in the Release node, or in the global Compiler Settings. Otherwise you get confusing results.
Ken, you need to update your compiler settings to include the whole command line in the build log - it's the actual catalina command that I need to see.
The standard Parallax keyboard, TV & VGA drivers are missing lots of necessary functionality - they have no cursor handling (with one exception), no special character handling, no scrolling, and they tend to return raw undecoded binary key values. They are nowhere near functional enough to be used as stdin or stdout drivers from C. In many cases there is not enough code space left in the driver to fix any of these shortcomings in the drivers themselves. The HMI plugins address all these issues, but consume an extra cog to do so. They also (space permitting) contain trivial "printf" style output functions such as the ability to print binary, decimal and hex values. Finally, they also help implement the proxy driver capabilities for multi-Prop systems.
So using a HMI plugin allows Catalina to use the standard Parallax serial, keyboard, mouse and TV drivers with only trivial modifications (essentially, removing the Spin methods!) - and also provides a "wrapper" that makes them all look the same from within the C program even when they (internally) do very different things.
@ Ross, what exactly do I need to set in the compiler section, the verbose setting?
@Rayman I thought that I only had the flags set in the build options section with sst highlighted. I took em out of the settings tab. Am I wrong about this?I
Ken, I'm taking a look too, even though I don't really know what's going on...
It does appear that you are compiling vi instead of star trek. You know that, right?
I see two "-DNO_MOUSE" on every line, maybe that's a problem?
I also see a lot of "-w" in there. Not sure what that means, but it looks odd.
Maybe I'll try compiling vi and see what happens to me...
If you actually want to play the game, I'd suggest using HiresVGA, even though Ross says not to... The SD driver doesn't work and you need to jump start it, but you really need 80-column display.
Ross says we should use the "serial PC HMI option " for 80-column display. I'm not 100% sure what that is, but I assume it's using something like the "Parallax Serial Terminal" to view serial output from the Prop.
Its running in Hires Vga and I also had to do the Flash_Boot to get to work. It seamed to OK but like you said slow, guess do to the serial mem. I cant wrap my mind around all the redefined items and it still runs! Perhaps this is normal? I am not and probably never will be a programer... I have never got to complicated programming like you and the other guru's here!
That build log is definitely for xvi, and the reason it shows multiply defined symbols is that many of the compile flags and libraries are indeed defined twice on each catalina command line.
Obviously at some point you have successfully compiled and loaded sst (i.e. Super Star Trek) and it is now resident in the Flash RAM on the C3. That's why Flash_Boot can successfully execute it - that utility doesn't download anything, it just executes whatever is already in Flash.
You probably have fixed the sst settings, but your subsequent compiles have been of xvi (not sst) so you thought it was sst still failing to build.
In Code::Blocks, the easiest way to ensure you are compiling the correct project is to always right-click on the project name and select Rebuild. This will activate the project first and then rebuild it. Selecting Build->Rebuild from the main menu will rebuild the currently active project (whatever that happens to be!), but will not change the currently active project even if you have a different project selected in the project pane!
What's probably happened there is that at some point you thought you were setting the build options for sst, but in fact you ended up setting them for xvi. So now you will have to fix your xvi settings as well
Ross.
P.S. You can quite happily run Star Trek in HiRes VGA - just link using libc instead of libcx (i.e. -lc instead of -lcx). This will omit the file system support and (more importantly!) not load the SD plugin. Then just avoid the Help function, and don't load and save any games.
@Ross Thank you it Finlay makes sense to me and that was exactly what I was doing. I thought as long as I had sst highlighted that was what I was working on with the main menu's. Teach me to go think!
@Rayman big grin and thank you for sharing your thread with me.
Now back into Catalina and apply what I have learned here . I am sure more questions will come.
You can quite happily run Star Trek in HiRes VGA - just link using libc instead of libcx (i.e. -lc instead of -lcx). This will omit the file system support and (more importantly!) not load the SD plugin. Then just avoid the Help function, and don't load and save any games.
That's nice because I think Star Trek is a wonderful example of the power of Catalina and it'd be nice to tell people how to do it on the C3. (And BTW, how to do it soon an any Prop board with a RamPage module plugged in.)
I'd still like to get the clock out of it's own cog though. That seems like a big waste of a cog.
Maybe I'll see if I can add it to the High-Res VGA driver myself. Maybe that would make it easy for Ross to add to Catalina at some point...
Just did a quick bit of hacking, and the CLOCK plugin is now included in the SD card plugin. This means that if you use the extended library (which pulls in the SD plugin) then using the CLOCK no longer requires an extra cog.
This will be invisible to you - no code changes required to either the C program or the build process.
So Star Trek will now run properly in HiRes VGA on the C3, or when using the RAMPAGE.
Is SD really much slower that the flash chip? Seems to me they are similar technology, but with a regular SPI interface.
I was able to get some very fast speed using FSRW 2.6
If we could run this off of SD, that would open it up to a lot more setups...
Is SD really much slower that the flash chip? Seems to me they are similar technology, but with a regular SPI interface.
I was able to get some very fast speed using FSRW 2.6
If we could run this off of SD, that would open it up to a lot more setups...
Hi Rayman,
Yes, this would be trivially easy to do. I'll pencil it in for 2015
Is SD really much slower that the flash chip? Seems to me they are similar technology, but with a regular SPI interface.
I was able to get some very fast speed using FSRW 2.6
If we could run this off of SD, that would open it up to a lot more setups...
Ray, I love the way you think... This is likely applicable to many uses of external memory. (Except video of course)
Well, think about it. If you forget FAT and just use the raw block access, I think it's basically the same as an spi flash chip.
A few of us were thinking about this last month.
You can use raw block access, but that's an "apparent solution" ... that is, it apparently will work for a while in many cases, but not in all cases. The other concern is the maximum contiguous block size is limiting.
One major problem is that SD cards are built with NAND flash which allows for bad blocks. To deal with that requires an indirect management and access method. That means you'll end up with a "filesystem" anyway.
So, the best way to deal with it is to use the device the way it's meant to be used. I believe Mike Green's sdspiFemto PASM driver could be adapted for into a cache COG for reading the SD, but a virtual address map would be necessary to indirectly access the data.
The question then becomes will that be fast enough to be useful? Probably for some, probably not for others. Depends on the application.
I suppose one major drawback is that if you used the SD card as basic memory, without a fat, you wouldn't be able to save files to it, like Star Trek and the other programs can do...
Still, since the SD card reading engine is already installed, why not couple the cache driver to the SD card driver and just load up the cache from compiled code on the SD card?
Actually, couldn't you then also switch between different programs too?
I suppose one major drawback is that if you used the SD card as basic memory, without a fat, you wouldn't be able to save files to it, like Star Trek and the other programs can do...
Hi Rayman,
Correct. That's why I was thinking of implementing it via the existing SD Card plugin - the cache would just use this plugin to perform sector-by-sector access to a predefined swap file. This swap file access could therefore co-exist with any normal SD card file access the C program needed.
Not promising anything, but this would be so easy that I may have a go at it sometime in the next few weeks.
However, I think jazzed is correct that this would be too slow for many purposes! Only a masochist - or a Parallax forum member - would even contemplate it!
On one hand (for the Prop community) I hope you can do it, because I think a majority of Prop systems now include an SD card.
(Thanks to FSRW). Even if it were slow, it would probably be faster than Spin, right?
On the selfish side, I think having a Rampage module with an SD card is a real winner too.
Also, perhaps one day I'll have a nice Flash filesystem for Rampage and then you wouldn't need the SD card at all...
Comments
Maybe you could check that.... In the "Project Build Options" window, there is a tree control on the left side.
The root of the tree control is "sst". There is a "Release" branch under the root.
Click on the "Release" branch and make sure no compiler flags are set.
I think Ross wants us to select compiler flags only under the "sst" root.
It doesn't matter where you set these options - but it is usually best to set them only in one place consistently - either in the root project node, or in the Release node, or in the global Compiler Settings. Otherwise you get confusing results.
Ken, you need to update your compiler settings to include the whole command line in the build log - it's the actual catalina command that I need to see.
Ross.
The standard Parallax keyboard, TV & VGA drivers are missing lots of necessary functionality - they have no cursor handling (with one exception), no special character handling, no scrolling, and they tend to return raw undecoded binary key values. They are nowhere near functional enough to be used as stdin or stdout drivers from C. In many cases there is not enough code space left in the driver to fix any of these shortcomings in the drivers themselves. The HMI plugins address all these issues, but consume an extra cog to do so. They also (space permitting) contain trivial "printf" style output functions such as the ability to print binary, decimal and hex values. Finally, they also help implement the proxy driver capabilities for multi-Prop systems.
So using a HMI plugin allows Catalina to use the standard Parallax serial, keyboard, mouse and TV drivers with only trivial modifications (essentially, removing the Spin methods!) - and also provides a "wrapper" that makes them all look the same from within the C program even when they (internally) do very different things.
Ross.
@Rayman I thought that I only had the flags set in the build options section with sst highlighted. I took em out of the settings tab. Am I wrong about this?I
In Code::Blocks, select the Settings->Compiler and Debugger ... from the main menu
In the Selected Compiler dropdown list, ensure that the Catalina C compiler is selected
Select the Other Settings tab
In the Compiler Logging dropdown list, select Full Command Line
This is also described (with picture) on page 25 of the document Getting Started with CodeBlocks.
Ross.
It does appear that you are compiling vi instead of star trek. You know that, right?
I see two "-DNO_MOUSE" on every line, maybe that's a problem?
I also see a lot of "-w" in there. Not sure what that means, but it looks odd.
Maybe I'll try compiling vi and see what happens to me...
Ross says we should use the "serial PC HMI option " for 80-column display. I'm not 100% sure what that is, but I assume it's using something like the "Parallax Serial Terminal" to view serial output from the Prop.
I appreciate all your help and your projects....
That build log is definitely for xvi, and the reason it shows multiply defined symbols is that many of the compile flags and libraries are indeed defined twice on each catalina command line.
Obviously at some point you have successfully compiled and loaded sst (i.e. Super Star Trek) and it is now resident in the Flash RAM on the C3. That's why Flash_Boot can successfully execute it - that utility doesn't download anything, it just executes whatever is already in Flash.
You probably have fixed the sst settings, but your subsequent compiles have been of xvi (not sst) so you thought it was sst still failing to build.
In Code::Blocks, the easiest way to ensure you are compiling the correct project is to always right-click on the project name and select Rebuild. This will activate the project first and then rebuild it. Selecting Build->Rebuild from the main menu will rebuild the currently active project (whatever that happens to be!), but will not change the currently active project even if you have a different project selected in the project pane!
What's probably happened there is that at some point you thought you were setting the build options for sst, but in fact you ended up setting them for xvi. So now you will have to fix your xvi settings as well
Ross.
P.S. You can quite happily run Star Trek in HiRes VGA - just link using libc instead of libcx (i.e. -lc instead of -lcx). This will omit the file system support and (more importantly!) not load the SD plugin. Then just avoid the Help function, and don't load and save any games.
I think this is a text editor, right? I think I used to use that a long time ago in Linux, but now use gedit.
Anyway, with a good text editor, you can think about writing SPIN programs and compiling with SPHINX, on a the Prop...
Any chance Catalina could compile C code on the Prop? (i.e., can Catalina compile itself?)
(wait, I think I'm highjacking my own thread... I'll have to read those new forum rules again...)
@Rayman big grin and thank you for sharing your thread with me.
Now back into Catalina and apply what I have learned here . I am sure more questions will come.
Thanks guys for your help!!!
That's nice because I think Star Trek is a wonderful example of the power of Catalina and it'd be nice to tell people how to do it on the C3. (And BTW, how to do it soon an any Prop board with a RamPage module plugged in.)
I'd still like to get the clock out of it's own cog though. That seems like a big waste of a cog.
Maybe I'll see if I can add it to the High-Res VGA driver myself. Maybe that would make it easy for Ross to add to Catalina at some point...
Just did a quick bit of hacking, and the CLOCK plugin is now included in the SD card plugin. This means that if you use the extended library (which pulls in the SD plugin) then using the CLOCK no longer requires an extra cog.
This will be invisible to you - no code changes required to either the C program or the build process.
So Star Trek will now run properly in HiRes VGA on the C3, or when using the RAMPAGE.
Ross.
No, you'll have to wait for 3.3 - maybe tomorrow, if I get enough time.
Ross.
Is SD really much slower that the flash chip? Seems to me they are similar technology, but with a regular SPI interface.
I was able to get some very fast speed using FSRW 2.6
If we could run this off of SD, that would open it up to a lot more setups...
Hi Rayman,
Yes, this would be trivially easy to do. I'll pencil it in for 2015
Ross.
Ray, I love the way you think... This is likely applicable to many uses of external memory. (Except video of course)
OBC
You can use raw block access, but that's an "apparent solution" ... that is, it apparently will work for a while in many cases, but not in all cases. The other concern is the maximum contiguous block size is limiting.
One major problem is that SD cards are built with NAND flash which allows for bad blocks. To deal with that requires an indirect management and access method. That means you'll end up with a "filesystem" anyway.
So, the best way to deal with it is to use the device the way it's meant to be used. I believe Mike Green's sdspiFemto PASM driver could be adapted for into a cache COG for reading the SD, but a virtual address map would be necessary to indirectly access the data.
The question then becomes will that be fast enough to be useful? Probably for some, probably not for others. Depends on the application.
Still, since the SD card reading engine is already installed, why not couple the cache driver to the SD card driver and just load up the cache from compiled code on the SD card?
Actually, couldn't you then also switch between different programs too?
Hi Rayman,
Correct. That's why I was thinking of implementing it via the existing SD Card plugin - the cache would just use this plugin to perform sector-by-sector access to a predefined swap file. This swap file access could therefore co-exist with any normal SD card file access the C program needed.
Not promising anything, but this would be so easy that I may have a go at it sometime in the next few weeks.
However, I think jazzed is correct that this would be too slow for many purposes! Only a masochist - or a Parallax forum member - would even contemplate it!
Ross.
(Thanks to FSRW). Even if it were slow, it would probably be faster than Spin, right?
On the selfish side, I think having a Rampage module with an SD card is a real winner too.
Also, perhaps one day I'll have a nice Flash filesystem for Rampage and then you wouldn't need the SD card at all...