TC64 V2 in cartridge mode using emulated SID 6581 instead of the real 8580 when playing SID tunes

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • So when I play games it is using my real 8580 SID but when I listen to SID files it's using an emulated 6581 SID instead of using the real one. I have selected the 8580 under emulation settings for both SID's and CIA. Only using mono anyway. How can I change it so it's using my real SID when I listen to SID files? It's using the real 8580 when playing games. My speakers are connected to TC64 V2s audio output.


    Merry xmas!

  • This output will only give you the emulated SID's audio. For the real SID, you need to use the audio output on the AV connector of the C64.

    I was under the impression that even when using the audio output on the TC64 V2 it would still use the original SID (at least part of it). Because I can hear a difference in games with SID installed VS no SID in the C64. Or do you mean that only the SID player will use the emulated SID when audio is connected to TC64's audio port, while games will still take advantage of the real SID, even when audio is connected to the TC64?


    Also, as I said, when playing SIDs it's using an emulated 6581 while playing the same games (same music) it's using the 8580 which also sounds like it's getting the sound from the real SID, when audio is connected to the TC64


    According to Tobias reads from the SID will come from the real SID in cartridge mode. Just recieved Turbo Chamelon 64 V2 and two buttons stuck

  • I was under the impression that even when using the audio output on the TC64 V2 it would still use the original SID (at least part of it).

    Write accesses go to both, the real SID and the emulated SID. If a real SID is present, then read accesses will come from that. So yes, there may be an audible difference, even if the audio amplifier is connected to the TC64, where only the emulated SID can be heard. The reason may be that the player routine is doing reads from the SID in order to set other registers to a certain value, depending on what it has read. The differences should be minimal, though.

  • Write accesses go to both, the real SID and the emulated SID. If a real SID is present, then read accesses will come from that. So yes, there may be an audible difference, even if the audio amplifier is connected to the TC64, where only the emulated SID can be heard. The reason may be that the player routine is doing reads from the SID in order to set other registers to a certain value, depending on what it has read. The differences should be minimal, though.

    Thanks for the answer. To me it sounds like the emulated SID reads from the real SID like you say and makes it sound identical to the real SID. Because if I remove the real sid and connect the speakers to the TC64 then certain things sounds very different, even if I have it set to emulate the same type of SID. Good example is the music in the game Alien.


    However, I still don't understand why when playing SID files the player seems to default to an emulated 6581 SID even though I have my emulated SIDs set to 8580s in the settings. While in games I can clearly hear it's using the emulated 8580 (which sounds identical to the real SID as long as the real SID is present).

  • However, I still don't understand why when playing SID files the player seems to default to an emulated 6581 SID even though I have my emulated SIDs set to 8580s in the settings.

    I have to guess here, because I don't maintain the menu software and SID player of the Chameleon. However, I do know that every SID file also contains meta information about the author, year, copyright and the SID type that it plays best with. So what you observe may not be "defaulting" to a 6581 SID, but merely a choice of the SID file author that the files you're choosing are all composed for a 6581 SID.


    Tobias can answer this when he returns from his holidays on january 6th.

  • I have to guess here, because I don't maintain the menu software and SID player of the Chameleon. However, I do know that every SID file also contains meta information about the author, year, copyright and the SID type that it plays best with. So what you observe may not be "defaulting" to a 6581 SID, but merely a choice of the SID file author that the files you're choosing are all composed for a 6581 SID.


    Tobias can answer this when he returns from his holidays on january 6th.

    Thanks for the answer. I will try to investigate this further.


    Another question which is not directly related to SID. How much of the real VIC II is actually used when using the TC64s VGA output? Is it only syncing with the VIC II to get smooth scrolling? Would different types of VIC IIs in any way affect the picture quality you get from TC64s VGA output?


    Also, would it be impossible to let's say have an option in the TC64s menu to use the real C64 CPU instead of the emulated one so one could enable the casette port, but at the same time keep the VGA output enabled? Sometimes I would like to load real tape games (nostalgia reasons) and at the same time have the VGA output working

  • How much of the real VIC II is actually used when using the TC64s VGA output? Is it only syncing with the VIC II to get smooth scrolling?

    It's a bit more than that - the address that the VIC is putting on the bus is compared to the address that the emulated VIC is generating in order to re-sync in real time.


    Would different types of VIC IIs in any way affect the picture quality you get from TC64s VGA output?

    No, not at all. The picture is always generated by the FPGA and not a single part that the real VIC chip is generating is going into that picture generation (how would it - there is no analogue connection!).

    Also, would it be impossible to let's say have an option in the TC64s menu to use the real C64 CPU instead of the emulated one so one could enable the casette port, but at the same time keep the VGA output enabled?

    That's not possible, unfortunately, because we need to know the state of the six processor port bits in order to tell if an access to the $dxxx area is really going to the IO chips or not. It may become an option in the future after we have fixed the remaining CPU bug, but that will result in other drawbacks, such as a limited or maybe even non-working menu system after you have chosen to activate the tape port. Again, I'd like to emphasize that this is not possible yet, as we can't completely replicate the original behaviour of the CPU.

  • That's not possible, unfortunately, because we need to know the state of the six processor port bits in order to tell if an access to the $dxxx area is really going to the IO chips or not. It may become an option in the future after we have fixed the remaining CPU bug, but that will result in other drawbacks, such as a limited or maybe even non-working menu system after you have chosen to activate the tape port. Again, I'd like to emphasize that this is not possible yet, as we can't completely replicate the original behaviour of the CPU.

    I wouldn't mind if it had other drawbacks as long as VGA output was working at the same time and everything went back to normal after a powercycle. So maybe it would be easier and more realistic to add TAP support as a feature? So we could load TAP files from the TC64 the same way Tapuino works. I would be totally fine with having the tape port disabled as long as I could load TAP files from the TC64 itself, the same way we emulate the 1541 disk drive.

  • I wouldn't mind if it had other drawbacks as long as VGA output was working at the same time and everything went back to normal after a powercycle.

    Going back to the menu wouldn't even require a power-cycle in that mode (if it ever comes to life), but the "freezer" function(s) would not be available. So in essence, going to the menu would then mean to lose most of the status that the machine was in when you decided to go to the menu.


    So maybe it would be easier and more realistic to add TAP support as a feature?

    Nope, less realistic. We're feature-complete, and TAP support would be a new feature. The TAP file would have to be stored somewhere, logic for feeding it into the (emulated) CPU would have to be added, and the mere fact that the FPGA is practically full currently forbids to even think about new features. We need to keep a bit of space for bug fixes in the already-existing features.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.