Lee O'D

  • Content count

  • Joined

  • Last visited

  • Days Won


Lee O'D last won the day on April 5 2013

Lee O'D had the most liked content!

Community Reputation

1 Neutral

About Lee O'D

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Sheffield, England
  • Interests
    Audio hardware and software, chiptunes, extreme bass
  1. Lee O'D

    Working with I2S audio CODECs

    Sure, I'll share what I can when it's up and working. I will be making something vaguely wing form factor, depending on how much hardware I can fit onto the board (and whether i'll split off the analogue section to reduce noise). Cheers
  2. Lee O'D

    Working with I2S audio CODECs

    Thanks Steve, I managed to get simulation running ok. Managed to get some issues with the clocks resolved once the simulation was online. Now sounding 100% Next step is to get the data in, de-serialised and start doing things with it! Lee
  3. Lee O'D

    Working with I2S audio CODECs

    Hi all, So i've had a bit of time, managed to hack together the Wolfson 8569 onto a DIL breakout board and wire it up to receive clocks from the Papilio (C0=MCLK, C1=BCLK, C2=LRCLK for now). I used the PLL with 28x multiplier and 73 divider to get 12.274MHz MCLK (which is only 0.11% slow from 12.288MHz), and then used RTL to divide by 4 for the BCLK and by 64 for the LRCLK. For now i'm just looping the ADC digital out into the DAC in - getting the data into the FPGA will be the next step. I used hardware mode which means that I don't need to mess around with the SPI registers, and I can get 24 bit right justified out, which also means I don't need to implement I2S. I measured all the clocks on my scope and they were looking correct (though I only have a single channel scope, so checking the phase wasn't possible). Annoyingly I got zero output from the chip. Having given up last night, I checked everything today and same result. Then I realised that I hadn't selected fast slew on the clock outputs. Strangely, it works 100% when I have fast slew on the MCLK and BCLK, but leave the LRCLK with standard slew rate - weird! I don't have a proper PCB etc so perhaps there's some jitter getting in or something. Anyway, it sounds 100% with this configuration. I decided to use the onboard PLL, as when the design is done I will add a proper 12.288 or 24.576MHz crystal to an input pin and get all the clocks 100% accurate. I'm still finding my feet a bit around ISE etc (haven't done VHDL/FPGAs for over a decade, back in those days it was XACTstep and XC4000s), and I'm not entirely sure how to set simulation up - so I'm quite pleased to have something working in hardware after half a day! Cheers Lee
  4. Lee O'D

    Working with I2S audio CODECs

    Hi Steve, Yes I think for the final project implementation I would get a precise 12.288MHz crystal which are readily available, this was basically so I could get a basic prototype running with the parts I have to hand (Pap Pro, Wolfson 8569 CODEC, SSOP to DIL breakout board) to get moving on the HDL front. It should be easy later to swap out this temporary clock generator with a low jitter accurate one. I'll have a go with Hamster's code, solder up the parts and see if I can get any sampling going! Any thoughts on benefits of I2S vs right justified mode (the chip default is 16 bit right justified, I think this may be the simplest as it's just clocking data in/out MSB first,,,)? Thanks
  5. Lee O'D

    Working with I2S audio CODECs

    Hi all, Many thanks for all the info. Some great food for thought there. So I had tried using the clock wizard in ISE, but this couldn't get close to the desired clock frequency (and the jitter seemed pretty big too). This was using PLL_BASE, would DCM be any more accurate? Hamster - your code seems really interesting, using the same calculation, for me to generate a 12.288MHz clock (which is 48kHz x 256 as the ideal clock), then I'd get: 32 MHz -> 12.288 MHz= 32000000 / 12288000 = 2.604166666666666= 2 + 7424000 / 12288000= 2 + 29/48 (NB I assume FPGA clock at 32MHz, obviously if I decided to run the rest of the system faster I would need to scale up the values here, eg 96MHz source came out as = 7 + 39 / 48...) These values seem quite reasonable, do you think these values should work with your code (ie they are quite a lot smaller ratios than your SPDIF example)? I guess I will give it a go and see.. How can you estimate the amount of jitter - it is just +/- half the period of the source clock? Is this the period of the system clock (if I multiply up) or the physical crystal speed? Very interesting thoughts anyway, I must admit generating clocks ourselves rather than using the inbuilt clock generation isn't something that had occurred to me! The rest of the project (which will include EQ etc) will also be a challenge, but I'm starting small by just trying to get data in and out of the CODEC intact, then some simple summations etc - and go on from there. Cheers Lee
  6. Lee O'D

    Working with I2S audio CODECs

    Hi there, I'm starting a new project to provide basic audio mixing in the digital domain, using a bunch of 2 in / 2 out audio CODECs. They all seem to be very similar in spec, and typically use a 16 or 24 bit transport over I2S (though you can configure other protocols such as raw 16 or 24 bit frames). I would drive all the CODECs (probably 8 of them) from common system, bit and channel clocks, and just have individual pins for the data in and outs which should keep the pin count down. I have two main challenges to begin with, and I was wondering if anyone could offer some advice: 1. Providing a master I2S interface (with the CODECs running as slaves), there are a few example VHDL libraries out there (eg http://opencores.org/project,i2s_interface ), but if anyone has had success with any libraries out there, or used the other protocols to interface the CODECs if it's simpler? 2. Providing a synthesized clock of the right rate. Depending on the sample rate (44.1 or 48kHz) I would need to provide either 11.2896 or 12.288 MHz CODEC system clock, with the other clocks being divided/counted from that. Clearly these are odd rates to derive from the 32MHz crystal, and would ideally need to be fairly accurate. Any pointers / recommendations on how to start on this please on the Spartan 6, this has clearly been tackled for eg video clock generation? Many thanks everyone Lee
  7. Lee O'D

    ISE file for Retrocade (Pro)

    Thanks Alvie. I quite surprised myself by being able to get the design to synthesize, implement (all constraints met from the ucf), and generate a bit file - which worked (after putting back the sketch)!! There were loads of warnings during the process, but nothing that looked abnormal - is this what you get? Many thanks!
  8. Hi, I wasn't sure whether this belongs in the Pap Pro or Retrocade forum... So I've been meaning to find the time to pull down the git repos for the Pap Pro with the Retrocade peripherals such that I can finally start having a play with the HDL. As per the readme.txt in the retrocade ZPUino_SOC directory I was hoping that there would be an ISE project file so that I can pull in the project with all the components into ISE easily, but there doesn't seem to be an ISE directory or file within the retrocade variant as per the instructions: "To load the ZPUino RetroCade variant install Xilinx ISE Webpack and open:zpuino\boards\papilio-pro\S6LX9\variants\retrocade\ise\ise.xise" There is an ise file for the Pap One (retrocade lite) however which loads up fine... Is this missing from the repo, intentionally not there or just me being daft? :-) Thanks guys Lee
  9. Lee O'D

    SID Filters

    Yep - fully aware of the FPGA64, was just thinking that the SID would be so much better now... :-)
  10. Lee O'D

    NoteOff Issues

    Excellent glad I could help get you fixed.
  11. Lee O'D

    SID Filters

    Just been giving the new bit file a run through - I think we're pretty much there, I've listened to a few tunes and I can't spot any obvious issues! Well done guys, mightily impressed with the coding and turnaround time on these issues! I've noticed also since the direct register writing fix, the timing seems to be better. I think previously all the unnecessary writing to ram and then copying to registers was slowing down the ZPUino player too much, seems to sound a lot tighter now. Just as an aside, although my primary interest is for a standalone SID / POKEY / YM MIDI synth module (a hardware version of Plogue chipsounds is basically what I'm after!), I'm wondering from the papilio arcade side of the house, is there a desire to produce a full C64 as an output - a full SID with filters is obviously a big (and most exciting!) part, the PLA/CIAs are dead easy though the VIC-II would take some work (although obviously there's other HDL out there already for that)? Well done guys
  12. Lee O'D

    SID Filters

    Excellent, will give this a try tonight when I get home!
  13. Lee O'D

    SID Filters

    I agree that the envelope triggering issue is fixed with the direct register writing, which is great. There's definitely still something amiss with the voicing. Compare these attachments for Ghostbusters 2 - it's Sidplay and the retrocade (with the latest code from above). The drums sound completely different / very hard to hear on the retrocade? Any ideas? Thanks guys GHOSTBU2.mp3 GHOSTBU2_Retro.mp3
  14. Lee O'D

    SID Filters

    Brilliant, you know I was looking at the same thing last night before I ran out of time. I was mainly thinking about whether there was anything that was triggered if the same values were written into the register would perhaps restart the envelope... not the answer but I was close! Wouldn't it be better to arrange the code as: while (1) {while (!tick);tick=0;int clocks = cpuJSR(play_addr,0);//printf("Ticck? %d\n",clocks);.... Just because in the order it's in at the moment, it will do the code (with reg updates) and then wait for the tick. If there's any serial activity (or future code) it would slow down the time before reaching the next code execution? In this way it's closer to the real ISR in that the VBI would start the next round of code (and reg updates) immediately? Glad to see it's all working, yay! Alvie - very keen to see the new HDL when you can publish it please! Cheers
  15. Lee O'D

    SID Filters

    Just had a look, tried a couple of songs and I couldn't see any reads or writes to VIC, CIA1 or CIA2, or reads from SID (D000-D800, DC00-DDFF), so not sure... I also checked the IO register and that was set to all RAM mapped in, and I/O from D000-DFFF (no ROM) in the unlikely event that they were somehow reading stuff from the ROMs... Jack, so the one thing your combination didn't list as trying was ACID64 playing into the SID with filters? Just to fully rule out the VHDL side? In that case it should sound fine if the tinySID / SIDdumper is suspected as not emulating correctly...? Cheers