68000 ASM generating a tone on single FM channel YM2612
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
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!
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!
my album - last thursday died last week
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am
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.
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.
-
- Very interested
- Posts: 58
- Joined: Tue Feb 25, 2014 3:38 pm
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.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 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):
Code: Select all
.org 0x00000004
dc.l entrypoint
entrypoint:
move.b #0xAF, %d0 |; Move byte AF intro register d0
move.b %d0, %d1 |; Move byte from register d0 intro register d1
movea.l #0xFFFF0022, %a0 |; Setting up address in a0
move.b %d1, (%a0) |; AF should now be in FFFF0022 memory.
move.b 0xFF0022, %d2
cmp.b #0xAF,%d2
bne fail
success:
move.w #0x00E0,%d2 | Green
jmp setcolor
fail:
move.w #0x0E00,%d2 | Red
setcolor:
move.l #0xC0000000,%d1
move.l %d1,0xC00004 | setup CRAM write
move.w %d2,0xC00000 | write bg color
done:
jmp done
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.
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am
Oooh more learning.
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
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.
Code: Select all
setcolor:
move.l #0xC0000000,%d1
move.l %d1,0xC00004 | setup CRAM write
move.w %d2,0xC00000 | write bg color
Edit: I'm a little confused, taken from bigevilcorp's blog after trying to find more information on 0xC0000000
He uses 0x40000003. What page in the Genesis manual can help me understand these numbers?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:
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.
Last edited by Count SymphoniC on Sat Sep 20, 2014 6:10 pm, edited 1 time in total.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 58
- Joined: Tue Feb 25, 2014 3:38 pm
YesCount 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?
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).Count SymphoniC wrote:He uses 0x40000003. What page in the Genesis manual can help me understand these numbers?
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.
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am
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.
Should be fun.
Should be fun.
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
Also you'll want Charles MacDonald's VDP doc and the info on this page and maybe the interactive VDP docs at the bottom of that page.
my album - last thursday died last week
-
- Very interested
- Posts: 149
- Joined: Sat Nov 17, 2012 3:58 am