Shop OBEX P1 Docs P2 Docs Learn Events
Using the Propeller as a VGA switching unit — Parallax Forums

Using the Propeller as a VGA switching unit

WombleWomble Posts: 20
edited 2014-09-19 06:24 in Propeller 1
hi all!


I'm currently testing out my fpga emulation of the Lynx computer on my home-built box.

I don't have direct access to any of the pins on the fpga - 10 connections link the fpga and propeller.

Two pins are used for PS2 keyboard - again copied over from the prop - but in a spin cog.

vsync/ hsync come in on P0 and P1
RGB on P2 - 7

So these 8 pins need copying upward to the VGA output pins on the prop.

I'm currently using the attached code to copy the output (VGA) of my resurrection over to the VGA output pins
on the propeller.


Needless to say as you'll see it's a bit of a trial and error approach - this version was just the 'best' in

terms of least artifacts.


I've also been trying to stop and restart the fpga_vga driver but when I restart the output is more corrupted -

something not right with my understanding of start/stop on cogs probably.

CREATE_FPGA_wUpload - Archive [Date 2014.09.19 Time 12.36].zip


the most relevant section being this one - 3 cogs used with unrolled loops

NOTE: the mask is used to allow me to re-use the pins again as inputs to the fpga to transfer over ROMs etc.

in the attached code zip the mask has been set to 00000111 and hence I have a blue display of anything the
fpga creates whilst having 5 lines to do comms with.

Change the mask to $ff to get full VGA copy.
PUB Open(lower8vidmask,ptrToParams)    : i|  j

  Close
i := lower8vidmask  << 16
  'j := 16 & %100000 == 0
  reg_dira := i  ' & j
  'reg_dirb := i & !j   ' unused by prop at present? maybe was being used as a spare register - ah
          ' actually is this another internal 'bus' like the pins can be used?

 
  result := cog1 := cognew(@fpga_read,ptrToParams) + 1
  result := cog2 := cognew(@fpga_read,ptrToParams) + 1
  result := cog3 := cognew(@fpga_read,ptrToParams) + 1

      
PUB Close

  if cog1
   cogstop(cog1)
  if cog2
   cogstop(cog2)
  if cog3
   cogstop(cog3)
 
  if cog
    cogstop(cog~ - 1)
  
          
DAT
        org 0
' *******************************************************************************************************
' *                                                                                                     *
' *     Get Parameters and Initialise Driver                                                            *
' *                                                                                                     *
' *******************************************************************************************************

fpga_read 
    '    mov     paramPtr, PAR           ' Point to parameter block                                
         
           mov     dira,reg_dira           'set pin directions                   
 


        
 :read_byte
 
        mov r0, ina
        shl r0, #16 
        mov outa, r0 
       
        mov r0, ina
        shl r0, #16
        mov outa, r0
        mov r0, ina
        shl r0, #16
        mov outa, r0

  
        mov r0, ina
        shl r0, #16
        mov outa, r0
        mov r0, ina
        shl r0, #16
        mov outa, r0

   
        mov r0, ina
        shl r0, #16
        mov outa, r0
   
    

        mov r0, ina
        shl r0, #16
        mov outa, r0
        mov r0, ina
        shl r0, #16
        mov outa, r0

   
        mov r0, ina
        shl r0, #16
        mov outa, r0

        
        jmp #:read_byte



Any great ideas welcome on how to improve the output - given the lack of clock synch between the two osc.



On a related point - can the INPB register be used as an internal 'video bus' like the P0-7 trick?

Warm regards from still sunny Mid Wales!



Pete

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2014-09-19 05:28
    Assuming only outa[16..23] is actually driven you might get away with:
    movs    outa, ina
        shl     outa, #16
    
    That said, how do you deal with outputs being OR'd? You're starting three cogs with the same loop ...
  • WombleWomble Posts: 20
    edited 2014-09-19 06:02
    OR ing the outputs was the idea in order to 'oversample' the pins.


    with only 1 cog running the copy I get no display - I'm assuming that the sync signals are not accurate enough - the more cogs I add the better it gets (at the expense of ghosting due to the diff cogs OR effects)

    the combination of unrolled loop length vs number of cogs gave me the best result using the code shown.

    I feel it shoudl be possible to imporve things by using only two cogs or so - and synching them so that they sample the input VGA on a ping-pong basis.


    I will try out your suggestion thank you!
  • kuronekokuroneko Posts: 3,623
    edited 2014-09-19 06:17
    If you don't mind the signals being inverted you can use 8 counters (4 cogs) in feedback mode (e.g. POS/EDGE with feedback). This way you can feed P0..P7 directly to P16..P23. Delay here would be one system clock cycle, no active code necessary (except something to keep the cogs alive).
  • WombleWomble Posts: 20
    edited 2014-09-19 06:19
    Thanks very much for your excellent advice - that is much faster.

    Two cogs of the following code and the display is fairly useable, a single cogs gives more definition at the expense
    of slight flicker.
          
     :read_byte
           movs    outa, ina
        shl     outa, #16
           movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16         ' not bad
    
    
    
           movs    outa, ina
        shl     outa, #16
           movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
        movs    outa, ina
        shl     outa, #16
           movs    outa, ina
        shl     outa, #16
           movs    outa, ina
        shl     outa, #16
    
      jmp #:read_byte
    
    
  • WombleWomble Posts: 20
    edited 2014-09-19 06:24
    ah! now that is just superb (big beam)

    well worth a go :) I can pre-invert within the fpga if necessary.

    I've been pumping SRAM data from the fpga into the propeller and creating the VGA/TV in the prop until the present time. However the Lynx
    will require 256x248x8 bits (fulll 3 plane system) which isnt possible at present on the prop so hence i generate in the fpga and pass it through.

    here are some videos of the previous system I was using.

    https://www.youtube.com/channel/UCCa2b8ThIwUCbyQDOewNu2A


    my thanks once again for your help.
Sign In or Register to comment.