Actually for programming of this sort you'd probably be fine with basic algebra. Mostly you're going to want a good understanding of the chip hardware and FM synthesis in general, but the advantage of programming to hardware like this is it's not the same as programming something like an emulator where you need to know the math to produce the waveforms. Mostly to get sound out of the Genesis, you write registers to the chip and the chip produces sound. You might need a little math to do something like convert FM operator TL values to something more common like decibels (just off the top of my head) but I think even that is a linear operation.

The best part about writing a tracker is you can simply expose the various chip registers as tracker commands and let the user worry about what data to put into what register, and you simply worry about making sure it is valid and putting it there. Most of the math will probably be very simple stuff, but you'll quickly find that writing something in assembly means there will be a lot of it. The elegant, mathematical expressions you see in higher level languages get broken down to their atomic operations. You actually end up learning to think of the "small picture." This is another reason to be thankful for the 68k architecture, it's much more tolerable in this regard than other processors of equivalent age. At least you aren't trying to do this on an 8 bit CPU!

Nice to know, that makes this project seem a lot less complicated, although I know it will still be complex. At least Algebra is painless.

I understand what you're saying. I've thought of ways I could use 68k to do something useful, beyond apparently just moving bytes around. Something like, read and display a bitmap image. So I would have to build a sort of a code fractal. Like building blocks that will be a part of larger building blocks. I have to tell the cpu where the bmp is located, read the header and it's data on the dimensions, color data and so on. Then tell the cpu to read pixel bytes from these addresses and move them to those addresses in vram, and more. That's all of course the very generalized aspect of it with missing info I'm sure. But I think I get it. I can just imagine how long it takes to type out enough code to actually start seeing results. So far it's an amazing language to me though.

powerofrecall wrote:Are you using a startup code, or is that code all you have total? You'll need at absolute minimum to have a vector table before your code begins or else nothing will work.

This is pretty nitpicky, but just to clarify: if you have a mega drive without tmss, you don't even need the full table. The minimum you need is the entry point vector.
This is an example based on the code Count SymphoniC posted earlier, which instead of looping, evaluates whether the byte has been written, and if it has been, sets the bg color to green (otherwise sets it to red):

This will turn into a rom with just 46bytes (which is less than the vector table), and works on my megadrive and on fusion. Exodus complained that it can't read the header data . If you fill the rom with 0x00s Exodus will run the rom fine.

I do realize that it's not very wise to write code over the vector table, I just wanted to state that it's possible.

Edit: just tested on Regen, and while it shows a very dark green (I guess STE is on), the debugger indicates that the code has been executed correctly.

I want to make sure I understand this because it's interesting to me. From the Genesis manual if I understand correctly, 0xC00004 is the address for the control port and 0xC00000 is the address to the data port for the vdp, right? What is the immediate value #0xC0000000 exactly, I get that it's being used to setup CRAM for write (or did I just answer my own question)? From my understanding, you're moving that to d1 then to the control port. Which then enables you to write green or red (whatever is in d2 based on the byte test) to the data port. Did I get all of this right?

Edit: I'm a little confused, taken from bigevilcorp's blog after trying to find more information on 0xC0000000

which in HEX is 0x40000003. Now we can move it to the VDP’s control port (I/O address 0x00C00004) to tell it we’re about to write data to VRAM address 0xC000:

He uses 0x40000003. What page in the Genesis manual can help me understand these numbers?

The only part of the code that I knowingly don't fully understand is
.org 0x00000004, I've seen it in some disassemblies but a quick skim through the instruction set books and wiki doesn't seem to have anything on this .org, or I missed something. Thanks for posting, interesting read.

Count SymphoniC wrote:From my understanding, you're moving that to d1 then to the control port. Which then enables you to write green or red (whatever is in d2 based on the byte test) to the data port. Did I get all of this right?

Yes

Count SymphoniC wrote:He uses 0x40000003. What page in the Genesis manual can help me understand these numbers?

If you search for "§ 6 ACCESS VDP RAM" you should find it (I don't know which original page it is, I always use the html file that came with sgdk).
0x40000003 Should be a VRAM write if I am not mistaken.

.org 0x00000004 tells the assembler to continue writing at position 4 (counted in bytes) in the rom, where the entry point vector is located.
In bigger projects it's much more useful to have a vector table instead of just specifying the entry point and beginning with code though.

Cool thanks for the info. Maybe I can learn 68k AND figure out how to do a hello world at the same time. I really want to get started messing with the genesis immediately. Then once I figure all that out I can start on the YMDJ tracker GUI and control pad input. Then I'll worry about the sound engine.