Popular Content

Showing most liked content since 08/06/2012 in all areas

  1. 3 points
    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! This post has been promoted to an article
  2. 3 points
    Hmm, this is something I started myself a while ago. One of the problems with extending the AVR softcore is that it just didn't seem to be built for a peripheral rich setup (IO space, etc). But I didn't want to leave an open source GCC based solution. Which is why I've watched the ZPU work with interest. I recently tried to use a quadrature interface from opencores, but it was far too featureful and resource heavy. So instead, I created my own "simple" quadrature interface for the ZPU, and using the standard HD44780 code in the ZPUino IDE install, created a sketch to read the quad counter and write to the LCD. It is so very nice to read a quadrature encoder as simply as: unsigned int y=REGISTER ( IO_SLOT (8) ,0); Serial.println(y); And to know that it is being clocked at 96Mhz. (Of course, I most probably have created a piece of junk, full of bugs - but I think it's cute) The code's a complete mess, but if you're interested... it's attached. View attachment: ZpuQuadDec.zip
  3. 2 points
    Hi all, over the last half year I have implemented a processor and surrounding SoC bringing the RISC-V ISA (http://riscv.org) to the Papilio Pro. It implements the 32Bit integer subset (RV32IM). The project is hosted on Gitub (https://github.com/bonfireprocessor). It still needs some additional documentation, cleanup and ready-to-run ISE projects to make it easy reproducable for others. But I post this link now, to find out if anybody is interested in my work. I will soon also post a bitstream here so anybody with access to a Papilio Pro can play with it. I have also ported eLua to it http://www.eluaproject.net @Jack: If you like I can also present the project in the GadgetFactory blog. Regards Thomas
  4. 2 points
    Original version of game was running on PIC18F6622 and Dingoo A320. Now it's running on Papilio One 500K + Arcade Megawing. I've used the ZPUino soft processor which is realized by Xilinx Spartan-3E FPGA. VGA signal is also generated by the FPGA. The game can be played with integrated buttons of Arcade Megawing or with Atari/Commodore joysticks. I've used a QuickShot II Plus (SVI-102 Plus) joystick in the video below: Demo Please, use the .bit file included in the ZIP. Otherwise buttons and joystick are not working properly. sometris_v121.zip
  5. 2 points
    Hi, I just got started with Papilio Pro last week (side note: Great work with the papilio family and wings.. Im really excited about the board's potential). The Pro was my first entry to the papilio line. I was mostly able to figure out how to get the board running and programming. But, many of the instructions/downloads on the papilio website are either outdated or directed towards Papilio One, so getting started took about 4 hours longer than I expected. I thought I'd put together a list of links and instructions for problems I encountered along the way so that perhaps others starting with the Papilio Pro could have something up-to-date (well, as of April 2013, that is): 1. Windows FTDI Drivers: I had some real trouble getting the Papilio recognized as both a USB and a virtual COM port. For my problem, the device was ALWAYS recognized on Windows-- even when I did not have the Gadget Factory drivers installed. And it never showed a virtual COM port. Troubleshooting suggests using a different cable, or editing the device properties. Apparently in my situation, the Papilio was recognized as an FTDI device first and was not using the Gadget Factory drivers. My solution: Download the FTDI CDM Uninstaller. Using FTDI's USBView utility, find the Device Vendor ID and Product ID. Use the CDM Uninstaller to uninstall the FTDI drivers for the Papilio. After plugging and replugging, Windows recognized a virtual COM port. I could also connect through putty and see the default ASCII table output which was apparently the factory default program. 2. Getting Started Bitfile: http://papilio.cc/index.php?n=Papilio.GettingStarted It appears as though the getting started website (as of April 5 2013) does not include the getting started bit file for Papilio Pro. In my beginner state, I assumed this website would have the materials I needed, so I fumbled around trying to use the Papilio One 500K bitfile. After a while, I realized it certainly doesnt make sense to try to use the Papilio One bitfile, especially since the Papilio Pro uses a completely different FPGA. I dont think I've found a replacement for the "Getting Started" bitfile for the LX9 yet. 3. Papilio Loader: As with the bitfiles, the Papilio Loader GUI on the Getting Started Page is out of date (it downloads v1.7). According to a forum discussion around December 2012, the Papilio Loader was modified to support the Papilio Pro. Download the Papilio Loader GUI specifically from the Downloads webpage (this should be version 2.1 or later): http://forum.gadgetfactory.net/index.php?/files/category/2-papilio-fpga/ 4. ZPUino Core and Loader: I think the official ZPUino download page is a little out of date for Papilio Pro. It looks like the papilio website ZPUino getting started guide is out of date too- It uses an old version of the IDE and does not include links for the Papilio Pro bitfiles. Instead a forum post indicates the RetroCade installer works with the Papilio Pro. So, to get the ZPUino to work, download the Retrocade Synth Windows Installer from the Download Page. Use the bitfile ZPUIno_SOC/zpuino-1.0-PapilioPro-S6LX9-RetroCade-1.0.bit to program the Pro. The installer should also include a version of the Arduino GUI which includes a board option for ZPUino on Papilio Pro (LX9). 5. Intro to FPGA Book: With a functioning Papilio Loader and a ZPUino core/ GUI, I was basically good to go with the Intro to FPGA E-book. I also installed the Xilinx toolchain as instructed. No issues there. I'm looking forward to generating and programming with my own bitfiles shortly. It would, however, be nice to have an updated Xilinx webpack quickstart page: http://papilio.cc/index.php?n=Papilio.XilinxISEWebpackQuickStart. EDIT: I installed the wrong Xilinx tools at first. The default link inside the Intro to FPGA E-book now leads to the Xilinx Vivado suite, which doesnt support the Spartan 3 or Spartan 6 series. Instead, make sure to download and install the ISE Design Suite. 6. Papilio Arcade: I also tried the papilio arcade wing. Just make sure to download the correct LX9 bit files from the github https://github.com/GadgetFactory/Papilio-Arcade I havent looked at the AVR8 softcore processor. This is on my list to test with the Papilio Pro, along with some other fun things (SoC editor is on the horizon too). Like I said, Im a big fan of the board. Overall, it looks to be a really great FPGA. I do want to see the usability/ learning curve get to the Arduino level, and it helps to have a good getting started procedure for all boards. Hopefully this helps another beginner in the same situation. Thanks for all the work so far! EJ
  6. 2 points
    Or any other Xilinx FPGA board with an FTDI chip with MPSSE-engine connected to the JTAG pins (like Pipistrello but not Mojo or Saturn). This is using the xilinx virtual cable driver. Playtag is written by Patrick Maupin. Steps: 1) you need python 2.7 installed. Get it here:http://www.python.org/getit/ 2) unzip the attached zip file playtag.zip somewhere on your computer 3) open a cmd-window and cd to <playtag>\tools\jtag 4) connect your Papilo board to the computer 5) type xilinx_xvc.py ftdi, this will report the available FTDI ports.You should see the A and B ports of the Papilio board (see image). 6) type xilinx_xvc.py ftdi 0, this will start the xilinx virtual cable server on the A port of the Papilo board 7) you can now use impact and chipscope etc. by selecting the xilinx_xvc plugin. Use this plugin settings: xilinx_xvc host=localhost:2542 disableversioncheck=true See attached images and zip file. Do a google-search for xilinx_xvc for more info on how to use the virtual cable driver. Magnus playtag.zip
  7. 2 points
    I have the J1 CPU running on the Papilio Duo. It runs a standard 32-bit ANS Forth, communication is through the UART. It is working quite well; in fact I used it to run my slides for a presentation last week (slides were on microSD, buttons and VGA output from the Computing Shield). Is anyone interested in giving it a tryout? Let me know if so and I will put together a release. Thanks! J.
  8. 2 points
    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 Download: Quadrature_decoder.zip
  9. 2 points
    Once you get it gojng, rather than using a sine wave, why not try a GPS gold code? ( or something similar to one) It is a pseudo random bit stream that is quite long. When you correlate with an external signal you can get a really precise phase lock. This time to phase lock is what gives the long time to first fix of a GPS as it trys all the different alignments, but once locked it is very solid, even though the power levels of the signal is well below the noise floor and mixed up with all the other GPS birds. By having g a real time clock on the GPS the time to first fix is improved as the GPS knows where to start hunting. Also, I believe that most GPS units have a one bit DAC, so maybe a bandpass filter and to compare against the long term average is all you need?
  10. 2 points
    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! This post has been promoted to an article
  11. 2 points
    There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle. Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.
  12. 2 points
    Hi, not every pin can function as clock input. See here http://www.xilinx.com/support/documentation/user_guides/ug385.pdf page 30, search for "GCLK" in the name. Now did you know that there are PLLs inside the FPGA? It takes 2 min of work (maybe a bit more if you do it the first time) to run the core generator and turn the existing 32M clock into 20 MHz or whatever you like. It's one of the most useful features, IMO, in everyday use.
  13. 2 points
    ever heard of "paralysis by analysis"? My advice still stands: Don't try to buy the "best" or the "right" board. Just get any cheap board, spend two working weeks and learn to make that LED blink.
  14. 2 points
    Well after finishing this mini project I was very sad because the Double Dragon only has a handful of (not really that great) songs it can play over the YM2151 chip. I started looking around "teh nets" for more YM2151 music and eventually I arrived in Japan so to speak. I guess since Yamaha is a Japanese company it makes sense that it was adopted as the chip of choice on local computer systems. One such very popular system is the Sharp X68000 which as the name suggests, is based on a 68000 CPU. The cool thing about this system is that it has vast amounts of music created for it, here is a hard disk image with over thirty thousand music files on it. The music is in an MML (Music Macro Language) format and typically has an extension of .MDX In fact there are two types of files, .MDX and .PDX and after a fair amount of looking into these formats it turns out that while the MDX files are the Music Macro files, the PDX files contains sampled sounds that can accompany the melodies produced via FM modulation through the MDX files. In fact the PDX files contain 4 bit ADPCM data and they could be directly feed into a chip such as the MSM5205. Another cool thing is that some very nice people have written and open sourced an MML parser that can read MDX/PDX file combos and play them via a software implementation of the YM2151 chip and some generic ADPCM decoder. It is at this point that my other post comes in. With such vast amounts of YM2151 music it was only fair to find a way to play them, so I took the source of the MML player and carved out the software YM2151 implementation (which was in fact copied from MAME's implementation of the YM2151) and only left the calls to initialize the chip and write to the registers. I then had the initialization call simply pulse the reset line to the chip while the write register calls the FTDI functions to transfer the register data to the FPGA which in turn writes it to the real chip. The result can be seen in this 4 minute video. Hope you enjoy it! If the embedded video shows in portrait mode (tall and narrow) click on the youtube logo in the bottom right corner of the video and it will show properly in landscape mode.
  15. 2 points
    Hi, I've got my SDRAM controller up and running on the Papilio Pro as well as the Logi-Pi. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller It is running at 96MHz, but as it currently does the full "row open, read or write two words, close row" cycle for every memory access it isn't too fast. However, 24MB/s is more than fast enough if you have any audio projects in mind... flanger, delay, chorus, reverb etc Maybe somebody will write a nice roomy reverb for on the RetroCade?? 8MB is enough for 43 seconds of 48k/16bit audio. That gets you an awful lot of reverb!
  16. 2 points
    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: http://www.saanlima.com/download/Papilio_One/Papilio_One_OLS_3.07.zip 250K and 500K bit files are attached. Let me know if you notice any strange behavior. This post has been promoted to an articlelogic_sniffer_P1_250K.bit logic_sniffer_P1_500K.bit
  17. 2 points
    A friend of mine found a junked Hitachi LCD and gave it to me to see if I could get it going. The LCD is an older type, monochrome low resolution. I couldn't find a datasheet for it or pinouts so I went old school and tracked down datasheets for the chips on board and did some reverse engineering of the schematic using a continuity meter. A very good datasheet resource is the "Hitachi LCD Controller Driver LSI Data Book" which is a compendium of a large number of Hitachi LCD controller chips. According to the datasheet, the large chips on board are six HD61200 column shifters (IC3,4,5 and IC 6,7,8) and two HD61203 row shifters (IC 1,2). The unpopulated footprint is is a little weird with some missing pin traces (the one trace gaps on the short edge of the chip) and one less pin on one side of the chip compared to the other side. This footprint matched exactly the footprint of the HD61830 controller chip. The last unpopulated footprint of IC12 should be a SRAM chip for the IC11 controller. The LCD has one 20 pin set of connections that just go to the unpopulated IC11 controller chip. It also has a 10 pin edge connector that connects to the outputs of the IC11 controller and the inputs of the row/column shifters. It appears the PCB was designed to work in both a smart mode (with controller) and a dumb mode (no controller) hence the two different connector options. Because the controller chip was missing, I realised immediately that this LCD could not be driven in a static mode, where you just write data to the LCD internal memory and you can leave it alone to display that data. Instead this LCD would be more like a VGA display where you must constantly send data to it to refresh the picture. The 10 pin connector pinout is:1 to pin 47 IC11 D1 - pin 42 (DR) IC 3,4,5 (upper half of screen)2 to pin 10 IC11 FLM - pin 50 (DR) IC 1,23 to pin 5 IC11 MB - no connection4 to pin 11 IC11 CL1 - pin 52 (CL2) IC 1,2 and pin 37 (CL1) IC 3,4,5,6,7,85 to pin 46 IC11 CL2 - pin 40 (CL2) IC 3,4,5,6,7,86 to pin 48 IC11 D2 - pin 41 (DL) IC 6,7,8 (lower half of screen)7 to pin 29 IC11 VCC (+5V supply)8 to pin 20 IC11 GND9 to TR1 Collector (LCD bias -10V )10 to TR1 Base (LCD bias enable, contrast?) The internal chip to chip connections of the column shifters match those from the datasheet as below. Essentially each column shifter can address 80 columns and three of them are chained together to form a 240 column shifter. There is one set for addressing the top half of the screen and another set for the bottom half of the screen. The two row shifters IC1 and IC2 then select one of the 64 rows to be addressed. Together these two chips can address 128 rows but because their inputs are connected together they address the entire screen (both top and bottom of screen simultaneously) so the entire screen is refreshed in 64 cycles. In cycle 1, row 1 and row 65 are selected and a line is drawn through the top and bottom column shifters, in cycle two row 2 and row 66 is selected, etc, through to cycle 64 where row 64 and row 128 are selected. So the LCD has a resolution of 240x128 but can be throught of as two independent 240x64 areas stacked together. Input D1 sends serial pixel data to the top half of the LCD (top column shifters) and D2 to the bottom. CL2 is the LCD master clock which can go up to 2.5Mhz according to the datasheet. CL1 is the signal that latches data from the shifter outputs to the display registers, MB pin is not connected to anything and FLM is the input to the row shifters. At the start of each frame a 1 is shifted into the row shifters through FLM then zeroes are shifted for the remaining 63 cycles. This way a single bit travels through the both top 64 and bottom 64 rows selecting one row at a time in each half of the screen. Once I understood the basic function of the shifters I decided to hook it up the a Papilio One FPGA as the ideal driver hardware. Please note that the LCD panel runs off 5V whereas the FPGA outputs are 3.3V, however since the LCD does not output signals to the FPGA, it is quite safe to drive the 5V LCD inputs with 3.3V from the FPGA without using level translators. I decided to display a picture on the LCD and I picked a dithered bilevel picure of Lena. I cropped it to 256x128 resolution so it can be easily stored and displayed to the LCD without performing additional math. If I had stored the picture in its more compact 240x128 native LCD resolution I'd have to convert the LCD vertical and horizontal coordinates to ROM addresses via some math such as address = v + h*240 whereas by storing the picture as two ROMs of 256x64 bytes the v counter can directly index ROM address lines 10..5, the top bits of the h counter can index ROM address lines 4..0 and the bottom three bits of the h counter index a bit within the currently addressed ROM byte. The top half 256x64 of the 256x128 picture is stored into one 8x2K RAMB and the bottom 256x64 of the picture into another 8x2K RAMB. The reason for using two separate RAMBs is because the top and bottom of the image is shifted simultaneously so both RAMBs need to be accessed simultaneously. Another way of doing this would be to create a 16x2K memory and use 8 bits for the top and 8 bits for the bottom, or a 8x4K using 4 bits for top, 4 bits for bottom but any of these schemes would require the original image to be preprocessed and interlaced accordingly. The final code to drive the LCD ended up being very simple and is shown below. One last thing to mention is that initially I got no picture at all. After of course simulating the design to make sure the signals produced are correct and then examining the final design running on the FPGA with an oscilloscope, I saw that while the inputs to the chips had valid signals, all the outputs of the row and column drivers were sitting at 5V instead of toggling. After refering to the datasheet again I realised that these drivers need a negative Vee voltage in the range -7v to -17v. This would normally be connected to the collector of transistor TR1 and the base of TR1 could adjust the amount of voltage let through the transistor forming a contrast adjustment. Since I didn't have a handy negative supply I simply soldered a 9V battery in reverse, with the positive to the system ground and the negative directly to the Vee (emitter of TR1). This then provided the necessary negative bias to allow the LCD to display a picture. The contrast is fairly low due to the 9V battery not supplying the ideal bias voltage, I guess -12V would have been better. -- Driver for LCD type LMG6351PLYR, 240x128 resolution, monochromelibrary ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all;library unisim; use unisim.vcomponents.all;entity lcd_top isport ( RST_I : in std_logic; -- active high reset CLK_I : in std_logic; -- master clock -- D1_O : out std_logic; -- data to top half of lcd column shifter D2_O : out std_logic; -- data to bottom half of lcd column shifter CL1_O : out std_logic; -- clock CL2_O : out std_logic; -- latch display data FLM_O : out std_logic; -- row drivers input MB_O : out std_logic -- not used);end;architecture RTL of lcd_top is signal rst : std_logic := '0'; signal clk : std_logic := '0'; signal cl1 : std_logic := '0'; signal cl2 : std_logic := '0'; signal d1 : std_logic := '0'; signal d2 : std_logic := '0'; signal flm : std_logic := '0'; signal mb : std_logic := '0'; signal bits_top : std_logic_vector( 7 downto 0) := (others=>'0'); signal bits_bot : std_logic_vector( 7 downto 0) := (others=>'0'); signal mainctr : std_logic_vector( 3 downto 0) := (others=>'0'); signal hctr : std_logic_vector( 7 downto 0) := (others=>'0'); signal vctr : std_logic_vector( 5 downto 0) := (others=>'0');begin -- input assignments rst <= RST_I; clk <= CLK_I; -- output assignments FLM_O <= flm; CL1_O <= cl1 and (not cl2); CL2_O <= cl2; D1_O <= d1; D2_O <= d2; MB_O <= mb; -- divide main 32Mhz clock by 16 to get 2Mhz clock clk_inst : process(clk) begin if rising_edge(clk) then mainctr <= mainctr + 1; end if; end process; -- 2Mhz clock (max 2.5Mhz per datasheet) cl2 <= mainctr(3); -- horizontal counter hctr_inst : process(cl2, rst) begin if (rst = '1') then hctr <= (others=>'0'); elsif rising_edge(cl2) then if hctr = 239 then hctr <= (others=>'0'); else hctr <= hctr + 1; end if; end if; end process; -- vertical counter vctr_inst : process(cl2, rst) begin if (rst = '1') then vctr <= (others=>'0'); elsif rising_edge(cl2) then if vctr = 64 then vctr <= (others=>'0'); elsif hctr = 239 then vctr <= vctr + 1; else vctr <= vctr; end if; end if; end process; -- generate CL1 (display data latch) cl1_inst : process(cl2) begin if falling_edge(cl2) then if (hctr = 239) then cl1 <= '1'; else cl1 <= '0'; end if; end if; end process; -- generate FLM flm_inst : process(cl2) begin if falling_edge(cl2) then if (hctr = 239) and (vctr = 0) then flm <= '1'; else flm <= '0'; end if; end if; end process; -- image data shifters bit_inst : process(cl2) begin if rising_edge(cl2) then case hctr(2 downto 0) is when "000" => d1 <= bits_top(7); d2 <= bits_bot(7); when "001" => d1 <= bits_top(6); d2 <= bits_bot(6); when "010" => d1 <= bits_top(5); d2 <= bits_bot(5); when "011" => d1 <= bits_top(4); d2 <= bits_bot(4); when "100" => d1 <= bits_top(3); d2 <= bits_bot(3); when "101" => d1 <= bits_top(2); d2 <= bits_bot(2); when "110" => d1 <= bits_top(1); d2 <= bits_bot(1); when "111" => d1 <= bits_top(0); d2 <= bits_bot(0); when others => null; end case; end if; end process; -- top and bottom of screen image ROMs ROM_TOP : entity work.ROM_TOP port map ( CLK => clk, ENA => '1', ADDR (10 downto 5) => vctr, ADDR ( 4 downto 0) => hctr(7 downto 3), DATA => bits_top ); ROM_BOT : entity work.ROM_BOT port map ( CLK => clk, ENA => '1', ADDR (10 downto 5) => vctr, ADDR ( 4 downto 0) => hctr(7 downto 3), DATA => bits_bot );end RTL;
  18. 2 points
    I've just finished my 8 digit frequency counter - I'm just waiting for a GPS module to arrive so I can use it as the reference timesource. Here's a block diagram of the project: And here is a photo of it in action, when using a one pulse per second generated from the local Xtal as the reference. Full source is up on my wiki at http://hamsterworks....equency_counter This post has been promoted to an article
  19. 2 points
    3 bit of green, 3 bit of red, and 2 bit of blue. http://en.wikipedia.org/wiki/8-bit_color
  20. 1 point
    Hi all, I know it will sound stupid, but anyone knows if I have to enable something in ISE (14.7) to get the symbol manager? I followed the tutorial on the learning site but, after I loaded the example project, the Tools dropdown ends with "Smart Xplorer" and there are no other options as on the screenshot..... Where am I missing the point? :-D Thanks!
  21. 1 point
    You will need to eventually filter those, and also do some clock domain crosssing. All depends on exactly what you want to do. Simulation and real-world differs a lot when the IO pins are used. Care to share more information ?
  22. 1 point
    I finally got to a computer and was able to download your original file and can see some of your problems. 1) You declare the VGA signals correctly in the top level entity on lines 15-17 as std_logic_vector but on lines 26-28 you need to keep VideoR, VideoG and VideoB as std_logic, not std_logic_vectors. This will fix the errors that come up on lines 88, 90 and 93 during synthesis. Change lines 26-28 to this: signal VideoR : std_logic; signal VideoG : std_logic; signal VideoB : std_logic; 2) On line 46 do connect the signal VideoR to each bit of the O_VIDEO_R like this: O_VIDEO_R <= VideoR & VideoR & VideoR; Do the same for the other two colors: O_VIDEO_G <= VideoG & VideoG & VideoG; O_VIDEO_B <= VideoB & VideoB; -- only 2 bits. That should get you through synthesis. Now for the Place & Route, you need to make sure you have the correct signal names in the ucf file. You need to uncomment (remove the leading #) and match the names to the names on your top level entity. For example on the nexys3_master.ucf you need the change line 156 to: NET O_VIDEO_R<0> LOC = "U7" | IOSTANDARD = "LVCMOS33"; do this for all the signals on your top level entity. I think that will get you through all the problems I can see.
  23. 1 point
    Yeah, I can see that. I don't know exactly what's causing the error but my guess is: That 'video_ram' was meant for the Spartan-3 FPGA found in the Papilio One board, and not the Spartan-6 FPGA you're building it for. A lot of Verilog or VHDL code is portable, but some things which use vendor primitives might not be. And it looks like video_ram is one of those; see "https://github.com/thelonious/vga_generator/blob/master/vga_text/ipcore_dir/video_ram.v". I see two options for fixing it: (a) Use Xilinx's core generator to make one that will be suitable for Spartan-6; or ( write one which can be inferred and therefore will be more portable. I would usually choose ( but I'm afraid neither (a) nor ( is really easy. (a) is explained in chapter 15 of the eBook linked here: http://forum.gadgetfactory.net/index.php?/page/articles.html/_/papilio/logicstart-megawing/intro-to-spartan-fpga-ebook-r34
  24. 1 point
    And we were able to do a full simulation of the system, so we can find bugs on it.
  25. 1 point
    @Sid, From playing with my, albeit broken, case, I believe the o-rings go between the bottom later and the board to keep any PTH pins from getting bent.
  26. 1 point
    I recently got a few of these http://www.ebay.com/itm/251605148131? The generic modules are nice for things that only have a few pins where taking an entire wing socket seems a little wasteful. They're versatile too since they're breadboard friendly and work with any micro or FPGA dev board.
  27. 1 point
    Ok, first a few definitions: USB High-speed = 480 Mb/s transfer rate -> this is what you want USB Full-speed = 12 Mb/s transfer rate USB Low-speed = 1.5 Mb/s transfer rate Most boards (like Arduino, Papilio One, Papilio Pro, Mojo) only has Low-speed or Full-speed USB I/O so not good for your application. The most common way to get USB High-speed device support is to either use an FTDI FT2232H chip or a Cypress FX2 chip. Cypress FX2: I have very limited experience with the Cypress FX2 chip so others might have to chime in here. The aes220 board above uses the Cypress FX2 chip so that sounds like a good candidate. There are many other boards that's uses the FX2 for USB (like Opal Kelly XEM6002, boards from KNJN and many more). Just do a google search on "FPGA FX2". FT2232H: To get the max data rate (~28 MB/s) from the FT2232H chip you need to use synchronous FIFO mode which is only available on the A port, but most boards with this chip (like Papilio DUO, Pipistrello, Saturn and miniSpartan6+) uses the A port for JTAG so no Synch FIFO mode. Pipistrello, Saturn and miniSpartan6+ have the B port hooked up for async FIFO mode, this will get you at most 9 MB/s. Papilio DUO only has the B port MPSSE signals hooked up to the FPGA so at the most you can get is the 30 Mb/s MPSSE data rate on the DUO. The only board that I know of that has an FT2232H chip hooked up for Sync FIFO mode is the version 1 of the Pipistrello board, it can do 28 MB/s transfer rate. Another alternative is to get a board with USB 3.0 support (a.k.a. USB SuperSpeed) using the Cypress FX3 chip, like Opal Kelly XEM6310, it can do > 340 MB/s... Hope this helps, Magnus
  28. 1 point
    Just took a quick glance at the datasheet. I see 2 pins connected to the FPGA and the MPSSE needs 4. Am I missing something?
  29. 1 point
    That should work. The reason I ask about the direction is the way the FX2 works. The 8051 is too slow to transfer the bytes manually, so it must be configured to just forward everything from the USB port to the GPIO. I only ever set this up one and left it since I was doing one way communication (DVB streams). For two way the 8051 would need to reconfigure it to be an input at some point. Anyway its 10 years since I was familiar with this so you'll have to read the FX2 manual to check it will work. From the papilio duo side I think 16-bit @ 12-13MHz is not a problem.
  30. 1 point
    You have several defines you can use. On all boards, ZPU is defined. On 2.0 boards, ZPU20 is also defined. You can also check for specific boards. Foe example, __ZPUINO_PAPILIO_DUO__ is defined in Papilio DUO boards, and __ZPUINO_PAPILIO_PRO__ in Papilio Pro boards. You can inspect platform.txt and boards.txt for ZPUino, as shipped in DesignLab, for more details: https://github.com/GadgetFactory/DesignLab/blob/master/hardware/zpuino/zpu20/boards.txt https://github.com/GadgetFactory/DesignLab/blob/master/hardware/zpuino/zpu20/platform.txt Alvie
  31. 1 point
    That's quite a laundry list of feature requests, you're probably going to have to tackle some of that yourself unless you can convince Hamster to work on it. With the exception of Jack, the people on this forum are not paid to work on this stuff and he's got his hands full with other things. You can get a free installation DVD from Xilinx if you don't want to download multiple gigabytes. For what it's worth, I started out with schematic design in ISE and quickly found it to be a waste of time. It's extremely tedious and circuits more complex than a handful of gates get unweildy. Additionally you end up with completely non-portable code that's difficult to debug or port to anything else. It's a good way to throw together a quick circuit to see the FPGA do something but in the long run you'll want to get a basic grasp on VHDL. For example the frequency counter, if you pick up a bit of VHDL you can modify it yourself to do anything you want without having to rely on others to add features to their hobby projects for you.
  32. 1 point
    USB host is hard because its a very complicated protocol you need to speak and the timings are tricky. USB slave is fair bit simpler, at least at the lower speeds. Simply using the USB connector is also not necessarily easy because on most FPGA boards it isn't wired to the FPGA directly in a useful fashion. The other problem for board choice and software is that Haider is in Iraq, and a lot of FPGA devices and software are on the controlled lists so export rules may be a problem (especially as the US enforces them its end with the 'shock and awe' scheme). Hamster: I assume you've seen http://jorisvr.nl/usb/, which only needs a UTMI buffer ? Alan
  33. 1 point
    Thanks Jack! My Kickstarter Papilio DUO Board Builder version is assembled! I have confirmed the power supply and FTDI 2232 are working. This weekend I hope to have time to check out the Arduino, FPGA, and SRAM! When I have it up and running I'll share assembly details and photos. Enjoy! Bill
  34. 1 point
    papilio-prog is not the same as xc3sprog. papilio-prog was forked off from xc3sprog way back and is using a different bscan file. I have attached a zip file with the vhdl source file as well as the ucf file for the qfp144 package. Hope this helps, Magnus bscan.zip
  35. 1 point
    If I was to approach this like developing an FPGA design, where rather than jumping all the way in the deep end and do everything at once I do things incrementally. How is this for a roadmap: 1. Papilio Technology Transition One (TT1) - End of life the Papilio One 250/500 and replace it with a TT1 without the SDRAM. - Keep Papilio Pro form-factor- Move to a four layer board - Add PMOD connectors at ether end of existing wing connectors. - Use 54-ball BGA footprint for the SDRAM, (try to make it compatible for DDR for experimentation) - Route differential pairs to wings - Implement USB interface changes (high B/W FIFO) - Add an additional four power pins between the high/low eight bit wings, giving a middle wing position. Benefits for GadgetFactory: - Build up four-layer PCB design skills - Build up BGA experience - Platform to prototype a DDR platform without using an MCB - decide after a few test boards to go DDR or not - Minimal schematic changes from existing Papilio Pro design - Rework on BGA SDRAM is far cheaper less risky than rework on the larger more expensive FPGA - More freedom for signal routing - EOLing the Papilio One design should reduce the number of configs stock and support (e.g. RMAs, new-user startup issues, EDA tooling) - If BGA proves a difficult nut to crack then you still get to update the PapOne and experience - Solves the eventual problem with Xilinx EOLing the Spartan 3E parts. - adding another 4 pins to the power rails replaces 6x4pin connectors with 4x12 pin connectors, maybe helping out with assembly Benefits for us end users: - Plug and play for the vast range of PMODs (maybe 40 or 50 devices) - Maybe twice the memory SDRAM bandwidth if DDR works out - All existing Papilio Projects should work with a UCF file update, unless they use the SDRAM - Better signal integrity due to more freedom in PCB design - Ability to use differential wings - Access to a higher speed USB host Interface- Removes a bit of the the Papilio One/Papilio Pro divide, as all are now Spartan 6 LX9 - Could use up to 6 PMODs and three 8-bit wings because of the middle wing position. - PMODs are more stripboard / protoboard friendly - MegaWings still work - Just like the Papilio Pro, but even better! 2. Papilio Technology Transition Two (TT2) - Physically same form-factor as the Papilio TT1. - Move to a BGA FPGA as well as BGA SDRAM - Add LX25 options - Wire for using the on-die MCB - use extra I/O and space on PCB for HDMI and uSD card Benefits for GadgetFactory: - No major technology changes - can focus on BGA issues - Leverage built up BGA experience on the TT1 - Minimal software changes required to support - Migration off of TQFP - they won't be available forever - Place Papilio Boards back above the competition Benefits for us end users (over the Papilio TT1): - On board HDMI, - On board uSD - Able to use the higher performance / more flexible MCB in designs - More FPGA logic (due to larger FPGA and use of MCB freeing up resources) You'll notice that I've dropped off the whole Arduino / AVR part of the design. Why? - Most modules/sensors I get require four or five jumpers and don't use the full shield form factor (eg Power + I2C + an interrupt). - PMODs cover nearly all of the Arduino Shields I could see being used. Sure, they cost a little bit more, but where else can you get a 4 channel 4.8 kHz 24-bit A/D converter for an Arduino that you can use for sensing ULF waves? Or an I2S DAC? - All Arduino wings and shields are made to be used by an 8 or 16 MHz MCU. They don't need the power of an FPGA to support them. Nearly any design that the FPGA enables can also be achieved with one of the new 80MHz ARM based Arduino. - You can't use an Arduino to drive HDMI, a high speed serial interface, a CMOS camera, a LVDS display, this is where you need wings or PMODs, and they don't need the Arduino headers - I sort of agree with Alex that moving to an FPGA+Arduino confuses things. If you jump over the Arduino fence I fear you will land in a pool full of sharks and alligators - I would hate to see the forum filled with "I have brand X shield, and it doesn't work right - can you help?" posts. At least with Wings and PMODs it gives a limited set of well known hardware with good documentation (well, some Digilent documentation is patchy in places) that people can leverage - I hate 5V-only Arduino shields with a passion. If you need to include Arduino to improve marketability then I think it is looking in the wrong direction. What you want to be doing is hitting products like the http://www.xess.com/shop/product/xula2-lx25. I think that the TT2 works because it is 'more friendly' than the 40 pin form factor as you can just plug in PMODS/Wings and play. It would also scores over the $230 Digilent Nexys3 in my book - I can use the I/O for what I want to use it for. Why would I want three different sorts of memory? Where is my HDMI? Where is my uSD card?
  36. 1 point
    oh I forgot all about the onboard atmega. That makes a very cheap ADC for those pins. I guess it costs about the same as a 8 channel ADC....
  37. 1 point
    I have been playing with porting DOOM to Pipistrello. The code is based on the work Janne Kulmala and Juho Järvinen did to port Chocolate Doom to the Altera DE2 board using the NIOS soft processor, however a lot of changes have been made by me to make it run on Pipistrello using Microblaze. Here is how to get the game up and running: 1) unzip the doom.zip file somewhere on your computer 2) copy the file doom1.wad to a uSD card and insert it in the Pipistrello sd-card socket. 3) connect a monitor to pipstrello via HDMI and a sound system via the audio-out connector 4) program the pipistrello board with the doom.bit file to flash (i.e. fpgaprog -v -f doom.bit -b bscan_spi_lx45_csg324.bit -sa -r) After loading the program from flash to dram the DOOM welcome screen will come up etc.and the game is then running in demo mode. To play the game a PS2 keyboard is needed, connected to Pipistrello using either the Digilent PS2 PMOD module (via the lower row on the PMOD connector) or the Saanlima NES/PS2 PMOD card. I will post the source code after I have cleaned it up a bit. Enjoy! Magnus Edit: I should add that this is still a work-in-progress - the sound/music is still not quite right but the game is very playable as is. Here is a link to a short video showing it booting up and running in demo mode: http://www.saanlima.com/images/DOOM.MOV doom.zip
  38. 1 point
    Mike, set the PLL's CLKFBOUT_MULT parameter to 25 and the various CLKOUT<n>_DIVIDE parameter to 8 and you get 100 MHz. 32 MHz * 25 yields an FB clock of 800 MHz. Pages 56/57 of the spartan 6 data sheet (ds162) give the min/max PLL operating range. Fvcomin is 400 MHz, and Fvcomax is 1000 MHz. If you feed the PLL 32 MHz and specify MULT=3, DIVIDE=1, you will be out of spec. BTW, the download link for your papilio pro zip file is messed up -- clicking on it leads to the message saying I don't have permission to upload that file!
  39. 1 point
    I've got some life and can write then read back the first 32 words of SDRAM @ 100MHz. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller No onward to find the optimal signal timing, and build a comprehensive test suite.
  40. 1 point
    I hope this doesn't breach any forum rules and I have no vested interest in the sales of this product but I remember a while back there quite a few people raving/drooling over Zynq boards but not able to afford them. It turns out now that Adapteva has met their funding campaign and will start shipping Zynq boards to fund contributors but will also accept pre-orders for the same $99 price for Zynq7010 boards, upgradeable to Zynq7020 (unknown price). For those not in the know, the Zynq7010/7020 combine a dual core A9 1GHz ARM CPU with Artix-7 level FPGA in a single package allowing one to combine the software programmability of the ARM core with hardware programmability of the FPGA core, letting you bolt on any custom hardware you care to design to the existing ARM cores.
  41. 1 point
    Hope it all goes well in San Jose
  42. 1 point
    Since I started digging though the Galaxian code yesterday, I couldn't just stop there so I ended up doing the following: The video on my monitor seemed to ride a little too high (in portrait mode) so I'd have to fiddle with the adjustments to center the picture. I got sick of doing that and replaced the scan doubler originally written by MikeJ or fpgaarcade with my own that I developed for my BombJack implementation. My scan doubler does a few things differently and more closely implements the VGA timing for the sync signals therefore the picture just ends up centered on the monitor without having to fiddle with buttons, in fact just reseting the monitor settings to factory defaults still ends up with a centered picture due to the scan doubler observing the correct front/back porch and sync signal polarity and duration. It also requires and generates composite blanking signals, see why below. In the process I also simplified the clock section and had it generate one additional 24Mhz clock which I required for my scan doubler, but more importantly that clock is required if you want to bolt on an HDMI output on the end of the scan doubler. The reason 24Mhz is required is because it is very close to the VGA standard 25.175MHz but also is an integer multiple of the 6Mhz that the game video runs at. To run an HDMI output you simply feed the scan doubler output into the DVID module that Mike Fields created. That module requires composite blanking signals as well as 24Mhz and 24*5 Mhz clocks to generate an as close as possible to VGA signal. This was tested successfully and it works. I didn't like how the top module of the project that was geared towards a Papilio board just contained all the game sub-modules. I think it is more proper to separate the game logic from the board implementation. As such the game module itself should be self contained, it should take as inputs some clocks and player controls and it should have as outputs the original video (not scan doubled) and sound. This game module can then be imported into a top level board specific module that then connects other stuff to the game module to make it work in a particular environment. Such add ons can be the scan doubler, a PS2 keyboard controller that is then converted to button presses and fed to the game module, the DACs, etc. So I went ahead and separated the game logic itself from the board specific bits and pieces. While trying to eliminate some warnings, I also ended up switching some negative logic signals to positive logic simplifying some code across several modules. Finally, some good stuff, the sound! I saw some complaints that the Galaxian was missing the right channel, sound effects. These include the ship explosion sound, the shooting sound and the background sound. Initially I looked at how the original author tried to implement this. He basically had three sampled sounds, one for each of the above sounds listed above and would just play the relevant sample as appropriate. These samples had been missing in the source and I couldn't find them on teh nets. I fired up MAME and recorded the background sound and the ship shooting sound but could not get a clean ship explosion as there are always other sound effects going on when the ship explodes. So I cheated and added a generic explosion sound effect. I down-sampled all of them to 11025Hz and added them to the game. Upon playing a test game I noticed that while the shooting and explosion sounds were OK, the background droning sound was just the static sample repeated over and over. The original Galaxian game actually plays that sound faster and faster as the game progresses adding a sense of urgency to the game play. I realized that just having this static sample would not do. I pulled out the schematic of Galaxian and had a look. The original hardware implements this sound with old fashioned 555 timer chips (no fancy sound generators here). Basically the CPU writes a 4 bit value to a 4 bit DAC implemented by latch 9M in the schematic. This is converted to an analog voltage by an 2-2R ladder and then feeds into a current mirror (transistors Q1 and Q2). This current mirror controls the first 555 timer labeled 9R. It causes it to generate a sweeping analog voltage, the sweep rate (how fast it sweeps) is controlled by the 4 bit A/D value from about once per second to ... um, really fast. This sweep voltage is fed to three other 555 chips, 8R, 8S, and 8T. Each of these is configured as an astable multivibrator and each is tuned to a different base frequency but the sweep voltage causes each of them to detune making each of them sweep across a range of frequencies. Essentially they are voltage controlled oscillators (VCOs). The outputs of these three VCOs are a set of square waves that combine together via resistors R24, R27 and R30 and are further filtered by C20, therefore this is a low pass RC filter causing the sharp sound of the square waves to be smoothed into the familiar droning Galaxian background sound. Each of the three VCOs is further controlled by lines FS1, FS2 and FS3 so each of them can be selectively enabled or disabled from producing sound. These lines were not connected in the original game source as they didn't have anything to control since the original author just played a static sample for the background. So what I did was implement a VCO module, that currently just generates a sine wave of a certain frequency based on an input value. I didn't want to bother with generating square waves and then passing them through digital filters, while that would have been a more faithful representation it adds complexity. So the VCO module it replicated three times and they are all controlled by a modulator that uses lookup tables to feed the VCOs their frequency based on the 4 bit A/D value generated by the game CPU. In practice, the game is much more realistic now with the background sound that changes cadence as the game progresses and becomes faster and faster just as the original Galaxian. The other sounds, the shooting and explosion are still just samples even though the original game implements them with discrete hardware. The explosion sound is a one bit digital noise that is passed through a low pass filter to create a the explosion noise. The fading volume of the explosion (starts loud and fades to quiet) is implemented via an analogue switch and a capacitor that discharges as the sound it played controlling the volume. The shooting sound is also a combination of a 555 timer chip 7S producing a base frequency which is modulated by the one bit digital noise after passing through an RC filter. The fading volume is also implemented by another analogue switch and capacitor. Implementing these two types of sounds in hardware is a bit challenging due to all the analogue electronics involved so for now we'll just have to put up with the two sampled sounds each consuming exactly 8KiB. I haven't uploaded the source anywhere yet as I'm still fiddling with it, if there is any interest I will share the last stable snapshot. Oh forgot to say, this of course means that other games using the Galaxian hardware will have these sounds, tested with Balck Hole so far.
  43. 1 point
    Just been giving the new bit file a run through - I think we're pretty much there, I've listened to a few tunes and I can't spot any obvious issues! Well done guys, mightily impressed with the coding and turnaround time on these issues! I've noticed also since the direct register writing fix, the timing seems to be better. I think previously all the unnecessary writing to ram and then copying to registers was slowing down the ZPUino player too much, seems to sound a lot tighter now. Just as an aside, although my primary interest is for a standalone SID / POKEY / YM MIDI synth module (a hardware version of Plogue chipsounds is basically what I'm after!), I'm wondering from the papilio arcade side of the house, is there a desire to produce a full C64 as an output - a full SID with filters is obviously a big (and most exciting!) part, the PLA/CIAs are dead easy though the VIC-II would take some work (although obviously there's other HDL out there already for that)? Well done guys
  44. 1 point
    I think it has been summed up fairly well here. The schematic entry is a great route for beginners and makes it dead easy to get something up and running. For a very visual person like myself, I found it to be an invaluable way to break the ice and familiarize myself with the tools and concepts. It is possible to implement fairly complex designs via schematic entry, but as has been said, it starts to get very tedious. What I've been doing is transitioning more and more towards VHDL, using a mix of the two methods. One of the really cool things about all this is that it's possible to almost seemlessly mix and match HDLs within the same project, since unlike a programming language, your code is describing the way hardware is wired up rather than executing instructions. Schematic is great for simple stuff like you would put into a small to midsized CPLD, but once you get to something that really utilizes a FPGA, you will quickly find that it gets unbearably tedious and unweildy. A pencil & paper to sketch and visualize the logic as you write the HDL code can be a lot less tedious than the schematic editor.
  45. 1 point
    i was thinking Papilio Blocks or something similar.
  46. 1 point
    The Papilio Plus sounded interesting but wasn't available when I started this project and did not have any of the needed interfaces on-board. The Avnet LX9-microboard was also a possibility but the limited user-I/O and the lack of HDMI on-board killed that idea. So the only option left was to make my own board - basically merging the fpga and LPDDR from the LX9-Microboard with the formfactor, wing interface and tool-set from Papilio, then adding all the needed interfaces on-board (and then some more to make it more interesting). The biggest challenge was the 324-ball BGA package which forced me away from the hobbyist PCB vendors (like Seeed studio and OSH Park) to the more traditional (and expensive) PCB vendors that offers the PCB geometry needed for this board (5 mil trace width/spacing, 8 mil holes, 4-layes). In my professional life I have used PCB Universe (http://www.pcbuniverse.com/) for many boards with great success and they have very reasonable prices and an on-line quote and ordering system so it's easy to place an order (disclamer: I have no business interest in PCB Universe, just a happy customer). The quote for this board was $450 for 50 boards, more than I like to spend but still a bargin compared to other options. So far all circuits on the board have been tested OK except for the USB host interface which really need Linux up and running first. The board came out perfect - no cuts or jumpers needed so far. Read more about the board features here:http://pipistrello.saanlima.com My plan is to make this an open-source project once all features on the board have been verified. Magnus Karlsson Saanlima Electronics
  47. 1 point
    The scramble.zip has the files from the list, not the .zips I ended up re-forking arcade blaster on github, did some small changes which hopefully Jack will pull into the main branch. having said that, here is the dat Papilio_Arcade_DAT.zip (works with romvault 1.7.7, didn't test cmp but should work there too) and here -link removed- merged into current on Github by Jack is my Games.xml, and associated images to add support for a few other Pac-Man variations/Hacks. Pac-Man (With Speedup Hack), Hangly-Man (Set 1, 2 3), Caterpillar Regards, //F// ps: no actual ROMs are included in my post (don't need to be spanked by jack, nor la policia) edit: Nice Raspberry Pi Still need to go find one
  48. 1 point
    Is it possible to enable Tapatalk for this forum? (an easy to use, nifty mobile client)
  49. 1 point
    I've just got DVI-D running on a Spartan 6, starting from scratch (well, the DDWG specs at http://www.ddwg.org/downloads.asp ) You can find the details of my project (incl all the vhdl source) here: http://hamsterworks....x.php/Dvid_test Feel free to use it in your own projects. Wonder if it will work on the Papilio Pro? Might have to butcher a cheap HDMI cable... Mike This post was covered on Hackaday too. http://hackaday.com/...m-vga-to-dvi-d/
  50. 1 point
    I can program SPI flash now via JTAG from ISE iMPACT, when it is configured as Part: S25FL064P Type: SPI PROM Data Width: 1 The flash itself is MX25L644E from Macronix (MXIC). Hope this info can save some time for someone else. Roman