[Coco] A Video Timing Question

[Neal Crook]

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
>
>