• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by hoglet

  1. 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. 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. 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. 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
  5. 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
  6. 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
  7. 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
  8. Thanks Jack.
  9. Hi all, I received my Duo last week, and this weekend I've been porting the Acorn Atom FPGA design to run on it. Here's the end result: You can get more details from the thread over at stardot.org.uk. This design currently uses an AVR Soft Processor to run the AtomMMC software stack for the SDCard interface. My next step is to try switching to the ATmega32U4, which will free up quite a lot of FPGA resources. All of the VHDL code is on github: https://github.com/hoglet67/AtomFpga There is also a Duo bit file: https://github.com/hoglet67/AtomFpga/blob/master/Atomic_top_duo.bit If you want to try this out, you'll need the Atom Software Archive. Download AtomSoftwareArchive_20140817_V7.zip from the above thread, unzip it onto a blank FAT32 format MicroSD card, pop in into the Duo and hit Shift-F10 (F10 is mapped to the Atom Break key). Here's a screenshot of the Menu system help page: Search (S) is the single most useful way of finding a specific program, once you know what it's called. GALAXIAN (Bug Byte) is a good program to try first! Please let me know if you manage to get this working, either here, or over on the stardot.org.uk forums. Dave
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. Goos, I'm using one of these: http://www.johnlewis.com/sandisk-ultra-class-10-microsdhc-memory-card-8gb-48mb-s-with-sd-adapter/p1799183 I've just realized it is actually partitioned and formatted with a small (50MB) FAT file system. I wonder if there is an issue with either FAT32 or the filesystem size. I'll do some testing with a fresh card.... Dave
  18. Jack, Yes, just one SD Card issue remaining (Goos) The keyboard layout for the Atom is problematic to map to PC keyboard, and all of the emulators also have the same issue. It you look carefully at the attached photos, on the Atom most of the rows have 15 keys across, where as the PC keyboard has between 12 and 14 keys. The control and shift keys are also transposed. Control/Shift/Repeat are frequently using in games, as they are easy to read in software. I don't think much than can be done to improve the mapping, unfortunately. Dave
  19. Hi Pascal, I'm glad you got the keyboard sorted, and had no further problems. So, just one issue remaining: Goos's SDCard issue. Let's wait and see if a different card helps. Dave
  20. Pascal, I agree with you that pullups should be present on the PS/2 signals, so I've added them into the UCF file and rebuilt the bitstream. This is now pushed to github. Let me know if this makes any difference. Dave
  21. Pascal, I assume you are using Windows? Have you tried a different keyboard? The .xise file was created on Linux, so if you are trying to build it on Windows the Xilinx tools might be interpreting the path separator character incorrectly. You should just be able to re-add all the sources. Or you could try to fix up the .xise file manually. Does anyone know if .xise files are portable between Linux and Windows? The manual for the Acorn Atom can be downloaded from here: http://www.stardot.org.uk/forums/viewtopic.php?f=32&t=6370#p62322 Dave
  22. There was something fixed in the change log with 2.8: CHANGELOG 4/1/2015 Version 2.8 Papilio GUO -Fix for SPI Flash not programming correctly in simple mode. -Change the Operations buttons to check boxes. https://github.com/GadgetFactory/DesignLab/issues/24
  23. Goos, I wonder why the Papilio Loader 2.7 was just failing to FLASH my bitfile, but was OK with others ??? What do LEDs 1 and 2 do on power up? They should both flash briefly, then go out. LED1 indicates an access to the SD Card. LED2 indicates an error with the SD Card. It might be worth trying a different brand of SD Card if you have one. Dave
  24. Goos, I'm starting to run out of ideas. Maybe Jack could give this a try if he has a moment. Dave
  25. I've had one more thought (a bit of a long shot...) The AVR processor on the Duo shares lines with both the PS/2 A keyboard and SD card. It's possible that a design previously loaded in there is interfering with their operation. Could you try moving the slider switch on the Duo board is pointing towards the edge of the board. This should disable the AVR. Dave