Interfacing the VS23S010 chip with an Atmega1284 Micro Controller

[Neslou]

Hi,
First of all, would like to thank you for all your work with this chip (the VS23S010).
I just learn some hardware details from the uzebox diy game console and i found your topic.
Here is my question :
I would like to use your chip instead of the AD725 DAC used in the original schematics of the uzebox.
Personnally, i don't use this chip because i have built the scart version (i live in France )
How to obtain samples of your chip please?
Also, could you provide an application note for the Atmega644 / 1284 micro controller , for helping me to interface all this stuff?
I am thinking of doing a retro game console based on a Atmega1284 because of his capacity.
I will follow your work.

Regards.

Neslou.

[Panu]

Dear monsieur Neslou,
Welcome to the forum!

First of all, would like to thank you for all your work with this chip (the VS23S010).

Thanks! It's one of the more fun things at work, actually!

Please contact sales@vlsi.fi for samples.

I am thinking of doing a retro game console based on [VS23S010 and] Atmega1284 because of its capacity.

That's great! I've just completed a full screen tile-based scroller which uses the block move engine (blitter) to draw and scroll the full screen using 32x32 pixel tiles and the default 8-bit palette. Works great; it takes only 5 milliseconds (about 30..35% of frame time) to completely redraw the display using the blitter hardware! All the microcontroller does is give instructions to copy tiles from off-screen memory locations to on-screen memory locations.

vs23s010 tile graphics.png (403.8 KiB) Viewed 14237 times

So I'm thinking of making, as an example, an engine that has a tile-based world map which you can scroll around and place a few sprites on. You know, just a demonstration of one possible way to effectively use the on-chip hardware and resources. I'll publish some code when it's ready. I'll use our own processors as the platform, but I'll try keep the code quite platform independent so it should be readable. Mostly you'll just see some calls to SPI write functions, so hopefully it will be easy to port.

Also, for me, even if the chip might not be primarily intended for games, I think it makes sense to do a game example, because a game should be the ultimate test of real-timeliness and reactivity, as well as push on-chip resource usage to maximum. If you can do a game with it, then you can probably also do most anything else.

As for the hardware interfacing with the Atmega, we can discuss about it here. Basically the minimum is the SPI bus. Then you can add more connections to make it more efficient: An interrupt signal for BLOCK MOVE COMPLETED and perhaps another interrupt to signal start of picture frame or end of picture frame (another possibility is to use SPI to read the current line register but using an interrupt can provide a more efficient implementation).

If your MCU has double-bit or quad-bit SPI, please connect that. And another way to go is to use the 8 bit bus, but you'll still need the SPI to access the graphics hw; the 8 bit bus is only for memory access.

-Panu

[Neslou]

Thank's for your prompt reply!

Also, for me, even if the chip might not be primarily intended for games, I think it makes sense to do a game example, because a game should be the ultimate test of real-timeliness and reactivity, as well as push on-chip resource usage to maximum. If you can do a game with it, then you can probably also do most anything else.

>> I am totally agree with that!!! Game (and retroGame off course) is life!!! Displaying video / Sprite / Moving screen and sprite / Making Sound and/or Music / counting score etc... all these aspects are good test!


How about buying some sample in order to begin prototyting?

Also, except the atmega1284 and your own processor, have you got a preference for better use your chip?

*MCu
* 8Bit MPU (6502 / Z80 / ?)
etc..
My aim is to see your chip as a video frame buffer for the retro console and of course a Video Display Controller. How about hardware function? Screen Mode / Sprite Number / Color Palette / Scrolling H or V etc.. are they implement or we still need a VDP to do the job?


Regards.

Neslou.

[Panu]

Hi again!

We just got a new lot from the tester, so I think it'll be available in the web shop shortly. And as for the processor, I think you should (first) use the processor you're most proficient and experienced with. Later on, you can test our processors; we'll probably build a developer board with this chip and one of our own DSPs at some point. Now I am using a VS1005 Developer Board and a hand-assembled VS23S010 daughterboard.

-Panu

[Neslou]

You answering me too quickly i was editing my post.
Ok, i will wait when your chip will be available so.. an idea for the price (or too early?)

[Panu]

Ok, i will wait when your chip will be available so.. an idea for the price (or too early?)

Budgetary high volume price is something like USD2, but in small quantities it's more expensive. We'll see what kind of pricing we will set for it in the web shop.

-Panu

[Panu]

My aim is to see your chip as a video frame buffer for the retro console and of course a Video Display Controller. How about hardware function? Screen Mode / Sprite Number / Color Palette / Scrolling H or V etc.. are they implement or we still need a VDP to do the job?

I think you'll go quite far with an ATMega and the VS23S010. In the VS23S010, there's the frame buffer memory, video timing generation, PAL/NTSC modulator, DAC and the blitter (block copy engine). I think you can vision fairly accurately what you can accomplish with these. The blitter doesn't have transparency, so my approach will be to draw sprites offscreen and then use the blitter to copy them on-screen at screen refresh/redraw.

