Hallo Besucher, der Thread wurde 114k mal aufgerufen und enthält 185 Antworten

letzter Beitrag von Frenetic am

Nano SwinSID upgrades (paddles, etc...)

  • Thanks to a nice fellow at FOReVER 2015 party, I have been able to test the prototype with SuperCPU --- sadly, the Metal Dust ain't working with it :(
    As Capac(Singular) explained, it uses some calibration before the level starts and that would require a little bit(?) faster response trough the readable registers.


    He also recommended to add custom wavetables in the future... What do you think about it? (there is space for 3x 256 byte in the RAM and/or 1x 256 byte in EEPROM -- i would prefer to have some settings stored in there, so despite the 512b size, there would be enough for 2 piece of wavetable)

  • hey codekiller, still didnt find time to test your new chip... hats off to the prototypes you showed me!


    i would say superCPU/metal dust is not really the most common application, i would not invest much time to make it compatible to that.


    and anything that goes beyond original soundchip specification would be a nice feature, but who would write songs for it, in which application, and who will be able to play them back? on a "single end user" musician level it can make sense, but on a broader level it might be more annoying than useful imho.

  • Ok folks, I'm getting there --- now the Master of the Lamps finally sounds as expected (with the added bitfade). There are however some glitches: random changing of waveform, muting sound, some beeps... -- maybe needs some more decoupling capacitor.
    And I have found another potential incompatibility: the real SID samples the bus at the falling edge of the clock, while the SwinSID (the uC core) samples the at the /CE(and /W and phi2) condition, where the address and data bus not guaranteed to be valid (ok, that condition only triggers the IRQ and only some times after that the handler really reads the address and data buses... but that's not exactly the same). On the other hand the bitfade has to sample at the falling edge, otherwise only garbage will be available.


    Also the ADC has major problems (not working at all) and I need a high voltage programmer for ATTiny.... (I tought I have one, but the config file is missing from the G540 program )



    Aaaaaanyway, here is a picture of the prototype :) (without the ADC co-processor)

  • Ow shoot....
    Found the bug in the ADC (comparator) --- forgotten to clear the counters after sendig it to the ser-par buffer..... not surpising it showed garbage :whistling:



    The new boards also have arrived and I've started to assemble the first one -- still missing the passives

  • For most stuff the Swin SID is ok to listen to. (Tested my pieces, current new firmware out of Dec. '14+. ) But has anyone listened to the Edge Of Disgrace tune, sounds totally different and not nice.. ;) (it just hasn't been programmed for the IC), really strange, get's stranger and stranger the further the track goes ?
    Also some sounds (like melody lines) sometimes are much too silent compared/in relation to the much more apparent ('too' loud) drum or rhythm sounds in this and other tracks. Like in that Chess-Board / Trailblazer Scene (where the 'melody' is too silent). As an example. Maybe this helps a bit to improve things.

  • Very impressive hardware. Looks expensive :)


    Are there big improvements in compatibility regarding sound effects, or is it mostly for register reading and paddle/mouse support?

  • Very impressive hardware. Looks expensive :)


    Are there big improvements in compatibility regarding sound effects, or is it mostly for register reading and paddle/mouse support?


    You know, lot of old stuff relies on these registers (WoW, master of the lamps,...) Also, the bitfade is implemented too.


    Compared to the lazy fix it also has all the nice things that was added to the HC version too (full 12bit PWM, master volume, test bit trigger, Mahoney-PCM)





    For most stuff the Swin SID is ok to listen to. (Tested my pieces, current new firmware out of Dec. '14+. ) But has anyone listened to the Edge Of Disgrace tune, sounds totally different and not nice.. (it just hasn't been programmed for the IC), really strange, get's stranger and stranger the further the track goes ?
    Also some sounds (like melody lines) sometimes are much too silent compared/in relation to the much more apparent ('too' loud) drum or rhythm sounds in this and other tracks. Like in that Chess-Board / Trailblazer Scene (where the 'melody' is too silent). As an example. Maybe this helps a bit to improve things.


    Not sure about the cause, but maybe the not cycle-exact timing/access is to blame.... which is unfortunate, as this chip/circuit is incapable of handling that.
    Probably the men behind that demo can enlighten me what are they using :)

  • (i have written some long text before my browser just died on me-- so some sorter version)


    So some update: still tweaking the ADC -- the mouse now seems to work but the paddles interferes with each other (the ones on the same port)



    Here is a pic with the familiar steps of the mouse signal connected to and processed by the SwinSID (SwinADC?) (i have no idea why the trippy colors on the preview :P )

  • Ok, so apparently to solve this problem .... you guessed it ... needs a faster cpu (technically the old one could be fine, if there would be an available pin for external clock --- buut there are 3 pin for analog (Vref, potx, poty), 3 pin data out (clk, sdat, latch) and 2 power pins occupying all 8 )


    It's a bit more pricier than the Attiny13 but not that much...


    Now it needs a little adjustment in the Vref to use a wider range of the potentiometer, if possible... (the original SID also has terrible range-to-value conversion, but now on my circuit it's even more narrow)



    But ultimately it's quite stable and supports mouse too :)


    It's time to test it on a real PCB prototype too.

  • Here you have it, the pictures of the first actual size prototype (only difference is the red jumper -- it won't be on the production version; and the jumper below will be bent to angle)


    What it can do over a "normal" SwinSID:
    (everything that the HC can do)
    - gate/test bit trigger
    - full 12bit PWM
    - master volume
    - Mahoney PCM playback
    (plus)
    - OSC3/ENV3 readable registers
    - POT_X / POT_Y registers with mouse support
    - ext_in external audio input
    - read / write LED
    (planned)
    - soft config: filter type (6581/8580), pal/ntsc, disable ext_in, alternative LED driving (4 led indicating the active channels(+digi) --- only if wired to separate board/leds )

  • Well, there are still some problems with the ADC -- i just tested with a "compatble" mouse before (clever mouse 1), but yesterday tested with a 1351 aaaaand not working :( (it may have something to do with the comparator's voltage levels)
    Also tested with a neos one and that's even worse than the 1351... --- ok, i found in wiki, it uses different protocol, so never mind (does not use the ADCs or at least not in the way a 1351 does)

  • Aaaaaaahh.... ok so the original 1351 is kinda bad. Tested with original 6581 too and still has some mistiming/flickering... But it seems the programs are aware that and smooths these data out.


    So the swinADC is working as intended :)


    In timing, the swin is a little bit sorter than the genuine 6581 in a PAL machine, but I think it is longer than an NTSC timing, so there shouldn't be problem with it.

  • I've mostly finished the soft config, please tell me, what do you think about it:


    So it works the following way --
    poke (sid_addr+29 - 31), 0 (clear the junk before)
    then
    poke (sid_addr+29), asc("S") ....


    or to be a bit sorter--- set the addr+30, +31 then finally set the +29


    Return values are in sid_addr+27(enc3) and sid_addr+28 (orc3)
    print chr$(peek(sid_addr+27));chr$(peek(sid_addr+28 ))



    After changing the setting there should be a reinit to take effect.



    A little more about the LEDs ---
    The board could have 2 LEDs for hardware displaying the Read and Write (not really visible most of the time sadly). These run by the CPLD. There were an empty and an obsolete function output pin too, then i thought adding an alternate driving function into the logic, so there it is. A bit hard to solder to these points, but not impossible--- maybe then glue in a pin-header somewhere for easier access.


    The CPLD can source 4mA but sink 24mA so the invert drive can be better if directly driving the LEDs (sadly, the installed LEDs are for forward driven... i looked these electrical data too late)
    The modes then are the following:
    - PWM -- using the channel's volume envelope, adding it up and if it carry, then it will lit the corresponding led
    - Counter -- in gate start, lit up the led full, for ~1sec, then if the envelope !=0 keep lit for 50% , when env=0 the led turns off (if gate starts again, will change back to full power)