Hello, Guest the thread was called91k times and contains 183 replays

last post from Frenetic at the

Nano SwinSID upgrades (paddles, etc...)

  • Ahh, yes I've figured out ---- the code checks if the voice gates are equal, then if it was shut for a short time AND -- this is the latest fix -- check, that the gate was not shut in the first place before the ADSR update route has been taken. --- Now it eliminates the stuck voices in 'Fanta in space' too 8)
    (actually, the interrupt handler can cope with the few additional cycles by the sbrc and mov, no need additional hardware)
    Will upload some proof video later this Sunday.

    Please share, what other game/music has hard time with the swinsid and I will look into it. (actually still no clue how the music being calculated, but the control-lines are kind of clear now)

    And now I can go back and fix up the ADCs :P
    For reading, the additional components cost is only a few cents so I don't know what's the problem with it...

  • The interrupt handler checks for the 0 to 1 gate change because this is the essential part of the voice triggering. Change from 1 to 0 is not that important and it will be detected while ADSR processing. When zero level is very short the 0 to 1 change will follow and trigger the voice once again.
    The solution with you source code detecting zero gate bit and storing address in register is far from perfect. When other registers are accessed with zeros a copy of control register will be cleared. This will also occurs when other voices are accessed. In my test firmware I added checking for specific address of each voce control byte that will store this information on three different addresses in memory.
    In the current SwinSID firmware there is a special dirty hack for Fanta in Space that checks previous value of control register and this may not work when modifying this part of ADSR triggering.

  • I know it's not the best solution, but i assure you, it's working. No one can make perfect SID emulation on just 32Mhz single core cpu.. not a chance! It would require that the total calculation of every ADSR, OSC, filter should be done in 32 cycle....
    But making a fair enough emulation, it is still a viable alternative. So why NOT check more than absolutely necessary is essential to keep low any overhead. If the int handler looks for transition it had to jump to a less tight space, look-up the old value, compare, branch and store - and for every single ctrl register. My code works because most of the time the main loop can do at least one loop before the same registers updated. However in 'Lazy Jones' there is too little time between gate close and reopen, so for the main loop it often looks like nothing has changed.
    Yes, sure, other access will overwrite the address, if the data ends with 0, but will it really change the output? NOT! If it's not gate, then the code for voice just ignores it. You can write code were you bang a lot of data to the SID in rapid succession, but that won't affect that much either, because a) it doesn't audible - gate-on-off multiple times on the same channel - only the last gate_on matters and the fact that there were an off too b) the main loop goes through one more time - updating a channel requires quite some register updates and the gate is the last one so there is time to catch it in the regular way c) "banging" multiple voice gates in rapid succession - it can "hurt", but i yet to find a player to do this. (why the heck would someone restart all voices one-by-one when it's easier to close them all and turn on all after -- and by doing so, the main loop may catch up with them) d) REU DMA may "hurt" too in some cases -- I can't test....

    What problem I still have is in 'Master of the Lamp' there is some hissing/screeching sound (sames as in frodo emulator) where in real SID (and in VICE) there is a decreasing frequency sweep (beginning in the flying stage 1 / from SID voice 2) I have no idea what or how to fix it tough....

  • I cannot figure out any complete failouts/big problems anymore...seems you made a perfect job!

    Really cool....good work!!

    Edit: Master of the lamps sounds curious, youre right, but all in all your firmware seems to be better than before.
    Edit: ´Chase that feeling´ from Julian_Jaymz sounds curious, too...

    Maybe I do a direct comparison in dualmono with old firmware later today, but for now I try some more tracks...

  • Thanks for releasing the fix publicly. I have analyzed your new firmware (only asm code) and i think it should not have any side effect, but it may not work on some tunes and only further tests with other problematic tunes will tell how effective it is. Anyway it is fast and it would be hard to do anything better that will not consume more CPU power.
    For better testing I've gathered all the problematic SIDs here in single archive. If the fix will work on most tunes properly I can merge these changes to my firmware and put on the official SwinSID site.
    I cannot test your firmware on a real device because I have problems soldering Kanda programming cable to tiny pins of the nano SwinSID ISP socket.

  • Great to see progress for Swinsid performance here. :D

    Unfortunately I don't have much time to test the improvements. At least I have a cable ;) It is modeled like shadowolfs sd2iec programming cable, with the standard 6pin ISP layout. No need for much soldering ... I'll try to attach a picture later.

    Regards x1541

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

  • Looked into '180' and that is exactly the code to break my "lazy fix" -- sort gate close-and-open and update of other registers, which I haven't thought about. It can then overwrite the temp address, so the note restart doesn't happens.
    Still has more notes than before... just not all :(

    There is no time pressure...maybe you find a solution when you think about a few days :) Anyway, good work already!

  • Well, I have already thought about another solution before this one, but maybe it has it's downfalls too: instead of using some temp, just set the ctrl registers to an "invalid" state (0xff) after processed, and check if it still 0xff or some more useful value (copy the old values to processing if still 0xff). So instead of hunting gate-close events, now the gate-open ones are enough (as this is the more interesting phase of the ADSR). Sadly, it still makes a mushy result in '180' - now the notes are there, but doesn't cuts off at the end, making them blend together :böse
    Maybe it needs a bit cleanup in the code as this invalid state is kinda dirty hack into the current check....
    It also breaks something in 'Fanta in space' - the digi plays fine, but the normal notes are way off - volume and sound too.

  • but maybe it has it's downfalls too

    Oh yes, it retriggers the notes even if no gate close has received before.

    Alternatively, if the int-handler stores the bytes ends with 0 to a second set of registers (addr+0x20 - with the internal registers moved further) may help----- however in PCINT, I can't go below 13cycle - most likely the turning point of the good-enough and the not-so-good (previous code with 12 cycle worked without a hick-up). Maybe a faster osc can help...
    OOOOH FFS!!!! It was the ORI f#cking up the SREG during the interrupt, that caused all the glitchy sound. After the SREG saving and restoring, now '180' sounds as intended too.

    So it combines all the previous fixes with some new one:
    - saving if the data ends with bit0 =0 (int handler)
    - save to a new set of registers too (the old registers also updated, but if the data is even, it stores to a new set too) (int handler)
    - check if the new ctrl_regs has valid values (main loop)
    - if valid and the current ctrl not set to gate-close, then the voice can be retriggered / and the new_ctrl set to invalid (0xFF) again (main loop)

    I think all the problematic SIDs Swinkels posted now plays fine.

    Now i have to squeeze it into the old INT0 handler if I want to support the old hardware --- if I can.....

    So, any more problematic music out there? 8)

    (Master of the Lamp issue is not related to control flow, so I'm not sure how to fix it... also would be better to have a real RND generator instead of the loop, as is quite noticeable..)

  • Sorry, no support for old hardware--- the interrupt handler is too long there, unless external hardware added (an inverter gate for the CLK, and a 3-input OR gate for CS/W-R/and the inverted CLK)---not yet tested....
    What is tested is a longer, jumpy routine which is so long that it does misses out updates.

    On the new HW tough it still needs externals - now there is an OR gate and a JK Flip-flop for edge detection, because the PCINT works a little different.
    But at least it doesn't need to fiddle with the data's and address' bits.

    I think ´Chase that feeling´ from Julian_Jaymz sounds sh!t even with good, original SID :drunk::whistling:
    (confirmed with 8580 and 6581r? )