Jack Gassett
Mike Field wrote a great ebook to help beginners learn VHDL and FPGA technology. We asked Mike what would be the perfect hardware for his proposed book and the end result was the LogicStart MegaWing!
Download pdf version of Intro To Spartan FPGA.
Find all code examples on the ebook's github repository.
Wiki page with more material that pre-dates the book.

I've built the Z80 CP/M variant, complete with VGA & Keyboard terminal, Serial port, SD-Card and external SRAM. The steps I followed to accomplish this:
  1. Adapted the pinouts, ports and some signals of all the modules (Main Interconect, Z80, VGA, Serial, Keyboard, SD-Card) from the original design to fully use the Computing Shield peripherals and the DUO's SRAM (using and updated Computing Shield UCF file).   2. Converted the original 6 bit color VGA to 12 bit color interface.   2. Converted the internal BIOS ROM and Character Font ROMs, to use Xilinx's Core Generator's Block Memory instead of the original Altera Altsyncram IP.   3. Converted the internal double port Display & Attribute RAMs also to use the Core Generator's Block Memory instead of the original Altera Altsyncram IP.   4. In my first attempt I adapter the CPU and Baudrate clock generators, to use the Papilio's 32 MHz OSC instead of the original 50 MHz, but I ran into timing problems converting the many clock -dependant constants in the design. So I decided to generate a new 50 MHz clock using the DCM & PLL Wizard.   Wherever possible I tried to maintain Grant's original VHDL & Z80 code, generating new signals and "wrapper" code to adapt to the different hardware. This way you can still refer to the original design as a rich learning experience, as every source code is available and well explained in Grant's website.   The final outcome is a very usable and complete Z80 soft-core based machine, running the venerable Digital Research CP/M 2.2 OS. The modular design concept  allows for extensive hacks and mods, even CP/M 3 and MP/M could be run (my next milestrone !).   Hope you enjoy it ! I've attached some pictures of my working system and the full VHDL ISE 14.7 Project tree files, including an already generated "bit" file for transferring it to the Papilio Duo with the Computing Shield attached (default serial port baudrate is 9600, 8N1 no handshake).  
Also updated is the stepper to allow to stop after specific number of steps to help in position based applications. The library works in position or velocity applications.
Usage example are in the sketch under examples once the library is installed.
Hope folks find it useful.papilio_stepper-150411a.zip

Quadrature Decoder

By Filip, in Libraries,

This is a library for Designlab and Papilio Duo. The decoder module can have up to 4 encoders. For example 4 wheels on a mobile robot platform.
Optionally this can be use with a PID regulator for controlling current position, velocity, and direction of an object.

