Shop OBEX P1 Docs P2 Docs Learn Events
CodeBlocks, Catalina, and Star Trek on C3 - Page 2 — Parallax Forums

CodeBlocks, Catalina, and Star Trek on C3

2»

Comments

  • RaymanRayman Posts: 14,865
    edited 2011-09-27 12:42
    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.
  • RossHRossH Posts: 5,517
    edited 2011-09-27 16:47
    Rayman wrote: »
    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.

    Ross.
  • RossHRossH Posts: 5,517
    edited 2011-09-27 17:03
    jazzed wrote: »
    What makes the HMI cog necessary? Just curious.

    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.
  • KMyersKMyers Posts: 433
    edited 2011-09-28 10:19
    @ 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
  • RossHRossH Posts: 5,517
    edited 2011-09-28 15:47
    Hi Ken,

    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.
  • KMyersKMyers Posts: 433
    edited 2011-09-29 09:48
    Ross thought I had this done as I worked through Getting started but who knows? Any how I reset it and here is the build log.
  • RaymanRayman Posts: 14,865
    edited 2011-09-29 10:08
    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...
  • KMyersKMyers Posts: 433
    edited 2011-09-29 10:17
    Thanks Rayman, I thought I was doing sst as that was the file I activated and had selected. It does run however on my vga monitor...
  • RaymanRayman Posts: 14,865
    edited 2011-09-29 10:44
    Great! Which one did you get running? Star Trek or xvi?
  • KMyersKMyers Posts: 433
    edited 2011-09-29 11:24
    I got super star trek running on my C3. Never tried VI, nut probably should!
  • RaymanRayman Posts: 14,865
    edited 2011-09-29 12:00
    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.
  • KMyersKMyers Posts: 433
    edited 2011-09-29 14:49
    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!

    I appreciate all your help and your projects....
  • RossHRossH Posts: 5,517
    edited 2011-09-29 15:45
    Hi Ken,

    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.
  • RaymanRayman Posts: 14,865
    edited 2011-09-29 17:19
    Well, I'm glad we got that all sorted out! I'm kinda interested in xvi now...

    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...)
  • KMyersKMyers Posts: 433
    edited 2011-09-30 09:00
    @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.

    Thanks guys for your help!!!
  • RaymanRayman Posts: 14,865
    edited 2011-09-30 16:42
    RossH wrote: »
    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...
  • RossHRossH Posts: 5,517
    edited 2011-10-01 21:53
    Hi Rayman,

    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.
  • RaymanRayman Posts: 14,865
    edited 2011-10-02 03:55
    Hurray! Will that show up if I download it now? Or, is this part of 3.3?
  • RossHRossH Posts: 5,517
    edited 2011-10-02 04:36
    Rayman wrote: »
    Hurray! Will that show up if I download it now? Or, is this part of 3.3?

    No, you'll have to wait for 3.3 - maybe tomorrow, if I get enough time.

    Ross.
  • KMyersKMyers Posts: 433
    edited 2011-10-02 09:04
    Sounds good Ross!!!
  • RaymanRayman Posts: 14,865
    edited 2011-10-03 15:25
    Ross, I was thinking some more about the C3...

    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...
  • RossHRossH Posts: 5,517
    edited 2011-10-03 18:26
    Rayman wrote: »
    Ross, I was thinking some more about the C3...

    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.
  • RaymanRayman Posts: 14,865
    edited 2011-10-04 08:48
    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.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2011-10-04 09:24
    Rayman wrote: »

    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)

    OBC
  • jazzedjazzed Posts: 11,803
    edited 2011-10-04 10:04
    Rayman wrote: »
    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.
  • RaymanRayman Posts: 14,865
    edited 2011-10-08 08:51
    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?
  • RossHRossH Posts: 5,517
    edited 2011-10-08 16:25
    Rayman wrote: »
    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!

    Ross.
  • RaymanRayman Posts: 14,865
    edited 2011-10-08 19:53
    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...
Sign In or Register to comment.