Popular Content

Showing content with the highest reputation since 08/06/2012 in all areas

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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!
  8. 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
  9. 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;
  10. 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
  11. 2 points
    3 bit of green, 3 bit of red, and 2 bit of blue. http://en.wikipedia.org/wiki/8-bit_color
  12. 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
  13. 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!
  14. 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.
  15. 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.
  16. 1 point
    Hope it all goes well in San Jose
  17. 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.
  18. 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
  19. 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.
  20. 1 point
    i was thinking Papilio Blocks or something similar.
  21. 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
  22. 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
  23. 1 point
    Is it possible to enable Tapatalk for this forum? (an easy to use, nifty mobile client)
  24. 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/
  25. 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