I am working on a color NTSC video circuit using assembly and SRAM (32k).
I am having some strange problems that seem to be getting the best of me.

First of all, my setup:

SX52 @ 80MIPS rc = video bus
rb = data bus (for SRAM)
rd/e = 15 bit address bus (parallel)
ra = misc control
Now, here is what I am doing.  Just for SIMPLE testing, I am only using the first 256 bytes of the SRAM.  I set port RD and RE to all 0 which I assume is address $0000
RD is wired to A0 - A7 and RE is wired to A8 - A14
When the scanline starts, I set the address bus to all 0 ($0000) and I increment port RD.  Then, the raster grabs the new value from SRAM and blits it to screen.  A framebuffer really.  This should give be 256 bytes...one for each of the 256 pixels.

I copy the databus directly to the video bus.

In the beginning, I clear out the SRAM (the entire 32k) so that I don't have garbage.

Now, here comes the fun part.  Let's say I clear the 256 bytes with a blue background and nothing else.  This works. On the TV you see my blue.  Now, lets say I change position $0002 to have a white pixel.  This works.  Now, if I add another pixel, it works but it takes the original pixel and duplicates it randomly on the screen!!!  It's hard to explain.

At first, I thought 256 pixels was just too much.  So, I reduced it down to 16 pixels (fat pixels!).

Still the same problem.

Maybe this can explain it better:

Now, I am only using *16* pixels address $0 to $F
B=BLUE
W=WHITE
This works:
0123456789ABCDEF
BBBBBBBBBBBBBBBB
Produces a solid blue line

This works:
0123456789ABCDEF
WBBBBBBBBBBBBBBB
Puts a white pixel at the front
This works too:
0123456789ABCDEF
BBBBBBBBBBWBBBBB
A single white pixel (at $A) works.  A single pixel can be anywhere.

This does NOT work:
0123456789ABCDEF
WBBBWBBBBBBBBBBB
Two white pixels.  One at $0 and one at $5
On screen, it looks like this:
0123456789ABCDEF
WBBBWBBBWBBBBWB
You'll notice the extra white pixels.  This only happens when I plot more than one pixel (other than the background)

Thanks!

cbmeeks
I am totally stumped on this one.  I am using 15ns SRAM so I was careful at making sure there was enough delay between setting up the address bus and reading/writing to the databus.

