Hello, Guest the thread was called331 times and contains 14 replays

last post from deft at the

Goattracker for MEGA65

  • Hi pmprog,

    thanks for that Idea.
    However I would like to have it to run in the C65 mode. Once I got that to run, I think it would be possible to have one goattracker file to be playe on one sid and one on the other. But, of course, such things are only working in the C65 mode....

  • When you say "one file on one sid and another on the other", you do know GoatTracker only exports a single SID tune. On top of that, the C65 isn't exactly a multi-tasking computer, so it's not like you can load up two "SIDplayer" programs and play a track on each.

    If you're thinking about playing two different tunes at the same time, you're probably going to need to write a completely new application that allows you to specify two SID files, load them into memory and have an interrupt routine that processes each tune and updates the associated SID.

    This isn't available "out of the box" (AFAIK), at least it's nothing supported by GoatTracker

  • Might be I have exmplaines it in the wrong way.
    For the C64 if you use a sid-file in your own program it works like this:
    First you load the sid-binary into the memory.

    !bin "hack_sound.sid",,$7e

    Then you ahve a short init section somewhere at the beginning of the code.

    ;init music
    jsr copy_sound
    lda #$00
    ;init music end

    And then you call the algorithem to play the sound for the next 1/60 sek. This is the followed by the other code - so you achieve parallelity to the code for example of your game.

    ;play sound
    jsr SOUNDADRESSE+3; $e003
    asl $d019
    ;play sound end


    So what I mean by playing two sid-files on the two sids would be the following:

    1) Loading both sid-binayies to the memory.
    2) Having two inits.
    3) Having the two sections after each other in a interrupt routine.

    You are right - this is not real parallelity, but it would seem like it to the humans ear (as it was before with sound and game for the human on the C64).


    So comming now back to my question:
    In order to do what I explanied above I need to adapt either the calling code or the sid files themself.
    Does someon have something where I can learn form how to do that?

  • I understand what you are after. You will need to write brand new init and interrupt routines; which means you'll either need to write a new "export" function inside of GoatTracker, or write some C65 that can read either the GT source file, or one of it's exports.

    The reason this is the case is because the C64 only has one SID chip, so the player that is used in the GT export only writes to a single set of SID registers. If you ran two different SID tracks on the C65 (or even the C64) in the manner below:

    call init_sid_a
    call init_sid_b
    jmp loopforever

    call play_sid_a
    call play_sid_b

    (Sorry, this is probably more x86 than 6502, but hopefully still understandable)

    All this will do on the interrupt will play SID B, because the SID registers known in both players point to the same SID chip, so "play_sid_b" will overwrite all the registers just set by "play_sid_a".

    So you'd either need to patch your second SID, or write a new playroutine that accepts a SID chip number in (A) or something, and use that to select which registers/addresses to use when setting the values.

    I hope that's a bit clearer

  • @pmprog,
    thank you so much for that detailed descrpition. Especiall at the important technical part, concerning the play routines, I see now much clearer. But might be, I can get the oppinion of some others, as well.

    Is there a way to patch the sid-file from the goattacker to make it play on the MEAG65 in C65 mode?
    According to my assumptions only few bytes concering some register adresses and something concerning the timer would have to be patched.
    I allready have the corresponding workflow to patch a sid-file to run on the C128 in C128 mode, and my first idea was to learn from that, but the person that started that couldn't finish it...so I do no see the compleete way.

  • Using the following source code:

    It appears the "right" SID is mapped at $D400 which is where the C64 SID chip is mapped (meaning GT files should play without any changes, would need to test this though), and the "left" SID is mapped at $D440.

    This means to play a SID track on the "left" SID, you need to add $40 to each address in the INIT and PLAY subroutines. Whether you do this to your SID file, or if you patch this as you load the file into RAM is entirely your choice.

    Anyway, there's not much more I can say here; maybe deft or gardners or somebody else who's actually got their dev board up and running can confirm what I've said, or even correct me if I'm wrong.

  • @Zaadii: well, it depends who those SID files work. Honestly I have no experience with that at all :( But if you give examples, or you have well specified questions ... Basically, if the question is about to load something in C65 mode (something like the usual BASIC stub with a SYS line), it can be done with writing C65 version (it would need a BANK token as well, and another memory address), then maybe some init code to set C64 speed, alter memory configuration etc etc, and then the program will more or less "sense" it's a C64 or so. However you may have problem with illegal opcodes especially on a real C65. On M65 though, as far as I know there is an ongoing change to use 6502 CPU personality if VIC-II I/O mode is set so it can help in that situation at least. But I am not sure if you want this, or you'd be more happy to port things to "really C65 mode" not something like "mangled" ... Well, I am not sure I could explain myself clearly enough ...

  • Who - I found a post here. Posted so very long ago in the other Forum :):):).

    Si in the meantime I have the posibility to answer myself.

    Dear Zaadii,

    you have asked a very good an falid question.:D

    If you use the goat traker, you need to write the two sound played on the two sid in two seperate tracker projects.

    You need the to patch the outputs of the tracker generated files to adapt the adresses the code is accessing.

    I have done this allready for the Commodore MK2 board (that hosts 2 SIDs).

    The only difference is that is had to patch there only one of the outputs, but the worklow would be the same.

    You might want to have a look at the MK2 workflow here:

    Might be you retry this for the MEGA 65 and post a Video on how you did it an how it worked:)

  • I don't know if this helps but I wrote my own tools to generate source code instead of binaries for GoatTracker tunes to compile with ca65. I could provide them if they would be of interest?

    Having the source code would allow some versatility. More over, the tools use a driver that you provide so you could even potentially optimise it for the 4510.

    I'm not sure that they support dual SIDs as they stand but it would be extremely simple to do this if not the case.


  • Hi Daniel,

    this seems really helpful, thanks for the offer! I have to admit the whole music topic is more or less untouched yet, I believe we need someone who takes care of it. What we would need in the first place is a extended (Goat?)Tracker that allows for two 16-bit pcm audio channels which the MEGA65 provides along with the 2 SIDs. Without such a tracker we are not able to make use of the hardware possibilities of the MEGA65. Imagine real drums or a stereo choir playing along with the stereo SIDS :)

    "VHDL schreiben ist wie in Mordor zu arbeiten. Es gibt viel Streben und viel Rauch, aber nur wenig Erfolg. Und Erfolg sieht meist schlimmer aus als Misserfolg" PGS 2019