- The shown pins are totally optional
- By default the Avr chip is disabled
Papilio Pro and Papilio One (500k) with the Arcade MegaWing are supported.
Papilio DUO is detected but there are no base hardware bitfiles to merge into (yet)
Source code will be released after I am completely done.
The project runs on Windows .NET framework 3.5 but should run on MONO with a little love
(untested as I don't have a MONO setup to work with, but will probably require some minor tweaks)
Project is based on RomVault by GJeffereyes and is available at https://github.com/gjefferyes/RomVault and was used with permission.
2600 data is based on work from Rom Hunter's v10 Atari 2600 collection.
Arcade data is based off of MAME compatible files
Galaxian Test ROM (just a hardware test ROM) is from
Unzip archive (preferrably to somewhere like c:\RV-PE\ but i run from my desktop)
Place ROM files in the unsorted folder
Click the update button on the top right
-- ROM files will be sorted and identified (if supported)
Click on a game then load (or double click on a game) to load it to the FPGA


1 Pixel offset in pacman based games (bitfile issue not UI issue)
some 2600 games play better on the pOne (500k) than on the pPro
? you tell me ?

Papilio Pro and Papilio One (500k) with the Arcade MegaWing are supported.
Papilio DUO is detected but there are no base hardware bitfiles to merge into (yet)
Source code will be released after I am completely done.
The project runs on Windows .NET framework 3.5 but should run on MONO with a little love
(untested as I don't have a MONO setup to work with, but will probably require some minor tweaks)
Project is based on RomVault by GJeffereyes and is available at https://github.com/gjefferyes/RomVault and was used with permission.
2600 data is based on work from Rom Hunter's v10 Atari 2600 collection.
Arcade data is based off of MAME compatible files
Galaxian Test ROM (just a hardware test ROM) is from
Unzip archive (preferrably to somewhere like c:\RV-PE\)
Place ROM files in the unsorted folder
Click the update button on the top right
- ROM files will be sorted and identified (if supported)
Click on a game then load (or double click on a game) to load it to the FPGA
ROMVault-PapilioEdition (08 Mar 2015).zip
Jack Gassett
This library uses the Open Source BitCoin FPGA project to implement a Bit Coin Miner for DesignLab.

Request for Help
We can use some help with this library, there are still some things that can be done to make it better.
Documenation Learn Guide at http://learn.gadgetfactory.net Increase speed and the loop variable. Right now we run at 50Mhz and with a Loop of 5. We should be able to do 100Mhz and maybe a loop of 3 or 4... Connect the bitcoin miner to ZPUino and write a stratum miner in a sketch so we don't have to depend on python. Get cgminer working so we can use more pools and maybe some GUI clients like easyminer.  
Jack Gassett
Learn more about Gameduino at James' Wiki page.
There is excellent documentation and examples included with this project, all available at the Wiki.
This library turns the Gameduino project into an easy to use schematic symbol or what we call a 'Chip' that you can easily use in your DesignLab circuits. This chip is stand alone so you can use it to add graphics to any project, whether it has a wishbone bus or not.
The Papilio DUO board is required for this library. All sketches run on the ATmega32u4 chip and communicate with the FPGA circuit over SPI.

Gameduino Computing Shield Circuit

Gameduino LogicStart Shield Circuit

Flavia, the Free Logic Array, is a programmable device intended primarily as a teaching tool for FPGAs and CPLDs. Unlike every commercial device I'm aware of, Flavia's tool suite is free-as-in-liberty open-source software (FLOSS). This means it can run on platforms other than x86 PCs, including Raspberry Pi (tested) and BeagleBoard/Bone (not fully tested yet).
Flavia is a "CPLD in an FPGA", which uses FPGA look-up tables (LUTs) to implement both logic and routing. Since Xilinx documents ways to find the locations of your LUTs and flip-flops in their otherwise undocumented bitstreams, it's possible to program those LUTs to make a reasonably nice CPLD that can be programmed using FLOSS tools.
Flavia's first implementation uses the Papilio One 250K as its underlying FPGA. The 250K Spartan-3E FPGA has enough logic resources to make a useful CPLD and the FT2232D provides an easy programming interface for Flavia's software.
If you're interested, take a look at my 'blog at element14, which has links to all the software and documentation.
Hi guys,
I just wrote a small C++ application (text-mode) that can compute the two primary configuration values for PLL (multiply and divide), given an input clock speed and the required speed. Since some of these are not possible directly using a single PLL, the application also scans for a dual-chained PLL approach, where the output from the first PLL is fed into the input of the second PLL.
These two parameters are enough for you to get a working PLL with your desired frequency.

Source code and prebuilt windows .exe available at:
Will Sowerbutts
The original forum post is here.
The project page is here.
Hi everyone.
Last year I wrote a Z80-based retro microcomputer which runs in the Papilio Pro. It started out small but I added a few interesting features, in particular a memory management unit and a 16KB cache to hide the SDRAM latency. I've ported several operating systems to it. Both the hardware and software aspects of the project have been good fun with lots of new opportunities to learn.
I've just made my first public release, you can download it at http://sowerbutts.com/socz80/ and try it out. That page also describes the project in a bit more detail.
RAM disk images are included to boot CP/M-2.2, MP/M-II and UZI (a UNIX system). I've included Zork and the Hitchhiker's Guide game which will play under all three operating systems; they are native CP/M application but MP/M-II implements the CP/M system calls, and UZI includes a CP/M emulator.
The release also includes the full VHDL source code for the machine and the source code to all the software I've written, with the exception of the UZI port which I plan to release shortly after I extend it to support the N8VEM Mark IV SBC.
Please let me know if you get it to work!
Corey Kosak
Hi folks,
I thought I'd share my third project with you all. I got sort of obsessed with the idea of driving the VGA protocol without any frame buffer memory backing the display (note 1) and I wanted to see how far I could get with such a design. I ended up with a cute little program that bounces a few geometric shapes around the screen and also does boundary and collision detection.
There's a YouTube video here (http://youtu.be/ltEPILMaUMk) and the source code is here: https://github.com/kosak/PapilioPro-AnimatedShapes
Feedback on the code is very welcome. I'm a newbie VHDL programmer and I find the language sort of frustrating so I sort of made up my own coding conventions and did some other hacks. I also agonized a lot about how modular such a design should be and how inter-module communication should work.
In the process I've also generated a bunch of VHDL questions which I hope to post somewhere, if y'all don't mind. The first is hopefully an easy one: I used the IP Core generator to get a 25.175MHz pixel clock and it crapped out a huge number of files into my ipcore_dir. I'm sure most of those do not need to be checked into source control. Can you tell me which ones are supposed to be checked in?
Thanks for looking at my demo!
(note 1) mostly because I'm intimidated by the SDRAM :-)
Matthew Hagerty
Thanks for the camaraderie! As requested here is the code. I need to do a write-up if I can get some spare time. Hamster, thanks for the wiki offer, I might take you up on that in the near future. In the mean time, feel free to put it up if you are so inclined. I do need to mention that the rw_i request and done_o response / handshake is combinatorial and needs to respond in 5ns on both sides. This is because I used the falling edge for my register transfer and all my other HDL uses the rising edge.
Sometimes we all wish for "only one more LED". Now how about 307200 LEDs, all RGB, perfectly arranged in a square? (And I bet also your monitor has an unused analog input...)
Seriously, an RGB monitor can be a useful debugging tool, a poor man's logic analyzer.
The hardest step is probably the first, and that is to get some picture at all.
That's why I'm posting this VGA timing generator. It's rather compact (less than 200 lines, many of them comments), but it takes no shortcuts with the sync generation.
View attachment: IMG_3253.JPG.
The use of an inferred DSP48 for the test picture (via "*") is heavy-handed - but hey, we already paid for it, so let's use it.
This is the planAhead project:
View attachment: RGB.pa.zip
The interesting file is RGB.srcs/sources_1/imports/src/top.v
Further, there is a generated 32-to-25.175M PLL (approximate frequency) and the constraints file.
The latter is for a Xess RGB wing in Papilio Pro port "C". Pins may need to be re-mapped, depending on connections.
Now, how to use it for more than a test picture:
The generator provides X and Y as numbers, "blank" (here RGB must be zero), besides HSYNC and VSYNC signals to the monitor.
A typical implementation would need some processing delay on X and Y, simply delay HSYNC and VSYNC by the same amount.
"Ouch", because at the end of a long and painful debug process came the insight that the 2nd ADC on my board is broken. Works only when I push it down... will try resolder it tomorrow. Edit: Fixed.. the little fella had one foot off the dancefloor.
Anyway, one result is an ADC demo that got out of necessity a little more polished than planned.
Controls LED brightness with input 1 (the one closest to the SD card). The signal pin faces the edge of the board. Dumps all 16 channels through USB. Set up virtual com port for the 2nd USB interface, open Teraterm and connect with default settings (9600 baud, 8 bits, 1 stop bit) There is some information out there regarding control of this ADC that I find questionable, after reading the data sheet (It states explicitly that there are no timing requirements between falling edges of CS and CLK so they may change in the same cycle and the whole control logic simplifies greatly) ADCs run at 50 % of maximum throughput, that is, they take turns. 8 frames are captured in one shot. The data sheet shows 10 bits even though it's an 8-bit ADC. The implementation picks the correct ones, others are apparently zero (edit: no they are not - you get 10 bits of data out of the ADC)  

Don't pay attention to values from unconnected (floating) inputs. Lower channels will "leak" over into higher, undriven channels and the terminal output gets quite noisy. Putting jumpers between signal and +5V gives clean readings (but double-check, the other position would short +5V to GND).
The archived project is for PlanAhead, which comes with the ISE 14.7 download.
Jim Battle
I've finally gotten far enough in my project to post some status. The task at hand is to capture (and maybe in the future write) data off of arcane disk formats. In the past I've used the catweasel card, but it is no longer supported, and isn't general purpose enough to support the needs of my current subject, the Compucolor II floppy disk.
I turned to the kryoflux card, but soon realized that I didn't like the API much, and I was going to have to build an adapter card, as the CCII floppy interface is nonstandard. Also, some of my past arcane disk decoder projects used an 8" drive, and I would need yet another adapter for those. Since I was going to build an adapter, why not go all in and build my own capture hardware.
So I bought my Papilio Pro and got to work. I wrote my own SDRAM controller, but then glommed on to Mike Field's (Hamster's) SDRAM design, before going back to my own. The FPGA work was actually the easy part. Once I was able to capture bits off the disk, I had to write a python script to decode the bits into sectors and tracks and whole disk images, to decode the file structure and detokenize BASIC programs and such. The python script has a mini-shell to allow me to interact with it, eg, if a disk has read errors, I can dump the contents of individual sectors, or ask for specific tracks to retry capture.
Anyway, I've posted a 5 minute youtube clip of my setup showing it at work. This is my first attempt at narrating a video and it could be better, but it is good enough for now.

I've used this system to capture about 250 disk images for the Compucolor II, and I may come into another large batch to process. PCBs should be showing up in a week or two, then I'm going to rewrite one of my old catweasel drivers (for the wang 2200 computer) to use this new system.
As great as the famous C64 SID chip is, it is not the only way to produce great music and sound effects. There is another category of sound chips based on frequency modulation (FM) synthesis.
A very popular choice, mainly in Japanese arcades and consoles as well as some keyboard synthesizers / pianos, is the Yamaha YM2151. This is in fact one of several chips in the family of OPL, OPN, OPM and OPS chips. These acronyms indicate how many oscillators per channel the chip contains but they all fall in the wider family of FM synthesis chips.
The YM2151 (and others in its category) do not output analog sound, instead they output digital data over a serial channel. This typically goes to a separate D/A chip like a YM3012 stereo DAC or a YM3014 mono DAC. The YM2151 and its companion DACs are available for purchase on ebay for just $3 each so the enthusiast can experiment with them without considerable cost.
The fact that the chip does not have an integrated D/A and requires additional external components might be considered a drag by some, but in this particular instance, for someone like me, the fact that the chip outputs digital data is actually a bonus since that output can be fed back into an FPGA (without going through a D/A and A/D conversion) and further processed numerically.
To be honest, the idea for this mini project came to me after browsing though various schematics of arcade games. I came across a high res scan of a schema for the arcade version of Double Dragon
This was one of those rare schemas that are clean and legible but also just real easy to follow (despite it being over 20 pages), it's just a pleasure to look at and it just makes sense. The signals that cross pages are also very easy to follow because the designer labeled them not just with the page they connect to but the coordinates on that page as well. This is one of these games that have a separate sound board, complete with its own CPU. The interface from the game board to the sound board is via a simple 8 bit port with a single strobe (write) signal. I had the feeling I could just implement most of this sound board on a FPGA and then simply drive the external YM2151 chip with the signals produced by this sound board implementation.
Wiring all the external chips on a prototyping board is not really that hard, below is the basic schema that needs to be followed. This schema is a composite after cutting/pasting parts from different pages of the original schema to illustrate just the YM2151 connections to the D/A and audio amps.
View attachment: YM2151_schema_snd.png
So in order to implement the sound board on a FPGA I need to figure out how the main game communicates with the sound board. Focusing on the main game CPU is the wrong approach here though, this is like taking the long way to get somewhere, the right thing to do is look at the sound board CPU and see how it needs to be "tickled". Here is the schema with irrelevant bits taken out.
View attachment: YM2151_schema_adec.png
The data latch IC17 is written to by pulsing the signal line *3806 low then high. This clocks in the value from the DB data bus into the IC17 latch. In parallel however, the signal *3809 also clocks the flip-flop IC39. Because the D input is tied high, the pulse on its clock line cause the D input to be latched to the Q output (not shown) and its complement /Q at pin 9, meaning /Q goes low whenever the clock (line *3806) rises. This cause the active low /IRQ line to the 6809 CPU IC49 to go low triggering an interrupt.
Disassembling the sound ROM we see that the CPU vector table contains:

ROM:FFF0 fdb start ; RSVDROM:FFF2 fdb start ; SWI1ROM:FFF4 fdb start ; SWI2ROM:FFF6 fdb vec_FIRQ ; FIRQROM:FFF8 fdb vec_IRQ ; IRQROM:FFFA fdb start ; SWIROM:FFFC fdb start ; NMIROM:FFFE fdb start ; RST
So following the IRQ vector we get to:

ROM:880D vec_IRQ: ; DATA XREF: ROM:FFF8oROM:880D lda $1000ROM:8810 cmpa byte_2 ; if same as currently playing melodyROM:8812 beq locret_881A ; exitROM:8814 ldb byte_0ROM:8816 bne loc_881BROM:8818ROM:8818 loc_8818: ; CODE XREF: ROM:881DjROM:8818 ; ROM:8823jROM:8818 sta byte_A ; store index of melody to playROM:881AROM:881A locret_881A: ; CODE XREF: ROM:8812jROM:881A rti
Simple stuff so far. When the IRQ vector is called it reads address $1000 and ignoring some of the bits in the middle, it stores that value to byte_A (RAM address $000A) and exits the interrupt handler via the RTI instruction. The reason we ignore some of the code in the middle is because I've already analysed it for you and I can tell you it's not relevant for our discussion.
So why does the IRQ handler read address $1000? Well if we lay out the address lines as A15, A14, ... A1, A0 then $1000 is binary 0001 0000 0000 0000 on the corresponding address lines. So the top 5 address lines A15,14,13,12,11 are 00010 when reading from address $1000.
Looking at the schema we see these lines are connected to address decoder IC79 (pin 5 on that IC is not labeled in this cut down schema but tracing it on the real schematic shows it going to A15 on the CPU). IC79 is a 3-to-8 decoder meaning the 3 bit binary signal presented to its inputs 1, 2 and 3 is decoded so the corresponding output 0 through 7 goes low. Pins 5 and 6 are active low chip enables (meaning they must be low for the chip to do its job). So when the CPU places address $1000 on the address bus, the chip sees 00010 on its pins 5,4,3,2,1, meaning the two enables are enabled (low) and the remaining binary data 010 represents decimal number 2, so output 2 goes low. This output goes to our familiar flip-flop active low clear input. When the clear input is activated by a low signal the flip-flop clears its state, so the Q output (not shown) goes low (cleared) and its complement /Q goes high.
So the operation is now clear, whenever the *3806 signal goes low then high, the DB is latched into IC17 (which goes to the CPU data lines through another buffer to avoid contentions with other stuff on the data bus) and an IRQ is triggered. The CPU stops whatever it is doing and services the IRQ by executing the IRQ routine which clears the IRQ signal by reading address $1000 and storing the DB data from the IC17 latch into the CPU internal memory at address $000A.
This is pretty cool because I can now go to MAME and set a breakpoint at the sound CPU address $880D and every time an IRQ occurs, I can see what value was being written. Using this trick I can see that the following values cause the following things to happen.

$FF clears/stops any melody sound currently playing$FE clears/stops any sound effect currently playing$01 through roughly $30 play different effects or melodies on the YM2151$80 through ?? play different sound effects but not through YM2151.
The sound effects triggered with values > $80 do not use the YM2151 but instead play these effects through separate DAC chips IC80, IC81 and associated circuitry consisting of discrete programmable counters and digital comparators (the relevant schema for these is not shown anywhere in this post). There are in fact two identical circuit duplicated so two effects can be played simultaneously. I won't show an analysis of the circuitry for the effects but roughly it works like this.
Each channel has a 64KB ROM with sound effects stored inside. The CPU writes to the programmable counters to preset them with the starting address in the ROM and also to the digital comparators with the end address in ROM of the sound effect. The counters start counting up from the programmed address until the end address is reached at which point the programmable comparators issue a reset to stop the sound playing and the counters stop counting.
For example the CPU can preset $1234 into the counters and $2345 into the comparators and the ROM would be presented with addresses $1234, $1235, $1236, ... up to $2345 on it's address bus then the address would freeze there. The ROM output is connected to the DAC chip causing the value from the ROM data bus to be turned to analog sound into the speakers. The address counters are clocked with a presumably low clock which it seems is generated by the DAC chips, probably a few KHz.
More to follow...
EDIT: Any code for this project will be available here. So far I have added there the full schematic of the sound board, all three pages into one image for convenience. My development hardware will be a Papilio Plus with an Arcade Mega Shield (plus any external chips of course).
Well done Kosak, It is my hope that this forum will have more posts from people showcasing their projects step by step as they are developed covering both successes and failures, or showing their troubleshooting techniques. Then we can all pitch in with ideas. I attempted to do this with my latest Roboton posts, though given the lack of responses, perhaps it was too hard for people to follow or they may even have found the posts annoying and just skipped them
1) What I do for all my projects is create a special directory which I usually call "build" but any name will do. This directory can only be specified when creating a new project and I haven't found a way to change it through the GUI afterwards. If you already have created the project then open the .xise project file with a text editor and search for "working directory" which will contain just an empty string in quotes like so "", change that to "build" and save it. The next time you open the project it will ask you if you want to create this directory and answer yes. From now on, all the junk during the build will end up in this directory. I think there was a while ago a post or perhaps an article on the papilio page discussing this, The recommended way to create a project directory structure was along these lines:
root / +-build +-doc +-source +-tools
Where "build" is the directory I mentioned above, "doc" contains project documentation, datasheets, useful references, etc, "source" (or "src" or "hdl" if you prefer contain the HDL source code of your project then "tools" can contain useful scripts for building parts of your project such as binary to VHDL converters to create ROM files or any other scripts or executables needed for your project.
2) You're right, even if your case statemnt covers all possible cases, you still get a warning during synthesis unless you have an "others" case (durrr!). If you just need "others" as a filler that does nothing I usually use "when others => null;"
3) Nothing wrong with that. Usually you do this if you're going to re-use that piece of code several times, then you turn it into a separate module. You can now include that module file into other projects that need a hex to 7seg decoder.
Corey Kosak
Hi folks,

