• Content count

  • Joined

  • Last visited

  • Days Won


Posts 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:



    • Like 1

  2. Thanks Larry,

    I've got it mostly working now, with some minor tweaks for using the buttons on the classic computing shield:


    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?



  3. Larry,

    Thanks for this excellent project.

    I'm trying to rebuild from the soures you have posted on github:


    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.


  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?


  5. 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?



  6. 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?



  7. 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=0xf0

    The 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:
    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.

  8. Hi Goos,


    Here is a debug build for you to try:



    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.



  9. 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?



  10. 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.



  11. 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:




  12. 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.



  13. 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.