Beiträge von CodeKiller

    since the sid "oscillators" are only in audio range up to maximum ~4 kHz, they would have to be updated in an interrupt at that frequency minimum

    You have forgot, that there is a wider range in the osc than divides of 4kHz. --- also no one said anything about filter upgrade...

    I think the current SwinSID works well enough, but can be improved.


    Back to the topic -
    Current pending issues:
    - unnoticed ADSR restart while maintaining a sort enough interrupt handler (with external clock divider a few instruction can be omitted)
    - ADC support for 2-out-of-4 paddle mode
    (maybe external sound in)
    - soft setup instead of the filter-select pin
    (- soft setup for other values)

    Current solved issues:
    - env3 reading
    - osc3 reading
    - swinsid identification
    - partial ADC support (without multiplex or with 4 paddles -- needs a discharging circuit)
    - partial support for ADSR restart (needs to properly distribute the checks in the main loop, or find another solution)

    The problem is not the speed, but the single pipeline: a real SID does all voice calculation, ADSR, paddle checking, etc.. in simultaneously. So a proper emulation has to clock 100+MHz single pipeline, or using FPGA with the parallel execution.

    The paddles almost works -- the problem is the multiplex - if both c64 joyport is polled, while one is not populated, the capacitor in the mainboard retains some charges and fools the ADC circuit in the AVR, so i think it should be discharged before sampling.


    Holy quackamoly --- just did the (almost) impossible - proper Fanta AND Lazy Jones :thumbsup: (well there are still some quirks)
    The trick is to handle as little in interrupt as possible while signaling the changes: if the incoming data ends with 0 bit, it saves the address to a temp register and in some places in the main loop it checks if the address is indeed a ctrl one. Then it sets the extra gate bits in another reg and clears the temp address after.

    @Nobody -- so you wanted 'Lazy Jones'? I just did it :rauch: With this modifications to the code: if a gate 0 received, it saves a corresponding bit to an aux memory too, so in the voice processing if there are no change between the previous and the actual ctrl register the aux bit can still initialize the ADSR to start over.

    It has however a performance impact on the interrupt handling, making the 'fanta in space' glitchy :cursing: (if implemented in the interrupt handling)

    The other method is to regularly check the control registers against the old values and set the aux bits accordingly -- this lead to timing problems (notable pitch differences) and some notes still left undetected (there are ~only 192 avr cycle to catch a rapid gate-closing-opening)
    In sort:
    -interrupt - glitchy Fanta, clean Jones
    -polling - pitch differences, skipping Jones

    Maybe Swinkels could re-tune the pitch? Because the interrupt can't be much longer, or the Fanta sound get distorted.

    "Looking the game trough ICU64+Frodo, it looks that the SwinSID may not like that the ADSR doesn't go to Release phase."
    Well, it certainly does go to Release phase, but only for two instruction long ( LDA #$20 -- STA $D40B -- LDA #$21 -- STA $D40B ) --- it may not enough time to go trough a full main loop and update the registers accordingly. And because of that, the swinsid thinks, the gate hasn't been changed so no need to restart the ADSR.....

    Currently I have no idea, how to fix this....

    @Nobody - in theory it should, but it doesn't fix issues that are purely software dependent.
    As I have looked into this 'Lazy Jones', it does not use the readable registers from the SID, so it must be some other problem. Looking the game trough ICU64+Frodo, it looks that the SwinSID may not like that the ADSR doesn't go to Release phase. (the game always push 0x21 into voice1&2 ctrl registers)

    There is also a problem with 'Master of the Lamps", and that I can't even trace that easy, as the Frodo emu does the same bad sound as the swinsid but the ICU64+VICE lacks the SID debug page. (in memory map, the reading and writing to SID address is observable, but the values doesn't change)

    So yeah, I will look into, if there is a chance to fix.

    I have asked Swinkels about the env3 register location before, but despite the sent schematic and explanation, he only written that it's not possible due to fw limitations. Haven't heard any word from him since that one line of reply back in end of july. (even after I sent the modified firmware too)

    Well, I've been a bit rushed to conclusion as I've only tested the software methods to read the needed registers.
    BUT as the SID only has 4 bytes of read only registers, it can be added by cascaded serial-to-parallel buffers connected to the SPI bus of the Atmega. It needed fiddling with the pins to make room for controlling, access to the SPI output, and the ADC inputs. Actually 3 pins needed from the atmega for the SPI: spi_clk, spi_data, serial-to-parallel_load. There is another pin needed, the output enable, but it is decoded from the ~CS and address lines. The processing of the SPI bus is very simple, after setup any byte written to the SPDR causes that byte to be shifted out, so only a few instruction added doesn't really change the rest of the execution.

    There are some progress in the soft-mode-select too. Using the normally unused 3 bytes it can report identification, and will be used for filter mode select (the pin normally used for this will be used for drain the caps on the motherboard - the atmega's ADCs uses different methods and higher sample rate, so the caps interfere with it)

    Bitte melde dich an, um dieses Medienelement zu sehen.

    So, I have RE-ed the latest nano SwinSID firmware (sorry, i have forgotten THE MAIN MAN behind SwinSID -- THANK YOU SWINKELS :respect: -- however the lack of source and the polish comments in available older source aren't that nice) and was able to rebuild the binary content to the same.
    Due to the fact, that the Atmega88PA can use more interrupts than INT0 and INT1 -- namely the PCINTx pins, I've managed to reduce the interfacing code quite a bit, by swapping the ~CS and the D2 lines (no more bit-trickery). As the PCINTx-s fire at level change, it required a level check and added an R/W check too, but it was for vain..
    From CS LOW to set the data lines to output and set to zero, took ~450-470nS with the following code:


    As you can see, it did'n even fetch the address, nor the memory at that address. This is the shortest code i can think of to handle read, and it still takes too long to get executed.
    It is really a shame, because of it, SwinSID can never replace the good old MOS SIDs :cry

    Digging deeper into the code also found some leftover(?)/junk(?) codes inside the channel calculations (2-2 section that could never get executed), don't know why are there, but seems to working fine without these.

    Have you seen the Bitte melde dich an, um diesen Link zu sehen. page and the referenced Bitte melde dich an, um diesen Link zu sehen. address?
    There are a lot of reversing done there, and also very high quality images if you're willing to start that over :)

    But it may not easily reproducible on uC or FPGA environment... (for example you can clearly see the linear cutoff resistors for 6581 and logarithmic resistors for the 8580 )

    Hi everyone,

    First I have to thank x1541 and everybody who contributed for this awesome project known as SwinSID :thanx: you guys rocks! :zustimm:

    However I have found some weird shortcomings of the device, which I think could been easily addressed:

    - support for paddles -- the atmega88 has 2 unused ADC channel which should be used for at least for potentiometer input (lot of musicians use potentiometers connected to paddles to modify sound - mouse support would also be nice)
    - PAL/NTSC (other?) selection -- sampling the computer's clock after reset could be used to set the output's base frequency (the CBM/B machines also use SID at ~2MHZ!!)
    - may be some support for ext_audio_in(?) -- ok, I know it would be more different, and more difficult, but rearranging the pins may free up at least an additional ADC and then maybe it could be processed to simulate the filtering.... (as two pins of PortB only used for the ISP connector, during normal usage these are just wasted, could be repurposed; using external oscillator on PortB6, the PortB7 is also available for I/O)

    I'm yet to know the more in depth operations, but dated and different generation's source codes doesn't helping in the looking for potential optimization/idle cycles to fit in some of the above.

    I've already laid out a board with the paddles connected, but without any pin swapping, so it's still 100% compatible with the older versions.


    What do you think about this?


    cheers,
    ck