At 25 MHz for 640x480... 200nS is really slow :-(. That is only good for a LCD or for an interlaced display. It would be much better to maybe use one propeller as memory controller and another one to use the data. You could teoretically get one byte per 50 nS but only maybe 400 something of them. Still not enough even for 640x480 or did I err ?
Great speeds can be achieved when more than 1 byte is read at a time, then 16 bits @ 20 MHz are just enough for 800x600.
The propeller reads 1 long in 50 ns, but they contain several pixels at 1 or 2 bpp and not 8bpp or so, so 1 long lasts quite a while, enough to get another one. I was talking about using 8bpp. In the case of only 1 or 2 bpp, even 1 byte will last for 4 or 8 pixels @ 25 MHz (for example) 8*40 ns = 320 ns. for 4 pixels it is only 160ns.
Dual ported RAM could be simulated with a fast SRAM and some glue logic. a 15 ns SRAM could be read two times in 50 ns.
Maybe interleaved SRAM access would work well for for 640x480... If we use a 6.25 MHz crystal for 100 MHz clock, one cog could update at the pixel clock of 25 MHz, while another cog is out of phase for writing updates... Is 25.000 MHz close enough to 25.175?
I guess this could also work for 400x600 signaled at 800x600 with 50.0 MHz pixel clock reduced to 25 MHz.
There's also a 800x600x60Hz mode with 40Mhz pixel clock that would work better with 80Mhz Prop clock...
just my humble opinion, since i just bought my first propeller and i´m still reading the manual.
as another member sugested, i guess mike, the adaptor board for the Prop B could be DIP40 and have a socket to externally connect any peripheral like extra RAM.
another aproach would be an adaptor board that had the present DIP40 plus a DIP24 (just the pass through holes) on top, so that a RAM chip adaptor could be connected/stacked on top. this configuration would also fit the prop II.
Also this is relatively old thead. were as this subject finish? any clue were i can follow this subject?
don't know of any headway with dram. Several have made products with large high speed sram. I am planning to release an 8MB Ram 8MB flash DIP40 package with prop on board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
just speaking out of my butt here: (go easy on me, im only 25% through an AEES)
It appears that there is a desire for an easy way to interface some form of RAM to the prop. So it seems that with the PropII more internal fast ram would be more desirable than doubling the cogs, even though in a virtual sense you are doubling the cogs by doubling their speed. The idea of jamming RAM inside the PropII sounds all but beneficial. Interfacing a memory controller (even if prop I based) and external ram seems a bit clunky for a propeller. If it was not so hard to implement, perhaps an option, like others suggested to keep the PropII versatile, to utilize the port B for interfacing with an external RAM chip. Im guessing that the addition of an internal memory controller would be prohibitive on many levels (time, space, pin count, development ...).
Perhaps instead, it would be possible for someone to utilize the FULL processing power of the prop I, write a pure ASM prog and make it a dedicated RAM controller, and for their efforts maybe charge a few bucks for the software. Something lie a modern intel motherboard. access speed could be increased further by utilizing dual port video RAM an a little clever programming by the memory controller, similar to how DDR2 works. while address $FF is being read, the other port is setting up to R/W $A0 at the same time. Although dual port video RAM might have limitations in terms of applications, alot of apps that just need more processor power/speed this could be a viable solution for everyone.
This was the concept i had for a prop based video card, Prop 1 renders a detailed background into FIFO video RAM once per frame, Prop 2 renders vector gfx over the background (like txt, gauge needles, ect..), and then prop 3 reads the finished image and renders it to VGA, NTSC, PAL or whatever.. I'm probably wasting propeller power here, but maybe the third could just render a scanline at a time in one cog and use the rest on the third prop for a main program or something...
Come to think of it, prop 1 could render the background, prop 2 could be interleaved and begin processing sprite/user data and overlay that onto the background, then have a cog in prop 1 render finished image to a screen before rewriting the background for the next frame..
i posted a bit late in this thread apparently... i was only on page 5 reading
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it... http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 8:25:14 PM GMT
Toby Seckshund said...
Wasn't the Z180 in a 64 pin DIP? Not 100 mils, but big enough.
I think it might have been. The 68000 was 64-pins on a 100mils pitch. But I think can't think of any chip manufacturers who offer any current designs in this size of package. Surface Mount seems to be the preferred packaging now for bigger chips.
Actually, if they do like mctrivia has done and put an SRAM chip in the package, then maybe a DIP package makes sense again as the other pins can be used for the SRAM...
Comments
Great speeds can be achieved when more than 1 byte is read at a time, then 16 bits @ 20 MHz are just enough for 800x600.
@Ale: The current prop VGA is not accessing memory at 50nS is it???
Does anyone know what speed the VGA software is fetching each "long" for a 1024 bit display line?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Without dual-ported memory, it's difficult to quickly update the screen...
Dual ported RAM could be simulated with a fast SRAM and some glue logic. a 15 ns SRAM could be read two times in 50 ns.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I guess this could also work for 400x600 signaled at 800x600 with 50.0 MHz pixel clock reduced to 25 MHz.
There's also a 800x600x60Hz mode with 40Mhz pixel clock that would work better with 80Mhz Prop clock...
as another member sugested, i guess mike, the adaptor board for the Prop B could be DIP40 and have a socket to externally connect any peripheral like extra RAM.
another aproach would be an adaptor board that had the present DIP40 plus a DIP24 (just the pass through holes) on top, so that a RAM chip adaptor could be connected/stacked on top. this configuration would also fit the prop II.
Also this is relatively old thead. were as this subject finish? any clue were i can follow this subject?
best regards,
Hugo
http://forums.parallax.com/forums/default.aspx?f=25&m=388394
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
It appears that there is a desire for an easy way to interface some form of RAM to the prop. So it seems that with the PropII more internal fast ram would be more desirable than doubling the cogs, even though in a virtual sense you are doubling the cogs by doubling their speed. The idea of jamming RAM inside the PropII sounds all but beneficial. Interfacing a memory controller (even if prop I based) and external ram seems a bit clunky for a propeller. If it was not so hard to implement, perhaps an option, like others suggested to keep the PropII versatile, to utilize the port B for interfacing with an external RAM chip. Im guessing that the addition of an internal memory controller would be prohibitive on many levels (time, space, pin count, development ...).
Perhaps instead, it would be possible for someone to utilize the FULL processing power of the prop I, write a pure ASM prog and make it a dedicated RAM controller, and for their efforts maybe charge a few bucks for the software. Something lie a modern intel motherboard. access speed could be increased further by utilizing dual port video RAM an a little clever programming by the memory controller, similar to how DDR2 works. while address $FF is being read, the other port is setting up to R/W $A0 at the same time. Although dual port video RAM might have limitations in terms of applications, alot of apps that just need more processor power/speed this could be a viable solution for everyone.
This was the concept i had for a prop based video card, Prop 1 renders a detailed background into FIFO video RAM once per frame, Prop 2 renders vector gfx over the background (like txt, gauge needles, ect..), and then prop 3 reads the finished image and renders it to VGA, NTSC, PAL or whatever.. I'm probably wasting propeller power here, but maybe the third could just render a scanline at a time in one cog and use the rest on the third prop for a main program or something...
Come to think of it, prop 1 could render the background, prop 2 could be interleaved and begin processing sprite/user data and overlay that onto the background, then have a cog in prop 1 render finished image to a screen before rewriting the background for the next frame..
i posted a bit late in this thread apparently... i was only on page 5 reading
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 8:25:14 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
I suppose they'd need a uSD card on there too....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm