[Coco] A Video Timing Question

[tim franklinlabs.com]

   That's exactly the kind of info I was looking for. You gave me an idea
   that should work. The bandwidth should be OK ( I haven't actually
   looked at it yet). Admittedly, I haven't even considered reading the
   video RAM yet. I'm taking baby steps. LOL
   My planned max resolution is 800x600 @ 60Hz frame rate and the clock
   timing is 40MHz, If the RAM can handle 12nsec reads & writes we should
   be good.

     On September 13, 2015 at 3:21 PM Neal Crook <foofoobedoo at gmail.com>
     wrote:
     Hi Tim,
     I'm not sure whether you're using on-FPGA (synchronous) RAM or
     off-FPGA
     asynchronous RAM. The basic problem is the same in any case.
     Calculate how
     much bandwidth you can squeeze out of the RAM. Calculate how much
     bandwidth
     is needed by the video readout. If you're lucky your RAM will have
     2x the
     bandwidth needed by the readout. In that case you can simply
     alternate
     cycles between the CPU and the VDU. Each can only access within
     their time
     window (in both cases they may or may not need to perform an
     access). This
     is simplest if the control logic cycles at a clean multiple of the
     video
     rate. If a simple calculation shows you don't have enough bandwidth
     then
     you have to stall the CPU or change your architecture. One
     architectural
     trick is to divide the memory into 2 independent banks and address
     it so
     that the video readout accesses alternate banks. That effectively
     doubles
     the bandwidth available and provides the extra bandwidth needed for
     CPU
     access. In all cases, you need to carefully co-ordinate the
     sequencing of
     the CPU's access; you may need to stall the CPU to get it to the
     right
     time-slot (if you're super-aggressive you would put a single write
     buffer
     here so the CPU can dump-and-run on writes and only stalls if the
     write
     buffer is full).
     Your FIFO approach sounds interesting, but I wonder how you cope
     with CPU
     reads from video memory? Correctness demands that a read cannot
     overtake
     writes and so you must stall the CPU until older writes have flushed
     through the FIFO.
     Perhaps you could turn your FIFO idea on its head: use the FIFO to
     hold
     video data. Fill the FIFO at maximum SRAM rate, empty it at the
     video rate.
     Since you know the time that the CPU needs to perform an access you
     will
     know how full the FIFO needs to be in order for you to allow the CPU
     to
     proceed "now" (stalling FIFO fill) without incurring video underrun.
     If the
     FIFO is not full enough, you must stall the CPU. When you reach the
     end of
     the active row/frame, the FIFO will fill up and remain full (ie will
     not
     get read during the blanking time) and the CPU will naturally have
     access
     to all of the bandwidth during that time.
     Since you refer to "sparkles" can I infer that you are debugging
     this on
     the bench? In debugging various problems with my multicomp-derived
     design I
     have written very small 6809 test programs and run the whole thing
     as a
     logic simulation. If you haven't ventured down this path I
     thoroughly
     recommend it.
     My apologies in advance if anything I have suggested is laughably
     obvious
     to you.
     Neal.
     On 13 September 2015 at 20:30, tim franklinlabs.com
     <tim at franklinlabs.com>
     wrote:
     > OK, this is a "best practices" question for those working with
     FPGA
     > video. My SOCoCo project is moving along. I got the CPU running in
     > SDRAM and the video running on SRAM. However, I have struggled
     with the
     > best method of syncing the CPU writes to the Video. I first tried
     a
     > FIFO to delay the writes until the vertical and horizontal sync
     pulses.
     > This worked but when I sped up the CPU to over 1MHz, with
     continuous
     > writes, I was getting dropped character (sync times are too slow).
     Then
     > I tried letting the CPU write to SRAM (still using a FIFO) and
     sync the
     > writes within the reads of video (i.e. when data is ready to write
     I
     > write instead of read). This method works well but I get sparkles
     on
     > continuous CPU to video writes. I think that this is caused by the
     data
     > going to the dac from the previous read cycle is actually delayed
     and
     > held by the write cycle time.
     >
     > So, I'm wondering how others have addressed this?
     >
     >
     > --
     > Coco mailing list
     > Coco at maltedmedia.com
     > https://pairlist5.pair.net/mailman/listinfo/coco
     >
     >
     --
     Coco mailing list
     Coco at maltedmedia.com
     https://pairlist5.pair.net/mailman/listinfo/coco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tim at franklinlabs.com.vcf
Type: text/vcard
Size: 245 bytes
Desc: not available
URL: <https://pairlist5.pair.net/pipermail/coco/attachments/20150913/bfb91d41/attachment.bin>