alex

Members
  • Content count

    391
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by alex

  1. alex

    Boo

    Hey guys, It's been a while since I was last here so I thought I'd pop in and say hi to all the old timers I used to know. I wonder how many of them are still here poking around, trying to beat them FPGA gates into submission A
  2. I had a broken laptop that was given to me and after it sat there gathering dust for a long time I decided to take the LCD apart since I had nothing to lose if nothing came of it. Once I exposed the LCD panel, I was pleasantly surprised to find a datasheet online with electrical, timing specs, even a pinout for the LCD panel, a QD15TL02 type which is a 15" panel with 1280x800 pixel native resolution. The panel requires about 10V (5W) for the CCFL inverter and 3.3V (1.4W) for the logic, you can see below a 3.3V linear regulator I found in my junkbox bolted to a heatsink which I'm using currently do bring up the LCD panel. Additionally the panel is driven with four LVDS differential pairs, three for data and one for clock. Currently I have all the signals soldered to a small perfboard with a header that plugs into wing slots BH and AL. The reason I chose these slots is because I need differential signal pins and no single wing alone provides these. Eventually I plan to make a small circuit board with a switch mode regulator that will fit in the corner seen in the picture above (the three screw holes). The PCB will have a barrel connector for power, a small pot for adjusting the brightness and a HDMI connector for the signals. Below is an eagle board I submitted to Batchpcb the other day. The LCD panel is not HDMI capable but the HDMI connector is ubiquitous and ideally suited for passing the high frequency data signals required. On the right hand side above is a Pap wing with an HDMI connector which I plan to use to connect to the LCD panel but by reprogramming the FPGA to talk TMDS, that wing should be able to be used with any proper HDMI sink. I can't wait to use that wing to try out Mike's Dvid_test on my HDMI monitor. The ground planes in the picture above have not been rendered for clarity. I've already received the components from Digikey (in less than 2 days no less) but Batchpcb has been having issues for the last few days and I only just today managed to buy my design, now a few weeks waiting for boards to turn up A This post has been promoted to an article
  3. alex

    FPGA as USB PIA

    I recently needed to bitbang some data on several IO pins and was considering my options. I didn't want to write HDL code and run it on a FPGA, I didn't even want to write C code and compile it and then run it under a soft processor on a FPGA. What I wanted was to write code on a PC, compile it, run it on the PC and quickly see the the results on a bunch of IO pins, kind of like the old days of the parallel port. My first thought was to use a FT2232H breakout board, the FTDI chip has a bunch of ports and several operation modes: However none of these modes would give me more than two 8-bit ports, one for channel A and one for channel B. Then I remembered that on a Pipistrello, Magnus had connected the entire port B to the FPGA allowing parallel data transfer. My thought was, why not use the FPGA's 48 IO pins as a PIA chip (Peripheral Interface Adaptor) and read/write them programmatically from the PC via the FTDI chip. After reading the FTDI datasheet cover to cover as well as the FTDI Programmer's Guide I still had questions as to how to enable the various modes. For example the ftd2xx.h file contains only the following modes that can be set via the FT_SetBitMode function: #define FT_BITMODE_RESET 0x00#define FT_BITMODE_ASYNC_BITBANG 0x01#define FT_BITMODE_MPSSE 0x02#define FT_BITMODE_SYNC_BITBANG 0x04#define FT_BITMODE_MCU_HOST 0x08#define FT_BITMODE_FAST_SERIAL 0x10#define FT_BITMODE_CBUS_BITBANG 0x20#define FT_BITMODE_SYNC_FIFO 0x40So how does one set the "245 FIFO" mode from the datasheet? Note that this isn't the same as the "245 FIFO SYNC" which is a special fast mode that uses channel A (connected to JTAG on the Pipi) and also uses all the resources on the FTDI chip which makes channel B become inactive. After much googling it turns out that the answer is easy and a little weird. "245 FIFO" mode is not set programmatically by calling the FT_SetBitMode function, instead this mode is programmed in the FTDI's eeprom chip for channel B, with a free FTDI Utility program, then on powerup, the chip will use "245 FIFO" mode for that channel. With the programming side sorted, it was a simple matter to come up with some HDL code to run on the FPGA that would allow the user to set and read pins. It is a simple state machine that receives commands from the PC and executes them. Each transfer is two bytes, a command and data byte. The 48 pins on the FPGA are treated as six 8-bit ports AL, AH, BL, BH, CL, CH just like the wing groupings. Each pin can be individually set as an output (direction bit = 0) or an input (direction bit = 1). When the pin is an input it is tristated but has a pullup (in the .ucf file) so this can be changed as required. On the PC side the programming is easy, you need to check the FTDI programming manual in the link above which has example code in it for every function call. Here's a quick guide to get something minimal up and running. This is written for Windows (minGW environment) and should therefore apply equally well to Linux. Grab ftd2xx.h and ftd2xx.lib from the drivers package on the FTDI web site. You can drop these into your include and lib directories respectively in your minGW installation. To compile you need a line similar to gcc -o your_program your_program.c -lftd2xx Inside your program you then need to #include "ftd2xx.h" Some useful defines would be:#define PORT0 0x00#define PORT1 0x01#define PORT2 0x02#define PORT3 0x03#define PORT4 0x04#define PORT5 0x05#define GET_VAL 0x00#define SET_VAL 0x08#define SET_DIR 0x10Then you need to open the FTDI port with: ftStatus = FT_OpenEx("Pipistrello LX45 B", FT_OPEN_BY_DESCRIPTION, &ftHandle);if (ftStatus != FT_OK) { printf("Failure\n");} else { printf("Success\n");}For the above to work you should make sure that your Pipistrello's board FTDI chip EEPROM is programmed with the name string "Pipistrello LX45", if you have changed it you need to adjust accordingly. Every function call in the FTDI library returns an FT_OK on success so you need to check that for error handling. To set port 0 to all inputs you would use something like this: buffer[0] = SET_VAL | PORT0;buffer[1] = 0xFF;ftStatus = FT_Write(ftHandle, buffer, 2, &BytesWritten);To read 1 byte from port 1 you could do this: buffer[0] = GET_VAL| PORT1;ftStatus = FT_Write(ftHandle, buffer, 1, &BytesWritten);ftStatus |= FT_Read (ftHandle, buffer, 1, &BytesReceived);Each USB transaction (call to FT_Read / FT_Write) introduces latency because the data has to be packaged into a USB packet and transferred complete with USB protocol overhead such as handshaking. A trick you could use is to package multiple write commands into just one packet. For example suppose you want to write a value to port 0 and then strobe low a pin on port 1 to indicate to some attached circuit that new data is available. You could do this in three USB calls, write data to port 0, write to port 1 to bring pin low, write to port 1 to bring pin high, or you could just do this in one call: buffer[0] = SET_VAL | PORT0;buffer[1] = 0x12; // output data on port 0buffer[2] = SET_VAL | PORT1;buffer[3] = 0xFE; // drop bit 0buffer[4] = SET_VAL | PORT1;buffer[5] = 0xFF; // raise bit 0ftStatus = FT_Write(ftHandle, buffer, 6, &BytesWritten);Finally, always be a good boy or girl and close the door when you leave. ftStatus = FT_Close(ftHandle);This is of course the bare minimum to get you going, you simply must read the FTDI programmer's manual to get a feel of all the functions available to you. I recommend you check out FT_SetUSBParameters, FT_SetTimeouts and FT_SetLatencyTimer. Also a very useful command is FT_Purge to clear the FIFO's. Oh this reminds me. The FTDI chip uses FIFO's on both the read and write channels. This means of course that you don't have to read each data byte immediately if you don't have to. For example suppose you want to read all six ports. You may think you'd have to write the read command for port 0 then read the value returned then repeat for all the other ports meaning you have to call the FTDI procedures in this order: read, write, read, write, read, write, read, write, read, write, read, write. Because of the FIFOs however you could simply send six read commands packaged into one USB packet then simply read six bytes for a total of two function calls, one read and one write as below: buffer[0] = GET_VAL | PORT0;buffer[1] = GET_VAL | PORT1;buffer[2] = GET_VAL | PORT2;buffer[3] = GET_VAL | PORT3;buffer[4] = GET_VAL | PORT4;buffer[5] = GET_VAL | PORT5;ftStatus = FT_Write(ftHandle, buffer, 6, &BytesWritten);ftStatus |= FT_Read (ftHandle, buffer, 6, &BytesReceived);Below is the source code of the project. It's very small and very simple. Pipistrello_fifo.zip
  4. Good old Hack-a-Day made me spend more money on this Indiegogo Campaign for a super cheap GPS board. In any case researching the components on that board it seems the Venus 822 GPS chip they they are using is an ASIC that incorporates a Leon3 processor. Tracking that down to the supplier web site I see the VHDL core is downloadable: The LEON3 is a synthesisable VHDL model of a 32-bit processor compliant with the SPARC V8 architecture. The model is highly configurable, and particularly suitable for system-on-a-chip (SOC) designs. The full source code is available under the GNU GPL license, allowing free and unlimited use for research and education. LEON3 is also available under a low-cost commercial license, allowing it to be used in any commercial application to a fraction of the cost of comparable IP cores. The LEON3 processor has the following features: SPARC V8 instruction set with V8e extensionsAdvanced 7-stage pipelineHardware multiply, divide and MAC unitsHigh-performance, fully pipelined IEEE-754 FPUSeparate instruction and data cache (Harvard architecture) with snoopingConfigurable caches: 1 - 4 ways, 1 - 256 kbytes/way. Random, LRR or LRU replacementLocal instruction and data scratch pad RAM, 1 - 512 KbytesSPARC Reference MMU (SRMMU) with configurable TLBAMBA-2.0 AHB bus interfaceAdvanced on-chip debug support with instruction and data trace bufferSymmetric Multi-processor support (SMP)Power-down mode and clock gatingRobust and fully synchronous single-edge clock designUp to 125 MHz in FPGA and 400 MHz on 0.13 um ASIC technologiesFault-tolerant and SEU-proof version available for space applicationsExtensively configurableLarge range of software tools: compilers, kernels, simulators and debug monitorsHigh Performance: 1.4 DMIPS/MHz, 1.8 CoreMark/MHz (gcc -4.1.2)
  5. alex

    Isim is driving me crazy

    I'm trying to simulate a DRAM design using the free Webpack ISE Simulator, basically used the MIG core generator to get a MCB core, downloaded the Verilog model of the DRAM chip from Micron, added some glue logic to tie it all together and when I try to simulate it, I get "This is a limited version of the ISE Simulator. The current design has exceeded the design size limit for this version and the performance of the simulation will be derated." The simulation still runs, if you can call it that, but at about 1000th the normal speed. It literally takes 2 minutes to simulate 1uS, at this rate to get past the MCB core initialization, I estimate I'd have to run the simulator for a few days. I searched online for a solutions and I came across the FAQ at Xilinx which states "ISE Webpack - Performance Deration when exceeding 50,000 lines of HDL code". Great, that is fine, except I have counted all the lines in every single source file I have for this design, not just my code, but also the Verilog DDR model I downloaded, the config files to go with it and every single text source file that the wizard created for the memory core and everything together, including comments barely reaches 16000 lines. Yes the memory core is quite fat once you count the wrapper files generated for it by the MIG but even so I'm way below the 50K lines. This has to be some kind of bug, has anyone come across this before?
  6. As great as the famous C64 SID chip is, it is not the only way to produce great music and sound effects. There is another category of sound chips based on frequency modulation (FM) synthesis. A very popular choice, mainly in Japanese arcades and consoles as well as some keyboard synthesizers / pianos, is the Yamaha YM2151. This is in fact one of several chips in the family of OPL, OPN, OPM and OPS chips. These acronyms indicate how many oscillators per channel the chip contains but they all fall in the wider family of FM synthesis chips. The YM2151 (and others in its category) do not output analog sound, instead they output digital data over a serial channel. This typically goes to a separate D/A chip like a YM3012 stereo DAC or a YM3014 mono DAC. The YM2151 and its companion DACs are available for purchase on ebay for just $3 each so the enthusiast can experiment with them without considerable cost. The fact that the chip does not have an integrated D/A and requires additional external components might be considered a drag by some, but in this particular instance, for someone like me, the fact that the chip outputs digital data is actually a bonus since that output can be fed back into an FPGA (without going through a D/A and A/D conversion) and further processed numerically. To be honest, the idea for this mini project came to me after browsing though various schematics of arcade games. I came across a high res scan of a schema for the arcade version of Double Dragon This was one of those rare schemas that are clean and legible but also just real easy to follow (despite it being over 20 pages), it's just a pleasure to look at and it just makes sense. The signals that cross pages are also very easy to follow because the designer labeled them not just with the page they connect to but the coordinates on that page as well. This is one of these games that have a separate sound board, complete with its own CPU. The interface from the game board to the sound board is via a simple 8 bit port with a single strobe (write) signal. I had the feeling I could just implement most of this sound board on a FPGA and then simply drive the external YM2151 chip with the signals produced by this sound board implementation. Wiring all the external chips on a prototyping board is not really that hard, below is the basic schema that needs to be followed. This schema is a composite after cutting/pasting parts from different pages of the original schema to illustrate just the YM2151 connections to the D/A and audio amps. So in order to implement the sound board on a FPGA I need to figure out how the main game communicates with the sound board. Focusing on the main game CPU is the wrong approach here though, this is like taking the long way to get somewhere, the right thing to do is look at the sound board CPU and see how it needs to be "tickled". Here is the schema with irrelevant bits taken out. The data latch IC17 is written to by pulsing the signal line *3806 low then high. This clocks in the value from the DB data bus into the IC17 latch. In parallel however, the signal *3806 also clocks the flip-flop IC39. Because the D input is tied high, the pulse on its clock line cause the D input to be latched to the Q output (not shown) and its complement /Q at pin 9, meaning /Q goes low whenever the clock (line *3806) rises. This cause the active low /IRQ line to the 6809 CPU IC49 to go low triggering an interrupt. Disassembling the sound ROM we see that the CPU vector table contains: ROM:FFF0 fdb start ; RSVDROM:FFF2 fdb start ; SWI1ROM:FFF4 fdb start ; SWI2ROM:FFF6 fdb vec_FIRQ ; FIRQROM:FFF8 fdb vec_IRQ ; IRQROM:FFFA fdb start ; SWIROM:FFFC fdb start ; NMIROM:FFFE fdb start ; RSTSo following the IRQ vector we get to: ROM:880D vec_IRQ: ; DATA XREF: ROM:FFF8oROM:880D lda $1000ROM:8810 cmpa byte_2 ; if same as currently playing melodyROM:8812 beq locret_881A ; exitROM:8814 ldb byte_0ROM:8816 bne loc_881BROM:8818ROM:8818 loc_8818: ; CODE XREF: ROM:881DjROM:8818 ; ROM:8823jROM:8818 sta byte_A ; store index of melody to playROM:881AROM:881A locret_881A: ; CODE XREF: ROM:8812jROM:881A rtiSimple stuff so far. When the IRQ vector is called it reads address $1000 and ignoring some of the bits in the middle, it stores that value to byte_A (RAM address $000A) and exits the interrupt handler via the RTI instruction. The reason we ignore some of the code in the middle is because I've already analysed it for you and I can tell you it's not relevant for our discussion.So why does the IRQ handler read address $1000? Well if we lay out the address lines as A15, A14, ... A1, A0 then $1000 is binary 0001 0000 0000 0000 on the corresponding address lines. So the top 5 address lines A15,14,13,12,11 are 00010 when reading from address $1000. Looking at the schema we see these lines are connected to address decoder IC79 (pin 5 on that IC is not labeled in this cut down schema but tracing it on the real schematic shows it going to A15 on the CPU). IC79 is a 3-to-8 decoder meaning the 3 bit binary signal presented to its inputs 1, 2 and 3 is decoded so the corresponding output 0 through 7 goes low. Pins 5 and 6 are active low chip enables (meaning they must be low for the chip to do its job). So when the CPU places address $1000 on the address bus, the chip sees 00010 on its pins 5,4,3,2,1, meaning the two enables are enabled (low) and the remaining binary data 010 represents decimal number 2, so output 2 goes low. This output goes to our familiar flip-flop active low clear input. When the clear input is activated by a low signal the flip-flop clears its state, so the Q output (not shown) goes low (cleared) and its complement /Q goes high. So the operation is now clear, whenever the *3806 signal goes low then high, the DB is latched into IC17 (which goes to the CPU data lines through another buffer to avoid contentions with other stuff on the data bus) and an IRQ is triggered. The CPU stops whatever it is doing and services the IRQ by executing the IRQ routine which clears the IRQ signal by reading address $1000 and storing the DB data from the IC17 latch into the CPU internal memory at address $000A. This is pretty cool because I can now go to MAME and set a breakpoint at the sound CPU address $880D and every time an IRQ occurs, I can see what value was being written. Using this trick I can see that the following values cause the following things to happen. $FF clears/stops any melody sound currently playing$FE clears/stops any sound effect currently playing$01 through roughly $30 play different effects or melodies on the YM2151$80 through ?? play different sound effects but not through YM2151.The sound effects triggered with values > $80 do not use the YM2151 but instead play these effects through separate DAC chips IC80, IC81 and associated circuitry consisting of discrete programmable counters and digital comparators (the relevant schema for these is not shown anywhere in this post). There are in fact two identical circuit duplicated so two effects can be played simultaneously. I won't show an analysis of the circuitry for the effects but roughly it works like this.Each channel has a 64KB ROM with sound effects stored inside. The CPU writes to the programmable counters to preset them with the starting address in the ROM and also to the digital comparators with the end address in ROM of the sound effect. The counters start counting up from the programmed address until the end address is reached at which point the programmable comparators issue a reset to stop the sound playing and the counters stop counting. For example the CPU can preset $1234 into the counters and $2345 into the comparators and the ROM would be presented with addresses $1234, $1235, $1236, ... up to $2345 on it's address bus then the address would freeze there. The ROM output is connected to the DAC chip causing the value from the ROM data bus to be turned to analog sound into the speakers. The address counters are clocked with a presumably low clock which it seems is generated by the DAC chips, probably a few KHz. More to follow... EDIT: Any code for this project will be available here. So far I have added there the full schematic of the sound board, all three pages into one image for convenience. My development hardware will be a Papilio Plus with an Arcade Mega Shield (plus any external chips of course). This post has been promoted to an article
  7. Not sure if this is common knowledge but I more or less accidentally came across it when I was playing around in Impact and did a JTAG scan with my Pipistrello attached. It was detected by Impact and I was able to point Impact to a bit file and it successfully uploaded it to the board. The Impact log shows the following: Welcome to iMPACTiMPACT Version: 14.5// *** BATCH CMD : setMode -bs// *** BATCH CMD : setMode -bs// *** BATCH CMD : setMode -bs// *** BATCH CMD : setMode -bsGUI --- Auto connect to cable...// *** BATCH CMD : setCable -port autoINFO:iMPACT - Connecting to TCF agent...INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.4INFO:iMPACT - Digilent Plugin: found 1 device(s).INFO:iMPACT - Digilent Plugin: opening device: "Pipistrello", SN:400100000001INFO:iMPACT - Digilent Plugin: User Name: PipistrelloINFO:iMPACT - Digilent Plugin: Product Name: Pipistrello-USBINFO:iMPACT - Digilent Plugin: Serial Number: 400100000001INFO:iMPACT - Digilent Plugin: Product ID: 30800151INFO:iMPACT - Digilent Plugin: Firmware Version: 0105INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 10000000 HzAttempting to identify devices in the boundary-scan chain configuration...INFO:iMPACT - Current time: 2/10/2013 9:46:41 a.m.// *** BATCH CMD : Identify -inferir PROGRESS_START - Starting Operation.Identifying chain contents...'0': : Manufacturer's ID = Xilinx xc6slx45, Version : 4INFO:iMPACT:1777 - Reading C:/Xilinx/14.5/ISE_DS/ISE/spartan6/data/xc6slx45.bsd...INFO:iMPACT:501 - '1': Added Device xc6slx45 successfully.--------------------------------------------------------------------------------------------------------------------------------------------done.PROGRESS_END - End Operation.Elapsed time = 1 sec.// *** BATCH CMD : identifyMPM It appears it is using Digilent drivers which I already had installed (or maybe Xilinx installs by default). If you don't have them installed, the installer for them seems to be located in C:\Xilinx\14.5\ISE_DS\common\bin\nt64\digilent\install_digilent.exe (or the equivalent path for your version install). I was even able to click on the SPI/BPI and select the attached flash as a N25Q128 which is a supported option but didn't experiment yet with writing a file to the flash as I needed to convert it to .mcs format first. I also attached my Papilio and run a scan but it wasn't detected. I suspect this is because as I remember from another post in this forum, Magnus said he is sending the Pipistrello boards with the FTDI eeprom pre-programmed whereas the Papilio FTDI eeprom is left blank.
  8. alex

    Robotronic adventures

    A while back Vlait made a mention of a Robotron game in this post so I decided to grab the source code mentioned and try and bring it up on my Pipistrello board because of the memory requirements of the game currently 49 RAMB. I encourage you to read the wiki of the original author, Jared Boone, but as a quick recap, his implementation uses a real 6809 CPU connected to the FPGA board. Because the real Robotron uses in fact two 6809 CPUs, one for the sound and one for the game, and Jared could only connect just one physical CPU to his FPGA board, he has a split project where he can test either the game or the sound but can't have a complete game with sound running all at the same time. As Vlait said, there is now an Opencores implementation of a 6809 so it should be possible to do away with the physical 6809 CPU and implement the entire game on one FPGA, complete with sound. I grabbed the Opencores 6809 and and quickly made a top level module connecting all the components together, should be a piece of cake bringing this to life, right? Well... no, actually. Running the game ROMs in MAME, I can see that the expected behaviour at power on for the game is to fill the screen with what I call rainbow noise, like this This is a side effect of the memory test filling the entire RAM including the video buffer with pseudo-random data, but my board produced... a black screen. On to the simulator we go, fire up Isim and start a simulation, while in parallel run MAME in debug mode to bring up the game disassembly and single step and compare the two. Immediately apparent was that the soft CPU failed to fetch the reset vector and was executing garbage. This turned out to be due to slight timing differences between the real CPU and the soft CPU so I had to delay the latching of the CPU signals by a few ns. As soon as I did that I got the rainbow noise just like the real game which was promising but immediately after that, the screen would turn black and remain so indefinitely, whereas the real game would post a message "Initial tests indicates: operational" and proceed to the attract screen. What could be wrong, I wondered? Back to Isim. It turns out that the memory test takes a significant amount of time, about 5 seconds in real time, and since I know that works fine given the screen output and that the problem occurs after that, there is no point trying to simulate 5 seconds of real time which would take a very long time to simulate, and probably fail because Isim can only store so much signal data in its database before it throws up its hands and stops due to it having reached its limits. The easy way around this is to make the game skip the memory test and just go straight after it. This can be accomplished by patching the game ROMs in the right place. A (not so) quick session inside the MAME debugger reveals some interesting locations:F472 JMP $FD65 (7E FD 65) Jump to mem test area, fall through to next instruction to skipF479 JMP $FF3F (7E FF 3F) Jump to checksum area, fall through to next instruction to skipF47C start of gameSo the easiest thing to do turned out to be to patch memory locations F46B through F47B inclusive, with no-op type instructions such as LDX #$0000 (three byte) or LDY #$0000 (four byte). After this, the game happily skipped through the time consuming parts to quickly move to the problem area at about 70ms after reset. The simulator shows that the CPU address freezes and this is of course due to the halt signal being asserted. Zooming in shows that the last instruction fetched before the freeze are at address 6007. What we really have there is:ROM:6004 sta word_CA00 ; start blitterROM:6007 puls y,ccSo the last instruction actually executed was that at 6004, storing the A register at address CA00, which according to MAME source code from williams.c is the "start blitter" address. So basically, as soon as the blitter is accessed, it halts the CPU to gain the bus, but for some reason the CPU remains halted indefinitely. Why would that be I wonder? Well it turns out that the real CPU is meant to acknowledge certain events such as IRQ, fast IRQ, Sync, Reset and Halt as well, by posting certain levels on output pins BA ("bus available") and BS (bullsh... err, I mean "bus status"). But the Opencores 6809 does not implement those signals at all, so there's the problem. Taking a glance through the source it seems the best place to add the missing signals is to hook them to the state machine like so: change_state : process(clk) begin if rising_edge(clk) then if rst = '1' then state <= reset_state; else if hold = '0' then state <= next_state; case next_state is -- halt ack when halt_state => ba <= '1'; bs <= '1'; -- sync ack when sync_state => ba <= '1'; bs <= '0'; -- irq/rst ack when reset_state | int_mask_state | vect_hi_state => ba <= '0'; bs <= '1'; -- normal when others => ba <= '0'; bs <= '0'; end case; end if; end if; end if; end process;The part between case ... end case statement was what was added to the existing code. Pretty easy fix really. The proof was of course when synthesizing this and running it on the FPGA I now get past the memory test rainbow and into the game attract screen. At a glance it mostly looks correct though I can make out some small issues, such as some graphics are a little corrupt and some sprites are missing. Here's a screen shot of the actual FPGA running the game showing one of the faulty graphics (the tall column of lines bottom right) Enough debugging for today though, it's 1:30am, yawn... next I'll need to add the sound CPU to the project, not sure how it connects to the rest, will have to consult the schematics.
  9. 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
  10. This is available on HaD, looks pretty useful if someone wants to reuse/recycle modern LCD displays like the ones in iPhones. Source code and everything is available.
  11. alex

    LogicStart Shield for the Papilio DUO

    That is what I think as well. It's hard to make one mega shield that will please everyone, which is why I'm surprised that there hasn't been a bigger emphasis on wings, which was a big selling point in the old days of Papilio. With individual wings one could assemble exactly what they needed. I still think it is useful to have specialized mega wings such as the arcade one for example but for learning purposes a collection of individual wings could be more suitable. For example the logic megawing can be broken down to an 8 bit wing with 4 sliders + 4 LEDan 8 bit wing with 4 sliders + 4 LED an 8 bit audio wingan 8 bit wing with directional switches (or joystick)a 16 bit VGA winga 16 bit wing with the 7 segment displayThen everyone's happy. You want alphanumeric displays, just replace the 7 seg wing with and alphanumeric one (once one is designed of course). Or maybe you want 8x8 dot matrix. No need for VGA, leave that wing off and you have more free pins available. Maximum flexibility. Another useful widget might be a 8 bit wing to PMOD adaptor, either straight or right angle to open up the world of Digilent PMODs to the Papilio.
  12. alex

    Question about Papilio Pro

    A Papilio digital line set to be an input should not place that much load on your test circuit as to cause a huge voltage drop. Most likely the FPGA has the internal pulldown resistors configured and they are stronger than your test circuit pullups. You should re-synthesize the bitstream with all pullup/pulldown resistors from the FPGA removed in the constraints file.
  13. alex

    LogicStart Shield for the Papilio DUO

    You can try to do video processing with HDMI in /out wings. VGA input is problematic due to it being an analog signal.
  14. alex

    Propeller 1 open source

    Niceeee. I like it when this sort of stuff happens.
  15. 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.
  16. Hey Jack, you might have to buy Colin a beer or two next time you see him. In the latest issue #289 of Circuit Cellar magazine he has another article that starts with a very large picture of a Papilio Pro and LogicStart Megawing. It almost looks like a full page ad for Papilio.
  17. alex

    Papilio DUO Kickstarter - Feedback request!

    But trenz are not cheap, expect big markup on price
  18. alex

    Papilio DUO Kickstarter - Feedback request!

    Looks pretty flashy Jack, I wish you all the best with this new KS endeavour and hope you achieve the funding. Video sound is a bit echoey, mic must not have been close enough but nothing major.
  19. alex

    OV7670 and PPro

    I thought you can right click on a signal in isim and do a "show drivers" to see what's driving it. Then you can decide if there's something there that shouldn't be.
  20. alex

    socz80: A Z80 retro microcomputer for the Papilio Pro

    Thanks for sharing Will
  21. alex

    Microblaze on Papilio Pro

    Correct. The LX9 has built in MCB cores but they are only connected to external pins in BGA packages.
  22. alex

    Dead Papilio Plus?

    If you get no power across the USB power pins, it's possible that either your PC's USB port has blown a fuse or it has disabled power on purpose after the overcurrent warning you received. Why not try rebooting the PC to try to clear the condition and also try another USB port (with just the FPGA board plugged in, not the LCD or any other add ons).
  23. alex

    Bitcoin Mining

    Based on my earlier experiments with a Virtex 5 FPGA chip, expect to make 1 cent a day in "profit" if you're lucky. I say "profit" because you'll invariably spend more than that in other expenses so your actual profit value will be negative. But yeah, if you're just having fun, like I did, go for it, I no longer mine bitcoin, nor did I ever other than that week I was playing with it on the FPGA.