So for a while now I've been looking into the possibility of using the Prop's video hardware to drive not
the data but the control signals of an SDRAM, allowing operation near or at the full design speed as a
video RAM, and also for signal capture (logic analyser, digital scope).
I designed a simple breakout board for a generic 54 pin SDRAM (SDR, PC100 or PC133). When this came
back from the PCB fab I got out the trusty sandwich toaster (converted to reflow oven) and transplanted a
HY57V56820B SDRAM chip onto it and started experimenting in earnest.
I'd previously written various pieces of PASM for driving various SDRAM functions and checked the timing
on the scope, to get basic confidence it was feasible.
Currently the setup is using the Prop clock / 4 as the SDRAM clock, but the technique can go faster, you just
have to insert NOPs in the SDRAM instruction stream (provided by the video hardware) so that you can
update the address bus faster enough (typically with consecutive "mov OUTA, addr" instructions.
So for each set of SDRAM instructions to send I have to choose a subset of at most 4 instructions, put their
pinstates into each of the 4 bytes of the colours argument to waitvid, and a set of di-bit selectors is fed as the
pixel data. A pin driven by CTRA both clocks the LCD and the SDRAM clock, and the low Prop
pins are connected to the address and bank-select lines.
For generating video to an LCD screen I use page-mode burst reads, setup at the start of the scanline (one
of the pins waitvid is controlling is the DEN pin on the LCD (it has DCLK/DEN + 18bit colour inputs - no HS/VS
to worry about) so that this can be set high two cycles after the READ instruction is issued (I'm using a CAS
latency of two).
waitvid is used to feed nops (and keep DEN high) for 800 cycles, then a different waitvid clocks in a BURST-TERM
instruction followed by PRECHARGE to close the row.
Between scanlines 4 AUTO-REFRESHs are issued to keep the DRAM happy, and at the end of the frame (480 lines)
I use a big gap of 100 scanlines to switch to code that writes the DRAM.
I push records onto a queue in hub ram, each represents a horizontal line segment to paint, its x, y coords and pixel
width and colour. During the 100 blank lines time the same cog pulls these off and executes burst-writes to update
the SDRAM with the updates, whilest keeping a count-down cycle counter updated with the number of video clocks
passing. When close to the deadline the code vidwaits for the actual deadline and goes back to the screen display
Anyway, time for images and videos:
The breakout board is hard to see with all the connections! The actual SDRAM I have has 8 data pins used, not the full 16 that
the 54 pin package allows, and these are routed straight to some of the colour pins on the LCD flex-pcb breakout. I've also added
resistors between some of the lower address pins and the datapins to allow the address bus to be used to write values to the RAM.
For graphics I'm setting up one value to the data pins (via the address pin resistors) and burst writing it to the whole line-segment
drawn, so the speed of Prop I/O isn't limiting the datarate.
In theory with a well laid out PCB and perhaps replacing the resistors with a DQ latch it would be possible to go upto 80MHz
My next experiments are going to be generating 1024 x 600 (WSVGA) at 40MHz pixel clock. This is 1024x768 with more blank
lines (to enable more graphics painting).
The current SDRAMs I have on various DIMMS are mainly 32MB so will hold over 50 screenfuls at WSVGA resolution. This would
enable frame-by-frame animation of course
The video shows that vertical hardware scrolling is trivial, only the row-address has to be
updated - the driver already reads this from hub ram.
The test patterns are generated in Spin using the sine table and are written to 4 screenfuls of memory (after having overwritten all 68
screenfuls at start up).
[edit: BTW the LCD is a CLAA070VA01 from a recycled Phillips digital photo frame,
it has a relatively sane interface, all 3.3V, just DCLK/DEN and 18 bit digital colour