"Anacon-xC" Retro Analog Video Console

XCore Project reviews, ideas, videos and proposals.
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

"Anacon-xC" Retro Analog Video Console

Postby kevpatt » Sat Mar 04, 2017 5:52 am

Hi all,

I've been playing around with my StartKit off and on for about a year now. One of the projects I've been hacking together is a "retro" analog video console, just for fun. What that is supposed to mean is, something like a small "home computer" or "game console", with analog (standard definition) video output. I grew up around the end of the 8-bit home computer era so I have a fondness for that kind of "retro" eyecandy. Of course this is running on a modern 32-bit multi-core microcontroller, but I don't have the time or patience to wire hundreds of TTL ICs together. :)

So far I have my StartKit generating 24-bit RGB pixel data in realtime, using a scanline-based rendering approach (no framebuffer). This is fed into a RGB DAC on a separate board I made, along with an AD724 video encoder for TV output. There are connections for VGA, S-Video, and Composite Out that I desoldered from some old VGA cards. :)

So far I have a variety of cool stuff going on: 320x240 resolution (to be increased), render-list based OO drawing framework in C++, PS/2 mouse and keyboard support (with hot plug and device auto-detection!). Sprites. Alpha blending. Bitmap text. Anti-aliased circles. Right now I have one thread running general I/O, one thread pumping pixels out to the DAC, and two threads rendering the next two scanlines in parallel. I plan to build an "upgraded" I/O board in the near future with a 256 mbit DRAM and a stereo audio DAC.

It's a "spare time" project that I cooked up mainly just to play around and get intimately familiar with the xCore platform. So far I love it. This project uses xC for most of the I/O, parallelism, and inter-thread communication, C++ for most of the "user space" stuff, and plain-old-C interfaces for calling between. It doesn't do anything "useful" yet, but you can type on the screen and look at some pretty sprites and other graphics. I have a gut feeling that the chip (XS-2 anyway) is more than capable of emulating a variety of real 8-bit CPUs and peripheral hardware, so it should be possible to create a cycle-accurate implementation of a complete home computer/console, like a NES. I'll probably take a stab at something like that down the road.

I've released all the code under the GPL on Bitbucket and posted the project on Hackaday.io. Right now it runs on the StartKit and fits in about 40k of RAM. I just received my xCORE-200 eXplorerKIT so at some point I'll migrate over to that when I need the extra memory or performance.

Anyway, just wanted to let everyone know. If you're interested, I'd love to have you follow the project on Hackaday.io. Feedback or contributions are welcome! If anyone has questions about the project, I'll be glad to answer them here.

Cheers!

-Kevin H. Patterson

Image
User avatar
ahenshaw
Experienced Member
Posts: 86
Joined: Mon Mar 22, 2010 8:55 pm

Postby ahenshaw » Mon Mar 06, 2017 5:22 am

Really, really impressive! I'd like to see some video, when you get a chance.
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Mon Mar 06, 2017 5:29 am

Yeah, I do plan to post some video (on YouTube, probably). The problem is, since the video output is _analog_, I have to use a digitizer to capture it on my computer! :P I have an ADVC-110 at work I'll probably borrow... (I suppose I could do some kind of "software" capture and dump the generated pixels data to another device, but that's pretty high bandwidth and it wouldn't have that "retro" video look to it...) Hmm. Maybe I should just film the TV screen. :/

Got a 256 mbit SDRAM breakout board designed and ordered with OSH park today, so at some point I'll try out the SDRAM library (on XS-2, likely). (Eagle board files are on the Hackaday.io project page.) I also have a nice 24-bit stereo DAC (WM8524), but I still need to design a board for it. Maybe tomorrow.

Image Image
Last edited by kevpatt on Fri Mar 10, 2017 6:22 am, edited 3 times in total.
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Mon Mar 06, 2017 9:21 pm

Mini adapter board for Cirrus Logic WM8524CGEDT I2S Stereo Audio DAC has been designed and ordered from OSH park. 24-bit, 106dB SNR. Dual RCA line-level outputs, which are also available on the pin header. Eagle 7.5 files are available on the Hackaday.io project page.

At some point in the near future I will use this board to add stereo audio output to the Anacon-xC project. Hopefully it can be a useful little I2S Stereo DAC board for other xCore projects as well.

Image Image
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Fri Mar 10, 2017 6:27 am

Today I designed a clock generator board around Silicon Labs Si5351A-B-GM, which can generate 8 independent channels of non-integer-related clock signals between 8 kHz and 160 MHz.

I plan to use this board to generate a variety of different clocks for the Anacon-xC project. This includes DAC pixel clock, I2S audio master clock and bit clock, NTSC/PAL encoder 4FSC clock, and in the future maybe even the XS-200 core clock as well (prob. 24 MHz).

For an example of how this would work: The xCore chip would send out a desired pixel clock frequency over I2C. The Si5351 would output this clock to both the video DAC and a 1-bit input on the xCore mcu. Falling edge of the clock would trigger the xCore to output 24-bit RGB data on a buffered port (using that input pin as clock), and the DAC would load the data on the rising edge. This makes it easy to select use any arbitrary pixel clock frequency, and take full advantage of xCore port buffering. Right now I'm burning a fair number of CPU cycles in the pixel output loop just doing the fractional division of the block clock to get an approximate desired pixel clock.

