mc, I was working on the principle of ask for a little and you might get away with it , but you're right, we should ask for 64 bits, and then if Chip only gives us 48 we can feel hard done by
(I was just dreaming really, it's all been discussed and I understand it won't be happening for a while).
Just to clarify, I wasn't saying the Prop I wouldn't still be great ( it is and will be ), but say for
a CP/M or Z80 emulator, the memory limit is an issue on the I and it makes sense to develop
for the II. Then the impetus is to keep developing with the II and forget the I as it was never
really suitable, never will be, so "why bother with it". I was wondering what sort of knock-on
effects that would have in the wider scheme of things.
When the BS2 came out, did the 'smart alecs' keep pushing the BS1 boundaries or did they
move almost entirely to the BS2 ? I can see a lot of Prop II code and objects appearing which
will be incompatible with the Prop I and cannot easily be made multi-Prop usable ( function
pointers for one ). Hence my wondering where it will eventually leave the Prop I ( and IB ).
Windows 98SE is still great (IMO) but few people develop for 98 and make sure it runs on XP
and Vista. The reality is people develop for what they use and neglect the earlier versions
which forces people to upgrade whether they want to or not. The PropTool is a typical example.
The underlying force of all technology business is based on obsolesce. I'm sure no one wants to really hear that, but its fact. And Moore's Law is and will be the driving force for another decade or two. Advancement in technology can only be obtained by pushing the limits of current thinking and capabilities. If we were to be complacent with our technology, then advancement would cease. Yes its a pain that your average PC is out of date in 3 or 4 years, and the industry creates a huge pile of garbage every year...but think of the alternative...stagnation. Every bit of technology from computers to refrigerators to golf clubs must progress or face commoditization. Commodity means low price, low margin... most technology companies are formed with the primary goal of making money, not technology. Although I must give Parallax a huge amount of credit for balancing the two rather well...that's a benefit of being a privately held company.
The PropB, PropII decisions hopefully going to be based on sound financial, business and marketing facts. With the proper market segmentation, pricing, and feature selection there is plenty of room for I, II, B, whatever. It just requires correct market analysis. A business development team that can close some major commercial or industrial deals would go a long way to the success of the product line too. Imagine the next great consumer device craze...what ever it ends up being, based on the PropII.
hippy: microcontrolers and computers are not the same. I still use 20MHz processers like the TI 420 day processer because they draw almost no power, are very cheap and work for the application. Not to mention having built in flash memory and rediculously small package size. I still know people using the old motrola HC6811 chip. Its over 20 years old.
awesomeduck: I was under the impression we had pretty much hit the limit of Moore's Law in CPUs. Speed of light and breakdown voltage of insulators becoming increasingly difficult to make faster more powerful chips. Of course super conductors may soon be the savior of the CPU industry.
mctriva: in the strict sense we might hit a limit on CMOS size in 10 years...in broader terms, one way to look at Moore's law is that the compute function/unit area doubles every X months...the other way to look at it is that the compute function/$ doubles every X months. Even if we stopped being able to reduce the size of features, the cost curve would continue to decline, as a result of improved manufacturability, resulting in new ways to use massive amounts of technology at lower price points.
You make a very good point about the HC6811 vs. a PC...its all about market segmentation, features and price. There will still be uses for HC6811 for many years to come because its used in so many industrial/commercial applications. That's why I made my comments about Parallax getting into some of those applications...they can drive volume business for years to come just because the cost of switching to a new tool chain or rewritting code is so high. The one time a business don't need technology obsolesce to grow revenue is when they have a captive market. The innovations of the Prop and what I am seeing talked about in the Prop follow-ons is something that could be marketed to certain niche markets, for example educational customers are clearly a niche for Parallax. The key is finding the industrial application niche that is high volume and needs a specific feature set. The multicore nature and lack of need for interrupts in the Prop makes for an interesting point of differentiation. There are probably other points of differentiation too. The key is converting people that have one world view of how microcontrollers should work, to the new view, which only you can provide. In effect, you need to obsolete the competitor's product so you can get the user hooked on your microcontroller/stereo/vehicle/golf club/insert product here.
there is really only 1 thing i can see keeping the propeller from lots of commercial applications. No code security at all. Any product using the propeller i could remove the eeprom chip and copy it's content to a hex editor and reverse back to its code. There are ways around this with the current design. Put the chip and eeprom in a metal encloser and fill with a hard epoxy. But for mass production this is not that viable.
What about just putting a drop of epoxy over top of the eeprom. I've seen this done before when i have opened products and to get the epoxy off you would end up destroying the chip
as long as it covers all traces to it as well in a way you can't get it off without damaging. If you can cut the traces you can access just as easily. Still I like the way you think.
There was a very long discussion here some time ago about the issue of code protection. The opinions of people who have experience in this area is that the typical sort of microcontroller code protection gives false security. It provides the illusion of protection, but is easily broken with equipment readily available (but expensive), for example, with the electron beam probe system that Parallax uses for its own Propeller development.
yes there is equipment available to do it but not everyone has it and false sense of security is a major selling feature. I am willing to put it my products because I am not to worried about people stealing my code and I realise even the best security can be broken. Larger corps don't usually see it that way.
Hippy, I agree that propeller heads, in the general sense, will want to start pushing the Prop II to it's limits as soon as they get their hands on them. Everyone likes to explore new boundaries. Which does not mean that demand for Prop I dries up as it will have advantages in lower power, ease of use (DIP), lower price (hopefully). By that time there will plenty enough drivers around for all sorts of things to keep it going for years, even if new drivers and objects come out to exploit the new chip.
I'm not sure it matters much what happens with the emulator scene. Some how I don't think emulating old CPUs and systems will drive the market very much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Your drop of epoxy is a valid security measure. Therefore can be said to have security for those that ask. It's not a lie in marketroid speak and there's that false sense you were after.
Regarding Moore's Law, Intel's marketroid dept adapts their implied meaning to suit the times. Clockrate used to be the benchmark, then just speed, but now they've decided to jump ship altogether and go for some density measure.
Say one of the moto chips mentioned. (or maybe Microchip now, I guess) One of those, with some add-on special purpose chips forms a solution. So, emulate it on the Propeller, using COGs for the special purpose chips.
What I don't know, and am interested in learning more about is the cost implications of that. Does having one chip improve the BOM in a favorable way? Can being software based improve on the original design in a favorable way, particularly in the field? Could such a design, emulated, then be more easily re-purposed?
That's kind of where I was going with my comment up-thread. The ground work for attempting those things lies in the current emulation projects.
Specifically, regarding the Propeller I B, do those things warrant the cost right now? For the Propeller in general, I think this topic warrants some more discussion and investigation.
In respect of C on the Propeller I'd say that is the case already. What the Prop reduces to is a hardware configuration on which the compilation runs to deliver the target task. What the hardware is becomes largely irrelevant to the end-user, what they see is a virtualised system from a C perspective, what it can do, not what it is, is what's most important. In that role the Prop is another micro, tuned to running the C compilation.
Likewise a Prop emulating a JavaStamp, a Prop emulating a BS1 or BS2. That's emulating a system rather than a chip, but I believe it's in the same category.
So here we go, 80k... Tough call? End Vote.... Timeframe. If it ends up affecting prop 2, hell no. If it can be done on the side, sure. I honestly think we will run into a ram limitation, before the pin limitation @ 64, ram/cog space will become an issue. On average we can get 1 chip driver in each cog, even if we have nothing else to do but read chips... We just run short of pins now. Take 4 wire SPI, Clk, Din, Dout, Enable. 4*8 = 32 pins, So maybe an extra few wouldnt hurt, but a whole set of 32 more. Not really needed.
Considering its going to look like were going to need some language time to transition to P2, Its not like P2 will be a add more to your P1 program, it will require re-write time. So prop 1-64, will not really help us advance our capabilities.
There seems to be this idea we need to max out the prop 1, before we can go to prop 2. I disagree there will always be advances that we can still use P1 on, there is always the balance of cost, complexity, and power, the prop 1 will still have applications that it is better for than P2. Look at the 555 chip, just the other day I saw a soldering iron, that the heater was based off a 555 chip, stamped with a Patented 2008. Hell the 555 chip has been around what 30 years +, and there are still new designs being built off it. Prop 1 will always be there for us, it has been good to us. But We need to push the limits, in order to take advantage of more IO's we need more power. How ever that may come.
Note*
Link to post talking about P1-64.
Bob Lawrence (VE1RLL) said...
Chip Gracey (Parallax) said...
Posted 4/20/2006 1:01 PM (GMT -4)
We plan to make a 64-I/O-pin version of the current Propeller soon. It will be identical, except for the addition of a 32-pin 'B' port, and of course a bigger package with more pins. This chip should be ready in six months. We are also working on the next-generation Propeller chip, which will be an order of magnitude faster than the current chip. It is probably a year away.
What the hell happened there? That post was from 4/06. Um 10/06 for P1-64, Sometime over 1 year ago for P2. Since were this far behind, the market is moving, Push P2, bring P3. The tech market is fast, Im not saying it has to match it, but what is reasonable 1 year to the next is a large change. Either push P2 as it is now, and get cracking on a 64 bit version, and plan for production 1 year out, or revamp P2 to match the current capabilities. P1 brought something to the table no other chip had, now its time to do it again for P2.
Well I guess the question for chip is does he have an updated timeline?
Also I forget who asked but I looked it up and all BGAs come with solder balls on each foot so my suggestion of using vias to align and heat gun to melt in place works for all BGAs.
Also I forget who asked but I looked it up and all BGAs come with solder balls on each foot so my suggestion of using vias to align and heat gun to melt in place works for all BGAs.
Do you need to apply flux on the pads first?
Are your pads hot air blown (with solder coat) or just silver plated?
Most of my PCBs have silver plated pads.
Can the BGA chip connect reliably with silver plated pads without additional solder paste?
I have always used solder coat from the pcb manufacturer so I can't say for sure about silver coat but I would suspect it would still work. There is a fair bit of solder on the balls of a BGA. I would recomend flux in any fine surface mount work but it is not required.
Do make sure your work table is level when working with BGA's, and keep the heat source directly above. if the chip slides odds are you will need to get a new one(will probably have shorts). They are fun though and I have not yet rect one. Good thing some Genum IC's are $200+
Finally, circling back around ot the original topic... Burst mode looks pretty cool for displaying the bits. But (and maybe there's something I don't understand about the DRAM architecture) it's not clear to me when there's time to change them without interrupting the display.
Phil Pilgrim (PhiPi) said...
Finally, circling back around ot the original topic... Burst mode looks pretty cool for displaying the bits. But (and maybe there's something I don't understand about the DRAM architecture) it's not clear to me when there's time to change them without interrupting the display.
-Phil
Yeah, you'd have to temporarily clamp the RGB DAC outputs to ground in order to manipulate the data lines without causing color signals. While it could display a fairly high-bandwidth signal, it would be tedious to write to, as only in the horizontal and vertical blanks could you get data into it.
Perhaps if you used two x16 chips with their data buses connected separately and had a mux to select which chip's data outputs went to the·RGB DACs, you could get full-bandwidth read and write (separate chips doing different things), plus inherent double-buffering, which is pretty much needed, anyway.
The RGB DAC I was looking at had an output enable...
But, maybe it'd be a lot easier to use two 8-bit DRAMs and settle for simple resistive ladder outputs.· A 16:8 MUX with OE could be between the DRAMs and the ladder.· 8-bit color wouldn't be all that great, but similar to the 6-bit we have now...
On second thought, I'd really like 16-bit video...
Also, the 16-bit wide DRAM I was looking at would let you select only the upper or lower byte to write to. So, I think you could use just 9-pins to send data, one byte at a time...
Bean (I think it was he) mentioned earlier that the VGA spec leaves precious little time during blanking to do much of anything between actual bit outputs, which is what prompted my question. Double buffering would work if you could rewrite the entire buffer from scratch each time, without knowing what was already in it. An alternative would be to have one RAM for the upper half of the display and another for the lower half. That way you'd have time to read the contents of the display and change it, without having to regenerate everything from scratch.
Still OT, but this is where the thread is going...
Are you trying to use an external VGA DAC? Why not with the propeller?
Please correct me if my understanding is wrong - I haven't played with VGA. So, why can't you do this...
Read the whole scan line into hub (will take a cog - call it the DRAM cog) in burst mode (either byte or words). This would be faster than the actual bit rate going out, so this leaves time for the DRAM to be updated with other data in between accesses. Perhaps likewise this (update) data could be setup in hub ready for the DRAM cog to update when it is not busy. One or two cogs do the VGA generation (as is done now, slightly modified to get a fixed scanline from hub). That leaves 5 cogs for the video processing and comms. Wouldn't this be a better solution (fewer parts - no glue chips), even if two props were used - one for the VGA and DRAM and one for the other pins and other processing?
How much external memory is required for the hires? My circuit for the SixBladeProp (Blades 1 & 4 - with multiplexed bus) can handle 512KB SRAM with access of 10242048 bytes (A0-10) in a burst style fashion (no latching) in either 150nS200nS (presuming I can·keep the lower·address bits in the outa register and do an increment (i.e. add #1) directly to the out register, otherwise 200nS·250nS) per byte. Some inline coding could be used to reduce the instruction loop by 1 (removing the djnz). However, if we are storing in hub, the hub access becomes important.
I presume that a 1024x768 would require 1024 wordsbytes of data per line, so this would be limited to 512 lines of data. Baggers mentioned to me that HD uses less than the 768 lines.
Of course, DRAM has higher density and its burst mode could read in bytes or words at 100nS burst rates.
Postedit: In DRAM, I forgot about the read pulse required to increment the address in burst mode, so that DRAM is in fact slower, being 200nS250nS to allow for the pulse. SRAM can be used without strobing, just changing the address (but obviously, not for writing) so it would be faster
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
(I was just dreaming really, it's all been discussed and I understand it won't be happening for a while).
Your board offer's good.
a CP/M or Z80 emulator, the memory limit is an issue on the I and it makes sense to develop
for the II. Then the impetus is to keep developing with the II and forget the I as it was never
really suitable, never will be, so "why bother with it". I was wondering what sort of knock-on
effects that would have in the wider scheme of things.
When the BS2 came out, did the 'smart alecs' keep pushing the BS1 boundaries or did they
move almost entirely to the BS2 ? I can see a lot of Prop II code and objects appearing which
will be incompatible with the Prop I and cannot easily be made multi-Prop usable ( function
pointers for one ). Hence my wondering where it will eventually leave the Prop I ( and IB ).
Windows 98SE is still great (IMO) but few people develop for 98 and make sure it runs on XP
and Vista. The reality is people develop for what they use and neglect the earlier versions
which forces people to upgrade whether they want to or not. The PropTool is a typical example.
Post Edited (hippy) : 2/1/2009 11:25:55 AM GMT
The PropB, PropII decisions hopefully going to be based on sound financial, business and marketing facts. With the proper market segmentation, pricing, and feature selection there is plenty of room for I, II, B, whatever. It just requires correct market analysis. A business development team that can close some major commercial or industrial deals would go a long way to the success of the product line too. Imagine the next great consumer device craze...what ever it ends up being, based on the PropII.
awesomeduck: I was under the impression we had pretty much hit the limit of Moore's Law in CPUs. Speed of light and breakdown voltage of insulators becoming increasingly difficult to make faster more powerful chips. Of course super conductors may soon be the savior of the CPU industry.
You make a very good point about the HC6811 vs. a PC...its all about market segmentation, features and price. There will still be uses for HC6811 for many years to come because its used in so many industrial/commercial applications. That's why I made my comments about Parallax getting into some of those applications...they can drive volume business for years to come just because the cost of switching to a new tool chain or rewritting code is so high. The one time a business don't need technology obsolesce to grow revenue is when they have a captive market. The innovations of the Prop and what I am seeing talked about in the Prop follow-ons is something that could be marketed to certain niche markets, for example educational customers are clearly a niche for Parallax. The key is finding the industrial application niche that is high volume and needs a specific feature set. The multicore nature and lack of need for interrupts in the Prop makes for an interesting point of differentiation. There are probably other points of differentiation too. The key is converting people that have one world view of how microcontrollers should work, to the new view, which only you can provide. In effect, you need to obsolete the competitor's product so you can get the user hooked on your microcontroller/stereo/vehicle/golf club/insert product here.
Post Edited (mctrivia) : 2/1/2009 8:14:19 PM GMT
I'm not sure it matters much what happens with the emulator scene. Some how I don't think emulating old CPUs and systems will drive the market very much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What if said emulation was another micro?
Say one of the moto chips mentioned. (or maybe Microchip now, I guess) One of those, with some add-on special purpose chips forms a solution. So, emulate it on the Propeller, using COGs for the special purpose chips.
What I don't know, and am interested in learning more about is the cost implications of that. Does having one chip improve the BOM in a favorable way? Can being software based improve on the original design in a favorable way, particularly in the field? Could such a design, emulated, then be more easily re-purposed?
That's kind of where I was going with my comment up-thread. The ground work for attempting those things lies in the current emulation projects.
Specifically, regarding the Propeller I B, do those things warrant the cost right now? For the Propeller in general, I think this topic warrants some more discussion and investigation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/1/2009 10:14:43 PM GMT
In respect of C on the Propeller I'd say that is the case already. What the Prop reduces to is a hardware configuration on which the compilation runs to deliver the target task. What the hardware is becomes largely irrelevant to the end-user, what they see is a virtualised system from a C perspective, what it can do, not what it is, is what's most important. In that role the Prop is another micro, tuned to running the C compilation.
Likewise a Prop emulating a JavaStamp, a Prop emulating a BS1 or BS2. That's emulating a system rather than a chip, but I believe it's in the same category.
Considering its going to look like were going to need some language time to transition to P2, Its not like P2 will be a add more to your P1 program, it will require re-write time. So prop 1-64, will not really help us advance our capabilities.
There seems to be this idea we need to max out the prop 1, before we can go to prop 2. I disagree there will always be advances that we can still use P1 on, there is always the balance of cost, complexity, and power, the prop 1 will still have applications that it is better for than P2. Look at the 555 chip, just the other day I saw a soldering iron, that the heater was based off a 555 chip, stamped with a Patented 2008. Hell the 555 chip has been around what 30 years +, and there are still new designs being built off it. Prop 1 will always be there for us, it has been good to us. But We need to push the limits, in order to take advantage of more IO's we need more power. How ever that may come.
Note*
Link to post talking about P1-64.
What the hell happened there? That post was from 4/06. Um 10/06 for P1-64, Sometime over 1 year ago for P2. Since were this far behind, the market is moving, Push P2, bring P3. The tech market is fast, Im not saying it has to match it, but what is reasonable 1 year to the next is a large change. Either push P2 as it is now, and get cracking on a 64 bit version, and plan for production 1 year out, or revamp P2 to match the current capabilities. P1 brought something to the table no other chip had, now its time to do it again for P2.
TJ
Also I forget who asked but I looked it up and all BGAs come with solder balls on each foot so my suggestion of using vias to align and heat gun to melt in place works for all BGAs.
Do you need to apply flux on the pads first?
Are your pads hot air blown (with solder coat) or just silver plated?
Most of my PCBs have silver plated pads.
Can the BGA chip connect reliably with silver plated pads without additional solder paste?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Do make sure your work table is level when working with BGA's, and keep the heat source directly above. if the chip slides odds are you will need to get a new one(will probably have shorts). They are fun though and I have not yet rect one. Good thing some Genum IC's are $200+
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
http://forums.parallax.com/forums/default.aspx?f=25&m=121609
Rgds,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
http://tinyvga.com/avr-sdram-vga
Instead of using a RAMDAC, I think it'd be easier to use a 16-bit wide DRAM and a 3-channel RGB DAC directly...
Looks to me like the hard part is sequencing the screen updates...
-Phil
Perhaps if you used two x16 chips with their data buses connected separately and had a mux to select which chip's data outputs went to the·RGB DACs, you could get full-bandwidth read and write (separate chips doing different things), plus inherent double-buffering, which is pretty much needed, anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
But, maybe it'd be a lot easier to use two 8-bit DRAMs and settle for simple resistive ladder outputs.· A 16:8 MUX with OE could be between the DRAMs and the ladder.· 8-bit color wouldn't be all that great, but similar to the 6-bit we have now...
On second thought, I'd really like 16-bit video...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
-Phil
Are you trying to use an external VGA DAC? Why not with the propeller?
Please correct me if my understanding is wrong - I haven't played with VGA. So, why can't you do this...
Read the whole scan line into hub (will take a cog - call it the DRAM cog) in burst mode (either byte or words). This would be faster than the actual bit rate going out, so this leaves time for the DRAM to be updated with other data in between accesses. Perhaps likewise this (update) data could be setup in hub ready for the DRAM cog to update when it is not busy. One or two cogs do the VGA generation (as is done now, slightly modified to get a fixed scanline from hub). That leaves 5 cogs for the video processing and comms. Wouldn't this be a better solution (fewer parts - no glue chips), even if two props were used - one for the VGA and DRAM and one for the other pins and other processing?
How much external memory is required for the hires? My circuit for the SixBladeProp (Blades 1 & 4 - with multiplexed bus) can handle 512KB SRAM with access of 1024 2048 bytes (A0-10) in a burst style fashion (no latching) in either 150nS 200nS (presuming I can·keep the lower·address bits in the outa register and do an increment (i.e. add #1) directly to the out register, otherwise 200nS·250nS) per byte. Some inline coding could be used to reduce the instruction loop by 1 (removing the djnz). However, if we are storing in hub, the hub access becomes important.
I presume that a 1024x768 would require 1024 words bytes of data per line, so this would be limited to 512 lines of data. Baggers mentioned to me that HD uses less than the 768 lines.
Of course, DRAM has higher density and its burst mode could read in bytes or words at 100nS burst rates.
Postedit: In DRAM, I forgot about the read pulse required to increment the address in burst mode, so that DRAM is in fact slower, being 200nS 250nS to allow for the pulse. SRAM can be used without strobing, just changing the address (but obviously, not for writing) so it would be faster
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
Post Edited (Cluso99) : 2/3/2009 10:59:09 AM GMT