Help create the Spin Standard Library!

135

Comments

  • Here is Kye's SD drivers, as modified and split by me. It is what I currently use in PropOS.
    They currently support FAT16/32 and SD & SDHC cards.

    I almost have Michael Park's Sphinx Compiler (compiles spin/pasm on the propeller) working under PropOS.

    Self-hosting... here we come ! :) :) :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Here is a basic I2C driver that I have used
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,227
    edited 2016-01-01 - 00:23:14
    I would delete formatting methods like dec, hex, etc. from the serial and video text objects. Nothing more than character and string methods should be included. SimpleNumbers handles the formatting stuff.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • David Betz wrote: »
    This all sounds great! If you can figure out a way to make use of Cluso99's rendevous console I/O interface to allow the serial driver to be swapped for one of the LCD drivers it would be even better.

    I won't be including those objects because they require rendezvous points. Those kinds of things are more like frameworks than plain old libraries. I will however be making the APIs for all the console objects identical so that they can be swapped in that regard.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • I would delete formatting methods like dec, hex, etc. from the serial and video text objects. Nothing more than character and string methods should be included. SimpleNumbers handles the formatting stuff.

    -Phil

    +10 for that.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • DavidZemon wrote: »
    Brett Weir wrote: »
    Lev wrote: »
    Off the top of your heads, do you guys have any suggestions for any of these? Can you think of any I haven't listed here that should be covered by this library? -

    Should add ADCs MCP3202, 3204, 3208

    Oooh, that would be a good one. Do you know any good drivers for it? Preferably one that can be used for all 3. Then it can be one object called:
    signal.adc.mcp320x
    

    I'd recommend picking your favorite Spin object for any of the MCP3xxx devices and then use my MCP3000 object from PropWare as inspiration for tweaking it.
    https://github.com/DavidZemon/PropWare/blob/release-2.0/PropWare/mcp3000.h

    there is no function difference between an MCP3202, MCP3204 and MCP3208, only how many channels. So, the most you'd want to do is check the channel requested and, if too high, return an error. Other than that, all of the logic remains the same. Then the only difference between MCP300X, MCP320X, and MCP330X is how many bits you shift in. All of the bits are still in the same order, channels are selected in the same way, etc etc.

    Oh, sweeeeet! I didn't realize they were all so closely related. I also didn't notice this, but it looks like there's already an object in the library for the mcp3208 at least. I've never used the chip though so I'm not entirely sure how any of it works. Can someone fill me in on this object? How does the API work? Also, if I understand correctly, the interface to this chip is SPI, so is there any reason it needs its own assembly driver implementation? Or can it just use com.spi?

    (can someone tell me how com.spi works? haha)

    https://github.com/parallaxinc/spin-standard-library/blob/master/library/signal.adc.mcp3208.spin
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Erlend wrote: »
    Brett Weir wrote: »

    I went there - looked at some of the work - fantastic!

    Erlend

    Thanks!
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • potatohead wrote: »
    Brett, maybe. I've got some stuff written for the Parallax, what I call reference drivers. A lot of that is in the HYDRA book too.

    The other drivers all vary considerably, and some are specific purpose too.

    At this time, I remain unsure just what to put into such a work. Seems like it would have to cover video formats, signals, general graphics concepts, graphics hardware concepts such as tiles, sprites, colors, buffering strategies, etc... along with specific implementation details and math for the various drivers out there. Frankly, the HYDRA book, coupled with one on game design and graphics from the 90's era covers it well. That is for the Parallax drivers, and at least one other high color, game oriented one.

    Andre' and I discussed this some time back. If someone gets "The Black Art of Game design" and the HYDRA book, they can do a lot.

    One exception is tricks for technical, or instrumentation type displays. Game tricks apply, but can be hard to map over to a more industrial application...

    So, I arrived at a place where it is either a real book, like maybe one people pay for, or it won't do too much more good than a forum search and or some time spent with the code would.

    I'm not convinced the audience is all that large too. Could be bigger, build and they will come, but I really don't know.

    So there is the state of it. I really don't know what would make sense, and the effort is non trivial enough to make that an obstacle.

    Ahh, fair enough. I suppose you would in large part be retelling a story that's already been told, if you want to go that deep into it.

    What would still be very helpful from you is a short tutorial on how to get the drivers up and running and some very short and to-the-point examples on how to use them. Fiendishly short, like this one, that demonstrate only one or two features at a time:

    https://github.com/parallaxinc/spin-standard-library/blob/master/library/demos/com/serial/HelloWorld.spin
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Thanks, @Cluso99. You've given me a huge amount of material to look over!!

    I have to say, the FAT engine object is huge. Would it make sense to split it into multiple objects? And since it can only open one file at a time, perhaps it would make sense to call it:
    storage.sdcard.file.fat
    

    My question is, does this entire FAT engine only work with SD cards. Would a new one have to be written to work with USB drives? How portable is this code? Does anyone use any filesystem besides FAT for SD cards?

    I think the I2C driver will go great in the "tiny" collection, which is where all the small. basic objects that don't require a separate cog are going. Does anyone know a hardware-accelerated I2C driver?

    Out of curiosity, do you have a video of PropOS in use? =P
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • I would delete formatting methods like dec, hex, etc. from the serial and video text objects. Nothing more than character and string methods should be included. SimpleNumbers handles the formatting stuff.

    -Phil

    Already in the works. Here's my plan so far:

    Basic objects that implement a communication protocol only implement the bare minimum. In the case of serial and video text, that's Char and CharIn. Then, the corresponding terminal objects (com.serial has com.serial.terminal) implement convenience functions using string.numbers since they are to be used for this purpose anyway. Otherwise, there is little reason at all for the terminal objects to even exist.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Cluso99Cluso99 Posts: 14,728
    edited 2016-01-01 - 04:24:45
    Brett Weir wrote: »
    Thanks, @Cluso99. You've given me a huge amount of material to look over!!

    I have to say, the FAT engine object is huge. Would it make sense to split it into multiple objects? And since it can only open one file at a time, perhaps it would make sense to call it:
    storage.sdcard.file.fat
    

    My question is, does this entire FAT engine only work with SD cards. Would a new one have to be written to work with USB drives? How portable is this code? Does anyone use any filesystem besides FAT for SD cards?

    It only works with SD cards formatted in FAT16/32. USB drives are not supported on the prop and not likely to be. I would not expect them to be on P2 either although I will be attempting to get USB Serial working to the PC at FS.

    I have split the PASM driver which uses a separate cog from the rest of the spin FAT code. It only supports 8.3 filenames but also supports multiple directories.

    The spin code may be used multiple times for multiple file access. Remember, only the VARs are duplicated in the hub, with the spin routines only included once. Some spin compilers support code removal if not used, so the unused spin calls could be removed.
    I think the I2C driver will go great in the "tiny" collection, which is where all the small. basic objects that don't require a separate cog are going. Does anyone know a hardware-accelerated I2C driver?
    I am sure there is a pasm version - just don't recall where.
    Out of curiosity, do you have a video of PropOS in use? =P
    No. Presume I could do it on iPhone/iPad and post the file.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 14,728
    edited 2016-01-01 - 04:27:18
    Here is a copy/paste from PST via Notepad of my PropOS...
    *** Cluso's Propeller Operating System v0.84 ***
    ------------------------------------------------
     (see 'VER' for acknowledgements)
     Locks used: --------
     SD Driver Cog = 2
     Hardware: Cluso's P8XBlade2
     ClockFreq 096000000Hz, ClockMode $E, Cog 0
     SD card on pins 12,13,14,15
     Serial  on pins 30,31, Mode 00, Baud 00115200, Cog 1
     Screen size: 080 x 040
     <LF> is OFF
     Resident Cogs : 1 2   This Cog: 0
     Cogs available: 3 4 5 6 7 (=5)
     Booting from SD card...
    SD:>dir
    ARGS    .D8A   ARGS    .D8A   ASCII0~1.SPN   AUTOEXEC.BAT   BINTREE .SPN
    CODEGEN .BIN   CODEGEN .SPN   COGCHECK.SPN   COMBOKB .SOB   COPY    .SPN
    DEL     .SPN   DIR     .BIN   DIR     .SPN   ECHO    .SPN   ED      .SPN
    EVAL    .SPN   FDSERIAL.SOB   FLTMATH .SPN   FLTSTR  .SPN   GRAPHICS.SOB
    GRAPHICS.SPN   GR_DEMO .SPN   HELLO1  .BIN   HELLO1  .SOB   HELLO1  .SPN
    HELLO1  .TOK   HELLO2  .BIN   HELLO2  .SOB   HELLO2  .SPN   HELLO2  .TOK
    ISXFS   .SOB   ISXFS   .SPN   ISXKB   .SOB   ISXTV   .SOB   ISXTV   .SPN
    KEYWORDS.SPN   KWDEFS  .SPN   LEX     .BIN   LEX     .SPN   LINK    .BIN
    LINK    .SPN   METHODS .SPN   MOUSEISO.SOB   RAMBLADE.ZIP   SPHINX  .BIN
    SPHINX  .SPN   SPHINX1 .ZIP   STRINGX .SPN   SXFILE  .SOB   SXFILE  .SPN
    SXFS    .SPN   SXFS2   .SPN   SXKB    .SPN   SXSDSPIQ.SPN   SXTV    .SPN
    SYMBOLS .SPN   SYSTEM~1.      TIMESTMP.D8A   TOKENIZR.SPN   TOKENRDR.SPN
    TV      .SOB   TVTEXTED.SPN   TV_TEXT .SOB   _CMD    .CMD   _CODEGEN.CMD
    _COPY   .CMD   _DEL    .CMD   _DIFF   .CMD   _DIR    .CMD   _DIRCPM .CMD
    _DIRX   .CMD   _DIRX   .SPN   _DIRX   .TOK   _DIRX2  .TOK   _FREE   .CMD
    _GETCPM .CMD   _GETFAT .CMD   _HELP   .CMD   _HELP   .TXT   _HUBDEF3.SPN
    _HUBDUMP.CMD   _HWDEF  .SPN   _LEX    .CMD   _LF     .CMD   _LINK   .CMD
    _LS     .CMD   _MAPCPM .CMD   _OS     .CMD   _PROGRAM.CMD   _PUTCPM .CMD
    _PUTFAT .CMD   _REBOOT .CMD   _REN    .CMD   _RUN    .CMD   _SD_FAT .SPN
    _SD_PASM.SPN   _STDIN  .SPN   _STDOUT .SPN   _TESTSD .CMD   _TYPE   .CMD
    _USED   .CMD   _VER    .CMD   __MODULE.SPN
    SD:>help
    *** Propeller SD card Operating System v0.83 ***  (19 December 2015)
    -------------------------------------------------------------------------------
    cmd     ---                               ' Internal use (command interpreter)
    copy    <source_file> <destination_file>  ' Copy a file
    del     <file>                            ' Delete a file
    diff    <file1> <file2>                   ' Display file differences
    dir     [mask]                            ' Display directory of files
    dircpm  <cpm_disk>                        ' Display directory of files on CPM
    free                                      ' Display FAT16/32 used/free space
    getcpm  <cpm_disk> <cpm_file> <fat_file> -T/B ' Get (copy) CPM file to FAT16/32
    aetfat  <fat_file>                        ' Get (copy) FAT16/32 file to PC
    help                                      ' Display help info
    hubdump <addr> <lines>                    ' Dump hub memory addr(hex) n lines
    lf                                        ' Toggles LF on/off
    ls      [mask] [A]                        ' Display directory of files
    mapcpm  <cpm_disk> [<cpm_file> [-d]]      ' Maps info about the CPM filesystem
    os      ---                               ' PropOS binary file (runs PropOS)
    program <source_file> [{-WL}{-WU}]        ' Program to EEPROM L=Lower/U=Upper
    putcpm  <fat_file> <cpm_disk> <cpm_file>  ' Put (copy) FAT16/32 file to CPM
    putfat  <fat_file>                        ' Put (copy) FAT16/32 file from PC
    reboot                                    ' Reboot the Propeller Chip
    ren     <source_file> <destination_file>  ' Rename a file
    run     <file>                            ' Run a ".BIN" file (kills PropOS)
    testsd                                    ' Tests the SD card (writes to SD)
    type    <file> [-h]                       ' Display the contents of a file
    used                                      ' Display FAT16/32 used/free space
    ver                                       ' Display info about PropOS
    
    BOOTPROP.BIN    '\ Boots the OS (a copy of _OS.CMD)
    _OS     .CMD    '| Boots the OS (a copy of _OS.CMD)
                    '/ may be programmed into EEPROM to boot PropOS
    
    To RUN any Propeller Binary (replaces the OS completely)...
    SD:>RUN z3_174fx                          ' Runs ZiCog RamBlade3 V174 binary
    A:>HALT                                   ' Reboots the prop (from CPM prompt)
    
    SD:>lex _dirx -v3
    LEX 20151231
    Reading _DIRX.SPN
    Writing _DIRX.TOK
    SD:>
    
    Note "LEX" is Michael Park's Sphinx Compiler (part 1 of 3) running under PropOS but not verified yet.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Brett Weir wrote: »
    David Betz wrote: »
    This all sounds great! If you can figure out a way to make use of Cluso99's rendevous console I/O interface to allow the serial driver to be swapped for one of the LCD drivers it would be even better.

    I won't be including those objects because they require rendezvous points. Those kinds of things are more like frameworks than plain old libraries. I will however be making the APIs for all the console objects identical so that they can be swapped in that regard.
    Too bad.

  • Brett Weir wrote: »
    ...I have to say, the FAT engine object is huge. Would it make sense to split it into multiple objects? And since it can only open one file at a time, perhaps it would make sense to call I...

    Yes, I spend a lot of time with Kye's Fat_Engine. I even have some version using FSRWs Block Driver mixed with Kye's PASM. Somewhere.

    You are NOT right about just opening one file at a time. Like most spin objects you can use multiple instances of the driver, Just start/mount the first one.

    All of them will use the same code, the same data BUT their own copy of VAR sections.

    I spend a lot of time shrinking down Spin Objects by commenting unused Methods, since I was using the PropTool. But the latest versions of OpenSpin seem to be able to prune out unused code.

    The fastest implementation of SD card SPI is in FSRW. That PASM driver written by @LoneSock is optimized for fast block write and read. Small little Gem's in there written by @kuroneko. Basically the driver supports read ahead and write behind. so it will transfer as fast as possible between hub and cog ram and then return control to the caller and do the work in parallel.

    FSRW is really worth to study.

    So splitting the Fat_Engine Code in separate parts may be interesting for - say - using a Fat File System on some other storage medium able to support block access, like EEPROMS or Flash or even external RAM.

    FSRW is way faster but does not have as much features as Fat_Engine has.

    But if you would start to remove all the formatting stuff like writeByte, writeLong like you are planning with the serial driver stuff, it might be very easy to use, later.

    So YES it would be a good idea to split this into multiple objects. With serial you have byte access, with block driver you just have access to sectors, so some buffering will be needed.

    Good work.

    Enjoy!

    Mike


    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • What would still be very helpful from you is a short tutorial on how to get the drivers up and running and some very short and to-the-point examples on how to use them.

    Like this one: http://forums.parallax.com/discussion/123709/commented-graphics-demo-spin/p1

    A walk through that code and the comments will typically answer most questions on colors and tiles. When you run it, the code walks through the features shown. One can then read the code, watch the screen, see the change, etc... A couple helper methods are in there for easy, "ok, what if I do this?" type modify and learn attempts.

    Getting drivers running is largely covered in either their internal documentation, or example demo code documentation, or the HYDRA book, which does go into a lot more basic detail. That's not something I'm inclined to write. There are a lot of boards, video circuits, clocks, methods of driver setup, computation of frequencies and constants.... That too is a short book.

    You did give me something I could work on at some point though, and that is a little set of programs that show features. I would most likely do this for the parallax TV, VGA, and Graphics.spin drivers. Might do it for a character and or linear bitmap driver or two, depending. I'll think on this some.

    Truth is, it's software driven video. It's been done a lot of ways, and there are a lot of possibilities and trade-offs. Once one gets past the basics Chip did, it's a big playground. Hard to document formally, and like I said, it can be done, but the audience size and effort don't quite match up.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Brett,

    I would also include the str and strin methods in the basic I/O objects.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Off the top of your heads, do you guys have any suggestions for any of these? Can you think of any I haven't listed here that should be covered by this library?

  • Oooh, that would be a good one. Do you know any good drivers for it? Preferably one that can be used for all 3. Then it can be one object called:

    I like jm_320x_ez. It is simple and works great.
  • Cluso99 wrote: »
    USB drives are not supported on the prop and not likely to be. I would not expect them to be on P2 either although I will be attempting to get USB Serial working to the PC at FS.

    Why is that? Does USB require a massive driver or something?
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • msrobots wrote: »
    Yes, I spend a lot of time with Kye's Fat_Engine. I even have some version using FSRWs Block Driver mixed with Kye's PASM. Somewhere.
    msrobots wrote: »
    You are NOT right about just opening one file at a time. Like most spin objects you can use multiple instances of the driver, Just start/mount the first one.

    All of them will use the same code, the same data BUT their own copy of VAR sections.
    msrobots wrote: »
    So YES it would be a good idea to split this into multiple objects. With serial you have byte access, with block driver you just have access to sectors, so some buffering will be needed.

    Oh, yes, I understand that. I use that to create singleton core objects in the LameStation SDK. I meant that a single instance of the object can open a single file. It would be better if the core object that interfaces to the SD card and handles mounting/unmounting was one object, and the object that represents an open file was another object, and it would be very good to have different wrapper objects for doing block vs. serial access.

    So we'd have something like this:
    storage.sdcard
    storage.sdcard.file.stream
    storage.sdcard.file.block
    
    msrobots wrote: »
    I spend a lot of time shrinking down Spin Objects by commenting unused Methods, since I was using the PropTool. But the latest versions of OpenSpin seem to be able to prune out unused code.

    The latest version of OpenSpin does support unused code removal, but I haven't enabled it by default in PropellerIDE because it causes some undefined behavior that hasn't been resolved.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • potatohead wrote: »
    What would still be very helpful from you is a short tutorial on how to get the drivers up and running and some very short and to-the-point examples on how to use them.

    Like this one: http://forums.parallax.com/discussion/123709/commented-graphics-demo-spin/p1

    A walk through that code and the comments will typically answer most questions on colors and tiles. When you run it, the code walks through the features shown. One can then read the code, watch the screen, see the change, etc... A couple helper methods are in there for easy, "ok, what if I do this?" type modify and learn attempts.

    Getting drivers running is largely covered in either their internal documentation, or example demo code documentation, or the HYDRA book, which does go into a lot more basic detail. That's not something I'm inclined to write. There are a lot of boards, video circuits, clocks, methods of driver setup, computation of frequencies and constants.... That too is a short book.

    You did give me something I could work on at some point though, and that is a little set of programs that show features. I would most likely do this for the parallax TV, VGA, and Graphics.spin drivers. Might do it for a character and or linear bitmap driver or two, depending. I'll think on this some.

    Truth is, it's software driven video. It's been done a lot of ways, and there are a lot of possibilities and trade-offs. Once one gets past the basics Chip did, it's a big playground. Hard to document formally, and like I said, it can be done, but the audience size and effort don't quite match up.

    I'm getting a similar feeling to when I first started with the Propeller. Even the easy demo isn't that easy to understand. Do you think it would make any sense to have some stripped down versions, or wrapper objects pre-configured to some specific settings, so that the user can just load them and go? This part is particularly daunting for new users:
      'Reserved variable space for comms with the TV driver
      long  tv_status     '0/1/2 = off/visible/invisible           read-only
      long  tv_enable     '0/? = off/on                            write-only
      long  tv_pins       '%ppmmm = pins                           write-only
      long  tv_mode       '%ccinp = chroma,interlace,ntsc/pal,swap write-only
      long  tv_screen     'pointer to screen (words)               write-only
      long  tv_colors     'pointer to colors (longs)               write-only               
      long  tv_hc         'horizontal cells                        write-only
      long  tv_vc         'vertical cells                          write-only
      long  tv_hx         'horizontal cell expansion               write-only
      long  tv_vx         'vertical cell expansion                 write-only
      long  tv_ho         'horizontal offset                       write-only
      long  tv_vo         'vertical offset                         write-only
      long  tv_broadcast  'broadcast frequency (Hz)                write-only
      long  tv_auralcog   'aural fm cog                            write-only
    

    I think a tree like this would be really awesome for starting users:
    display.tv
    display.tv.bitmap.320x240x4
    display.tv.bitmap.800x600x4
    display.tv.bitmap.640x480x4
    display.tv.text
    display.tv.text.terminal
    display.tv.tile.1280x720
    

    Or whatever color depth is commonly used. The important thing is not covering every possible scenario but making it easy to turn the damn thing on. That's the general idea.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Brett,

    I would also include the str and strin methods in the basic I/O objects.

    -Phil

    Those seem more human-readable text-oriented than a basic I/O function. If you were creating a structured protocol over serial, would you be sending null-terminated strings or formatted data?
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • potatoheadpotatohead Posts: 9,700
    edited 2016-01-02 - 09:14:34
    The nice thing about the Parallax drivers is there happens to be a TON of documentation on them, they work reasonably in PAL or NTSC, and on most any TV, use the default video DAC circuit, and will work on pretty much any setup, and a nice general purpose graphics library is included.

    https://www.parallax.com/sites/default/files/downloads/32360-Hydra-Game-Dev-Manual-v1.0.1.pdf

    That covers every single prerequisite concept needed to understand and use the Parallax TV.spin driver and the graphics.spin library. The good stuff starts on page 325, with reference and background material by topic before that. It's very, very complete actually.

    Two gaps I see:

    1. there is really no need for a distinction between tiles and bitmaps in the library hierarchy, unless one is going to include several drivers in addition to the Parallax ones.

    With the Parallax drivers, they are one and the same. Other drivers vary a lot on this, and for beginners, it's likely not a good idea to include them as they would need to at least be able to manage the Parallax ones before exploring other ones. Most other drivers are commented in the code, and that plus a small demo, is the documentation.

    2. the TV driver could use a nice setup method. That would more or less get rid of the set of parameters you highlighted, or at least not require them for a couple of cases. This isn't hard to write.

    Double buffering is the simplest way, but it's RAM expensive. For beginners, it's probably wise to go with the default 256x192, or maybe 320x200x4 and call it good. They can learn to do a lot on that, and would need experience to understand when it's going to begin to not make sense from a HUB RAM perspective. The higher resolutions you mention either don't make sense on TV, due to the format limits being roughly 640x480, or the buffer requirements exceeding HUB RAM practicalities.

    And how beginning of users are we talking about here?

    I'm asking, because if one picks the right pins, or just uses a Demoboard compatable video setup, turning the darn thing on is as simple as opening graphics_demo.spin and pressing the F10 button and they see cool stuff on the TV. From there, it's read the code, read the docs, or change stuff and see what happens. What boards are being targeted now? What really prevents this from working today? It's pretty easy.

    If more advanced use cases are desirable, say a higher resolution, single or partial buffer, kind of scenario, then it's just not beginners anymore, and covering those cases very rapidly become project specific trade-offs, and that goes back to the trouble I mentioned earlier. I struggle to see where it's real help as opposed to yet another duplication of material done a few times before...

    So, maybe write a setup method for tv.spin, and set defaults and include one alternative to graphics_demo.spin, like a program that plots a dot, or draws at the origin and extants?

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Those seem more human-readable text-oriented than a basic I/O function. If you were creating a structured protocol over serial, would you be sending null-terminated strings or formatted data?
    If Spin allowed function pointers, I would agree. Then a generic outstr method could point to both a string to output and the I/O method to do the outputting. But this is not something Spin allows. Without including the str-type functions in the I/O objects themselves, it will be that much more cumbersome to output data formatted into strings by external formatting methods or to input CR-terminated strings.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Those seem more human-readable text-oriented than a basic I/O function. If you were creating a structured protocol over serial, would you be sending null-terminated strings or formatted data?
    If Spin allowed function pointers, I would agree. Then a generic outstr method could point to both a string to output and the I/O method to do the outputting. But this is not something Spin allows. Without including the str-type functions in the I/O objects themselves, it will be that much more cumbersome to output data formatted into strings by external formatting methods or to input CR-terminated strings.

    -Phil
    I guess this is where Cluso99's rendevous would help. The string output functions would just use whatever driver is pointed to by the rendevous variables.

  • Yep. Agreed.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • The str method that is included with serial drivers is trivial. It calls the tx/out method until a NULL is encountered. An instr method would be a little more complicated if you want to ensure you don't overflow the input buffer and you want to allow for backspace editing.

    I'm not sure how a rendezvous tables helps since Spin doesn't have method pointers. You would need to provide drivers for all possible inputs/outputs and switch between them depending on the I/O type. That's how spinix does it. It includes the driver routines for both VGA and serial, and determines which driver to call based on an I/O descriptor. The same is true for keyboard versus serial input.

    I did develop a method pointer object a few years ago, and posted it to the OBEX. It is a bit cumbersome to use, but it does work. Maybe a new Spin compiler could incorporate methods pointers in its syntax.
  • potatohead wrote: »
    ... use the default video DAC circuit,...

    Which is the default circuit? I've seen lots of different circuits used for various examples.
    potatohead wrote: »
    1. there is really no need for a distinction between tiles and bitmaps in the library hierarchy, unless one is going to include several drivers in addition to the Parallax ones.

    I made that distinction because there are already some objects in the library that are simply wrappers around the tv driver for specific purposes.
    display.tv.text
    display.tv.terminal
    

    They also look like they handle some fairly generic setup stuff.
    '' Start terminal
    ''
    ''  basepin = first of three pins on a 4-pin boundary (0, 4, 8...) to have
    ''  1.1k, 560, and 270 ohm resistors connected and summed to form the 1V,
    ''  75 ohm DAC for baseband video   
    
      'init bitmap and tile screen
      bitmap_base := (@bitmap + $3F) & $7FC0
      repeat x from 0 to x_tiles - 1
        repeat y from 0 to y_tiles - 1
          screen[y * x_tiles + x] := bitmap_base >> 6 + y + x * y_tiles
    
      'start tv
      tvparams_pins := (basepin & $38) << 1 | (basepin & 4 == 4) & %0101
      longmove(@tv_status, @tvparams, paramcount)
    

    I'd like to see how this could be encapsulated and more easily made available. I also agree that I don't want to see lots of different drivers in the mix, but if only one TV driver is necessary, what is the story behind all the VGA drivers in the project?
    potatohead wrote: »
    2. the TV driver could use a nice setup method. That would more or less get rid of the set of parameters you highlighted, or at least not require them for a couple of cases. This isn't hard to write.

    Yes! That's exactly what I'd like to see.
    potatohead wrote: »
    Double buffering is...

    Yes, I was quoting random resolutions that didn't really pertain to anything. >.>
    potatohead wrote: »
    And how beginning of users are we talking about here?

    I'd like to make it simple enough that someone with a passing familiarity with Spin could figure out how to set up this driver, change the resolution or color depth, without needing lots of study to do so.

    My experience when I started with the Propeller was that even after I set up Graphics_Demo.spin, I still didn't know how to do anything with it. I didn't know how to put a picture on the screen. As well, the API was based around all these scaling parameters, and all I wanted to do was put an object at (x,y). I got so frustrated that I tried writing my own driver. I got some kind of vertical blanking to work, and saw some white bars, spent weeks fiddling, had little to show for it, gave up and went with a 128x64 graphic LCD.

    Perhaps TV is too complicated a topic for beginners. I don't know. That's what I came here to find out.
    potatohead wrote: »
    What boards are being targeted now?

    It looks like there's only two boards that Parallax actually carries now that have TV broken out, and that would be the C3 and Propeller Professional Dev board. So we'd have to provide the pin out for a generic circuit. I think this document is in keeping with the general spirit. It's short and tells you how to get up and running.

    https://www.parallax.com/sites/default/files/downloads/28050-RCA-Adapter-v1.0.pdf
    potatohead wrote: »
    What really prevents this from working today? It's pretty easy.

    Someone just has to do it, and there are only so many things I can do at once.
    potatohead wrote: »
    So, maybe write a setup method for tv.spin, and set defaults and include one alternative to graphics_demo.spin, like a program that plots a dot, or draws at the origin and extants?

    Yes, that's exactly the kind of thing I'd like to see in the library. :D
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Ok. Cool.

    I'll take a swing at this. It helps a lot to understand what is at issue.

    We seem to just lose stuff. It's out there, gets forgotten, done again, etc... ;)

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Those seem more human-readable text-oriented than a basic I/O function. If you were creating a structured protocol over serial, would you be sending null-terminated strings or formatted data?
    If Spin allowed function pointers, I would agree. Then a generic outstr method could point to both a string to output and the I/O method to do the outputting. But this is not something Spin allows. Without including the str-type functions in the I/O objects themselves, it will be that much more cumbersome to output data formatted into strings by external formatting methods or to input CR-terminated strings.

    -Phil

    Let me elaborate:

    My current target is for two kinds of objects: basic objects ("com.serial") and terminal objects ("com.serial.terminal")

    Basic objects implement Start, Stop, Char, CharIn, Count, and Flush
    Terminal objects implement all of the previous, plus Chars, Str, StrIn, Clear, and some additional formatting functions.

    So if you need to send formatted text, you'd use a terminal object. But if you're planning to roll your own protocol, and just need a serial object that can send and receive data, you'd use a basic object.

    I think this is a good approach, and if you find yourself needing the extra functionality, just add ".terminal" to the object you're using.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
Sign In or Register to comment.