I believe your analysis is specific to graphic (pixel) data from RAM rather than character pixel data from program memory with the character selected by RAM data and that you have not taken into account the SX's IREAD instruction... http://www.sxlist.com/techref/scenix/inst.htm http://www.sxlist.com/techref/scenix/usersmanual/gohtm/result_86.html which does a one cycle lookup of a memory location any where in program memory (character data) addressed by the combination of the mode register and W and returns a 12 bit result in mode and W. I have a chunk of code written (untested) that will put out a pixel from a character table every other instruction with an extra pixel separation (black) between each character. Any takers? I'll post it tomorrow. James Newton jamesnewton@sxlist.com 1-619-652-0593 phone http://www.sxlist.com ----- Original Message ----- From: Bob Ammerman To: Sent: Thursday, November 30, 2000 16:01 Subject: Re: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Contest ----- Original Message ----- From: Russell McMahon To: Sent: Thursday, November 30, 2000 4:14 PM Subject: Re: [sx]: SCENIX VIDEO VIRTUAL PERIPHERAL Design Challenge and Contest > >Sure would be nice to have a built in USART to shift out the dots. That is > >how my PIC18C manages to get 432 H x 240 V pixels on the screen, including > >animated graphics. > > > And how does that compare with the likely software only Scenix performance > using software alone I wonder? > Imagine using a scheme where you store 8 pixels in a PORT register, and feed the MSBit to the outputs. Now you could have code that looks like this: movwf PORTx ; output msbit i1 i2 i3 rlf PORTx,F ; move to next bit i1 i2 i3 rlf PORTx,F ; move to next bit i1 i2 i3 where 'i1', 'i2' and 'i3' are instructions that are getting the next byte of pixels ready to send. Note that this gives you 24 instructions to prepare each byte, but they have to be in little groups of 3. I would imagine you'd need at least these 4 instructions per pixel to manage anything reasonable. It would be hard to do anything conditional in fewer cycles. So: PIC = 8 instructions for 8 pixels and SX = 32 instructions for 8 pixels Thus for equivalent resolution the SX would need four times the MIPS as the PIC. My PIC does 10MIPS, so an SX at 40MIPS should be able to manage it. However, it would be _very_ tricky coding! Going to 50MIPs on the SX and 5 instructions per bit might help a lot. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body