Matt Ownby

Members
  • Content count

    26
  • Joined

  • Last visited

Everything posted by Matt Ownby

  1. Hi guys, What I'm currently trying to do (aside from going through most of Hamster's tutorials, thanks these are GREAT!) is to read from a 15 MHz ADC (hardware already working) and stream the results to an SD card. I don't even know if I'll be able to pull this off due to the performance demands, but it will still be very educational for me to go through the steps of learning how to control an SD card. I realize that it is popular to control SD cards in SPI mode but since I really need every ounce of speed I can get, I want to do it in the 25 megabyte/second mode ("high speed, wide-bus SD mode"). Since the SD spec requires quite a bit of setup before one can actually start bulk writing, I am _positive_ that I will be making mistakes and I am going to need some feedback along the way. So I think it would be _very_ helpful I can get some logging over the FTDI usb port to show me what's going on. I've gone through hamster's tutorial on how to output RS232 and I actually got this working earlier today (woohoo) using putty on a windows PC. But here is the issue I am currently grappling with: - since the FPGA has different components running in parallel, it is conceivable that two different modules may want to output to the log simultaneously. Is there some kind of locking mechanism to prevent this? like some kind of mutual exclusion object or something? - And what about the issue of the log wanting to output to the serial port while another module wants to add to its buffer? - Speaking of buffers, I am thinking about using a small array of bytes with indices pointing to the start and end of the buffer (ie a revolving buffer). Too complicated?
  2. Matt Ownby

    Robotronic adventures

    Citation needed I'd be interested in looking into this.
  3. Like other Williams games, Star Rider uses a paging system to address more than 64k of RAM/ROMs. The ROMs that can be addressed by the main CPU include two 8k ROMs and three 16k ROMs. I guess that means 64k Only one can be read at a time. The CPU's clock is 1 MHz so this isn't exactly speedy. However, I would be skeptical of whether an SD card would always be able to guarantee delivery on time. I have no experience with serial flash. The RAM size is the same 0xcc00-0xcfff 4-bit nvram area you mentioned for Robotron, as well as five 8-bit 2k chips (10k). I have attempted to implement this with block RAM and, without being able to test it, ISE isn't complaining so I'm probably on the right track. EDIT : maybe I could put all the ROM on something like this: http://www.onsemi.cn/pub_link/Collateral/CAT28C513-D.PDF EDIT #2 : did more googling, it seems that parallel ROMs are pretty obsolete these days. I guess I am one of the last to realize this hahaha
  4. Hi, I want to make a wing-styled PCB that allows me to comfortably interface a Xilinx FPGA with an original Motorola 6809E CPU. I am going to need read-only voltage conversion from the 6809E's address pins, and safe bidirectional I/O for the data pins. I've been looking at how the input buffer wing and I/O buffer wing accomplishes this and it looks like I might want to go the same route. So I downloaded the .SCH and .BRD files hoping to steal the Eagle parts for the voltage conversion ICs but it looks like it's in a .LBR file that I cannot find. Any idea where this is located? And am I on the right track or is there a newer better approach to this? (I noticed there was an older thread that mentioned some problems with one or both of these boards) thanks, Matt
  5. I found your thread and read it. It is very interesting! The reason I want to use a real 6809E CPU is to avoid all of the problems that you had using the VHDL version When I googled for existing 6809E VHDL cores I didn't find much, and what did find proudly proclaimed that it was not cycle accurate to the original. I am actually working on something pretty related to your Robotronic adventures: I am very deep into reverse engineering another Williams game, Star Rider. My ultimate goal is to offer a hardware replacement for the laserdisc player used in this game. But in order to do that, I need the game to work well enough to prove that my hardware replacement works. This game is pretty dang rare these days. So I decided that the best way to learn how the game works is to emulate it. I have been working on this since January and I have actually got the game's attract mode running and I can even coin up and play the game although it definitely does not work yet. You can see videos and blog posts about my exciting progress at : http://my-cool-projects.blogspot.com/search/label/starrider . A friend had the original hardware and he shipped it out to me. As you can see from my blog post, I spent a lot of time rigging up a power supply and finding a way to see the output of the game without having an original RGB monitor. But when I powered the game on, it DID NOT WORK. After some troubleshooting, I determined that the main CPU board had become destroyed due to corrosion (alkaline battery leakage?). And since I had just spent months and months studying the schematics to this game, I realized that I almost completely understood the hardware on the main CPU board. At this point, I determined that if I used an FPGA, I could whip up a replacement PCB of the main CPU board without "too much" effort and then I'd be able to plug it into the rest of the original hardware and actually play this dang game and proceed with my original goal (testing the laserdisc interface!). I hate getting derailed by things like this but it is sure fun!!! Anyway, so that's what I am working on. My status is that while I am trying to keep the PCB board size small, the original components are HUGE and this is a big problem for me. The main CPU board has quite a few of the massively huge molex connectors which I have put on my current Eagle implementation but boy, I am wondering if I should shrink them down and build cable adapters or something. Like I said, I want to use the original 6809E because I do not have time or desire to debug a buggy VHDL 6809E and I know enough from emulating this game that accuracy matters a lot. Another problem I'm running into is FPGA capacity. I've put the RAM (and NVRAM) onto the FPGA successfully but when I tried to shove the CPU's ROMs on there I ran out of room. So I am looking at the prospect of exploding the PCB's size to massive proportions by putting sockets for the original EPROMs on the PCB. I really don't want to do this. I am thinking maybe I can use my Papilio One as a "ROM server" (if the ROMs will fit) or if the ROMS won't fit, maybe I will try using my Papilio One as a "RAM server" instead. I am trying to do something that is accurate but also somewhat quick n' dirty since I Don't want to get too derailed on perfecting this board. (Although it would be awesome to come back later and perfect it). So basically what I am trying to do is still use the original CPU and I will still need to talk to the Video Graphics Generator board from the main CPU board using TTL-compatible voltage (and possibly will need to talk to original EPROMs with the TTL voltage) but otherwise I've got this thing on the FPGA. In other words, I've finished writing the VHDL for the rest of the CPU board and just need to figure out how to get the ROMs on there somehow. So I'm open to any and all suggestions --Matt EDIT: I almost forgot. I also found John Kent's PIA6821 VHDL code and am using it but I am somewhat tempted to just drop it and use original PIA6821's as well (even though they are huge). The reason is that I found several things about Mr. Kent's VHDL code that I did not like. For one thing, his IRQA' and IRQB' implementation outputs high or low but a real PIA is open drain and should output low or "open". This actually matters a lot for Star Rider because the game has the IRQ lines from two PIAs daisy chained together. So I fixed this bug in Mr. Kent's code but then noticed that he has a few other problems like reset being active high (instead of low), and only one active high Chip Select pin (the original PIA has three chip select inputs). This seemingly arbitrary decision to not expose the original interface of the PIA has made me suspicious of how dedicated Mr. Kent was to preserving accuracy when he designed it. I am still using it for now but I will be very sad if I have to spend a lot of time debugging it if the game doesn't work. Really, if the original PIAs weren't DIP40, I'd slap them on my PCB because Jameco.com still sells them for cheap. *end musings/rant*
  6. Matt Ownby

    Robotronic adventures

    Awesome reading! Thanks for the info!
  7. Hehe... ok in the interest of learning the answer on my own, I did some more reading and concluded that if I want to use QuickSwitch to clamp all voltages to 3.3V, I need to have the QuickSwitch's VCC be about 4.3V and I can use a diode from a 5V source to achieve this.
  8. Ok, I am a little confused. It seems on this latest Eagle schematic/board that you've ditched the IDT QuickSwitch in favor of a part from TI. Was there something wrong with the QuickSwitch line? Someone recommended that I look into these and I am really confused about which one would meet my needs. I see that they have 5V and 3.3V QuickSwitch parts, and this confuses me because I don't understand what the difference is. Do they both do the same thing and one is powered by 5V and one is powered by 3.3V ? I just want something that does what the I/O wing is supposed to do (always output at 3.3V, accept 5V input). Some of the tips I've read say that a diode is needed, others don't seem to make mention of any diode. I just wanna have the 6809E CPU's data bus go through some kind of IC and have 3.3V come out on the other end and I want to send back 3.3V and have the 6809E receive 3.3V and interpret it as a logic high. Is the new TI part bi-directonal? I looked at the data sheet and it seems that the direction must be explicitly set. Sorry for my newb questions
  9. Thanks! Now that I see these files, I realize that I was somehow looking at the wing template Eagle file instead of the buffer wing Eagle file. Not sure how I got so far off! At any rate, I appreciate the help! --Matt
  10. Matt Ownby

    How does the SPI Flash auto-configure the FPGA?

    That is really cool. Since the flash is only connected to the FPGA, I figured that the FPGA had to be temporarily configured to write to the flash instead of read from it. That's a pretty neat idea to cut down on hardware costs I just read the Spartan 3E datasheet (section about Master SPI) and looked at the Papilio One Eagle schematics and have concluded that it is set up the following way: M[2:0] is 001 (Master SPI mode) VS[2:0] is 111 (use "fast read 0x0B" command) HSWAP: 0 (enable pull-up resistors on all I/O pins during configuration) Thanks for helping me learn!
  11. Hi all, I've recently been looking into the possibility of making my own PCB with an FPGA on it so I've been studying how my Papilio One configures the FPGA. I was expecting to see a little microcontroller on the board to do this task but instead, to my astonishment, the only thing on this board that can configure the FPGA is the SPI Flash itself (and the JTAG interface via the FTDI chip). This is like black magic to me I briefly skimmed the datasheet for the SPI Flash and it does not appear to have any inherent "auto FPGA configure" setting that I could see So my question is, how does this work? Does the FPGA bootstrap the SPI Flash chip or does the SPI Flash chip bootstrap the FPGA?
  12. Original forum thread. Ok, I've got a v1.0 release of working code now at 50 MHz! Many thanks to Hamster for the help! You can find the code (with readme) here: http://www.rulecity.com/browsetmp/sd_card_writer-17Feb2013.7z Please feel free to suggest improvements to the stupid bone-headed newbie VHDL mistakes I make! -------------------------------------------------------- VHDL SD card writer v1.0 By Matt Ownby (http://www.daphne-emu.com and http://www.laserdisc-replacement.com) 16 Feb 2013 This is VHDL code (for the Papillio One FPGA board) that shows how to write to an SD card in a high-speed mode. Features: - Uses 4-bit SD mode, not 1-bit SPI mode (faster) - Uses 50 MHz "high speed" mode, not 25 MHz "normal speed" mode (also faster) - Logs to Papillio USB serial port (230400 bps) so you can see what is going on Requirements: - An SDHC card (older probably won't work) that supports high-speed aka 50 MHz mode. How to use: - Get the pins of an SD card (or adapter) somehow connected to Papillio pins. Not discussed here as you are expected to have enough expertise to figure this out on your own What you will see on serial port (230400 bps) if everything is working correctly (this is very terse since string handling is a pain in VHDL): - C00 C08 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C02 C03 C07 C55 A06 C06 C24 C13 S Explanation of above data: "-" gets sent on reset, it means the process is starting over "C00" is the reset command sent to the SD card. It expects no response. "C08" is the voltage-request command and is only supported on newer cards. The Papillio requests normal 3.3V operation. If I/O is not working, or if the SD card does not support this command, this is the last line you will see. "C55/A41" is the init command. It usually needs to be repeated over and over again until initialization is finished which is normal. "C02" is the "get SD card CID" command. It is required otherwise I wouldn't bother sending it. "C03" is the "get SD card's relative address" command. It is also required. "C07" puts the SD card into transfer mode. "C55/A06" switches the SD card from a 1-bit bus into a 4-bit bus (4x speed increase). "C06" switches the SD card from 25 MHz mode to 50 MHz mode (2x speed increase). If you see an "E" after this, it means that the CRC check failed (this happened to me occasionally during development). "C24" starts writing a single 512 byte block at address 0 (beginning of card). "C13" requests the card's status and is optional but it makes me feel better to see it working since at this point we are communicating at 50 MHz. "S" means 'success' and means that the SD card responded that the write operation was completely successful. If you see an "E" here it means that the CRC check probably failed. If you see anything with "X" in front of it, it means that an unexpected response was received and the unexpected response has been dumped out in ASCII hex format. This is for troubleshooting purposes.
  13. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Hello guys, I am in the western USA myself. As Alex says, it appears that blogspot mirrors itself.
  14. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Ok, I've got a v1.0 release of working code now at 50 MHz! Many thanks to Hamster for the help! You can find the code (with readme) here: http://www.rulecity.com/browsetmp/sd_card_writer-17Feb2013.7z Please feel free to suggest improvements to the stupid bone-headed newbie VHDL mistakes I make! -------------------------------------------------------- VHDL SD card writer v1.0 By Matt Ownby (http://www.daphne-emu.com and http://www.laserdisc-replacement.com) 16 Feb 2013 This is VHDL code (for the Papillio One FPGA board) that shows how to write to an SD card in a high-speed mode. Features: - Uses 4-bit SD mode, not 1-bit SPI mode (faster) - Uses 50 MHz "high speed" mode, not 25 MHz "normal speed" mode (also faster) - Logs to Papillio USB serial port (230400 bps) so you can see what is going on Requirements: - An SDHC card (older probably won't work) that supports high-speed aka 50 MHz mode. How to use: - Get the pins of an SD card (or adapter) somehow connected to Papillio pins. Not discussed here as you are expected to have enough expertise to figure this out on your own What you will see on serial port (230400 bps) if everything is working correctly (this is very terse since string handling is a pain in VHDL): - C00 C08 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C02 C03 C07 C55 A06 C06 C24 C13 S Explanation of above data: "-" gets sent on reset, it means the process is starting over "C00" is the reset command sent to the SD card. It expects no response. "C08" is the voltage-request command and is only supported on newer cards. The Papillio requests normal 3.3V operation. If I/O is not working, or if the SD card does not support this command, this is the last line you will see. "C55/A41" is the init command. It usually needs to be repeated over and over again until initialization is finished which is normal. "C02" is the "get SD card CID" command. It is required otherwise I wouldn't bother sending it. "C03" is the "get SD card's relative address" command. It is also required. "C07" puts the SD card into transfer mode. "C55/A06" switches the SD card from a 1-bit bus into a 4-bit bus (4x speed increase). "C06" switches the SD card from 25 MHz mode to 50 MHz mode (2x speed increase). If you see an "E" after this, it means that the CRC check failed (this happened to me occasionally during development). "C24" starts writing a single 512 byte block at address 0 (beginning of card). "C13" requests the card's status and is optional but it makes me feel better to see it working since at this point we are communicating at 50 MHz. "S" means 'success' and means that the SD card responded that the write operation was completely successful. If you see an "E" here it means that the CRC check probably failed. If you see anything with "X" in front of it, it means that an unexpected response was received and the unexpected response has been dumped out in ASCII hex format. This is for troubleshooting purposes. This post has been promoted to an article
  15. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Ok, I got the RAM working using this inference method. Slick! Thanks for the tip! It would've taken me forever to find that on my own! Now I've got a question about clocks. The way the SD card works is during initialization its clock needs to run at 400 kHz but at some point it can be configured to run at 50 MHz (which is my goal). So I am using a 100 MHz clock generated from the DCM to derive both of these target clocks from. I've got a little clock divider thingy going on but being the newbie that I am I'm probably doing something wrong (plus I am getting a new warning now). The new warning is: "Phase 8 : 0 unrouted; WARNING:Route:455 - CLK Net:myclk100 may have excessive skew because 0 CLK pins and 2 NON_CLK pins failed to route using a CLK template." And here is my clock divider: divider: process(sd_clk100_in, bDivideClock)variable clock_counter : integer range 0 to 62;beginif bDivideClock = '1' thenif rising_edge(sd_clk100_in) then-- if we are dividing the clock-- 100,000,000 Hz / (400,000 Hz * 2 for double clock * 2 for falling_edge) = 62.5-- see section 4.2.1 for 400KHz frequency noteif (clock_counter = 62) thensd_clk_2x <= NOT(sd_clk_2x);clock_counter := 0;elseclock_counter := clock_counter + 1;end if;end if;-- else let it go full blast!elsesd_clk_2x <= sd_clk100_in;end if;end process; (I divide the sd_clk_2x in another process down to just sd_clk due to me seeing someone else doing that with his SPI SD card code, so I figure it may come in handy) The problem area is in bold. I am pretty sure this is bad practice. But I'm not sure what else to do. I could have two clocks but I have a bunch of utility stuff inside one of my processes (which I can't figure out how to get out due to my inexperience) so if I had two clocks I'd have to duplicate the utility stuff which I definitely know would be the wrong approach. I know that having huge processes is a Bad Thing but I have not been able to avoid it here even though I've looked for ways. The good news is that despite this warning, I am reading and writing to the SD card (apparently at 50 MHz!) which is awesome!
  16. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Thanks! I will play around with this soon and hopefully report back with a successful tale
  17. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Ok, I'm to the point of this SD card writing business that I need to ask... How does memory work on the FPGA? Does it have any internal RAM? Is it crazy to try to make a massively large resistor (ie 4096 bit) to behave like memory? I know from reading Hamster's guide that it has internal ROM but I am unclear if it also has RAM. Basically, I think that I need maybe 1k of RAM (to be safe) that can be written to at 50 MHz. The details: I will be reading from the ADC at 15 MHz and we can assume 8-bits for now for simplicity. The SD card accepts writes in 512 byte blocks and it has a short delay between each block while it writes to its internal storage. Its clock runs at 50 MHz (in high speed mode) and can write 4 bits per clock, so its bus can essentially receive data at a rate of 25 megabytes/second minus the delay in writing each block (when writing multiple blocks, this delay can be reduced). So assuming the SD card can write at an average of over 15 megabytes/second when doing a continuous stream (which I think is possible as I was seeing those rates above that when I plugged it into a usb adapter), I will need some kind of buffer to hold data from the ADC while the SD card is busy between 512 byte blocks. For fun, I tried creating a 4096 bit std_logic_vector but I was informed that I had exceeded the maximum space for the FPGA (this made me sad). So what is the standard way of getting RAM on these things? I appreciate any help! --Matt
  18. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    I've finally worked out enough of the issues in my VHDL code that I've been able to successfully write 512 bytes to the SD card. Here is how the correct CRC and response now look. I've also fixed the way that I output to the CMD and DATA lines so that it is consistent with the way that the SD card does it (ie the correct way).
  19. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    yikes! ohwell, thanks for finding that for me! I've made more progress on talking to the SD card. I've now completely finished the initialization sequence and am in transfer mode and ready to start multi-block writing. That will be my next task when I work on this again. I've also beefed up the logger. It is really inefficient but still meets my timing constraints so I am pleased. Here is what the logger spits out. My comments are in italics. - ResetC00 go idleC08 notify SD card that we're using 3.3V and we can support newer commandsC55 get ready to send ACMD41A41 initializeC55 initialization is busy, so we keep looping until it's readyA41C55A41C55A41C55A41C55A41C55A41C55A41C55A41C02 get SD card's CIDC03 get SD card's relative addressC07 select this SD card for transfer modeC13 get current statusC55 get ready to send ACMD6A06 switch into 4-bit (wide) data bus instead of 1-bit data busC06 switch from 25 MHz to 50 MHz (ie "high speed" mode)
  20. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Great, I'm glad you're interested I'm a little embarrassed at you seeing my code since this is basically my first attempt at VHDL and I mostly write software in C/C++/C# (with occasional assembly language for good measure!) but maybe you will be able to help give me some tips to improve it. One question I have right now is... how the heck do you do ASCII notation? For my logger, I am doing stuff like: sd_log_byte <= X"49"; -- 'I' meaning I want to sent an "I" to the serial port to show I am initializing... but I have to keep looking up ASCII values and then putting in their hex equivalents. It is a pain. I've googled for "ascii notation" and am not getting very far (ie nowhere).
  21. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Hi Hamster, I didn't realize that I never responded to this but I appreciate you posting that link. At first I thought you were saying that you were sending 512 megabytes/second up the serial port and I thought "What the heck?" Then I looked at your code and it appears you are just logging an occasional snapshot or .. something. I am still a bit too new to see exactly what is going on. But! I wanted to give an update on my end... I got the serial logger working. I ended up just having a buffer size of 1 byte (hehe) so I can do some primitive logging that way. it is good enough for my purposes. I wrote a program on the PC end that spits out any byte it receives as ASCII hex. I also have successfully started talking to an SD card (in SD mode, not SPI mode*) and hope to be writing bits to the card soon. I'm halfway through the init phase (there are like 10 commands you need to send to actually get out of init, it's a bit of a mess but once you have code in place to send the first few commands the rest are pretty much the same). * - I've been searching on google for example code showing how to talk to SD cards in SD mode but I have found exactly 0 examples! Everyone seems to heavily favor SPI mode. I don't get it. I know SD mode is "evil" because it is encumbered by proprietary shackles, and SPI is an open standard, but SPI mode also performs at best 4 times slower than SD mode so I thought someone would eventually say "screw it, here is how to do SD mode". I guess I was wrong! Anyway, since I am building a one-off solution that only I (and maybe a few close friends) will be using, I have absolutely no problem using SD mode because I need the speed. --Matt
  22. Matt Ownby

    Writing to an SD card and logging via FTDI usb port

    Hi! Thanks for your response! I realize this. But what if two things see that the log is ready and both try to add new content to it at the same time? Chaos would ensue. I think I've figured out how to deal with this though. I just won't let multiple sources write to the log; instead I will make the log pull from known sources. That way only one thing will be writing to the FIFO buffer. Ah, please forgive me. I talk about things from a software paradigm because that's the easiest way for me to describe them. My hope is that if I describe them from a software POV that smart people like you guys will understand what I am trying to say anyway. Well, my first exercise will be trying to write (unfragmented) a bulk page of bytes to the card and see how fast I can do it. I will be using a UHS class card and will not using a file system. Just trying to do a raw write. Thanks for your help!
  23. Matt Ownby

    Problems with ISE Source Wizard

    Thanks for this thread, guys. I had the exact same problem and now I am on my way to downloading ISE 14.3
  24. Matt Ownby

    Using Papilio with the TV-out wing (newbie to FPGA)

    Dear Hamster (and others who may be interested), I've got some feedback for your excellent PDF book as I have been going through it step by step. (and since I am a newbie, I may be able to spot some things that veteran proof-readers may gloss over) First of all, thank you for working on this book! It has saved me a TON of time already! Just getting the xilinx ISE stuff setup was a life saver! Here are some things I have got hung up on so far: Section 5.1 it says: You want the package called "Full Installer for Windows" or "Full Installer for Linux"-- one of the options given when you run the installer is to install the "cut down" WebPack version. I went ahead and assumed that you were saying we should install the WebPack version, but you may want to reword this from the passive "one of the options given when you run..." to the more assertive "Choose the WebPack version from the list of options." or something along those lines as I was a little hesitant to proceed here. Also I have just completed section 6 ("Your First Project"). In section 6.3 it tells us to setup some constraints which appears to me to be saying that switch_0 is mapped to P17 on the Papilio, etc. So far so good. I also successfully built the switches_leds.bit and run it through the papilio programmer. The window closed so quickly that I couldn't really tell if it succeeded or not but I am assuming it did. It was pretty fast. (but it may not have succeeded, how would I tell?) UPDATE: I have confirmed that I am programming it successfully, see below. But when I get to the end of the section 6, I am expecting some kind of "here's where you plug in on the Papilio board to test it, and here's what kind of voltage you can send through these pins" paragraphs but I didn't find them. Not wanting to throw my hands up at the first sign of trouble, I attempted to figure this out on my own and I did make a bit of progress but I am stuck. Here's what I've done so far: I found this page (http://www.gadgetfactory.net/blog/wp-content/uploads/2011/02/Papilio_Pins.png) which I am assuming is accurate. I believe I've found the right holes to plug in at. UPDATE: I've confirmed that I've found the right holes, see below. As I have the Papilio which has no LEDs or buttons on it, I decided to try to use my Atmel STK600 ( http://www.atmel.com/tools/stk600.aspx ) board which has both buttons and LEDs built into it. The buttons are active low as are the LEDs, but I figure this shouldn't matter (although if it does, that would be good information to know). So I plug in a wire from the STK600's button 0 into P4 which means I now have 5V going into P4. Then I plug another wire from P17 into LED0 on the STK600. The LED instantly lights up meaning it is getting GND basically. This is not what I am expecting to happen. So I remove the wire from P17 and plug it into my oscilloscope. I am seeing nothing but 0V here even if I press the button 0 on the STK600. In other words, nothing seems to be happening. Then I try just plugging in 5V, 3.3V, 2.5V from the Papilio pins into P4 just to see if I can see _something_ change on P17. Still nothing. (incidentally, is this bad? I saw nothing in the PDF about what kind of voltages are safe to use on these pins. If there are constraints, that might be a good idea to add in the tutorial! hehehe) Any help would be appreciated. UPDATE: I tried changing "LED_0 <= switch_0" to "LED_0 <= '1'" and I was able to see about 3.1V (3.3V? probably lower because I am using the USB power) on my scope on P17. so this means I am programming my FPGA successfully. Also, I changed the .ucf file so that LED_0 points to P4 instead of P17 and again I am now seeing 3.1V on P4 as an output. So I can therefore conclude: - I am programming the FPGA successfully - I have located P17 and P4 successfully UPDATE #2: Ok I think I solved my own questions here. But thanks for letting me talk through this! - Still a little confused about what LVTTL means. Does that mean it only works with 3.3V-GND ? - Verified (using scope) that P4 will output to P17 both GND and 3.3V (I just plugged a wire from the 3.3V hole to P4 and got it working). I am not going to attempt 5V again until someone tells me whether it is safe. I can settle for 3.3V now for my testing.
  25. Hi all, I am big into writing laserdisc arcade game emulators ( http://www.daphne-emu.com ) and emulating laserdisc players ( http://www.laserdisc-replacement.com ). Recently I've becoming interested in learning more about composite video in hopes of generating my own NTSC video signal. Some googling let me to the TV-out project for the Papilio ( http://papilio.cc/index.php?n=Playground.TVOutputWing ). I am very eager to try this out. I've ordered the parts from the parts list. One thing though, I am pretty sure based on the parts that I've ordered that I am not going to have any pin headers to plug into the "wing" slot on my Papilio (also recently ordered). So I am guessing this is missing from the parts list. Can someone point me to which part this would be so I can solder onto the board when I get it from BatchPCB? Or.. maybe I am totally misunderstanding how wings work, lol. I just looked at the batchPCB image and it actually looks different than the parts that I ordered. *gulp* Also I went through the "getting started" section which installs a "hello world" type program on the Papilio and outputs via the USB serial port. Got that working just fine. But when I wanted to go further I was prompted to install an Arduino IDE. This is where I started to put on the brakes because I thought "Wait a second.. I don't want to write programs that run in an emulated AVR because I have a bunch of real AVR's sitting right here on my desk. I want to do this VHDL stuff." I notice that the TV-out "wing" provides VHDL source code but I have been unable to find anything on this site (and believe me, I've tried) that explains how to compile a simple "hello world" VHDL program or even what compiler to use! So this must be such an obvious known fact that no one thought to put it anywhere on the site! lol... but with me being a VHDL newbie, I have no idea which compiler it is that everyone is using. I've seen some references to "Xilinx ISE". Would that be the compiler? Or is everyone using something else? Basically I just want to get that TV out wing working so I can start modifying it and learning more about NTSC. Thanks! --Matt