I'd like to show off my first Papilio Pro project. It's not much by anybody else's standards, but I was quite excited to get to this point after only a couple of days, starting from zero knowledge. Mike Field's tutorial was awesome!

I hope that this is an appropriate use of this forum. I realize that others on the forum seem to be much more sophisticated.

The project continuously increments a 16-bit counter, then renders that counter on the LED display. The project has three components: one that does the counter, one that multiplexes the counter onto the display, and one that translates 4-bit hex nibbles into 7-segment values suitable for display.

I'm actually quite surprised that it worked without too much pain. I had to guess here and there. Here's a video: http://www.flickr.com/photos/15819666@N00/10388671913/

My .vhd and .ucf files are attached. I called the top-level file "Beef" because it was displaying 0xBEEF in the earlier stages of the design.

I also had a couple of questions if you don't mind.

1 - I notice that the software spews out a huge number of files into my working directory. Is there a way to cleanly separate my source files from all these tool-generated intermediate files? An analogy in the C++ world is that I'd like to keep my .cc, .h, and Makefiles in a separate place from the .o and executable files. This makes for easy management with version control and also easy sharing (there's no point in checking in or sharing all these tool-generated intermediate files). What do other people do here?

2 - In a case statement (such as that in SevenSegMultiplexor.vhd) I tend to need a line like ``when others => ENABLES <= "XXXX";'' I was staring at the 9-valued logic page in Wikipedia and I couldn't decide whether I wanted "XXXX", "WWWW", "UUUU", or "----" here. I actually would have guessed "----" meaning `don't care` but XXXX seemed to work without complaint. Which is the most appropriate?

3 - I could have inlined HexTo7Seg inside SevenSegMultiplexor but I liked the way it looked as a separate component. Is this a reasonable thing to do?

Any advice would be greatly appreciated. And thanks! I've had a fun weekend!
View attachment: counter project.zip
I decided to also port the Demon 3.07 verilog code to Papilio_One. This version is identical to the code running on the OpenBench Logic Sniffer board except for using 32MHz oscillator and using serial@115200 instead of SPI. It supports both meta data and input pin data query.
The full XISE project can be found here:
250K and 500K bit files are attached.
Let me know if you notice any strange behavior.
View attachment: logic_sniffer_P1_250K.bit
View attachment: logic_sniffer_P1_500K.bit
Hi, I've been playing with my ppro, and have got it talking to an old laptop lcd I had. I was amazed at how easy this was, so I thought I'd post a few pictures and some code. So far it draws a picture of yoshi (stored in rom), and animates a square that grows as it moves. Not very impressive, but I feel like I've laid the groundwork for my next experiments. Most of the hard work was done by this guy: http://g3nius.org/lcd-controller/ The code I modified is here: http://www.filedropper.com/lcd-driver
The yellow cable is just the original cable that would plug into the motherboard, wrapped in heatshrink for strength, with the 4 differential pairs plugging into C8-C15 (You can't plug this into any port, not all of them have a full set of differential pins for LVDS). The black circuit board is a 3.3v step down converter to power the lcd electronics. The brown one is an inverter for the cold cathode backlight (I broke the original by shorting the HV to something). The fan is there because I'm overvolting the inverter (18v instead of 12v), and it gets a little warm without.
Anyways, this is a great way to get a basically free video display, since discarded laptop lcds are really easy to come by.

I've just done something similar with an old Epson EG2401 display. It doesn't really have enough pixels for Lena, and a single dual-port block RAM suffices as the frame buffer. I made a buffer board to produce 5V logic for the LCD (using 74AHC541s) and used a MAX232 to generate the needed negative voltage.
I'd already done this with an AVR, and was able to get reasonably good grayscale by only setting lighter pixels for some fraction of updates. I might try that as my next step here. Avoiding flicker does require "overclocking" the display a good bit past what it was rated for, mine seems very tolerant of such abuse (I only started getting glitches when I gave it a 32 MHz pixel clock with the FPGA controller).
Source code: https://github.com/cjameshuff/vhdlstuff/blob/master/sed11x0_lcd.vhd

Matt Ownby
Original forum thread.
Ok, I've got a v1.0 release of working code now at 50 MHz!
Many thanks to Hamster for the help!
You can find the code (with readme) here: http://www.rulecity.com/browsetmp/sd_card_writer-17Feb2013.7z
Please feel free to suggest improvements to the stupid bone-headed newbie VHDL mistakes I make!
VHDL SD card writer v1.0
By Matt Ownby (http://www.daphne-emu.com and http://www.laserdisc-replacement.com)
16 Feb 2013
This is VHDL code (for the Papillio One FPGA board) that shows how to write to an SD card in a high-speed mode.
- Uses 4-bit SD mode, not 1-bit SPI mode (faster)
- Uses 50 MHz "high speed" mode, not 25 MHz "normal speed" mode (also faster)
- Logs to Papillio USB serial port (230400 bps) so you can see what is going on
- An SDHC card (older probably won't work) that supports high-speed aka 50 MHz mode.
How to use:
- Get the pins of an SD card (or adapter) somehow connected to Papillio pins. Not discussed here as you are expected to have enough expertise to figure this out on your own
What you will see on serial port (230400 bps) if everything is working correctly (this is very terse since string handling is a pain in VHDL):
Explanation of above data:
"-" gets sent on reset, it means the process is starting over
"C00" is the reset command sent to the SD card. It expects no response.
"C08" is the voltage-request command and is only supported on newer cards. The Papillio requests normal 3.3V operation. If I/O is not working, or if the SD card does not support this command, this is the last line you will see.
"C55/A41" is the init command. It usually needs to be repeated over and over again until initialization is finished which is normal.
"C02" is the "get SD card CID" command. It is required otherwise I wouldn't bother sending it.
"C03" is the "get SD card's relative address" command. It is also required.
"C07" puts the SD card into transfer mode.
"C55/A06" switches the SD card from a 1-bit bus into a 4-bit bus (4x speed increase).
"C06" switches the SD card from 25 MHz mode to 50 MHz mode (2x speed increase). If you see an "E" after this, it means that the CRC check failed (this happened to me occasionally during development).
"C24" starts writing a single 512 byte block at address 0 (beginning of card).
"C13" requests the card's status and is optional but it makes me feel better to see it working since at this point we are communicating at 50 MHz.
"S" means 'success' and means that the SD card responded that the write operation was completely successful. If you see an "E" here it means that the CRC check probably failed.
If you see anything with "X" in front of it, it means that an unexpected response was received and the unexpected response has been dumped out in ASCII hex format. This is for troubleshooting purposes.
I had a copy of Lady Bug written by Arnim Laeuger, that I downloaded from fpgaarcade a long long time ago and forgot all about it. I recently came across it and I spent a little time getting it going for the Papilio. Unfortunately it won't fit on a Papilio One, it uses about 28 BRAMs and the Papilio One doesn't have any external memory and not enough internal memory.
Good news is, it will fit entirely into a Papilio Pro or any Spartan 6 FPGA without needing any external RAM or ROM. Getting this ported to the Papilio was just a matter of writing a top level module to connect the ladybug machine to the various ROMs and input controls. This is the first time I've finally used a PS2 keyboard controller from here which appears to have a well written bidirectional PS2 controller. Bidirectional means that when you hit for example the caps lock key, the PS2 controller detects that and sends data back to the keyboard to turn on the caps lock LED. The key mapping I chose can be easily changed if you look in the source code and have a handy PS2 key code reference. As is, the game should be playable with the arrow keys.
A small issue, if you have your monitor tilted one way to get other games like Pacman showing correctly, then Ladybug will appear upside down. If you can tilt the monitor the other way, you're all set, if however you can't and just reverse the state of the flip_screen_g variable, the screen will appear at first glance to be correctly flipped but unfortunately only the background is flipped, the sprites and key mapping are not, so, for example, Ladybug will appear to move the wrong way, won't line up with the corridors, eating the dots on one side of the screen causes the dots on the opposite side to disappear, etc.
Currently three games are supported: Ladybug, Dorodon (a Ladybug like clone) and Cosmic Avenger (a Defender like clone). I haven't searched what other ROMs the original hardware supported, if any.

The source code is available here. To make it all work, download the source then download and place the game ROMs into the appropriate ROMs folder. See the readme file in each folder for a list of the files and checksums you should be looking for, If you're on Windows, run the make_roms batch file in the relevant game rom folder. Game ROMs will be converted to vhdl files in the build directory. If you're on linux, there appears to be a makefile based system for creating ROMs and other files in the hex folder, seemed to work for me in MinGW, but I use Windows primarily. Once the ROM files are converted to VHDL, run the ladybug_papilio.xise project in the top directory and synthesize then upload to your board. You need a Papilio Pro with a Arcade Megawing and a PS2 keyboard in port "PS/2 B", VGA and audio connected. Enjoy!
Jack Gassett
We've been working on porting a stepper control core to work as a wishbone peripheral on the ZPUino. To help us out with this process Alvie put together a really cool wishbone testbench that lets us simulate the core by manually writing to the wishbone registers. This is a very lightweight solution that lets you verify your wishbone peripherals without the overhead of simulating or synthesizing the full ZPUino Soft Processor!
The code is located on github.
Original forum thread here
Happy Holidays to all. I had a little bit of free time so I sat down and managed to get Pengo running based on the Pacman implementation by Mike Fields. The video below is a quick demo of the game running on a Papilio Pro (well Plus, but close enough). It uses no additional external RAM or ROM, so any Spartan 6 hardware will do. I'm afraid the sum of all game memories won't fit on a Spartan 3E though.
The Pengo hardware is very close to the Pacman hardware but annoyingly it has just enough differences that you can't just run Pengo on Pacman hardware. The video, sound, input control registers, watchdog, etc are all at different addresses compared to Pacman as well as the fact that the ROM is twice as big as Pacman's and to make matters worse the Pengo ROM is scrambled, so I had to implement an on the fly ROM descrambler based on the MAME source code.
The game runs as is, though there are still a couple of internal connections that remain to be made. Once I tidy up the code a bit I'll upload it somewhere and post here with a link.