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.
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.
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.
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:
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?
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:
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
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.
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.
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.
...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.
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.
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.
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?
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?
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.
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.
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.
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.
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:
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.
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?
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
Comments
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 !
-Phil
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.
+10 for that.
Enjoy!
Mike
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
Thanks!
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
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:
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
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.
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 am sure there is a pasm version - just don't recall where.
No. Presume I could do it on iPhone/iPad and post the file.
*** 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.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
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 would also include the str and strin methods in the basic I/O objects.
-Phil
I like jm_320x_ez. It is simple and works great.
Why is that? Does USB require a massive driver or something?
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:
I think a tree like this would be really awesome for starting users:
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.
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?
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?
-Phil
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.
Which is the default circuit? I've seen lots of different circuits used for various examples.
I made that distinction because there are already some objects in the library that are simply wrappers around the tv driver for specific purposes.
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?
Yes! That's exactly what I'd like to see.
Yes, I was quoting random resolutions that didn't really pertain to anything. >.>
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.
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
Someone just has to do it, and there are only so many things I can do at once.
Yes, that's exactly the kind of thing I'd like to see in the library.
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...
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.