Leaderboard


Popular Content

Showing content with the highest reputation since 03/27/2013 in all areas

  1. 3 points
    Hi everyone. Last year I wrote a Z80-based retro microcomputer which runs in the Papilio Pro. It started out small but I added a few interesting features, in particular a memory management unit and a 16KB cache to hide the SDRAM latency. I've ported several operating systems to it. Both the hardware and software aspects of the project have been good fun with lots of new opportunities to learn. I've just made my first public release, you can download it at http://sowerbutts.com/socz80/ and try it out. That page also describes the project in a bit more detail. RAM disk images are included to boot CP/M-2.2, MP/M-II and UZI (a UNIX system). I've included Zork and the Hitchhiker's Guide game which will play under all three operating systems; they are native CP/M application but MP/M-II implements the CP/M system calls, and UZI includes a CP/M emulator. The release also includes the full VHDL source code for the machine and the source code to all the software I've written, with the exception of the UZI port which I plan to release shortly after I extend it to support the N8VEM Mark IV SBC. Please let me know if you get it to work! This post has been promoted to an article
  2. 2 points
    Original version of game was running on PIC18F6622 and Dingoo A320. Now it's running on Papilio One 500K + Arcade Megawing. I've used the ZPUino soft processor which is realized by Xilinx Spartan-3E FPGA. VGA signal is also generated by the FPGA. The game can be played with integrated buttons of Arcade Megawing or with Atari/Commodore joysticks. I've used a QuickShot II Plus (SVI-102 Plus) joystick in the video below: Demo Please, use the .bit file included in the ZIP. Otherwise buttons and joystick are not working properly. sometris_v121.zip
  3. 2 points
    Hi, I just got started with Papilio Pro last week (side note: Great work with the papilio family and wings.. Im really excited about the board's potential). The Pro was my first entry to the papilio line. I was mostly able to figure out how to get the board running and programming. But, many of the instructions/downloads on the papilio website are either outdated or directed towards Papilio One, so getting started took about 4 hours longer than I expected. I thought I'd put together a list of links and instructions for problems I encountered along the way so that perhaps others starting with the Papilio Pro could have something up-to-date (well, as of April 2013, that is): 1. Windows FTDI Drivers: I had some real trouble getting the Papilio recognized as both a USB and a virtual COM port. For my problem, the device was ALWAYS recognized on Windows-- even when I did not have the Gadget Factory drivers installed. And it never showed a virtual COM port. Troubleshooting suggests using a different cable, or editing the device properties. Apparently in my situation, the Papilio was recognized as an FTDI device first and was not using the Gadget Factory drivers. My solution: Download the FTDI CDM Uninstaller. Using FTDI's USBView utility, find the Device Vendor ID and Product ID. Use the CDM Uninstaller to uninstall the FTDI drivers for the Papilio. After plugging and replugging, Windows recognized a virtual COM port. I could also connect through putty and see the default ASCII table output which was apparently the factory default program. 2. Getting Started Bitfile: http://papilio.cc/index.php?n=Papilio.GettingStarted It appears as though the getting started website (as of April 5 2013) does not include the getting started bit file for Papilio Pro. In my beginner state, I assumed this website would have the materials I needed, so I fumbled around trying to use the Papilio One 500K bitfile. After a while, I realized it certainly doesnt make sense to try to use the Papilio One bitfile, especially since the Papilio Pro uses a completely different FPGA. I dont think I've found a replacement for the "Getting Started" bitfile for the LX9 yet. 3. Papilio Loader: As with the bitfiles, the Papilio Loader GUI on the Getting Started Page is out of date (it downloads v1.7). According to a forum discussion around December 2012, the Papilio Loader was modified to support the Papilio Pro. Download the Papilio Loader GUI specifically from the Downloads webpage (this should be version 2.1 or later): http://forum.gadgetfactory.net/index.php?/files/category/2-papilio-fpga/ 4. ZPUino Core and Loader: I think the official ZPUino download page is a little out of date for Papilio Pro. It looks like the papilio website ZPUino getting started guide is out of date too- It uses an old version of the IDE and does not include links for the Papilio Pro bitfiles. Instead a forum post indicates the RetroCade installer works with the Papilio Pro. So, to get the ZPUino to work, download the Retrocade Synth Windows Installer from the Download Page. Use the bitfile ZPUIno_SOC/zpuino-1.0-PapilioPro-S6LX9-RetroCade-1.0.bit to program the Pro. The installer should also include a version of the Arduino GUI which includes a board option for ZPUino on Papilio Pro (LX9). 5. Intro to FPGA Book: With a functioning Papilio Loader and a ZPUino core/ GUI, I was basically good to go with the Intro to FPGA E-book. I also installed the Xilinx toolchain as instructed. No issues there. I'm looking forward to generating and programming with my own bitfiles shortly. It would, however, be nice to have an updated Xilinx webpack quickstart page: http://papilio.cc/index.php?n=Papilio.XilinxISEWebpackQuickStart. EDIT: I installed the wrong Xilinx tools at first. The default link inside the Intro to FPGA E-book now leads to the Xilinx Vivado suite, which doesnt support the Spartan 3 or Spartan 6 series. Instead, make sure to download and install the ISE Design Suite. 6. Papilio Arcade: I also tried the papilio arcade wing. Just make sure to download the correct LX9 bit files from the github https://github.com/GadgetFactory/Papilio-Arcade I havent looked at the AVR8 softcore processor. This is on my list to test with the Papilio Pro, along with some other fun things (SoC editor is on the horizon too). Like I said, Im a big fan of the board. Overall, it looks to be a really great FPGA. I do want to see the usability/ learning curve get to the Arduino level, and it helps to have a good getting started procedure for all boards. Hopefully this helps another beginner in the same situation. Thanks for all the work so far! EJ
  4. 2 points
    This is a library for Designlab and Papilio Duo. The decoder module can have up to 4 encoders. For example 4 wheels on a mobile robot platform. Optionally this can be use with a PID regulator for controlling current position, velocity, and direction of an object. - The shown pins are totally optional - By default the Avr chip is disabled Download: Quadrature_decoder.zip
  5. 2 points
    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
  6. 2 points
    There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle. Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.
  7. 2 points
    Hi, not every pin can function as clock input. See here http://www.xilinx.com/support/documentation/user_guides/ug385.pdf page 30, search for "GCLK" in the name. Now did you know that there are PLLs inside the FPGA? It takes 2 min of work (maybe a bit more if you do it the first time) to run the core generator and turn the existing 32M clock into 20 MHz or whatever you like. It's one of the most useful features, IMO, in everyday use.
  8. 2 points
    ever heard of "paralysis by analysis"? My advice still stands: Don't try to buy the "best" or the "right" board. Just get any cheap board, spend two working weeks and learn to make that LED blink.
  9. 2 points
    Well after finishing this mini project I was very sad because the Double Dragon only has a handful of (not really that great) songs it can play over the YM2151 chip. I started looking around "teh nets" for more YM2151 music and eventually I arrived in Japan so to speak. I guess since Yamaha is a Japanese company it makes sense that it was adopted as the chip of choice on local computer systems. One such very popular system is the Sharp X68000 which as the name suggests, is based on a 68000 CPU. The cool thing about this system is that it has vast amounts of music created for it, here is a hard disk image with over thirty thousand music files on it. The music is in an MML (Music Macro Language) format and typically has an extension of .MDX In fact there are two types of files, .MDX and .PDX and after a fair amount of looking into these formats it turns out that while the MDX files are the Music Macro files, the PDX files contains sampled sounds that can accompany the melodies produced via FM modulation through the MDX files. In fact the PDX files contain 4 bit ADPCM data and they could be directly feed into a chip such as the MSM5205. Another cool thing is that some very nice people have written and open sourced an MML parser that can read MDX/PDX file combos and play them via a software implementation of the YM2151 chip and some generic ADPCM decoder. It is at this point that my other post comes in. With such vast amounts of YM2151 music it was only fair to find a way to play them, so I took the source of the MML player and carved out the software YM2151 implementation (which was in fact copied from MAME's implementation of the YM2151) and only left the calls to initialize the chip and write to the registers. I then had the initialization call simply pulse the reset line to the chip while the write register calls the FTDI functions to transfer the register data to the FPGA which in turn writes it to the real chip. The result can be seen in this 4 minute video. Hope you enjoy it! If the embedded video shows in portrait mode (tall and narrow) click on the youtube logo in the bottom right corner of the video and it will show properly in landscape mode.
  10. 2 points
    Hi, I've got my SDRAM controller up and running on the Papilio Pro as well as the Logi-Pi. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller It is running at 96MHz, but as it currently does the full "row open, read or write two words, close row" cycle for every memory access it isn't too fast. However, 24MB/s is more than fast enough if you have any audio projects in mind... flanger, delay, chorus, reverb etc Maybe somebody will write a nice roomy reverb for on the RetroCade?? 8MB is enough for 43 seconds of 48k/16bit audio. That gets you an awful lot of reverb!
  11. 2 points
    I decided to also port the Demon 3.07 verilog code to Papilio_One. This version is identical to the code running on the OpenBench Logic Sniffer board except for using 32MHz oscillator and using serial@115200 instead of SPI. It supports both meta data and input pin data query. The full XISE project can be found here: http://www.saanlima.com/download/Papilio_One/Papilio_One_OLS_3.07.zip 250K and 500K bit files are attached. Let me know if you notice any strange behavior. This post has been promoted to an articlelogic_sniffer_P1_250K.bit logic_sniffer_P1_500K.bit
  12. 1 point
    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
  13. 1 point
    I hit a brick wall on this for a couple of days - it locked correctly but no HSYNC or VSYNC was being detected by my TV. I've lent my 'scope to a friend to fix his stereo so decided to play with smart LEDs instead. However I had an minor epiphany tonight while getting the boy ready for bed - was looking for the wrong channel for the HSYNC and VSYNC signals. D'oh! Here's the test setup - Pipistrello generating HDMI (powered over the HDMI cable's 5V line! :-/ ), over to my HDMI input wing, then into the Papilio Pro, and out via the 8 bit analogue VGA output of the LogicStart. Holy C@#p - it works! Still a few little random pixel-level issues here and there. Looks like timing between clock domains and/or phase of the capture bit clock. But on the other hand, the errors look consistent between each colour channel - somewhere around the middle of the LSB. Might be a TMDS decode issue. I am stoked.
  14. 1 point
    USB host is hard because its a very complicated protocol you need to speak and the timings are tricky. USB slave is fair bit simpler, at least at the lower speeds. Simply using the USB connector is also not necessarily easy because on most FPGA boards it isn't wired to the FPGA directly in a useful fashion. The other problem for board choice and software is that Haider is in Iraq, and a lot of FPGA devices and software are on the controlled lists so export rules may be a problem (especially as the US enforces them its end with the 'shock and awe' scheme). Hamster: I assume you've seen http://jorisvr.nl/usb/, which only needs a UTMI buffer ? Alan
  15. 1 point
    I have often thought about a USB 1.0 stack (12Mb/s), based on the virtual USB HID for Arduino that you can set up with a couple of Zeners and a few resistors (http://www.practicalarduino.com/projects/virtual-usb-keyboard) However, even that is too hard for me to comtemplate moving to a FPGA, - every time I start to attempt it I feel like I am pounding my head against a brick wall.
  16. 1 point
    papilio-prog is not the same as xc3sprog. papilio-prog was forked off from xc3sprog way back and is using a different bscan file. I have attached a zip file with the vhdl source file as well as the ucf file for the qfp144 package. Hope this helps, Magnus bscan.zip
  17. 1 point
    I saw the excellent idea that Jack got to use the OLS-client's network interface to talk to a small socket server that then uses JTAG to talk to the FPGA, so I decided to use the same idea but instead talk to Pipistrello via the FTDI async fifo interface which should be much faster than using serial mode (see above). This is definitely work in progress but it's quite useful at this point. Here is how to set this up (currenlty windows only): 1) Download and unzip the attached zip file. It contains Pipistrello sniffer bit files as well as binary and source files for the programs used (with batch files to kick them off). 2) You need to change the Pipistrello FTDI eeprom setting to switch from serial to async-fifo mode using a program called setmode. The batch file set_fifo.bat will do that for you. 3) Power-cycle the board to reload the eeprom setting 4) Load the fifo version of the logic-sniffer bit file to the board (to flash or to ram) using flash_bitfile.bat or load_bitfile.bat 5) Start the server using start_server.bat 6) Start the OLS client and select Network connection type to localhost at port 5000 7) Capture data Use set_uart.bat to switch back the FTDI eeprom setting to serial mode. The server is quite verbose at this point (similar to Jack's screenshot). One limitation with this version of the code is that it's using blocking socket calls so it's not able to poll for reset commands from the OLS client while waiting for a trigger to happen. Also note that the official version of the OLS client has a limitation of maximum 256k samples (this is actually a limitation in the SUMP protocol) so you need the modified version of JaWi's OLS client that has extended the SUMP protocol with 32-bit size registers. Here is a link to that version (the file is too bit to attach): http://www.saanlima.com/download/pipistrello-v2.0/ols-0.9.8-SNAPSHOT-full.zip To capture and download 1 M samples of 32-bit data (i.e. 4 MB) takes less than a second so it's way faster than serial mode. See attached screen shot. Enjoy! Magnus Pipistrello_OLS_fifo.zip
  18. 1 point
    I haven't really had many thoughts on features I would like - I'm not really an ideas guy... However here is my five cents worth. I would prefer HDMI & uSD card to be a wing, as some day somebody will want HDMI-in and HDMI-out in the same project. It also seems to go against the idea of the FPGA board having no personality, allowing you to customise it with wings to meet your needs.I (most likely needlessly) worry about the power demands of shields and the additional I/OI love the idea of the PMOD compatible wings.sockets by adding GND+3V3 on the end of the connector.If you are going to go Arduino form factor and not have ADC on board then don't put the ADC header on. I'm sure people will get confused if you put a header, market as "Arduino compatible" and none of the analogue shields or sensors work Or at least add pads so the ADC signals could be jumpered to a ADC wing.I (most likely needlessly) worry that the 0.1" headers will become an increasing limitation due to signal integrity issues with more advanced add-ons (which conflicts to me wanting HDMI as a wing ).Decent mounting holes are a must-have.Has anybody ever got the differential input as a usable one-bit ADC to work? I've tried a couple of times with no useful results. It would be cheap and easy if a couple of pins could be made into a workable low-bandwidth/low rez ADC. An inexpensive all-passive 4-channel ADC wing might be possible using 4 differential pairs.
  19. 1 point
    I've ordered a batch of PCB from Seeed (ETA 3 weeks). If anybody would like one (less the through-hole components) just drop us a line. The pins are laid out for the Adafruit Themocouple Amp/ADC board, but should work with andything. It also has four general purpose LEDs on it
  20. 1 point
    Just reflash the quickstart bit file for your FPGA, if you just need an FPGA that does something, anything, all the stuff you need is on github
  21. 1 point
    How are the SID filters controlled? I don't see controls for them in the dashboard, are they mapped to CC messages?
  22. 1 point
    I have been playing with porting DOOM to Pipistrello. The code is based on the work Janne Kulmala and Juho Järvinen did to port Chocolate Doom to the Altera DE2 board using the NIOS soft processor, however a lot of changes have been made by me to make it run on Pipistrello using Microblaze. Here is how to get the game up and running: 1) unzip the doom.zip file somewhere on your computer 2) copy the file doom1.wad to a uSD card and insert it in the Pipistrello sd-card socket. 3) connect a monitor to pipstrello via HDMI and a sound system via the audio-out connector 4) program the pipistrello board with the doom.bit file to flash (i.e. fpgaprog -v -f doom.bit -b bscan_spi_lx45_csg324.bit -sa -r) After loading the program from flash to dram the DOOM welcome screen will come up etc.and the game is then running in demo mode. To play the game a PS2 keyboard is needed, connected to Pipistrello using either the Digilent PS2 PMOD module (via the lower row on the PMOD connector) or the Saanlima NES/PS2 PMOD card. I will post the source code after I have cleaned it up a bit. Enjoy! Magnus Edit: I should add that this is still a work-in-progress - the sound/music is still not quite right but the game is very playable as is. Here is a link to a short video showing it booting up and running in demo mode: http://www.saanlima.com/images/DOOM.MOV doom.zip
  23. 1 point
    Hi Rafael, For a frequency I chose the modulation values used was something like 1221381325 +/-1000000, so when transmitting the positive side of the square wave I used 1222381325, and for the negative side I use 1220381325. This gives the required depth of frequency modulation (a frequency change of approximately 75kHz). If you have an audio stream of signed 16-bit samples A(n), You could use 1221381325 + 32 * A(n) for your modulation. Actually getting the values from A(n) from the CODEC is a different project!
  24. 1 point
    Which FPGA was used for this batch?
  25. 1 point
    Hmm, this is something I started myself a while ago. One of the problems with extending the AVR softcore is that it just didn't seem to be built for a peripheral rich setup (IO space, etc). But I didn't want to leave an open source GCC based solution. Which is why I've watched the ZPU work with interest. I recently tried to use a quadrature interface from opencores, but it was far too featureful and resource heavy. So instead, I created my own "simple" quadrature interface for the ZPU, and using the standard HD44780 code in the ZPUino IDE install, created a sketch to read the quad counter and write to the LCD. It is so very nice to read a quadrature encoder as simply as: unsigned int y=REGISTER ( IO_SLOT (8) ,0); Serial.println(y); And to know that it is being clocked at 96Mhz. (Of course, I most probably have created a piece of junk, full of bugs - but I think it's cute) The code's a complete mess, but if you're interested... it's attached. View attachment: ZpuQuadDec.zip