hoglet

Members
  • Content count

    37
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

3 Neutral

About hoglet

  • Rank
    Advanced Member

Profile Information

  • Gender Not Telling
  1. Fractal project with Papilio Duo

    Another update. I've now returned to Mike Field's original design, and done some work to port this to the Papilio Duo + Classic Computing shield. The main difference from the Papilio Plus is the memory is 512KBx8 rather than 256KBx16. This entailed a re-write of the memory controller to deal with half the memory bandwidth, but nothing else. I also added in the colour maps from Larry's Mandelbrot-Explorer. This is working very nicely indeed, panning is super smooth, and multiple colour maps is really funky. The picture below doesn't really do it justice! If anyone want to try this out, the source is it github, and I'm happy to post a .bit file on request: https://github.com/hoglet67/DSPFract Dave
  2. Fractal project with Papilio Duo

    Thanks Larry, I've got it mostly working now, with some minor tweaks for using the buttons on the classic computing shield: https://github.com/hoglet67/Mandelbrot-Explorer/commits/master The only issue I'm seeing is that at the most zoomed out view there are some corruptions to the image in the cornest, which look like come pixels not being updated (i.e. if you zoom in and then zoom out you see some ghosting of the image from the previous zoom level). Hitting the redraw button multiple times causes these to be eventually corrected. I haven't investigated the cause of this yet. I did notice the design didn't seem to meet timing @ 200MHz, so it's possible this is a factor. Is this something you have ever seen? Dave
  3. Fractal project with Papilio Duo

    Larry, Thanks for this excellent project. I'm trying to rebuild from the soures you have posted on github: https://github.com/elkayem/Mandelbrot-Explorer This is so I can use the Classic Computing shield. To do this I need to re-create the FIFO and DCM cores in Core Generator (as you haven't checked in any implementation of these). What depth is the FIFO? What are the two clocks (clk_200 and clk_m)? From the comments I'm guessing 200MHz for both. I'm sure I'll have more questions if that is OK. Dave
  4. Use of D53 (INIT_B) as an input

    Thanks for confirming this Jack. In the end I just de-soldered bit 0 of the wing, and reconnected the signal elsewhere. It's now working fine. Dave
  5. I'm using the 16 bit input wing (LXC16245 based) and, for physical reasons, I would like to plug this into ports DH/DL on the Duo. When I do this, I'm sometimes experiencing a failure for the design to configure, until the wing is physically removed. I've tracked this down to pin Bit 0 of the wing being low. This connects to D53 which is then routed to the Xilinx INIT_B pin. So it seems like D53 cannot safely be used as a user input (both the shields use this as an output so are fine). Is this a known issue? I can work around this by simply not using Bit 0 of the input wing, and tying it high. But I'm concerned of the possibility of conflicts during configuration, as INIT_B is an open drain output, and can this be driven low. I guess I could go one step further and de solder the pin on the wing that connects to the Duo. Anyone got any thoughts on this? Dave
  6. Hi MamboDee, Remote debugging is always fun Can you also post your constraints (.ucf) file? Then we can check what pins you are using. I assume you are using the on-board oscillator, which is 32MHz not 35MHz.(just a typo because you have the right period: 31.25ns) What are you expecting the result to look like? It should be 153.8KHz clock that is high for 31.25ns then low for 6468.75ns. Is this what you are expecting? Could you post a screen shot or photo of what you are seeing? Dave
  7. Papilio one 250K discontinued?

    Thanks Jack.
  8. Hi all, Does anyone know if the Papilio One 250K is being discontinued? There's currently none in stock at SeeedStudio, and only a few left at the GadgetFactory store. Dave
  9. Acorn Atom on the Duo

    Foft, Thanks for those links. Turns out we are both using the same code (even the comments are identical). I'll do some diffs later, to see if there are any subtle variations. This just isn't making sense.... Dave
  10. Acorn Atom on the Duo

    Foft, Thanks for that info - very useful. What's really weird in this case is it's failing very early on - at the CMD0 - and up to this point I can't see any difference between your flow chart, and what the Atom code is doing. Can I ask what kind of speed the SD Clock would be running at in the Atari? Dave
  11. Acorn Atom on the Duo

    Hi Goos, Whey you have the time, the first think to check is that none of those four signals appear stuck at either '0' or '1'. i.e. When you press F10, you should see some transitions happening on each of them. Dave
  12. Acorn Atom on the Duo

    For anyone else following this, here is Goos's debug log: stdio initialisedcompiled at 16:34:42 on May 14 2015SerialPort0AVR CMD=0xfeAVR CMD=0xfeAVR CMD=0xfeAVR CMD=0x80mmc_initializesend_cmd cmd=0x40, arg=0x00000000send_cmd ret=0xffmmc_initialize set CardType to 0x00AVR CMD=0xf0The first command being sent to the SD Card (0x40) is the "Go To Idle" command. The expected response is 0x01, where as you are getting 0xFF. I get exactly this output when no card is present. It looks like the data line from the SDCARD (MISO) is stuck high. Do you get this same output with all the cards you have tried? As you have an scope, it's worth trying to capture the signals on the SD Card interface. You can see where they are on this diagram:http://papilio.cc/uploads/Papilio/Papilio%20DUO%20pinout%20for%20CC.pdf The signals you want to probe are:- SD SCK (P114)- SD MOSI (P115)- SD MISO (P118)- SD CS (P112) If it helps, I can capture the waveforms that I'm getting as a reference. Dave
  13. Acorn Atom on the Duo

    Hi Goos, Here is a debug build for you to try: https://github.com/hoglet67/AtomFpga/blob/master/Atomic_top_duo_debug.bit I've added some code to the AVR firmware to output some debugging info to the USB Serial Port 1. This is sent at 57600 baud (8 bits/no parity/1 stop bit). This is what I see when I hit break (F10): stdio initialisedcompiled at 16:34:42 on May 14 2015SerialPort0AVR CMD=0xfeAVR CMD=0xfeAVR CMD=0xfeAVR CMD=0x80mmc_initializesend_cmd cmd=0x40, arg=0x00000000send_cmd ret=0x01send_cmd cmd=0x48, arg=0x000001aasend_cmd ret=0x01send_cmd cmd=0x77, arg=0x00000000send_cmd ret=0x01send_cmd cmd=0x69, arg=0x40000000send_cmd ret=0x01send_cmd cmd=0x77, arg=0x00000000send_cmd ret=0x01send_cmd cmd=0x69, arg=0x40000000send_cmd ret=0x00send_cmd cmd=0x7a, arg=0x00000000send_cmd ret=0x00detected SDv2mmc_initialize set CardType to 0x0cAVR CMD=0xf0 Let me know how you get on. Dave
  14. Acorn Atom on the Duo

    Hi Goos, If the card type with *HELP is showing up as N/A that means the AVR Firmware has not detected a valid card. This is the same value that would be returned if there was no card present at all. This is especially weird as: - you have tried several different brand cards - you have verified the card slot on the classic computing shield works with the Atari 800 design, so there is no simple hardware fault - other people, myself included, have downloaded this same bit-stream and not encountered the problem Can you post the complete response of *HELP please? I want to make sure the various software versions are as expected. This will confirm that the AVR Soft Core is executing code. I'm sure we will get to the bottom of this, it might just take some time. Do you have access to an oscilloscope or a logic analyser? Dave
  15. Acorn Atom on the Duo

    I just tried another card - a Phillips branded one. This is 16GB and formatted with FAT32 and this worked fine as well. So I'm a bit stumped. Dave