I believe a low-cost external multi-channel clock generator can be very useful in a variety of xCore-based projects. Using an external clock allows you to program in a more "event driven" mode, where the external clock is an event that can be selected on, rather than trying to generate all these "events" in code. Timers and port timestamps help a LOT, but when the clock frequencies are very high even a little overhead starts to add up.

Eagle 7.5 files are available on the Hackaday.io project page.

Image Image
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Sat Mar 18, 2017 1:06 am

I've assembled the first copy of the I2S Stereo DAC and the TSOP54 SDRAM Adapter boards. I plan to test them this weekend.
Image
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Mon Mar 20, 2017 5:15 pm

Spent several hours testing the SDRAM adapter board. Haven't had a chance to play with the I2S stereo DAC yet.

I did get the SDRAM to work with my XCORE-200 explorerKIT. However, it's definitely erratic. I'm able to write pseudorandom values to the entire 32 MB, and read them back successfully, but not 100% of the time, more like 90% of the time. My suspicion is that using a rats nest of jumper wires to a breadboard is not adequate with respect to the signal integrity required. But the library works, and I'm satisfied I know how to interface an SDRAM IC to the xCore.

Here are my thoughts on the "reliability" issues. Please note that I'm not complaining about XMOS :). I realize the pictured setup is a completely hacked-up arrangement that is probably way out of spec, and it's probably a miracle I got it to work at all. :P The following thoughts are here just for anyone who is curious or might have some ideas of their own to share.

Possible problems:

1. Maybe there's a subtle timing or setup compatibility issue with the Micron SDRAM (I'm using part number MT48LC16M16A2TG-6A:G) See http://www.xcore.com/viewtopic.php?f=47&t=4733&start=10. I don't have any ISSI parts, but I may order one and try it on another copy of the adapter board.
2. As a result of reading the above thread, I ended up using the lib_sdram master branch from this git repo. It seems to be the most up-to-date. (I had trouble with the lib_sdram installed by xTIMEcomposer, but perhaps I gave up too soon?)
3. I may have insufficient ground connections between the SDRAM adapter board and the explorerKIT. I need to populate the rest of the Tile I/O ground pads on the explorerKIT...
4. All Vss connections on the adapter board are tied to a common ground plane, and all Vdd connections are tied to a common 3v3 rail. The SDRAM is decoupled by two 0.1µF and two 1µF MLCC X7R caps on the adapter board. Maybe this is not enough.
5. Noise picked up by the jumper wires, or signal issues caused by inductance, excess capacitance, lack of impedance control on these lines, or the breadboard stubs. I need to check this on my scope. Perhaps I have bad skew, reflections, ringing, and/or overshoot...
6. I don't have an ultra-fast NOR gate handy, so I'm using a 74AHC02. It's rated about 6ns at 3v3, compared to the 2ns of the 74LVC02 part recommended by XMOS, so about 1/3 the speed. This alone could be the source of all my problems, but I would think it would become irrelevant at slower clock dividers... But I'll order an LVC part and try.

Oddly enough, I get pretty good results at certain clock dividers. I can run the pictured setup at div=8 (31.5 MHz), but no faster. HOWEVER, going slower (div=9, 10, etc.) doesn't seem to help! I even tried running at div=20 and 25, but everything slower is about 10-20% "reliable", compared to about 90% at div=8. I tried changing CAS to various numbers, no help. 2 works best at div=8, and 3 is marginally better at slower clocks... I also messed with "#define N (1)" in io.S, but changing it to 0 makes things almost totally unusable, even at very slow clocks (div=20, etc.).

Perhaps the most nagging issue is that I feel like I should be able to get this to work reliably at a slower speed (say 5 or 10 MHz). Perhaps there are some tweaks that I need to make to the library that I'm not aware of?

So, barring some miraculous insight that I'm yet to have, I'll probably end up designing a new (4-layer) board that incorporates both the SDRAM IC and an XMOS mcu on the same board, with impedance controlled traces, etc. Definitely a learning experience.

Image

Image
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Mon Mar 27, 2017 2:31 am

The I2S Stereo Audio DAC board based on Cirrus Logic/Wolfson WM8524 has been tested and functions perfectly. Yay!

I tested it using my XCORE-200 explorerKIT and the lib_i2s 2.3.0 library in "i2s_frame_master" mode. Currently I'm running it using the following parameters:

* Master Clock: 12.288 MHz (generated externally by Si5351)
* Word Clock: 48000 Hz
* mclk_bclk_ratio: 4
* mode: I2S_MODE_I2S

Right now I'm just generating some nice sine waves at different frequencies, but the output looks (and sounds) very clean. Stereo separation is tested good as well.

On a related note, I ported the Si5351 clock generator library from Adafruit, and made a nice xC interface for it that links up with lib_i2c. I can program arbitrary frequencies on all 3 outputs over i2c from the xCore mpu, no problem. I would be happy to publish this on git somewhere, I noticed that there is an "xcore" github... anyone know how I would go about contributing it there?

Right now I'm using the little 3-output board made by Adafruit, but I will be assembling one of my 8-output boards soon to test as well. It should work fine with the existing code, and a few tweaks to enable outputs 4-8...
kevpatt
Member++
Posts: 21
Joined: Thu Feb 09, 2017 4:53 pm

Postby kevpatt » Tue Mar 28, 2017 8:07 pm

The I2S Stereo DAC is now available (pre-assembled) at Tindie.

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 6 guests