Yes. Wafers should be back from the fab in two weeks. Then, several days will be needed for transit and packaging. We'll be able to try it out once we get back packaged parts.
Wow! That's great. I thought we wouldn't see new chips until at least September. Sounds like you may have them in hand before the end of this month! Exciting times are at hand!
OMG, hardly any time left to get all my code working on P2 !
Somehow I seem to have lost steam on my P2 work. I think the people at Parallax are very busy with their Propeller C Education program so I haven't worked with anyone there for a while.
I got stuck troubleshooting a video driver, then work did what work does, and I just fired it up last night anyway. Tired this morning though
I think a lot of us just went into a holding pattern on the tough news we heard earlier thinking there was time.
I'm afraid I'm more driven by collaborative efforts and, when it started seeming like I was working in a vacuum, I lost a lot of steam. I still need to get the external memory interface working in PropGCC for P2 though so I guess I'd better get back to work!
Now is the time for all good men to come to the aid of the Propeller II.
Well, PropGCC is already running on P2. It would be nice to be able to use the SDRAM as external memory though. My main hesitation with that is that Parallax has shown little or no interest in the external memory solutions for P1. Understandably, they mostly want to target the bare chip not solutions that require an external memory.
Wait up a minute, On the PII update blog or somewhere it is very clear that Chip want's to make a PII module with SDRAM on board. There is a design and layout for it already.
In fact as far as I can tell he has no interest in making a board with just a PII (and minimal support circuitry) on it.
Wait up a minute, On the PII update blog or somewhere it is very clear that Chip want's to make a PII module with SDRAM on board. There is a design and layout for it already.
In fact as far as I can tell he has no interest in making a board with just a PII (and minimal support circuitry) on it.
Yes, this is all true. However, I'm not sure if Parallax wants customers to think they must have an SDRAM chip in their P2 designs. I imagine that the majority of P2 applications will not use external memory any more than the current P1 applications do. Maybe Parallax can make an MCM with a P2 and an SDRAM on the same chip! :-)
Edit: Plus, I think the main reason for the P2/SRAM combo on the Parallax boards is to allow the use of the SDRAM for video buffers.
Well, PropGCC is already running on P2. It would be nice to be able to use the SDRAM as external memory though. My main hesitation with that is that Parallax has shown little or no interest in the external memory solutions for P1. Understandably, they mostly want to target the bare chip not solutions that require an external memory.
I can't speak to the P2, but for the P1 I haven't had a need for external memory solutions. My app has grown to about 23KB and stayed there for the last few months. Every time I add more features I also manage to reduce the program size so that it remains about constant. My last technique was inlining, which saved about 500 bytes on the code. My app doesn't have any large data structures (just a couple of internal buffers ~900 bytes in size).
I don't think the P2 would be much different for me: as long as I don't do graphics I don't think external memory would be that useful in my application.
I can't speak to the P2, but for the P1 I haven't had a need for external memory solutions. My app has grown to about 23KB and stayed there for the last few months. Every time I add more features I also manage to reduce the program size so that it remains about constant. My last technique was inlining, which saved about 500 bytes on the code. My app doesn't have any large data structures (just a couple of internal buffers ~900 bytes in size).
I don't think the P2 would be much different for me: as long as I don't do graphics I don't think external memory would be that useful in my application.
I suspect this is true of most applications. This is why it may not be worth the effort to provide an external memory solution at this point. If it becomes clear that P2 (or P1 for that matter) are being used for larger applications then the external memory support can certainly be added.
David, I think getting the XMM working is pretty important. We've got a very difficult caching problem to chew on at the least.
Regarding how people will use it, who knows? I think a video buffer makes sense. However, the problem could be inverted with lots of code streaming in from the XMM, with the Hub being used in a way similar to the P1, with video being there but at modest resolutions and color depths, dynamically drawn, etc...
Whether or not the XMM sees use beyond a video / data buffer really depends on whether or not it's easy to use it for programs, and whether or not those programs can see enough MIPS to make sense.
Whether or not the XMM sees use beyond a video / data buffer really depends on whether or not it's easy to use it for programs, and whether or not those programs can see enough MIPS to make sense.
By the way, XMM for P1 is very easy to use if you have a board with external memory. Parallax has none other than the C3. They know their customers so I assume the reason is that there is no demand for external memory on the P1. That could be different for P2 of course.
I'm not sure if Parallax wants customers to think they must have an SDRAM chip in their P2 designs.
Sounds reasonable. Has Parallax told Chip yet:)
From what I remember of the debate, I and others were suggesting a minimal "carrier/break out" board for the PII but Chip was not much interested in that.
In the mean time... we have SDRAM on the FPGA boards. Is that supported by propgcc at all ?
From what I remember of the debate, I and others were suggesting a minimal "carrier/break out" board for the PII but Chip was not much interested in that.
In the mean time... we have SDRAM on the FPGA boards. Is that supported by propgcc at all ?
No, the SDRAM is not supported currently by PropGCC. That's what I have been working on but I'm doing it for P1 first. The problem is that to use Chip's SDRAM driver I need to rework the cache code for PropGCC to move tag handling into the kernel COG. I've done that and tested it on P1 but there is some work that needs to be done in the loader and the C startup code to make it work. That's what I lost momentum with. I guess I need to get back to it.
Maybe. I think at the least, SPIN 2 can use PASM snippets now.
My guess is one can launch the SDRAM driver COG and have it idle and ready to perform. Then run a SPIN 2 program that contains an in-line PASM snippet that drives the SDRAM COG to do whatever is needed. If we got object pointers and such sorted out better, that will mean data and or code overlays moving into and out of the HUB pretty easy.
An alternative would be to run SPIN 2 right out of the SDRAM, using extensions to the interpreter, which are now done with PASM snippets... A SPIN 2 program could load an alternative intrepeter as inline PASM that fetches from SDRAM, calling the same kinds of PASM routines in LMM as the current SPIN 2 intrepeter does now.
Comments
Check book?
Which century are you living in?
Can't wait to order mine.
Fingers crossed the Wafers are good this time
Rich
Just in time for Christmas. Maybe a P2 board will be the must-have gift this holiday season!
I've been working on other projects, but I am eagerly awaiting P2 chips/modules.
Ok, I do admit to playing with paper designs for some P2 boards at night
I think a lot of us just went into a holding pattern on the tough news we heard earlier thinking there was time.
I suspect you are right but:
Now is the time for all good men to come to the aid of the Propeller II.
Wait up a minute, On the PII update blog or somewhere it is very clear that Chip want's to make a PII module with SDRAM on board. There is a design and layout for it already.
In fact as far as I can tell he has no interest in making a board with just a PII (and minimal support circuitry) on it.
Edit: Plus, I think the main reason for the P2/SRAM combo on the Parallax boards is to allow the use of the SDRAM for video buffers.
I can't speak to the P2, but for the P1 I haven't had a need for external memory solutions. My app has grown to about 23KB and stayed there for the last few months. Every time I add more features I also manage to reduce the program size so that it remains about constant. My last technique was inlining, which saved about 500 bytes on the code. My app doesn't have any large data structures (just a couple of internal buffers ~900 bytes in size).
I don't think the P2 would be much different for me: as long as I don't do graphics I don't think external memory would be that useful in my application.
Regarding how people will use it, who knows? I think a video buffer makes sense. However, the problem could be inverted with lots of code streaming in from the XMM, with the Hub being used in a way similar to the P1, with video being there but at modest resolutions and color depths, dynamically drawn, etc...
Whether or not the XMM sees use beyond a video / data buffer really depends on whether or not it's easy to use it for programs, and whether or not those programs can see enough MIPS to make sense.
Sounds reasonable. Has Parallax told Chip yet:)
From what I remember of the debate, I and others were suggesting a minimal "carrier/break out" board for the PII but Chip was not much interested in that.
In the mean time... we have SDRAM on the FPGA boards. Is that supported by propgcc at all ?
However, p2load is able to load data into SDRAM.
My guess is one can launch the SDRAM driver COG and have it idle and ready to perform. Then run a SPIN 2 program that contains an in-line PASM snippet that drives the SDRAM COG to do whatever is needed. If we got object pointers and such sorted out better, that will mean data and or code overlays moving into and out of the HUB pretty easy.
An alternative would be to run SPIN 2 right out of the SDRAM, using extensions to the interpreter, which are now done with PASM snippets... A SPIN 2 program could load an alternative intrepeter as inline PASM that fetches from SDRAM, calling the same kinds of PASM routines in LMM as the current SPIN 2 intrepeter does now.
We shall find out soon enough!
Who knows what Chip gets up to in his dungeon? I just hope they remember to slide some food under the door occasionally:)