Nano SwinSID upgrades (paddles, etc...)

Tested the new Comaland demo on Swin -- this squeaky sound again in the first flip-screen (when the fonts are flashing)
I'm pretty sure, it is the problem of the voice synthesizer than anything ... and that part is not clear to me.

But up until that part, everything sounds as it should!

Zitat von Nobody

Maybe the creators can tell you what exactly happen at especially that point in their track?

Ok, i'll try to contact them.

In the mean time, this is how it's rolls now:

Zitat von Swinkels

SwinSID uses random generator that is only 15 bit long where SID uses 23 bits to calculate random numbers in a loop.

I thought SwinSID does not calculate random, but uses samples as for any other type of voice (now i see the calculation code). Then it is more puzzling, as there is clearly looping sound in the noise waveform (like in Super Games cart/ Silicon syborgs background "music" ).

It is also interesting to note, there are only 12 waveform sample (out of the 16 possible combination) in the hex, some of them are not genuine - eg. 0=12=sine. They maybe just remnants of older versions - as the 0 is properly handled (freeze DAC), but anything beyond noise recognized as noise waveform. So it does not have noise-multiplexed voices? (ok, i know they may lock up, but maybe something needs them....)
(There is also a first-at-first-bug: after reset, you can't just switch on channel1, because the gate is "wide open" after the initial beep, you have to close it first --- it is really a minor annoyance thou)

Looked into your code, but are you sure you can get away with the omission of R/W check? Well i would do too, but adding hardware to filter the read out ---- buut yeah... it may can't do any harm.... i have to check.

Edit: checked -- it produces complete garbage That check while not proper, still help a lot in the overall timing. Not even a single OR gate on the CS/RW pins are enough, the CLK has to be high too (may depend on the C64 board/PLA too)

I think you mistakenly stores the low address to the new sets of registers instead of data -- well, maybe not a problem, just very strange -- it would require the same amount of cycle, as like ORI 0x20 instead of the SUBI 0xA0... well i guess personal preferences. (And as I have said earlier, 0xFF would be better 'invalid' value, because it has the bit0 set, so the int handler can't put in that.)

Please guys, keep on topic!
There are a bunch of other how-to-pogram topic around, please use them!

This topic intended for Upgrades --- as in HW as in SW -- mainly for experts.
Feedback appreciated, but only if it's on topic: what's not work, what should work, etc-etc... (or more better: how to make it better. how to fix it)

The 'Alien' sounds that bad because the filer response not quite similar to the 6581 - even if jumpered to that mode -- currently it is not high priority.

There may be a chance to fix the old nanoSwinSIDs to '180'-compatible, but my first test with a few external components doesn't worked flawlessly, so more investigation needed.
In the mean time, I compared some emulators and had some interesting results:
- the 'Master of the lamps' sounds as bad in Frodo as in swinsid but in in vice/fastsid mode it works fine (it is some pwm magic, still not fully understand)
- 'Fanta in space' works in swinsid but not on vice/fastsid
- 'Comaland' first flip-screen sounds similar in swinsid and vice/fastsid

Holy guacamole!!
Now I experimented with custom built vice to see if I can replicate the problem with the 'Master of the Lamps' -- and Bingo, I can. And this is a very disturbing one: it READS VALUES from WRITE ONLY registers (channel 2 freq)!!
In my first test the reading of write only address returned 0 -- and that's kind of worked --- but after returning with rand() % 255 made that squeaky sound. Also no other static value seems to work just 0 - still not perfect but fair enough.

Zitat von stephen_falken

I have tried this latest one posted here but it doesn't seem to work for me!

I confirmed it before. But you may get a bit better compatibility with my 'lazy_fix' firmware ... the newer ones are not compatible with the current nanoSwinSID, as they need external components to be added, otherwise the interrupt handler (the code that reads byte from the c64 and stores in the atmega) become too long to be "transparent".

Zitat von stephen_falken

Also I have a bunch of Atmega328P chips here, I tried flashing the firmware to it but it doesn't seem to work.

It would not work unless somebody patch the interrupt-handler addresses for you as these differs from Atmega88.

Zitat von kjmann

Gyruss - Music volume dynamics are wrong. almost seems random at times.

and

Zitat von kjmann

Mirrorsoft Tetris - Main melody of music is almost Non-Existent.

From the 'lazy_fix' it works most better.

Zitat von kjmann

Panther - Bass Notes seem wrong on dynamics. drums are incomplete.

It needs the new generation hardware, sorry.

Please test the tunes with the 'lazy_fix' version of firmware too if you can. That firm is compatible with every nanoSwinSID with no other modification necessary.
(note the fix ain't lazy but it was developed because of the game 'Lazy Jones')

Thanks for the info, at least I can confirm, the new revision could potentially support these.

Ok, so I just learned about this "bitfade" stuff.
There are quite good description about this in the ReSID code in VICE so it may be doable in Swin too -- in the expense of another ser-to-par-buffer and I think it's time to replace these discrete logic with a CPLD as i couldn't cram more stuff into that tiny board even in double load and stacking.

The idea is: if the primary data read register<>0 copy to an empty one (data_hold) and data_read_reg=0, also set/reset some counter. If counter=0, data_hold=0. Do this at one point of the main_loop and (here or another point) push out through SPI to the buffer.
In the address decoding there should be some more logic to drive this buffer, if the address is not a read-only one. (that's a lot of OR/AND gate, so a programmable logic would do it more nicely)

Do you know a small, cheap, 5V operating programmable logic device?

Thanks, yes, i'm aware of the XC9500 series -- actually that is the proper 5V one without the XL ending. Sadly it already discontinued... only Chinese source are there for reasonable price.
Actually i have designed for XC9536 already .. just searched a more dense one for around the same price or a similar capabilities for more cheaper. It's still enough though if I use the 4 external ser-to-par-buffers.
Even the write only "hold" register fit into there (and it's much better too than previously thought, as it would be available instantly, no need for the main loop to notice it -- the clear can be done from the atmega and it's fine as it doesn't need precise timing), just the read only registers has to be external (too much registers and terms needed)

The PSoC looks very amazing, but to use it would need a complete rewrite from scratch. The current code is hand-crafted atmega ASM, not only just compiled from a high level code (or at least in my case).

Now for a "good" part: after contacting with Swallow (from Censor Design) he said that the 'Comaland /flip-screen' uses 'Vicious Sid' and PWM techniques combined. Sure enough, the former demo works great, but the latter (like Wonderland XIII last disk) just garbage. There is an article about it in http://www.ffd2.com/fridge/chacking/c=hacking21.txt
Basically, the same has to be done with the Test bit, as to the Gate bit earlier --- but it just get more complicated and more tight to do something useful in the interrupt handler. The currently effective 8 bit pwm is not too great for this either (instead of 12 bit).

Holy SHIT!!!

Now the PWM works too!!! Not perfect, as the resolution is much lower than it should be (thanks for the 8bit effective pwm) but at least I have managed to cram the test-bit flips into the interrupt handler.

However there is no chance to backport it to the older versions -- there are no space left in the int-handler. Not even with external logic.

To make it wok basically the handler should test if the data ends with 0xx1, and if not, store into the second register set too. Now in the main loop test the these bits in the control registers in the second set too and flip them after used.
I will try to expand the pwm tests to see, if it can improve the sound.

Getting better and better -- now I have added the 4 LSB to the pwm check too. Sounds better but there are a lot of carrier noise: http://www2.zippyshare.com/v/47799262/file.html

Reduced the square value in the wavetable to 7F from FF and the Comaland - outro now sounds a bit better (while the 'Fanta in space' sound a bit worse), but still no idea of the cause of the issue here: http://www2.zippyshare.com/v/87869729/file.html
Maybe bitfading here too?! Or the channel summation?

Swallow helped out again -- so the Comaland outro uses the 44kHz sample playback pioneered by Mahoney!
It's a bit more complex, as it is using the more analogue nature of the filter, the switches, and the main volume.... it should produce 8bit samples but i'm afraid i have to dig deep into the swin-filter routines. At least the update speed seems to be enough.... (but not sure -- 22 c64 cycle = 22*32= 704 avr cycle, not that short -- unlike the 4-6 c64-cycle gate and test bit toggles)

Stay tuned for more...