SX52 and SRAM problem...kinda long

cbmeeks · 2005-12-21 21:43

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 $4
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)

Hope this makes sense.

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://metroidclassic.com

=========
DMCA Sucks
RIAA Sucks

Post Edited (cbmeeks) : 12/21/2005 9:48:44 PM GMT

Paul Baker · 2005-12-21 22:06

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?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

cbmeeks · 2005-12-21 22:39

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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://metroidclassic.com

=========
DMCA Sucks
RIAA Sucks

Paul Baker · 2005-12-21 23:21

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Bean · 2005-12-21 23:24

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Forget about the past, plan for the future, and live for today.
·

Paul Baker · 2005-12-21 23:39

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

cbmeeks · 2005-12-22 00:17

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:

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

I will do the LED tests next and post my results.

Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://metroidclassic.com

=========
DMCA Sucks
RIAA Sucks

Michael Chadwick · 2005-12-22 05:56

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.

Should be a simple fix, and you will have beautiful pixels wherever you want them on the screen. [noparse]:)[/noparse]

MRC
·

Bean · 2005-12-22 12:33

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Forget about the past, plan for the future, and live for today.
·

Paul Baker · 2005-12-22 16:13

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

I would ignore using the /CE pin, and just tie it low, unless you are using multiple SRAMs (or using other devices on the same bus), theres no point using it, it just slows down the access.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Paul Baker · 2005-12-22 16:20

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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

cbmeeks · 2005-12-22 21:14

THANKS GUYS!

Michael Chadwick said...
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

Man, I believe that is it! I will try it this weekend...as soon as I remind Santa how to get to our house. ;-D
But I get what you are saying. I simply am not cycling correctly (or at all). I *assumed* all you had to do was set the address you want, wait 15ns, send the data and that was it. Looks like that is OK for reading but not writing. All of my writing will be done during VBlank so super high speed shouldn't be a problem. In fact, a 6502 will be responsible for the writing.

Bean (Hitt Consulting) said...
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.

Yup. You can't see it in the pic but I have two caps within mm's of the powerpin.

Paul Baker said...
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)).

You know, I actually thought about that. Eventually, the SRAM will be shared with a 6502 and maybe even ANOTHER SX (for sprites). But all that might be OK because only one would use the data/addr bus at any one point.

Plus, I am using an SX52 now because that is what I have. The final product will use an SX48

cbmeeks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://metroidclassic.com

=========
DMCA Sucks
RIAA Sucks

SX52 and SRAM problem...kinda long

Comments