You are aware that 15ns is in reference to the access time and not the cycle time, are you adhereing to the cycle timing as well? What SRAM are you using (it's clear its a Cypress, but whats the part #)? Also can you give the code for your loop?

Sorry, should have mentioned the part number.  It's a UM61256k-15.

Not 100% sure what you mean by the cycle time.  I am new to SRAM.  
I have the code at home and will post some tonight.  But basically, it something like:

;reset address bus
;ADDR_BUS_LSB is RD which is wired to A0 - A7
;ADDR_BUS_MSB is RE which is wired to A8 - A14

mov ADDR_BUS_MSB,#0
mov ADDR_BUS_LSB, #0
nop  ;small delay
nop
;SRAM should now be at $0000
StartLoop
mov VID_BUS, DATA_BUS
nop ;small delay
nop inc ADDR_BUS_LSB  ;now at $0001, $0002, ....$000F  (only 16 in this loop)
nop ;small delay
nop
...rest of padding for NTSC jmp StartLoop
...

Ok I was wrong that it was a cypress part, never heard of United Microelectron Corp. Can you scare up a spec sheet for the chip? I can't find one so I can't verify if your timing is correct. The access time specified as the key metric (15ns) for your part is only the measure from address valid to data valid portion of the read/write cycle, this doesn't tell you what the cycle time is (start of address valid to start of next address valid). Your program must adhere to both the access timing and the cycle timing to properly use the device.

Yeah, I couldn't find a datasheet either.
As a sanity check, try slowing down access to the SRAM. Or is that what you did when you did 16 pixels ?
Bean.

Try generating a test program for the SRAM chip (in abstentia of any other coding), something like storing the least significant byte of the adress into each memory location, then after the SRAM is filled read it back out comparing the read value to the lsbyte of the adress, if these are not the same, turn on an LED (or some other indicator). This will tell you if the data being stored is actually stored, Ive used a similar program to fitness test my Cypress SRAM and program timing (it actually was a 6 step write out/read in: all $00, all $FF, address, inverted address, $AA, $55, last 2 aren't nessesary, just in there for completeness), the first 2 tests for dead bits (stuck high or low), the second 2 test for "random" data reading and writing, the last two are supossed to check for cross talk and skew, but this isn't usually an issue.

Thanks guys.  I will try some tests tonight on some LED's to see if I am recording data correctly.

Here is a direct link to the datasheet:

http://jameco.com/wcsstore/Jameco/Products/ProdDS/75037.pdf
Here is some code:

;=============================================
;        TRUTH TABLE
;=============================================
;CE        WE        OE        Data Mode
;H        X        X        High Z Standby (ISB, ISB1)
;L        H        H        High Z Output disable (ICC)
;L        H        L        DOUT Read (ICC)
;L        L        X        DIN Write (ICC)

;=============================================
;        SRAM
;=============================================
SRAM_READMODE MACRO
        setb WE                                ;(1)
        mov !DATA_BUS,#%11111111        ;(2) Port C all input
ENDM
SRAM_WRITEMODE MACRO
        clrb WE                                ;(1)
        mov !DATA_BUS,#%00000000        ;(2) Port C all output
ENDM
SRAM_CHIPENABLE MACRO
        clrb CE                                ;(1)
ENDM
SRAM_CHIPDISABLE MACRO
        setb CE                                ;(1)
ENDM

;=============================================
;        PIXELS
;=============================================
PLOT        MACRO x,y,c
        mov ADDR_BUS_LSB, #x
        mov ADDR_BUS_MSB, #y
        nop
        nop

        mov        DATA_BUS, #c
        nop
        nop
ENDM

;here is a portion of my read code (active scanline):
....
;we are now at 872 clocks  (10.9 µS)
;Active Scanline 52.6 µS
;Normally, this would be 52.6 * 80 = 4208 clocks
;However, we have 3 clocks for the call and 3 for the return
;So we need to run for 4202 clocks
;reset SRAM LSB
        mov ADDR_BUS_LSB, #0                        ;2
        mov p1, #16                                ;2
StartPixels
        mov VID_BUS, DATA_BUS                        ;2
        nop                                        ;1
        nop                                        ;1
        inc ADDR_BUS_LSB                        ;1
                                                ;244 cycles
        mov        w, #$3D
        mov        d1, w
active_delay_0:
        decsz        d1
        jmp        active_delay_0
                                                ;3 cycles
        jmp        $+1
        djnz p1, StartPixels                        ;(4/2)
;pad out the rest
        nop                                        ;1
        nop                                        ;1
        nop                                        ;1
        nop                                        ;1
                                                ;100 cycles
        mov        w, #$19
        mov        d1, w
active_pad_0:
        decsz        d1
        jmp        active_pad_0
        ret

;My Clear Routine:
mov        d1, #0
mov        d2, #127
StartClear
        mov        DATA_BUS, #( COLOR5 + LUMA2 )
        nop        ;small delay (13ns -- SRAM is 15ns so this should be enough)
        nop
        inc        ADDR_BUS_LSB
        nop
        nop
        djnz        d1,StartClear
        inc        ADDR_BUS_MSB
        nop
        nop
        djnz        d2,StartClear

Thanks!

Just to jump in here, that is one fast SRAM chip, but I don't see in your plot macro or clear code where you cycle the write line.

To register the value, the write line has to go low for the specified 9 ns minimum, and *must* go high again to clock the data into the memory array.

With reads, the data sheet specifies that you can get away with putting CE and OE low and reading new data by changing just the address.  You just can't change the address any faster than every 15 ns.  But that should work OK.  You have to wait the required access time of 15 ns before reading the data, because it isn't guaranteed to be there before that.  The data hold time lets you read the data at the same time as you change the address, but since you are reading the data long after you change the address, you don't need the two nops between the mov VID_BUS, DATA_BUS and the inc ADDR_BUS_LSB.

To write, you have to put CE low, OE high is optional, but then you have to bring WR low and then high again before you switch addresses and data.  See note 10 in the specs on page 6, CE or WE must be high during address transitions.  So if you are setting them both low, then doing your plot macro, I think all bets are off as to the data that ends up in the ram, and where it ends up.  If you leave OE high and make CE low while writing you can set the address, output the data, bring WE low, wait at least 9 ns then bring WE high, and do it over for the next byte to write.

I noticed that the current required is quite high.
Make sure you have proper caps as close as possible to the SRAM, and that your supply can handle the current needed.
Bean.

Wow, thats a great SRAM, its 15ns is the cycle time and not just access time. Micheal seems to have covered the bases, the timing seems to be ok, but the /WE has to be toggled for each write, the note says either /CE or /WE has to be high during the address change. In the timing diagrams whenever a value is a minimum time of 0, this means the time can change at the same time, but the order must be preserved (the transition must occur in the order described either at the same time or some time later in the proper sequence (ie /WE can go high at the same time as the address change, but it must be high during the address change. I know this a slightly confusing).

What are you coupling to the video bus? Depending on what it is you can potentially eliminate the video bus by coupling it directly to the data bus (I use this trick frequently to reduce pin counts (might be handy since SX52 is discontinued)).

THANKS GUYS!

[Quoting: "Michael Chadwick"]Just to jump in here, that is one fast SRAM chip, but I don't see in your plot macro or clear code where you cycle the write line.

To register the value, the write line has to go low for the specified 9 ns minimum, and *must* go high again to clock the data into the memory array.

....
MRC

[Quoting: "Bean (Hitt Consulting)"]I noticed that the current required is quite high.
Make sure you have proper caps as close as possible to the SRAM, and that your supply can handle the current needed.
Bean.

[Quoting: "Paul Baker"]What are you coupling to the video bus? Depending on what it is you can potentially eliminate the video bus by coupling it directly to the data bus (I use this trick frequently to reduce pin counts (might be handy since SX52 is discontinued)).