Hallo Besucher, der Thread wurde 8,3k mal aufgerufen und enthält 12 Antworten

letzter Beitrag von farvardin am

How to reprogramming swinsid nano?

  • Zitat


    Also how do I reprogram my swinsid nano? what kind of device do i need?


    You need a so called ISP programming adaptor with a 6pin ISP interface. This 6 pin cable must end in open pins, maybe a little soldering is required. An example can be seen a few posts earlier in this thread.


    You can also find an FAQ for the Nano Swinsid in this Sub-Forum, where I explained the commands needed to do the programming. It is in German language, but the commands don't need to be translated ;)

  • Here is the Nano swinsid that I bought.


    swinnano.jpg


    Looks like there are some caps missing. Am I correct? Or are those six holes for programming?




    Also, I have one of these Programmers, USB to TTL. It uses the STMicroelectronics Software to program a chip (Uses HEX Files).


    usb2ttl.jpg



    It has 5 wires. 3.3v / 5v / Ground / TX / RX.


    Will this work or do I have to buy a different programmer?


    Also what pins do I need to attach to the Swinsid to reprogram?

  • I assume one needs a normal Atmel programmer device. For instance


    http://www.ebay.de/itm/Brand-n…apter&hash=item337c43784d


    Most cheap programmers seem to have a 10 pin plug, but a simple converter to 6 pins should do the trick:


    http://www.ebay.de/itm/10-Pin-…%3D30%26sd%3D271036228380


    (Note that I have tested none of the devices linked above, those are purely examples and not buying recommendations)


    After soldering in the 6 pin header (which, I assume, voids warranty) you should be able to reflash the firmware (again, not tested by me).

  • hello,
    just a "stupid" question, I've ordered an isp avr programmer which should arrive soon, I want to reflash because I suspect the firmware of my swinsid (the same as on the picture, labelled swinsid v.2 (is it 2 or 0.2?) is quite outdated. Is there a way to learn the version installed on the board (or to get any informations)? Or at least to dump the data already programmed in the atmel chip?

  • Just to tell you I got an USBasp avr programmer (search for usbasp on ebay, I got mine for 10 €, including a 10 pins to 6 pins adapter). It seems to work but I had to adapt the code, I copy there if it can help.


    Also, the pin labelled MISO on the avr programmer should go on the square on the 6 pin on the swinsid nano (so you know how to connect it now).


    In this command I used "-n" instead of "-e" to prevent to really erase the current firmware.


    Btw, I saw there the lastest firmware is from 2012: http://www.swinkels.tvtom.pl/swinsid/


    I can't find any other on this forum. Is there an improved firmware available to download?


  • Hi there,


    I built discontinued 8515 circuit on a breadboard, used a 24mhz external oscillator and I only got blips and blops. Later I wanted to try the newer setup with the atmega88pa. First of all, there is no official schematic on the swinsid website. Schematics there are for only atmega8515. I used the schematic from the sticky thread (Micro_SwinSID_JargoVpcb.sch) which I can't see get okayed from forum readers yet.


    I've used 0x6F (low), 0xDF (high) for fuse bits. Programmed the chip with TL866CS programmer. I hear a high pitched burst of 0.5 seconds or so, when I'm playing a sid it's silent. I didn't use the 4k7 resistor from Oscillator's vcc to sound output as it didn't make much sense. Also I use 200k resistor instead of 240k from PB2 line.


    Different from most people here I use the sid replacement in my sid player circuit I am currently developing since my 8580 sid chip died recently.
    Early test model of the circuit in action : http://www.youtube.com/watch?v=shy9O0qigQ4


    So the question is, which fuse bits should I use? Is there an official schematic, or anything that's tested and approved?


    I have spare c64s lying around but I don't want to kill any more sid chips. Swinsid is a very good alternative for me to continue on my project. Any help is greatly appreciated!

  • Sorry for bumping the thread. I'm posting because I can't edit my previous message. I already got the fuse bits correct. Programming with both 60 and E0 for low byte gives me a nice audible tone at start. But I can't make it play anything else. I checked the wiring multiple times.


    Edit : In my sid playing circuit I started to use a GAL16v8d which introduced all sorts of problems I think. Moving Sid CS back to discrete logic at least gave me some meaningful sound (of my test routine)
    Later I'll move all the address decoding back to discrete logic.

  • Finally got it working. The correct low fusebits should be E0 for external oscillator. Since it didn't work in my setup I deviated a lot from the default combinations but in my case problem turned out to be something else.


    I was simply decoding the sid chip using A15, A14, A13 and A12 lines. (Whole $d000-dfff area dedicated to a single sid chip). Inspected the circuit with a logic analyzer and found that chip select line to the swinsid was problematic. It's no problem if you have an actual sid chip in the setup since sid chip is already fed with PHI2 clock from the cpu but indeed it does matter for swinsid. So I changed the address decoding logic so that swinsid is selected only when PHI2 signal is high. Bingo! Now it works. It doesn't sound very good at the moment since my sound output circuit is a bit deviated from the original yet it serves me right at the moment. No more dead sid chips until I finish this hardware sid player.


    Here is a video of it in action. Since I was concentrated on getting swinsid to run, this is only a test circuit. There are 8 sids on the eprom along with a player. Each part mapped to $E000-$FFFF address space. Hot reset vector jumps to a simple player routine which copies the sid from eprom to ram and inits the sid and then calls the play routine 50 times a second by a cycle counted loop.


    In the final design it will transfer the sid with an interesting hack. PIC microcontroller drives IRQ / NMI and SO lines so that when it triggers an IRQ a 1 bit is sent, and when it triggers an NMI a 0 bit is sent. SO line is used to syncronize the data transfer job and used in the main program loop. I better not get too off topic, I'll publish all the details in my blog when I find time.


    Thank you Swinkels by the way! And thanks to all those who contributed to this project.


  • ok, I found a newer version of the firmware, called SwinSID88_lazy_fix_by_ck.rar
    which we can find on this thread:
    Nano SwinSID upgrades (paddles, etc...)


    when I try to flash the official firmware, I got this at the end:


    while with the "lazy fix" I got this:



    After some investigation (and also because of the "reading on-chip flash data", I assumed it meant that the new firmware I was trying to flash was not similar to the one already on the chip. Since it matched for the SwinSID88_20120524.hex it also means the firmware on my chip was the latest official one (SwinSID88_20120524.hex). After flashing the chip for real, I got the opposite for the two firmware, so it's all ok for me.

  • I've installed the updated swinsid on my C64. It seems it sounds much better than the original one (last official firmware from 2012). The previous one was rather ok, but behind the sidplay emulator. Now with SwinSID88_lazy_fix_by_ck.hex (oct. 2014) it sounds rather like sidplay (or sidplayfp). Well done! I'll try to post some comparisons, but in another thread.


    Now to come back to my original question, "is it possible to dump the data already programmed in the atmel chip", I found this kind of code:

    Code
    1. avrdude -v -v -c usbasp -p m88p -U flash:r:test.hex:i


    which will output the data to a test.hex file.


    I don't exactly get the same hex as the original SwinSID88_lazy_fix_by_ck.hex, I don't know why. There must be a way to get it but I don't know how. When I try to disassemble the test.hex file with this command:

    Code
    1. avr-objdump -j .sec1 -d -m avr5 test.hex


    then the beginning to the asm files is similar to the original .hex but maybe it's a bootloader or something else which is not significant.