Posts by CodeKiller

    Just because others are stealing, does this make it okay for you to do the same?

    You clearly miss the point -- I DID a lot of effort to improve unlike these copycats.

    Just because something is not easy does not make it impossible for hobbyists. That is a lame excuse!

    Okay, there is the most of the process in this very forum (up to Hermit's rework) -- please follow then (disasm and fix sh!t)

    You appear to have made something useful, but even if you only used the original SwinSID for reverse-engineering reference, then you are still basing your device on the works of others.

    The original project was never GPL-ed (or any other licensed), the later FWs didn't even had source code available so there is no excuse. I respect Swinkels for the original work, but my (or in the sound-gen code Hermit's) work is well beyond that.

    Now the SwinSID Ultimate does not share any code from the original, so how could you call it derivative work?!
    Your argument is totally false: WE ALL base our works on the the work of others!! If not, then we could not write, or speak, everybody should reinvent the wheel all the time!
    And for example have you heard about the JiffyDos??

    not their "improvements" or extensions on the core system.

    What do you call it? A new commodore64? Clearly not as those are only ROMs. Still sold if you want them legally!

    In summary: You require info about a project you never contributed, helped, or even promoted, just because there was a roughly similar project in the past that has the designs available?? And all of it for free of course?! Are you serious??

    You can still use the orig--- i mean my improved fw (lazy fix) -- but if you need better, then you can do it better and show, how to be open-source!

    As said it before, there are seller on ebay and amibay who sells SwinSID, built, programmed .... i doubt they have any more permissions to do so.
    ReSID-fp is only the foundation and not the source!! The code Hermit wrote is 100% avr assmebly, with tricks and shortcuts to be able to handle the task in this puny uC (mostly the comments in resid-fp has been used)

    My device has a lot more components, needed a lot more time to even laid out the PCB, so for assembly alone would grant it's price!

    But as I said, how would you blame the clone sellers that they "steal" something which is freely available, if your approach isn't better?

    Maybe because after long years of no progress, Hermit and I have increased the compatibility and quality to an unimaginable level? We did WORK on this (not just cosmetic)?
    They can sell whatever they want but I would like to get something back for my work too.

    And for hobby builders -- can you really put two QFN16, an SOP8, a TQFP44, a TQFP32 a dozen of resistors and half a dozen capacitor to a PCB the size of a DIP28; program a Xilinx CPLD and two AVR uC ?
    Not to mention, if you could design and make your own PCB...

    And for last -- even IF the Atmega code is not clean, the CPLD and the Attiny(paddle) are, and w/o those, the Atmega can't work properly...

    Also look at how many products has gone from open source to closed -- not only to hide from hobbyist but to protect themselves from cheap knock-offs or because the complexity is now beyond the average hobby builders.

    The code is not completely blocked off from people, because Hermit made the jsSID based on the code he written for the SwinSID Ultimate:

    Brand new stuff has been added to the swinsid (ultimate):
    As i have mentioned, there is a softconfig for various setup -- now it has the ability to mute selected channels (osc1 / osc2 / osc3 / classic digi) in a bitmask fashion (for example you can mute the osc2 and digi track, but still get the osc1 and osc3)

    So you will be able to record a music in every "track" independently. The calculation, syncing and all this sort of jazz is still present, only the sound output is muted for that channel, so it won't affect the other not muted channels.

    However you can't switch these channels on-the-fly because it relies on the 3 unused address and the 2 readable registers (the POTs/mouse registers are entirely different circuit, no communication between them) as the entire softconfig, but maybe with freezer carts..

    Then ask the ones too who only sells the clones..... They added jack s...t to the project.

    Didn't I released the "Lazy fix"? Didn't it get cloned? Did the clone sellers claim 99% compatibility while has no idea what the actual product capable of? Did i get valuable help from Swinkels in the enhancements?
    I only got some tips/feedback from 'Nobody', and a pointing-to-the-right-direction from a demo coder.

    Also, Hermit is almost completely rewritten the firmware (based on resid-fp) and redesigned some parts of the hardware already.

    It may go open source one day... but after this kind of responses.....

    That's fine if you don't want a full or even extended version, i planned to be somewhat modular:
    - just the bare minimal to make sound
    - compatibility with the old games (env3/osc3 available too)
    - full compatibility (added mouse/paddle support)
    - extended (and some flashy leds :) )

    Please understand, that i can't control the firmware any more, if i make it downloadable even for a fee --- somebody buys it then s/he can upload it to as many blank/old device as s/he pleases....

    The HC version of the swinsid is not compatible with the old version of the hardware (needs a bit of modification) however the latest developments are meant for a more different hardware.

    But currently we haven't even completed the hw nor the sw ... there are some in progress versions out, but sadly those still has some bugs in them.

    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)
    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)

    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.

    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)

    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
    - OSC3/ENV3 readable registers
    - POT_X / POT_Y registers with mouse support
    - ext_in external audio input
    - read / write LED
    - 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 )

    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.

    (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 )

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

    Because it will use new hardware elements, there is no use for others. After some proto build and fixing some bugs I will release the fw -- which will still only compatible to the that new board.. sorry.

    You know, you can't make proper test in firmware only, because the uC is too slow for that. But adding more components aren't easy, especially to nano swinsid. (and of course i don't want a buch of clones to show up before my devices sold a bit)

    On the other hand I should definitely speed up the design and production.....