Leaderboard


Popular Content

Showing content with the highest reputation since 10/02/2014 in all areas

  1. 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
  2. 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
  3. 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
  4. 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?
  5. 1 point
    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. 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!
  7. 1 point
    http://papilio.cc/uploads/Papilio/duousb-schematic.png Magnus
  8. 1 point
    This is not correct, the DUO does have a USB 2.0 chip on board (FTDI 2232H) and it can do up to 30 Mbits/sec in MPSSE mode and up to 12 Mbits/sec in serial mode. Not as fast as you want but faster than 3 Mb/sec. Magnus
  9. 1 point
    I don't think the Papilio Duo has USB. There is a USB serial chip as described here (http://papilio.cc/index.php?n=Papilio.PapilioDUOHardwareGuide#PProUSB). So up to 3MHz via serial. I think you'd need to connect a USB2 chip to the GPIO to achieve this. I've had success with usbhostslave, usb chip + some resistors, but that is only 1.1 speeds.
  10. 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.
  11. 1 point
    We're talking in context of the Papilio though, the Pro has a Spartan6 LX9. I just looked up the specs and it seems it has more BRAM than I had remembered, 32 blocks of 18Kb which works out to 72kB so that should be enough depending on whether it uses any other RAM or ROM. If it uses that many slices of the LX45 then there's no way it's gonna fit though, unless the high usage is due to using slices instead of BRAM for RAM.
  12. 1 point
    One thing about clock generation is that using a logic signal as a clock (as in 'rising_edge(tap)' above) is discouraged in FPGAs. As I understand it (which is limited, I'm still sort of a newbie) one of the problems is: Logic is sometimes "glitchy" (temporary bogus output values that last less than a clock cycle, and thus wouldn't matter, unless you use them as a clock). Another has something to do with routing and timing analysis. One alternative, if you want to run part of your circuit slower than your clock, is to use a clock enable. Suppose, for example, "CLK" is your clock and "en" is a signal that's HIGH for one out of every five clock cycles. Then you'd do the following: if rising_edge(CLK) and en = '1' then do <= stuff; end if; (Please pardon any syntax mistakes, I mostly use Verilog and am unfamiliar with VHDL.) The FPGA hardware has special support for handling this sort of thing.
  13. 1 point
    Hi All, A couple of years ago, I stumbled across a minimalist, interpreted programming language, created by Ward Cunningham - wiki pioneer. He called it Txtzyme - a concatenation of text and enzyme, and suggested that it could boost creativity. What it is, is a tiny interpreted language, where a single ASCII character is interpreted as an instruction, and causes a block of associated C code to be executed. It is so compact, it can be condensed into about 90 lines of Arduino C code. However, what it provides, is a powerful means to command the hardware of a microcontroller, just using a few characters sent over a serial port. Essentially it is a low level language for exercising new hardware. I took Ward's simple interpreter and extended it, to create a programming tool, that I call SIMPL. It borrows heavily from some of the minimalist ideas, first used 40 years ago by Chuck Moore's FORTH and the various TinyBasics used in the mid-1970s for some of the early 8 bit systems. To cut to the chase, I now have SIMPL running on ZPUino, on a Papilio Duo with Logic Start Shield. I can turn LEDs on and off with a few snippets of interpreted code, run LED chasers or synthesize musical tones. I'm currently trying to compile about 2 years of experimentation into a concise document. In the meantime - if you want to play with SIMPL - the raw sketch is up her on this github gist. https://gist.github.com/monsonite/97730b0456762da20a98 I'd appreciate comments and feedback. Have fun Ken B London
  14. 1 point
    You may also want to break it down into smaller chunks, that you can put together into a working project. First start with turning on some LEDs, then.... a: Can you receive a single byte from the PC and display it on some LEDs? b: Can you generate a VGA test picture? c: Can you make a memory and play back a pattern onto LEDs? Then you can build a+b: Can you store bytes from the PC into a memory? b+c: Can you display a picture from memory? Then finally a+b+c: Taking data from the host, storing it in memory, and displaying it on the screen.
  15. 1 point
    That's the spot sorry not much help ATM but it's almost 10pm and I work very early tomorrow. I will reply back on wed after I have a chance to look into it.
  16. 1 point
    I've just finished testing my LED driver PCB - 8 channels, each driving two constant current outputs (well, sinks actually). Loaded with 50 ohm sense resistors it gives 13mA per channel. 33 ohm will give 20mA. It is using discrete transistors to allow for higher power dissipation - maybe up to 300mW per channel, so should survive a hard short in in LED chains that that run at up to 15V. If anybody wants a PCB just ask... I can send it air post so you might just be able to use it for your Christmas tree lights
  17. 1 point
    Basics, back to basics.... Bootloader, loads app from SPI flash, which in turn uses SD card and bootstraps application from there. XThunderCore Boot Loader v0.1 (C) 2014 Alvaro LopesTesting memory: OK, connecting to SPI flashSPI Flash Identification: 0x00BF258DProgram size: 0x000052C7, CRC 0x0000Signature: 0x310AFAD5Target board: 0x00000000Loading: Checksum: 0xDCB4446F, mem 0xDCB4446F doneStarting application.Registered console dev:serial0STDIO base registered in console dev:serial0Starting....SD Card initialisedApplication found, size 445480Application read (445480 bytes), starting....Registered console dev:serial0STDIO base registered in console dev:serial0French version DOOM 2: Hell on Earth v1.10 V_Init: allocate screens.M_LoadDefaults: Load system defaults.Z_Init: Init zone memory allocation daemon.W_Init: Init WADfiles. couldn't openError: W_InitFiles: no files foundNow, need to port SD library to work with the application/zposix interface. Should be fairly easy. Alvie
  18. 1 point
    @Chris_C: I think the point of the flancter is not the counting (that's just given as an example) but handling input pulses that are so short that you can't sample them with your clock. I gather that crossing clock domains, or dealing with asynchronous (clockless) data, is quite a pain. That's what would make the flancter useful. Re synthesis: I've also heard that what's synthesizable on one FPGA might not be on another; or even with a different synthesis tool. Another reason I can think of that you might want to simulate something you can't synthesize, is if half your circuit is synthesizable RTL (your circuit in all its glory) and the other half is a non-sythesizable behavioral model. Like perhaps that second part isn't done yet; or it's something you're going to buy and this is just a sample; or it's an off-FPGA component on your board. Re simulation: My simulator of choice is Icarus Verilog. Free, relatively capable, command line oriented. But so far I seem to be using it more for debugging than testing. Also a quick (if over-lenient) syntax checker.
  19. 1 point
    Built two boards last night - one was trashed due to a misaligned HDMI connector, the other is looking OK. Haven't powered it up yet! Only problem so far is that the HDMI connector holes are a little bit too big... and yes, I also need to get some nice clean solder for attaching the pins, not my fifteen year old through-hole stuff!
  20. 1 point
    Yeah the subscription is only $50/year for the electronic edition (pdf download). I've been reading CC since I was a young whipper snapper, I have a full pdf collection back to issue 1.
  21. 1 point
    Hi guys, I just wrote a small C++ application (text-mode) that can compute the two primary configuration values for PLL (multiply and divide), given an input clock speed and the required speed. Since some of these are not possible directly using a single PLL, the application also scans for a dual-chained PLL approach, where the output from the first PLL is fed into the input of the second PLL. These two parameters are enough for you to get a working PLL with your desired frequency. Source code and prebuilt windows .exe available at: http://alvie.com/zpuino/downloads/pllscan/ Enjoy Alvie
  22. 1 point
    I could not found your code at here: http://www.rulecity....er-17Feb2013.7z. Please let me get source file for SDIO studying.
  23. 1 point
    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. View attachment: logic_sniffer_P1_250K.bit View attachment: logic_sniffer_P1_500K.bit
  24. 1 point
    Assuming the need to go to multi-layer for the BGA part, that looks like it will be a very expensive board. You might look at a part such as the XC3S500E-4PQG208I which is in a 208 pin PQFP package. The FPGA is a bit more expensive but the PCB will be a fraction the cost if you can keep it to 2 layers. Also at least when it comes to Seeed, the cost of the board increases rapidly with size. 5cm * 5cm max is around $1/bd, 10cm * 10cm max is $2.50/bd, while the next size up, 15cm * 15cm max is close to $9/bd. If you can manage to keep it within 10cm square then the bare boards are ridiculously cheap.
  25. 1 point
    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;