RANT: Propeller Tool still missing professional features
Bill Henning
Posts: 6,445
I, and many others, have been asking for a few simple features to be added to the Propeller tool to make writing configurable code feasible for YEARS now.
I've bugged Jeff, Ken, Chip and others at Parallax about it for years now - yet still we are missing the following extremely important features:
#define
#ifdef
#ifndef
#else
#endif
#include
Why am I complaining about it again?
I've resumed working on VMCOG, and I've been building some really configurable VGA text and tile based drivers - and I have to maintain many versions of Spin objects that are extremely similar, which could be covered by ONE file with the above features.
I've published my single cog 64x48 (and fewer rows) driver, I will be publishing 80 column, 50 column and 40 column versions - it could be a single source file that is configurable instead of having to keep adding new features to four files (and making bug fixes, and keeping them in sync)!
VMCOG is even worse, due to the number of possible memory platforms.
I know I can use BST (and I do) in most circumstances, and I could move to HomeSpun for even more preprocessor features.... but that makes it difficult for new propeller uses to use my objects; most will pass non-Proptool objects by if they have to install a third-party compiler.
I bet a lot of other professional developers pass on the Propeller because of the lack of such basic features in Proptool.
Rant over (for now)
I've bugged Jeff, Ken, Chip and others at Parallax about it for years now - yet still we are missing the following extremely important features:
#define
#ifdef
#ifndef
#else
#endif
#include
Why am I complaining about it again?
I've resumed working on VMCOG, and I've been building some really configurable VGA text and tile based drivers - and I have to maintain many versions of Spin objects that are extremely similar, which could be covered by ONE file with the above features.
I've published my single cog 64x48 (and fewer rows) driver, I will be publishing 80 column, 50 column and 40 column versions - it could be a single source file that is configurable instead of having to keep adding new features to four files (and making bug fixes, and keeping them in sync)!
VMCOG is even worse, due to the number of possible memory platforms.
I know I can use BST (and I do) in most circumstances, and I could move to HomeSpun for even more preprocessor features.... but that makes it difficult for new propeller uses to use my objects; most will pass non-Proptool objects by if they have to install a third-party compiler.
I bet a lot of other professional developers pass on the Propeller because of the lack of such basic features in Proptool.
Rant over (for now)
Comments
Graham
I've used m4 before - my point is that it must be in Proptool in order that newbies can use it effectively, without having to learn to install additional software.
I've posted on this subject before as well - and it is an issue that Parallax needs to address.
Frankly, it is FAR more important than the Proptool editor minor changes that are very high on their priority list.
-Phil
Why not develop in BST, and also create binaries? Part of the challenge there is building in configuration options, but it's not that hard to do. (Advantage of the PAR block method of communication, IMHO)
On the video driver specifically, isn't it possible to just use one common pixel clock, offering a choice of character densities, or setup a few different pixel clocks for the active area, using one common sweep frequency?
-Phil
It's a long time since I've needed to use it, but I'll give it a go!
Good thread, I just read it too; however it does not say anything about adding these features.
I am developing pretty much all of my work in BST, but until Proptool supports the features, newbies (I think) will avoid non-Proptool objects. And I don't want to build all the possible combinations of drivers even as binaries!
I agree about hub (mailbox) style configuration, however that does not help when the in-line code length differs between versions, or a different font needs to be included. Or different low level memory driver.
Re/ video driver - no, I had to get tricky to get these modes running in a single cog; basically unrolling loops, running at PLLx4 for the video generator, and leaving a big enough "hub shadow" for waitvid to always work properly.
I could do it with lots of comment blocks, but again, it makes it more difficult for newbies.
Sorry, I normally don't get upset like this, but I re-entered version control & driver permutation hell...
I've used BST for years (mainly because it supports PropBasic), and I just create binary files for PropTool.
Bean
I've known Ken a long time and I get the feeling that we're going to see better offerings -- though not 100% custom solutions like the Propeller Tool -- from Parallax. Ken recognizes that for more pros to use even try the Propeller, Parallax needs to offer a better, more professional tool chain. Roy's work on porting the Spin compiler to C/C++ (as Phil pointed out) is a start.
If Leon can produce some nice scripts for us, users don't even need to know if macros have been used. Nothing is stopping us from using other tools to achieve the same goal except for whining.
It seems easier for us to bend over backwards for users than for users to be aggravated trying to find the right combinations and be at risk of walking away disgruntled.
Having #include really helps #ifdef and friends easier to use. I don't mind such preprocessor macros at all, but I'm not brand new at this. Newbies can't be overwhelmed and #ifdef chains can be a horrible mess.
You can also use the "Propeller Backpack PC Loader", downloadable from the Backpack product page to compact (by pruning unused resources), compile, and upload your Spin code to any Propeller platform. I would be curious to know how its compaction rate compares with BST's.
-Phil
If it's the beginners or object use we are worried about, maybe it makes sense to just do more introductory / demo / project stuff with BST, and promote it some.
Went back to use it recently, and it flat out rocks. I think I'm gonna switch for some things.
Jon: Agreed, the size of objects can be much smaller with BST.
Steve: I agree, as you inferred, m4 would not be good for newbies, as it is an extra step
potatohead: not only unrolled, needs specific clock speeds too
all:
what I meant was being able to do the following:
#define ROWS 24 ' chose one of 60/48/32/24 etc
#define COLS 64 ' choose one of 80/64/50/40
OBJ
vga: "flexdriver"
and #ifdef's etc in the object take care of including the right font, configuring timing, and enabling/disabling the right number of unrolled code blocks
adding an "#error" directive would also allow warning the user about invalid combinations
Anyway, that's the other trade-off. A two COG driver can do a lot more, but then it's two COGs... Choices, choices. There is a reason I like to build in TV land, and those are some of them. Really wish we could get more use out of the TV style sweeps on VGA. Some of this would go away.
Valid rant, IMHO. Just thought it's worth exploring a option or two. I like to play it that way.
I am definitely going to check out those TV drivers...
The reason most of my work has been with VGA is that I am going after industrial uses with nice sharp detailed text/graphics, and one of my markets for PropCade is as a terminal replacement.
I really like the flexibility of Chip's two cog hirez text drivers, however on PropCade I am a miser with cogs, due to needing cogs for all the other features of the board - thus I did a lot of paper and pen timing work and figured out how to do one cog hirez VGA drivers. I started the rant because I was moving changes from one source file to three others, and thought it was bogus - not to mention a great potential source of bugs/version confusion.
I REALLY like BST, but for objects I post to OBEX I tended to avoid it so newbie's don't have to install another compiler - and I agree, we should be pointing newbies at BST instead of PropTool.
After I get all of the drivers solid enough, I'll re-factor for BST and merge it into one driver. Much easier for me to maintain.
btw, I just got the 40 column driver working; this time it is based on 640x480 @ 73Hz timing to make it work.
Soon I will start looking at NTSC drivers for PropCade, as I intend to have some nice demo's for PropCade at UPEW.
I spent a great deal of my post time talking about not having newbies use preprocessor tools, and you completely missed that.
More coffee perhaps?
Sorry about that, knee deep in VGA code + not enough coffee.
Going for another cup right now!
One thing I need to do on this pass is S-video. I keep getting distracted. Somewhere I've got a post of Eric's that describes how to set it up. Need to find that, and run the current TV COG I've written with S-video color. Did build up a simple LUMA / CHROMA cable, with two RCA jacks on one end, one funky S-video connector on the other. Figure I can build up a circuit with the simple RCA jacks, and use that cable to connect to the various S-video displays I have. I use the LUMA one for monochrome text, and it's flat out golden. Best way to run TV drivers, IMHO. Just no color that way.
By all means do look at the drivers too. If there is some stuff in there that helps, be my guest. I'm about to try a VGA port of some of my stuff, and have been looking around at other VGA code to get a feel for things.
Maybe I'll just move this TV project to BST. Bean is already there for the Basic. Why not? When I do better docs, I'll reference BST this time. In TV land, it's pretty easy to make a binary, so I'll do that. One thing about the two COG solution, is the ability to keep good render code seperate from the signal code. When they are woven together, ports are hard. Hard even with #ifdef.
Sorry to go off on video stuff. Suppose that's another discussion on some other thread. Good job on the 40!
edited...
I have my coffee. We all good?