Someone asked me to look at this a while back (it may have even been you!). While Catalina could compile it, the nethack binary is simply too big for any of the current Prop platforms - except possibly for Jazzed's 32Mb board - but Catalina doesn't run on that yet.
The speed would probably be ok though - most text-based games don't need high performance.
Did you use MSE, Microsoft Security Essentials? Highly recommended. Microsoft got that one right, in that it's lean and potent.
Sorry, I cannot overcome the temptation to comment on this. Of course they got it right, because this is not made by microsoft. It is third party software distributed and branded by microsoft.
Great! However it was done, it's done right, and that makes me very happy. The AV scene on Windows is a very ugly, horrible thing otherwise.
I do not disagree, the result counts and even I as a linux user have to say the result is good, the AV market is a pain in the ***. (I have one machine where I have dual boot and rarely use win 7, but if I have to it is there and it has to be secure).
To stop my off topic comment here and say something probably relevant to the discussion:
I am a bit an outsider in that I am not a professional embedded developer or electrical engineer (but I am a professional software developer).
What I really miss for the propeller are not so much fancy IDEs (I can see the point to have them, but I do not see their high priority as others do, just my personal point of view) and if Parallax will ever have one besides the Propeller Tool, I tend to think it should be based on some already accepted IDE like eclipse (which is bloated, I use it every day in my job since 2004).
What I miss is for example a good official macro assembler and maybe a good official LMM based macro assembler, a really well established official simulator which can also deal with peripherals and all of that of course available in a platform independent way (not Windows only).
Please note that I use the word official, that does not mean that Parallax has to do it themselves but can also mean to adopt tools written by this community and make them an official standard where everybody can rely on.
I was finally able to get caught up on this catching on thread last night and this morning thanks to my Nook. It's really interesting to see the discussion about the Propeller and it's industrial potential and it's apparent lack of presence there. I am aware of a number of commercial and industrial products using the Propeller and if you scour the forums well enough, many of them are hinted of here in similar threads about the Propeller. (I think there is a thread like this about once every 3 months).
Being in the electronics manufacturing for nearly 20 years now with a wide range of product, I have seen my share of various brains on products. I have just about every PIC, AVR, MSP430, NXP, Marvel, PSoC, etc, etc, that is available. For the most part, unless price is a true limiting factor, it all comes down to the designer's choice that meets their market's demand. Sorry, but I believe it is that simple and discussions I have had over the years with customers follows suit. I asked the designer about an MSP430 based product we recently started building and he gave me one answer to why he chose that chip, "That's what I used all through college so I am sticking with it". We are currently building an XMOS based USB audio product at work and the reason for that choice was "that's really the chip's strongpoint and firmware was mostly ready for market so development time was minimal". (However, due to the sensitivity of the XMOS chip when trying to get it to perform consistently at it's peak specs, it took 4 prototypes and constant support from XMOS to get it nailed down). An Atmel based board we build is using Atmel because the designer used an Atmel development board he had handy to make a prototype while brainstorming with their sales team and just continued with it so that the timeline of the finished product was easier.
When cost is an issue, we start to see variations with chips used within a product family. In other words, we have a product family of 8 PCBAs for example that all use the same Atmel chip. However, we have another product family of 7 boards and there are three different microcontrollers used because cost is extremely important so specific chips were chosen for each board. When cost isn't a direct factor, the designer pretty much has an open slate. For example, we have a product that has a selling price of $2500. The total cost (material/labor/etc) of the unit is a little over $900. So the decision to use an $4 chip versus a $2 chip isn't really a factor since the profit margin is so great. "If you want to use chip A instead of chip B, go ahead, because it only affects 0.08% of my profit" That comes up to a revenue difference of $10k per year for this particular product (based upon 400/month) but that $10k is easily justified since the two major firmware updates that occurred in the last year happened flawlessly and one occurred over the course of 12 days (from time that their sales team asked for a new feature to the time we had new code to program into the PCBAs)
On a personal note, I am designing a Cypress PSoC based capacitive touch board (prototypes are built actually) and I must say I am continually having to redirect my thoughts because I can't have two things occuring at the same time. The capacitive touch function has to be stopped for me to send serial data and vice-versa. I keep thinking, "I would not have this issue with the prop and my code would be so much cleaner" lol
I could not have said it better my self. And people wonder why I prefer DOS as a software development envirement?
DOS? All Real Programmers(TM) should be using CP/M as a development environment. Hell, you can even run it on a Propeller, so you'll have the best of both worlds.
My take on it is that there will always be a place for tools that make programming more efficient, and there will always be occasions where "close to the metal" is the best way to accomplish something. If someone wants to use a visual builder to blink some LEDs, remote control their blender, etc, and they don't need the code to be as fast, small, and efficient as possible then that's fine. I use C# daily for GUI programming because I can accomplish significantly more than by using C/C++, ASM, etc., and the speed (beyond a certain threshold) isn't critical.
On the other hand, the cloth simulation in our game was written in assembly from scratch by a very gifted programmer who knows the intricacies of the machine, because that was the only way to make it fast enough. I don't think we need to choose one or the other - I think there's a place for both.
And, to Sal, I built myself a punched card reader for the Prop 'cause that's the only way I really get anything done. ;-)
DOS? All Real Programmers(TM) should be using CP/M as a development environment. Hell, you can even run it on a Propeller, so you'll have the best of both worlds.
Yes, Yes, Yes. Thank you. Some day I will have to take the C source to CP/M 68K and port it to the Propeller as native (Or should i use GEMDOS [subdirectory support, neat]).
I remember running Nethack on my C128 in CP/M mode, and it only took about 12K of ram. Thus if someone were to hand compile it (to use the standard TV and KB drivers) we should be able to run it Prop native in HUB mem.
Hmmm. Not sure what game that was, but even under Dos (using only simple character graphics) the current NetHack binary weighs in at around 1.7Mb. And Prop binaries tend to be larger - I expect you'd need between 3 and 4Mb to run NetHack on the Prop.
Hmmm. Not sure what game that was, but even under Dos (using only simple character graphics) the current NetHack binary weighs in at around 1.7Mb. And Prop binaries tend to be larger - I expect you'd need between 3 and 4Mb to run NetHack on the Prop.
The version of 1989, of NetHack for CP/M. I did not realize that it had grown so much, wow.
I have a Gadget Ganster 32MB Prop board here. It works very well.
I'm just waiting for Catalina to support it.
Shhh....Don't let RossH know I said that:)
Heater,
Catalina 3.0 already supports it. The caching XMM driver uses the same interface as the driver for the 32Mb SRAM board. It should just be a matter of replacing Catalina's caching XMM driver with Jazzed's driver.
Note: there are some internal addressing limits that means currently Catalina will only be able to address 16Mb of the SRAM. But even 16Mb should keep you busy for a while!
It's not supported because I don't have one. But it should work. You mainly just need to replace Catalina_SPI_Cache wherever it appears with Jazzed's driver.
I'd suggest getting the XMM ram test program working first (in Catalina\ram_test) - there is a TV, a VGA and a PC version, but they're all basically the same.
These are fairly simple SPIN programs. Once they are working, Catalina will generally work without further messing about.
I completely agree with the Propeller being a great rapid-prototyping tool.
i.e.- as some of you may know, for my senior design we are developing/creating an autonomous UAV quadcopter. One of the team members was assigned to the ground station development. This included a Spinneret, IP Camera, and wireless router. We needed real-time video and data as well as control options of the UAV. He has never used the Prop or Spin and within a 1.5 months he finished the design. Using several objects from the OBEX, the SD card, AJAX for the real-time data and video and even an XBox controller for possible remote control.
I honestly believe this would not have been accomplished with any other uC (personally). I like the ability to quickly and efficiently utilize various I/O.
What is LMM? I have found a few objects on the OBEX that use it. Just from picking through the objects I've concluded that it is a way for cogs running PASM to communicate with each other or pass variables. Is this correct?
LMM is actually a kind of emulator for a processor that looks like the Propeller's native processor, but fetches instructions from hub memory and has appropriate jump and call instructions that refer to locations in hub memory. It turns out that, by using the actual native processor to execute most instructions, it can run pretty fast, expecially if the instructions are laid out backwards in memory to use the DJNZ instruction to decrement the emulated program counter, then jump to the start of the emulator main loop in the cog. It mostly gets you a way to get around the 496 instruction limit of the cogs with only a 1:4 time penalty with most instructions executing in 200ns with an 80MHz system clock.
LMM is very useful if you are writing code in a cog and run out of space. You can move that code into LMM and increase the code space from 2k to 10x that or more. The catch is that it is a little slower, and time critical things like audio and serial drivers will not work without modification.
I'm not sure what it stands for (how embarrassing!)
That quadcopter post is a really good example of the prop at work. 1.5 months is amazingly fast to get all that working, well done!
Thank you. We are considering entering it into the Spinneret competition if we can combine the flight code with the ground station code ( so that ultimately we have a Quadcopter using only the Spinneret for intelligence). That all depends on how compact we can get everything. A lot of thanks does have to go to everyone that has developed code for the Spinneret, without them we wouldn't have accomplished anything.
Received a few PMs about this post, so I'll just answer here.
I'd like to answer the original poster's question with an affirmative "YES!". Those using the Propeller have teamed with a winner! When we released the Propeller we knew it would take five years to truly start to be part of new designs, and the data below confirms that our expectations were realistic.
We are very positive about the future growth of Propeller. First, the future orders and bookings show a stable and continued trend of this graph. Next, our commercial customers will soon have the support they deserve through Parallax Semiconductor (May 2011). And most importantly, a new release is no longer a distant goal.
All of you contribute to and are part of this success, having equal value to us whether you use one or a one hundred thousand chips. The support on this forum is truly unique and valuable to the product and customers who use it. It exists because you are developers, engineers, hobbyists, scientists, students and experimenters - a cross-section that a company with only a few big fish could only dream of.
I hope to share more in the near future if you are interested.
There is definately more action on the propeller these days. More of us are using them in real designs and sometimes we don't discuss a lot about them because we can't. A new concept always takes time to take off. However, these forums, and the very assistance of Parallax is what makes the prop a joy to use, without considering the elegance of the design.
"Next, our commercial customers will soon have the support they deserve through Parallax Semiconductor (May 2011). And most importantly, a new release is no longer a distant goal."
The "new release" is that the propeller 2...and are we talking about months...six/five/four/three
The sales trend looks even more impressive if you average out the monthly variations over 12-month periods. The exponential growth trend is a little over 70% per year.
I couldn't keep myself from trying to extract the numbers from Ken's graph and play around with them in Excel. I believe my numbers are as close to Ken's as I could get from the graph..
Comments
To stop my off topic comment here and say something probably relevant to the discussion:
I am a bit an outsider in that I am not a professional embedded developer or electrical engineer (but I am a professional software developer).
What I really miss for the propeller are not so much fancy IDEs (I can see the point to have them, but I do not see their high priority as others do, just my personal point of view) and if Parallax will ever have one besides the Propeller Tool, I tend to think it should be based on some already accepted IDE like eclipse (which is bloated, I use it every day in my job since 2004).
What I miss is for example a good official macro assembler and maybe a good official LMM based macro assembler, a really well established official simulator which can also deal with peripherals and all of that of course available in a platform independent way (not Windows only).
Please note that I use the word official, that does not mean that Parallax has to do it themselves but can also mean to adopt tools written by this community and make them an official standard where everybody can rely on.
Being in the electronics manufacturing for nearly 20 years now with a wide range of product, I have seen my share of various brains on products. I have just about every PIC, AVR, MSP430, NXP, Marvel, PSoC, etc, etc, that is available. For the most part, unless price is a true limiting factor, it all comes down to the designer's choice that meets their market's demand. Sorry, but I believe it is that simple and discussions I have had over the years with customers follows suit. I asked the designer about an MSP430 based product we recently started building and he gave me one answer to why he chose that chip, "That's what I used all through college so I am sticking with it". We are currently building an XMOS based USB audio product at work and the reason for that choice was "that's really the chip's strongpoint and firmware was mostly ready for market so development time was minimal". (However, due to the sensitivity of the XMOS chip when trying to get it to perform consistently at it's peak specs, it took 4 prototypes and constant support from XMOS to get it nailed down). An Atmel based board we build is using Atmel because the designer used an Atmel development board he had handy to make a prototype while brainstorming with their sales team and just continued with it so that the timeline of the finished product was easier.
When cost is an issue, we start to see variations with chips used within a product family. In other words, we have a product family of 8 PCBAs for example that all use the same Atmel chip. However, we have another product family of 7 boards and there are three different microcontrollers used because cost is extremely important so specific chips were chosen for each board. When cost isn't a direct factor, the designer pretty much has an open slate. For example, we have a product that has a selling price of $2500. The total cost (material/labor/etc) of the unit is a little over $900. So the decision to use an $4 chip versus a $2 chip isn't really a factor since the profit margin is so great. "If you want to use chip A instead of chip B, go ahead, because it only affects 0.08% of my profit" That comes up to a revenue difference of $10k per year for this particular product (based upon 400/month) but that $10k is easily justified since the two major firmware updates that occurred in the last year happened flawlessly and one occurred over the course of 12 days (from time that their sales team asked for a new feature to the time we had new code to program into the PCBAs)
On a personal note, I am designing a Cypress PSoC based capacitive touch board (prototypes are built actually) and I must say I am continually having to redirect my thoughts because I can't have two things occuring at the same time. The capacitive touch function has to be stopped for me to send serial data and vice-versa. I keep thinking, "I would not have this issue with the prop and my code would be so much cleaner" lol
DOS? All Real Programmers(TM) should be using CP/M as a development environment. Hell, you can even run it on a Propeller, so you'll have the best of both worlds.
On the other hand, the cloth simulation in our game was written in assembly from scratch by a very gifted programmer who knows the intricacies of the machine, because that was the only way to make it fast enough. I don't think we need to choose one or the other - I think there's a place for both.
And, to Sal, I built myself a punched card reader for the Prop 'cause that's the only way I really get anything done. ;-)
Jason
Hmmm. Not sure what game that was, but even under Dos (using only simple character graphics) the current NetHack binary weighs in at around 1.7Mb. And Prop binaries tend to be larger - I expect you'd need between 3 and 4Mb to run NetHack on the Prop.
Ross.
I guess we need to think about more memory then!
More 512k chips? Other memory chips? How did things work out with Jazzed's 32mb chips?
I have a Gadget Ganster 32MB Prop board here. It works very well.
I'm just waiting for Catalina to support it.
Shhh....Don't let RossH know I said that:)
Heater,
Catalina 3.0 already supports it. The caching XMM driver uses the same interface as the driver for the 32Mb SRAM board. It should just be a matter of replacing Catalina's caching XMM driver with Jazzed's driver.
Note: there are some internal addressing limits that means currently Catalina will only be able to address 16Mb of the SRAM. But even 16Mb should keep you busy for a while!
Ross.
Damn, you found out. I'm a closet Catalina admirer:)
Sorry, I thought I read somewhere recently that the GG 32MB was not supported yet. So this is excellent news for me.
Just for fun I'm going to build my C version of the ZPU interpreter with Catalina just so that I can run C code compiled with GCC on it.
Never know, it might be as fast as Zog!:)
It's not supported because I don't have one. But it should work. You mainly just need to replace Catalina_SPI_Cache wherever it appears with Jazzed's driver.
I'd suggest getting the XMM ram test program working first (in Catalina\ram_test) - there is a TV, a VGA and a PC version, but they're all basically the same.
These are fairly simple SPIN programs. Once they are working, Catalina will generally work without further messing about.
Ross.
i.e.- as some of you may know, for my senior design we are developing/creating an autonomous UAV quadcopter. One of the team members was assigned to the ground station development. This included a Spinneret, IP Camera, and wireless router. We needed real-time video and data as well as control options of the UAV. He has never used the Prop or Spin and within a 1.5 months he finished the design. Using several objects from the OBEX, the SD card, AJAX for the real-time data and video and even an XBox controller for possible remote control.
I honestly believe this would not have been accomplished with any other uC (personally). I like the ability to quickly and efficiently utilize various I/O.
What is LMM? I have found a few objects on the OBEX that use it. Just from picking through the objects I've concluded that it is a way for cogs running PASM to communicate with each other or pass variables. Is this correct?
I'm not sure what it stands for (how embarrassing!)
That quadcopter post is a really good example of the prop at work. 1.5 months is amazingly fast to get all that working, well done!
XMM Extended Memory Model (uses external RAM with its additional access time penalty)
I'd like to answer the original poster's question with an affirmative "YES!". Those using the Propeller have teamed with a winner! When we released the Propeller we knew it would take five years to truly start to be part of new designs, and the data below confirms that our expectations were realistic.
We are very positive about the future growth of Propeller. First, the future orders and bookings show a stable and continued trend of this graph. Next, our commercial customers will soon have the support they deserve through Parallax Semiconductor (May 2011). And most importantly, a new release is no longer a distant goal.
All of you contribute to and are part of this success, having equal value to us whether you use one or a one hundred thousand chips. The support on this forum is truly unique and valuable to the product and customers who use it. It exists because you are developers, engineers, hobbyists, scientists, students and experimenters - a cross-section that a company with only a few big fish could only dream of.
I hope to share more in the near future if you are interested.
Thank you,
Ken Gracey
Parallax Inc.
Yeah, that looks like a nice trend. Please do update us, on the state of the Propeller, from time to time. I think it's good perspective. Thanks!
There is definately more action on the propeller these days. More of us are using them in real designs and sometimes we don't discuss a lot about them because we can't. A new concept always takes time to take off. However, these forums, and the very assistance of Parallax is what makes the prop a joy to use, without considering the elegance of the design.
Thank you for the update...
"Next, our commercial customers will soon have the support they deserve through Parallax Semiconductor (May 2011). And most importantly, a new release is no longer a distant goal."
The "new release" is that the propeller 2...and are we talking about months...six/five/four/three
I couldn't keep myself from trying to extract the numbers from Ken's graph and play around with them in Excel. I believe my numbers are as close to Ken's as I could get from the graph..