All Activity

This stream auto-updates   

  1. Yesterday
  2. Thank you for the understanding and I'm sorry we don't have a better answer. The material in the old ebook is still valid with the Papilio DUO, so it is still a great read... Jack.
  3. Thanks for the answer, it isn't about the money (didn't ask for a refund/store credit for the broken plexi case either).. just would like to get some hands on experience.. and the ebook combination seemed to be a nice combo.. Guess I will try to pick up another book.. if anyone has any recommendations..
  4. Hello RoelandK, I'm sorry but the eBook was never updated. Mike Field was going to do the ebook but right after the kickstarter finished he got hired on at a new job where he suddenly found himself with much less time to work on Open Source projects... We spoke about the book several times since, and he really wants to do the book, but he just does not have the time anymore... I'm sorry that was never completed, if you would like a partial refund or a store credit please send us an email at and we will try to make this right for you. I have actually considered updating the ebook myself, but I think it would be after I finish up the next Papilio board and a new software suite to go with it since that will probably be the most beneficial to the Papilio community. After those are done then I think updating the ebook is the next step. Jack.
  5. On Windows 8 ArcadeBlaster didn't seem to work properly. I installed it on a Windows XP VM, but I didn't manage to get PacMan (or any other thing, IIRC) working on a Papilio Pro + LogicStart. I managed to get the DesignLab working on Windows XP (I didn't try it on newer Windows versions), and I tested that the audio DAC on my LogicStart is still working. I thought I had managed to blew it up somehow (although I don't know how I would blow up an RC filter), but it's working all right. (The audio jack doesn't seem to like stereo plugs though, if you insert the jack fully it only plays the mono audio on one side...) Now I have to figure out why the audio doesn't work correctly on my own RTL... I figured out the original problem (I had used the sox program to convert all my audio files to a known 8-bit 11K bitrate raw format, but I hadn't specified unsigned PCM, and my delta-sigma logic was using unsigned integers) but while diagnosing this issue the sound started playing at an extremely low volume and with an high pitch noise, and I'm not figuring out what's wrong... and I didn't keep a commit with the original design >< ...) Thanks for the help!
  6. Last week
  7. Yesterday
  8. hey, I ordered the papilio duo through the kickstarter long ago... and never really used it because i was waiting for an update of the ebook... recently found it again while moving.. so wanted to see if there was any update.. Yet i can't seem to find any updates about the ebook ...?
  9. Last week
  10. Synchronous resets are not an issue. Reseting the clock generator is General rule is: - If you have a single clock on your system, make sure the reset signal is deasserted at least one clock cycle after your clocking is stable. Do not deassert it if you use a DCM/PLL until it locks. Do not reset DCM/PLL unless you absolutely need to. - For multiple clocks its a bit more tricky. You will need a reset for each of your clock domains. Here async reset for the reset itself may prove useful - assert resets asynchronously, but deassert them synchronously for each of your clock domains. May not be enough, though. Alvie
  11. OK, so I figured this out... silly amateur mistake on my part. For the record, the problem was caused by using synchronous resets and also connecting the reset signal to the coregen'd clock core. This of course caused the clock core to stop and therefore parts of the design weren't getting the reset (synchronous reset won't reset without running clock). Interestingly the slower clock circuits were getting reset while the faster ones weren't. Anyway, lesson learned.
  12. Hey All, I've got a problem with a design I'm working on for Papilio Duo as follows: Programming SPI flash works fine and starts up correctly on every power on. After power on if I program the FPGA directly there's some randomness in whether it starts correctly. Usually it fails. Basically the Z80 code executes in a way that can "never happen". Either the T80 core isn't getting reset correctly or there's some issues with ram/rom. It looks like a CALL instruction is simply skipped. After programing to FPGA, using the reset button on the classic computing shield resets correctly - everytime. So... I'm wondering if there's something different about the reset procedure after programming directly to FPGA vs programming to SPI Flash using the reset button. I'm sure this is an issue in my design, but not really sure what to look for - any hints greatly appreciated. Brad
  13. Hello adamada, You should check all of your configuration settings. The easiest way to do that is to open the *.xise file and compare it to an xise file that is successfully generating a bit file that loads to spi flash. You have probably accidentally set the configuration to a quad spi chip or something... Jack.
  14. FYI: This is the FTDI board to rule them all: "-H" means high speed version, the MPSSE will clock up to 30 MHz and this works reliably with JTAG+Xilinx. You can get it from many vendors.The same exists for quad-channel FT4232H BTW, but I prefer the remaining pins as GPIO. It has proper protection circuitry on the USB port, which most other boards are lacking. I am using those in volume for industrial automation BTW.
  15. No, the ft232R does not have an MPSSE unit, which is what the Papilio loader is using for JTAG. Magnus
  16. Well this looks like the right thread to ask my question, rather than open a new one. Hopefully people will notice the new posting! I have been given a Spartan 3 based tiny PCB. It has a large SRAM, Flash ROM, 32 pin general purpose header, and a few switches and LEDs. It also has a 14 way header (smaller than 0.1") which I am told is for a standard Xilinx programmer. Well I don't have a Xilinx programmer, although I do have a cheap Chinese Altera programmer. So I wondered if I could use the programming circuitry on my Papilio One/Pro (I believe they are the same). The Papilio programmer appears to be based around the FTDI2232, a dual channel USB to UART. I am guessing that it is not used in serial "RS232" mode, but the JTAG pins are toggled high and low. Given that I cannot isolate the JTAG pins (TCK, TMS, TDI and TDO), the answer must be no. Interestingly there does appear a row of empty vias for soldering in a header for an external programmer, but I can't tap off from this as there would be contention on the TDO connection. Now I have a Sparkfun FDTI breakout board, but when I found it, it uses the single channel FDTI232R chip and not the dual channel chip. I have access to all pins. The question is, will this work with the Papilio Loader? Well I tried it out. Using simple COMMs software it works correctly as COM5 if I connect TX and RX. When I start the Papilio Loader, I get no messages to confirm that any programmer has been seen, nevertheless I loaded a random bit file and hit the "Run" button. For a few seconds the TX/RX (still linked together) light up, and then go out. The "Run" button is still greyed out. So is the Papilio Loader really using this single channel chip as a programmer? If there are multiple FDTI chips plugged into the USB, including a Papilio, how does the software figure out which to use? Note: I am using Papilio Loader 2.6. I think the latest version is 2.8, which I ought to try out. --Gary
  17. Earlier
  18. Here some additional information: I wanted to see if I could use DesignLab to upload bit files generated in ISE. So I went into the Libraries directory and created a library called custom. I imitated the directory structure of the other libraries, so my bit file was at "C:\DesignLab-1.0.8\libraries\custom\circuit\DUO_LX9\papilio_duo_lx9.bit". Then I loaded a blank sketch template and changed the line #define circuit blank to #define circuit custom and pressed upload. The console indicated it was uploading the proper file to SPI, but then once everything was done, nothing worked as it was supposed to (the same symptom when using Papilio Loader to SPI and not directly to FPGA). So this is really weird. Writing to persistent flash works with the example .bit files that come with DesignLab, but not with my own .bit files made in ISE. This is not a vital issue for my current project, because I was able to load the blank circuit onto SPI so that the AVR reset was not constantly on high. So now I can use the 32u4 chip, which is the only one my currently assigned project uses. But if I want to use the FPGA chip again, I'm still no further than I was before I posted here: writing to FPGA works, but no program I use can get my own bit files to write to SPI.
  19. So I downloaded DesignLab and it seems I can load the ZPUino QuickStart circuit and sketch onto my board from the examples, and it stays persistent when I reconnect power. So I guess the SPI flash is not totally broken. But my school isn't using the Spartan 6 for ZPUino at all. We have been using Xilinx ISE projects, generating bit files, and using the Papilio Loader to get them onto our boards. I don't believe the best solution should be to just stop using that toolchain all together.
  20. You can try using ZPUino itself to perform the SPI programming. Let me know if you need some pointers on how to do it. Contact me at Alvaro
  21. Hi. So I'm a student at Binghamton University's EECE department. We use the Papilio Duo boards (plus the LogicStart shield, but that's not relevant) for our design courses. I (and many others in my class) have been having an issue with writing FPGA bit files to the persistent SPI flash memory. Using Papilio Loader (or even papilio-prog) to write to the FPGA directly works fine, but it needs to stay plugged into the computer, and it loses the program when you disconnect the power. When I try to write to SPI Flash, the program output does not indicate any problems. It indicates it could erase, verify erase, write, and verify successfully. But then nothing functions, even when I remove and reapply power. It starts working again when I load the file to FPGA directly. I have tried this using multiple computers (Linux, Windows, OS X) and I still have this problem. I have tried both SW1 positions to no avail, I have tried pressing the "FPGA Reset" button, and I have tried triggering an FPGA reconfiguration using papilio-prog. Nothing seems to help. Is there a known fix for this, or should I contact support to request an exchange? Note that I was able to program to SPI Flash successfully until about a month ago. (I can't think of anything that should have caused this change). Thanks.
  22. Hey Brad, The 5V rail is connected directly to the USB connector so you should be able to draw as much as the USB socket can provide. If you are powering from a USB socket then it is limited to 500mA unless you are connecting through a powered hub. The Voltage regulator on the 3.3V rail can supply a maximum of 600mA if I remember correctly. Jack.
  23. Not sure if anyone noticed but there are a few new chip cores created by jotego who frequents at least on the zxuno and mist forums. (link to ym2151 clone, there are also ym2612 and a new take on sn76489) I don't own a synth wing so i've no idea if they would be an useful addition or not, nor how much work they would be to plug in. br, -V ps. the jt51 demo is using a new cycle accurate 6809 core which could be of interest to someone running old synth code on fpga
  24. thanks for the feedback
  25. Follow up... I finally figured it out. It was a combination of block number miscalculations and some timing errors in my design. The SD slot on classic computing shield works fine with both SD and SDHC cards (at least the ones I have). Thanks for the help.
  26. Hey all, Anyone know how much current I can safely draw from the 3.3 and 5V supplies on the Duo board. Looking to power 1x MAX7219 based 8x8 matrix module. Says max current draw is 2A, but I'm only going to be lighting a few leds and can dial down the brightness. Brad
  27. Thanks! I'll look into some of these options. In the meantime I haven't had much time to play with it, but I've tried 3 or 4 other cards now and still no luck. I'll post back when I figure it out.
  28. I think designlab has a ready to run example too.
  29. not sure what to suggest other than trying out Vlait's project to check the SD card interface.
  30. Hi All, First post here... I'm in the process of porting my FPGA 80's home computer to Papilio Duo but currently stumped by the SD card. I'm using a Papilio Duo and a Classic Computing Shield. What I'm seeing is exactly like what's described in this post - Basically the card initializes correctly as SDHC, a read command is issued, the read response returns success, the lead token on the data packet comes back as expected, but the data is all zeros. I've double checked the data on the card multiple times and it definitely contains data. The cause of the problem in the above post was related to voltage drops once the read starts. ie: the card initialization and most register related commands worked but any access to the actual memory resulted in zero data due to a 2v drop. So... I'm wondering if this might be a problem with the way I'm powering the board or with the shield itself. I'm powering it via USB port from my Macbook but have also tried USB plugged straight into a iPhone charger. Anyone else seen issues like this? Any help resolving this would be much appreciated including suggestions of other projects/designs that are known to work that I could use for testing the hardware side of things. Brad btw: here's the details on my project - - it's an FPGA emulation of a Microbee which was an 80's home computer designed and built here in Australia.
  31. Load more activity