Shop OBEX P1 Docs P2 Docs Learn Events
Object Request: C++ VGA Support (compensation negotiable) — Parallax Forums

Object Request: C++ VGA Support (compensation negotiable)

People like VGA on the Propeller. It's cool! Unfortunately, I only know of a single VGA implementation for the Propeller in C or C++, and that's in the Simple libraries. The Simple libraries were written to be simple and in C - not fast, efficient, or object-oriented.

PropWare is important to me, and I'd love to say that VGA fully supported in PropWare without having to resort to using the Simple libraries, but that isn't the case at the moment.

I'm looking for someone willing to take on the task of researching existing VGA objects in Spin/PASM and re-creating one in C++. I am not looking to download a library from the Obex, throw it through spin2cpp, and call it done... I could do that just fine by myself (though you're welcome to start there). I am looking for someone to take the time to understand PropWare's goals and style and then create a VGA object (or set of objects) that follow the same guidelines.

If you do not have a VGA-capable board, I am willing to purchase one for you to keep. I am also willing to negotiate compensation that would be paid upon acceptance of a pull request in GitHub.

The GitHub issue for this object can be found here: https://github.com/DavidZemon/PropWare/issues/53
«1

Comments

  • Where can one learn about "PropWare's goals and style"?
  • Are you looking for just text, or graphics, or all of the above?
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-11-24 14:54
    JasonDorie wrote: »
    Are you looking for just text, or graphics, or all of the above?

    That's a good question. The naive little me says I want it all! Don't know how realistic that is.

    I think the best way that I can answer that, is that I would like someone else to do the research into what is required for each and tell me what the cost will be in terms of: development time (calendar days), execution speed, code size.
    David Betz wrote: »
    Where can one learn about "PropWare's goals and style"?

    Ah.... you just want everything don't you. I guess I'll work on getting that documented. At the moment, your best bet would be to read the main page (http://david.zemon.name/PropWare) and then peruse the source code.
  • DavidZemon wrote: »
    David Betz wrote: »
    Where can one learn about "PropWare's goals and style"?

    Ah.... you just want everything don't you. I guess I'll work on getting that documented. At the moment, your best bet would be to read the main page (http://david.zemon.name/PropWare) and then peruse the source code.
    I did look there. That is why I posted my question. That link seems mostly to be an attempt to sell me on CMake! :-)

  • Heater.Heater. Posts: 21,230
    edited 2015-11-24 15:00
    If you make it a VT100 compatible green screen text terminal display that would be great.
    Say 80 columns by 40 lines.

    Preferably with no build system or library dependencies.

    :)
  • David Betz wrote: »
    I did look there. That is why I posted my question. That link seems mostly to be an attempt to sell me on CMake! :-)

    DRINK THE KOOL-AID!!!!

    And yes, I certainly understand that it is not documented well at all. I'll see about finding an example of this type of documentation in other projects and attempt to replicate.
  • Most of the heavy lifting in these things is in PASM. Are you ok with the bulk of it staying that way in a spin file and just providing a new C/C++ API for it? That would presumably be a relatively simple port.

    Text mode would be easiest. Graphics are memory hungry, and C/C++ projects (especially LMM) can be too.

    J
  • JasonDorie wrote: »
    Most of the heavy lifting in these things is in PASM. Are you ok with the bulk of it staying that way in a spin file and just providing a new C/C++ API for it? That would presumably be a relatively simple port.

    Text mode would be easiest. Graphics are memory hungry, and C/C++ projects (especially LMM) can be too.

    J

    I would like inline assembly to be investigated. I've had tremendous success using it (and fcache) for other objects. I won't use any stronger word at the moment other than "investigated."
  • Jazzed already created a C port of the Spin VGA text driver. This works exactly as Jason suggested. It provides C functions to wrap the PASM portion of the original Spin driver.
  • David Betz wrote: »
    Jazzed already created a C port of the Spin VGA text driver. This works exactly as Jason suggested. It provides C functions to wrap the PASM portion of the original Spin driver.

    That will likely be a good start then. All that needs to be done is to PropWare-ify it :)
  • DavidZemon wrote: »
    JasonDorie wrote: »
    Most of the heavy lifting in these things is in PASM. Are you ok with the bulk of it staying that way in a spin file and just providing a new C/C++ API for it? That would presumably be a relatively simple port.

    Text mode would be easiest. Graphics are memory hungry, and C/C++ projects (especially LMM) can be too.

    J

    I would like inline assembly to be investigated. I've had tremendous success using it (and fcache) for other objects. I won't use any stronger word at the moment other than "investigated."

    I should add, inline assembly combined with cogcpp (an option unique to PropWare's build system - same as cogc but with C++) might be better than fcache for something like this.
  • Heater.Heater. Posts: 21,230
    What damage to you have to do to a C/C++ module (Plus assembler driver COG) to "PropWare-ify" it ?
  • Heater. wrote: »
    What damage to you have to do to a C/C++ module (Plus assembler driver COG) to "PropWare-ify" it ?

    That's the documentation that I promised David Betz above. In short

    * convert it to C++
    * Reformat the whitespace
    * Update naming convention
    * Replace use of pins with PropWare's "Pin" or "Port" class

    There are other details (preferences) I'll have to work out, but I think that's the majority of the work.
  • DavidZemon wrote: »
    David Betz wrote: »
    Jazzed already created a C port of the Spin VGA text driver. This works exactly as Jason suggested. It provides C functions to wrap the PASM portion of the original Spin driver.

    That will likely be a good start then. All that needs to be done is to PropWare-ify it :)
    I took a glance at your UART class and your conventions don't seem too different than what I would do anyway. I guess you prefer underscores over camel case. I haven't looked at your white space conventions yet. I may try converting Steve's C code to C++ later. I seem to remember that I did this once before when I thought Parallax was going to adopt C++ for their Learn program.

  • David Betz wrote: »
    I guess you prefer underscores over camel case. I haven't looked at your white space conventions yet.

    I read a style guide somewhere that said underscores were a common convention in C++. I'm not sure how accurate that was anymore, but I think it's too late to change it now :/
  • DavidZemon wrote: »
    David Betz wrote: »
    I guess you prefer underscores over camel case. I haven't looked at your white space conventions yet.

    I read a style guide somewhere that said underscores were a common convention in C++. I'm not sure how accurate that was anymore, but I think it's too late to change it now :/
    I tend to prefer camel case because it makes the identifiers slightly shorter.

  • David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    I guess you prefer underscores over camel case. I haven't looked at your white space conventions yet.

    I read a style guide somewhere that said underscores were a common convention in C++. I'm not sure how accurate that was anymore, but I think it's too late to change it now :/
    I tend to prefer camel case because it makes the identifiers slightly shorter.

    I gave up caring about line length when I started using JetBrains IDEs with their incredible autocompletion and purchased a monitor that is 1920 pixels wide.
  • Heater.Heater. Posts: 21,230
    Short/long identifiers is one thing but underscores make the source code look really ugly.

  • Heater. wrote: »
    Short/long identifiers is one thing but underscores make the source code look really ugly.
    Well, I'm not sure I'd say "ugly". I do prefer camel case though.

  • David Betz wrote: »
    Heater. wrote: »
    Short/long identifiers is one thing but underscores make the source code look really ugly.

    Well, I'm not sure I'd say "ugly". I do prefer camel case though.

    I do too. But I hate the idea of making such a large, breaking change. I'd be interested in hearing Parallax's opinion and if switching (or keeping it) affects their decision on official adoption.
  • DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    Short/long identifiers is one thing but underscores make the source code look really ugly.

    Well, I'm not sure I'd say "ugly". I do prefer camel case though.

    I do too. But I hate the idea of making such a large, breaking change. I'd be interested in hearing Parallax's opinion and if switching (or keeping it) affects their decision on official adoption.
    I didn't know they were considering adopting PropWare. In any case, they seem to use underscores in Simple Libraries so I doubt that your use of underscores would impact their decision.

  • David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    Short/long identifiers is one thing but underscores make the source code look really ugly.

    Well, I'm not sure I'd say "ugly". I do prefer camel case though.

    I do too. But I hate the idea of making such a large, breaking change. I'd be interested in hearing Parallax's opinion and if switching (or keeping it) affects their decision on official adoption.
    I didn't know they were considering adopting PropWare. In any case, they seem to use underscores in Simple Libraries so I doubt that your use of underscores would impact their decision.

    I have no idea if they are or not. But nothing would make me more proud of PropWare than for someone at Parallax to take a look and give me criticism/suggestions/requests.
  • My conventions: gg=G
  • Heater.Heater. Posts: 21,230
    Never mind that. The important questions are: Are you using spaces instead of tabs and if so are you using 4 space indentation? :)
  • SimpleIDE doesn't keep tabs. Probably my biggest rage with it. :-)
  • JasonDorie wrote: »
    SimpleIDE doesn't keep tabs. Probably my biggest rage with it. :-)
    Well, I actually prefer that hardware tabs not get saved. People never seem to agree as to how many spaces constitute a tab stop and I invariably get badly indented code when I open someone else's code containing tabs. I guess if you could force everyone to use the same tab settings then real tabs would be nice. Otherwise, I'd rather avoid them.

  • Heater.Heater. Posts: 21,230
    Jason,
    SimpleIDE doesn't keep tabs
    Glad to hear SimpleIDE is doing something right :)

    Tabs are the bane of every programmers existence. Especially if your code depends on white space for sematics, like Spin or Python.

    Aside: Which moron decided to give TAB semantic significance in make files ?
  • Heater. wrote: »
    Jason,
    SimpleIDE doesn't keep tabs
    Glad to hear SimpleIDE is doing something right :)

    Tabs are the bane of every programmers existence. Especially if your code depends on white space for sematics, like Spin or Python.

    Aside: Which moron decided to give TAB semantic significance in make files ?
    I have no idea but it was a really bad choice!

  • Did we find something that we can all agree on?!
  • DavidZemon wrote: »
    Did we find something that we can all agree on?!
    Nope. Some like tabs, some like spaces. No concensus.

Sign In or Register to comment.