-Panu

[Neslou]

Many Thank's for your reply Panu...

[JimDrew]

Neslou,

I have quite a lot of experience now with the VS23S010 chip. I have it interfaced to a PIC24 using both the SPI and 8 bit parallel ports. Panu has been a great help in figuring out the ins and outs of this chip. The one thing that is not documented in simple terms is that this chip is a video generator. As such, you have to setup how it generates video. Imagine this chip as a big state machine that executes code from it's RAM buffer. So, it draws the areas before the start of the display, the borders, the end of the display, and the actual video data. This is done using a series of pointers and a rather complex method of calculating the offsets. I had Panu just make a working display and dump it as a 64K file and I have been including that for setting up the chip. At some point I will have to make macros for doing that instead of burning up 64K of code space.

When the video is setup, the pointers to the video data are located "somewhere" in RAM. That somewhere is determined by chip setup. So, each display line has a pointer that points to the video data. The number of bytes of data depends on the display depth. 8 bits = a byte, but you could have 9 bits of video data, which would be packed as bytes together. For simplicity and learning the chip, I would recommend sticking with an 8 bit display to begin with. This chip does NOT deal with RGB, which has been the biggest problem for my projects. Instead, it uses YUV - which is standard for video stuff. With a 8 bit depth, there is no way possible to make a fixed palette that has 256 unique colors. That's the unfortunate issue with YUV. You probably get 100 or so unique colors out of 256. You can have 256 gray scales though. To get 256 unique colors you would have to use a 12 bit display (which means 1.5 times the amount of data to move). If you can use YUV data directly (like a mp4 or something) then you are probably going to love this chip! You could just change the burst value for every frame and use the data directly to have a variable palette.

I have several projects that are using this chip, one of which is an Arduino shield for a retro gaming console, and anything else where video is required. The VS23S010 does have 128K of on board SRAM, so that is handy for applications that need video as well as some extra RAM. Unless you are using the largest/deepest display there will be RAM left over. For example - 320x240x8 uses 76800 bytes + what the chip needs for output - about 2K. So, you have about 50K or so of extra RAM you can use for anything you like. Because the cost is reasonable for this chip, it's actually an inexpensive way to add 128K of SRAM to a project - which is why they have the version without the video generator capability.

Let me know if you run into any issues with interfacing the chip. I would *highly* recommend you use the 8 bit parallel port, otherwise it is going to be *really* slow through the SPI on an Atmega CPU, especially since the SPI speed is slow on the Atmel parts (< 10MHz) and you can't use dual or quad I/O. With the parallel interface you could do real time video (>24fps) with a 320x240 8 bit display. Because the SPI port on this chip is shared with the parallel port, you can just bit-bang the SPI setup using those lines, and then use all of the lines for the parallel transfers from that point on. Note - there is a bug in the chip that Panu discovered while working with me, and that is the video data needs to start on an odd address or there is some artifacing that occurs on the last pixel of each row.

Good luck!

[Panu]

Thanks for the explanation, Jim! It always helps to get another point of view, written by another set of eyes and hands. The bug you mention specifically relates to the end of the visible line, not the beginning. If the visible line ends at a 32-bit boundary, fetching new pixel data intereferes with returning to the background, causing visual effects. This is generally a problem when the pixel width is 4 clocks and the workaround is to start the pixel data at an odd byte address. Another workaround would be to set pixel width to 3 or 5 clocks so you can get a line width that is not divisible by 4 bytes. For example, when PICEND-PICSTART is 159, the picture line width is 159*8=1272 clocks and with pixel width of 5 you get 254.4 pixels per line, which is ok. Or with pixel width of 3 you get 426.7 pixels per line from 160*8=1280 clocks, which is also ok. If you want to do horizontal scrolling by setting line pointers so that you're always displaying just a part of a really wide picture, you must go this way. But if you use the blitter to draw tile graphics or scroll the screen, you don't have to.

-Panu

PS. Jim, I hope you'll still connect the SPI on your Arduino shield; the Arduino being slow, I think the blitter+tile graphics suits to it very well, because then the Arduino is mainly just commanding the blitter to copy blocks and not transferring new pixels to the screen (so much). In this way even the Arduino could do full screen realtime graphics with the SPI. The blitter registers are double buffered so you can set up a new block copy while the first is being executed so there's very little overall setup costs per transfer. If you connect the BLOCKMOVE0 pin you can use it to quickly detect the end of transfer and start the new transfer almost immediately resulting in 5 ms to draw the entire screen. My work-in-progress code uses 320x224 pixels, 256 colors (the default palette) and has 40 tiles of 32x32 pixels each in off-screen memory. A few kilobytes are reserved for a "world map" and random data storage. The 8-bit bus is fast, but uses 32-bit writes so individual pixel manipulation needs to be done in a read-modify-write fashion. My next board has quad bit SPI connected, which I'm hoping to be a best-of-both-worlds approach.