Shop OBEX P1 Docs P2 Docs Learn Events
Catalina 3.3 — Parallax Forums

Catalina 3.3

RossHRossH Posts: 5,458
edited 2011-11-01 15:30 in Propeller 1
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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
«13456711

Comments

  • RossHRossH Posts: 5,458
    edited 2011-10-09 05:45
    Reserved for updates etc.
  • RaymanRayman Posts: 14,572
    edited 2011-10-09 09:51
    Thanks Ross!
  • RaymanRayman Posts: 14,572
    edited 2011-10-09 12:24
    Ross, I ran "Uninstall Catalina" to remove the beta version. But, it didn't seem to remove very much...
    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.
  • RossHRossH Posts: 5,458
    edited 2011-10-09 14:43
    Hi Rayman,

    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.
  • RaymanRayman Posts: 14,572
    edited 2011-10-09 15:29
    Ross, I have noticed one small problem... If I do something wrong in the file flashpoint_def.inc, the build says "no errors", but when I scroll up, I see:

    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


  • RossHRossH Posts: 5,458
    edited 2011-10-09 16:19
    Rayman wrote: »
    Ross, I have noticed one small problem... If I do something wrong in the file flashpoint_def.inc, the build says "no errors", but when I scroll up, I see:

    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.
  • RossHRossH Posts: 5,458
    edited 2011-10-09 19:36
    Hi Rayman,

    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:

    Homespun Error.JPG


    Then press OK. Isn't Code::Blocks great?

    Ross.
  • RaymanRayman Posts: 14,572
    edited 2011-10-10 05:33
    I'm having trouble now using "PropTerm" with StarTrek.... Running with "PC" seems to work fine.
    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.
  • RaymanRayman Posts: 14,572
    edited 2011-10-10 06:03
    Something else... The "SRS" screen in Star Trek is supposed to show the 8x8 grid with dots except where there's a ship or star or something.
    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").
  • RossHRossH Posts: 5,458
    edited 2011-10-10 15:02
    Rayman wrote: »
    I'm having trouble now using "PropTerm" with StarTrek.... Running with "PC" seems to work fine.
    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.

    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.
  • RossHRossH Posts: 5,458
    edited 2011-10-10 15:10
    Rayman wrote: »
    Something else... The "SRS" screen in Star Trek is supposed to show the 8x8 grid with dots except where there's a ship or star or something.
    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").

    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.
  • RaymanRayman Posts: 14,572
    edited 2011-10-10 17:33
    Ok, I really have it working now. Running "sst" on a PropBox board with HighRes_VGA and keyboard and SD working too.
    (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?
  • RossHRossH Posts: 5,458
    edited 2011-10-10 19:29
    Rayman wrote: »
    Ok, I really have it working now. Running "sst" on a PropBox board with HighRes_VGA and keyboard and SD working too.
    (It was a long and painful struggle, but I'm very happy now!)
    Great - tell me about the bits that were painful, and I'll try and fix them for future users.
    Rayman wrote: »
    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.
    That what I had hoped you would do!
    Rayman wrote: »
    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...
    Yes. I decided to separate out the options related to plugins from the basic pin and clock configuration stuff. The CFG file contains a bunch of #define statements regarding various platform-specific peculiarities of the plugins, and the DEF file still contains everything else.
    Rayman wrote: »
    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.
    Correct in all cases.
    Rayman wrote: »
    The "xmm" and "emm" examples look like they could run in "small" mode (?).
    This depends on the platform and other options you use - for instance, if you use the PC HMI option there may be enough Hub RAM left to run the various program in SMALL mode, but if you use the HiRes VGA option there might not be, so you would have to use LARGE mode.
    Rayman wrote: »
    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.
    PST cannot be used for some things - for instance, you can run vi in putty, but not in PST. So rather than chopping and changing, I now just tend to use putty for everything.
    Rayman wrote: »
    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...
    Either one is fine, but if you post the questions here, the answer may be useful to others as well. People should still PM me for questions about commercial applications - but other than that posting here is fine.
    Rayman wrote: »
    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?
    Yes, it should. I'll check that out.
    Rayman wrote: »
    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?
    Yes. The above example cannot use small mode. Also, even if the size of cnst+init+data is less than 32k, in SMALL mode you also need to remember that plugin data, stack and heap space has to occupy Hub RAM as well - this can be difficult to estimate.
    Rayman wrote: »
    Also, wow the file is huge! Am I doing something wrong?
    No - for the Flash modes I don't bother to remove the unused SRAM space from the file, so you are in fact writing to the entire SRAM. This is just laziness on my part - I should not save or load the SRAM outside the used (i.e. init+data) space. I may fix this in the next release since it will reduce the load times.
    Rayman wrote: »
    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?
    Look in the file target\Catalina_VGA_HiRes_Text.spin, and select different configuration options (by commenting or uncommenting the various options out).

    Ross.
  • RossHRossH Posts: 5,458
    edited 2011-10-11 00:50
    Rayman wrote: »
    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?

    Yes, it looks like I broke that with a late edit. In the file FlashPoint_DEF.inc, the lines:
    '
    ' Define this symbol for the SUPERQUAD, since it does not include any SRAM:
    '
    #ifndef NO_RAM
    #define NO_RAM
    #ifdef LARGE
      ERROR : LARGE MEMORY MODE NOT SUPPORTED BY THE SUPERQUAD
    #endif
    #endif
    
    Should be replace with the lines:
    '
    ' Define this symbol for the SUPERQUAD, since it does not include any SRAM:
    '
    #ifndef NO_RAM
    #define NO_RAM
    #endif
    '
    ' Check for LARGE mode (which is not supported by the SuperQuad):
    '
    #ifdef LARGE
      ERROR : LARGE MEMORY MODE NOT SUPPORTED BY THE SUPERQUAD
    #endif
    
    I'll fix this in the next release.

    Ross.
  • RaymanRayman Posts: 14,572
    edited 2011-10-11 06:06
    Thanks Ross. More questions...

    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?
  • KMyersKMyers Posts: 433
    edited 2011-10-11 09:13
    @Rayman yes please continue posting on the forum as I read and learn from them!

    @Ross hope to get time this week to uninstall and upgrade my Catalina this weekend.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2011-10-11 12:18
    Ross, is there a Catalina & Code::Blocks "walkthrough" posted somewhere to guide a dummy through building and uploading to the Propeller an example program? I'm very very lost.
  • RossHRossH Posts: 5,458
    edited 2011-10-11 14:59
    Rayman wrote: »
    Thanks Ross. More questions...

    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?

    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.
  • RossHRossH Posts: 5,458
    edited 2011-10-11 15:00
    Ross, is there a Catalina & Code::Blocks "walkthrough" posted somewhere to guide a dummy through building and uploading to the Propeller an example program? I'm very very lost.

    Yes, there is a Getting Started with CodeBlocks document, and an even shorter CodeBlocks QuickStart guide.

    Ross.
  • RaymanRayman Posts: 14,572
    edited 2011-10-11 15:54
    RossH wrote: »
    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, 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?
  • RossHRossH Posts: 5,458
    edited 2011-10-11 17:17
    Rayman wrote: »
    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)?
    Code::Blocks comes with GCC support - but you have to install MinGW, MSYS and GCC yourself.
    Rayman wrote: »

    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):
    payload -e Flash_Boot
    
    If you want to do this from within Code::Blocks, just go Tools->Configure Tools. Then press Add and enter the following details:
    Name: Program Flash_Boot to EEPROM
    Executable: payload.exe
    Parameters: -e Flash_Boot
    Ross.
  • RaymanRayman Posts: 14,572
    edited 2011-10-11 17:43
    Ok, I think I see the EEPROM version isn't really an option for Large on Rampage since all of RAM is included in the file... Then, EEPROM would have to be at least 128 kB for the minimum program...

    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?
  • RaymanRayman Posts: 14,572
    edited 2011-10-11 18:17
    Ross, couple more questions... In "FlashPoint_CFG", I have these lines commented out:

    ' 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?
  • RossHRossH Posts: 5,458
    edited 2011-10-11 19:18
    Rayman wrote: »
    Ok, I think I see the EEPROM version isn't really an option for Large on Rampage since all of RAM is included in the file... Then, EEPROM would have to be at least 128 kB for the minimum program...
    I don't understand. Why would you want an EEPROM version when the FLASH version is permanent. Just load the program into Flash and the Flash_Boot program into EEPROM instead.
    Rayman wrote: »
    I think I like the "Configure Tools" thing in Code::Blocks. Perhaps I can write my own FlashPoint configurator utility to go in there...
    Yes, for C/C++ programming, Code::Blocks is the bees knees! You can easily modify the Catalina Wizard script to do more RamPage/Superquad configuration if you want - or write your own from scratch - it's really, really easy. I expect the GCC team will eventually realize this, and forget all about this "Eclipse" nonsense :smile:.
    Rayman wrote: »
    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?
    If Visual C++ is ANSI compliant, then the answer is yes.

    Ross.
  • RossHRossH Posts: 5,458
    edited 2011-10-11 19:21
    Rayman wrote: »
    I can't imagine anybody using a Flaspoint module with C3, since C3 already has expanded memory. Are these save to delete?
    I do!

    But yes, these lines should be deleted if you are not on a C3 (and they are not needed for your platform).

    Ross.
  • RaymanRayman Posts: 14,572
    edited 2011-10-12 06:42
    Ross, I was able to compile and run the "sst" example in Visual Studio...

    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.


  • RaymanRayman Posts: 14,572
    edited 2011-10-12 06:55
    Sorry, one more question... Catalina seems very close to looking like an OS...
    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?
  • RossHRossH Posts: 5,458
    edited 2011-10-12 16:55
    Rayman wrote: »
    Ross, I was able to compile and run the "sst" example in Visual Studio...

    Just had to remove the os2.c, linux.c and dos.c files from the project.

    ...

    Actually, adding "dos.c" to the Visual Studio project made everything better.

    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.
  • RossHRossH Posts: 5,458
    edited 2011-10-12 16:59
    Rayman wrote: »
    Sorry, one more question... Catalina seems very close to looking like an OS...
    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?

    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.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2011-10-12 17:43
    RossH wrote: »
    Yes, there is a Getting Started with CodeBlocks document, and an even shorter CodeBlocks QuickStart guide.

    Yes, right there in plain sight it would seem.:blush::blush::blush::blush:
Sign In or Register to comment.