Forum comments in chronological order

Anonymous
Tue 2-May-2017 23:53

Unfortunately the closest we can get to a SID file from converting is in RSID format, which won't play in a lot of players, especially older ones. Even those that can play it, don't seem to silence the SID when resetting at the end, so you'd have hanging notes. So far all my attempts to bodge in a fix for this have failed.

So, Linus, any chance we could get an official SID version? :)

Anonymous
Sun 7-May-2017 22:25

amazing article!

thank you very much

Anonymous
Sun 7-May-2017 23:09

I have never been this impressed by an oldskool demo before. Thank you sir for your art!

Anonymous
Mon 15-May-2017 00:18

I have tried to build a MIDI synth with similar capabilities on ATmega 32u4 but could not avoid annoying clicks in the audio as the midi signal was processed (takes way too long and halts DAC conversion for a short while). Hats off for putting it all into an ATmega 88... I have no idea how did you do that. What kind of data structure do you keep your "tones"/"pressed keys" ? Only thing that worked reasonably for me is an array of 127 elements, each for one MIDI tone. I tried using an "stack" of pointers but i sometimes needed to move an element from the middle (thats why the "") to the top which took way too long and made an audible click as well. This i tried by using a linked list but the overhead for that was just way too large.

lft
Linus Åkesson
Wed 17-May-2017 22:59

Done & added to the Downloads section.

lft
Linus Åkesson
Thu 18-May-2017 22:29

Thanks!

Generating the sound is done in an interrupt handler, and so is receiving the serial data. The latter interrupt handler just stashes the bytes into a circular buffer. Everything else is handled in main context.


Linked lists. I use one page of memory (256 bytes) as a heap of 3-byte list nodes. One of those bytes is a next-pointer; it can be a byte because the heap is just one page. So there are 85 nodes in the system, starting at offset 1 which makes 0 free to use as a null pointer.

At initialisation, all 85 nodes are chained together into a freelist. Heap allocation is then a simple matter of unlinking the first node in the freelist. Conversely, nodes are freed by unlinking them and putting them back at the head of the freelist.

Anonymous
Thu 18-May-2017 23:39

It's like a piece of art, this should be in the Tate modern. Minimalist beauty. Well played sir.

Anonymous
Fri 19-May-2017 23:12

(Same guy here)
Thank-you very much, I'm sure I won't be the only one who much appreciates it :)

Anonymous
Sun 21-May-2017 02:58

Hello. This relocate to $6000 why failed? http://csdb.dk/sid/?id=22120
Stranger in a Strange Land. 2800-3985, inic 2848, play 2821, Player routine: Music Assembler (Voice Tracker 4), 4486 byte. sidreloc -p 60 -r 28-39 -k -v, relocation failed, too many mismatching pitches, bad pitches 11635, 4%, zeropage 250-255.

Anonymous
Sun 21-May-2017 03:16

Continue Stranger in a Strange Land. I use -f option, "relocation successful with some mismatching pitches", output file save OK, music OK, no problem. Why did the sidreloc indicate that the relocation is wrong?

lft
Linus Åkesson
Mon 29-May-2017 14:32

In short, because it compares the register values, not the sound. I haven't looked into this case in particular, but if the tune writes location-dependent values into the pitch registers when a voice has already faded to silence, the above would be the result.

Why would a tune write location-dependent values into the pitch registers? I have seen this happen when e.g. a drum sound contains an out-of-bounds reference past the end of an arpeggio table, reading instead from an unrelated table of pointers that happens to be located after it. As the tune is relocated, the pointers change, and different pitch values get written.

Anonymous
Tue 30-May-2017 15:51

When do you fix the relocator program?
The program works uncertainly. Error indicate, but no real error, etc.

Anonymous
Tue 30-May-2017 17:06

I don't regard this as an error. It is useful to know when different register values are written, and one can easily override this behaviour with -f, like you did.

That being said, the program is open source, so you can easily amend or modify it yourself.

Anonymous
Wed 31-May-2017 23:34

The level is actually not as difficult as you think.
Using the upper path as a one-way sliding door makes it easy.

To make it more interesting, you can actually eliminate the upper path as a one-way sliding door by adding a wall.
Like this:

#####-----
##--###---
#@--$-####
##-##----#
-#.*.-.$-#
-##$-$-$.#
--#-.$.-##
--#######-

Still relatively easy.