68000 ASM generating a tone on single FM channel YM2612

For anything related to sound (YM2612, PSG, Z80, PCM...)

Moderator: BigEvilCorporation

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Sat Sep 20, 2014 4:35 am

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!

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Sat Sep 20, 2014 2:48 pm

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.

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Sat Sep 20, 2014 5:11 pm

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):

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
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 :D. 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.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Sat Sep 20, 2014 5:57 pm

Oooh more learning.

Code: Select all

setcolor:
   move.l   #0xC0000000,%d1     
   move.l   %d1,0xC00004      | setup CRAM write
   move.w   %d2,0xC00000      | write bg color 
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.
Last edited by Count SymphoniC on Sat Sep 20, 2014 6:10 pm, edited 1 time in total.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Sep 20, 2014 5:59 pm

A tiny rom like that works on MD without TMSS. To work with TMSS, you also need to write 'SEGA' to $A14000 before writing the VDP, and have the string "SEGA" at offset 0x100 in the rom.

4 is the reset vector, so setting 4 to a pointer to the start code sets where the MD will boot to when reset.

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Sat Sep 20, 2014 6:46 pm

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.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Sat Sep 20, 2014 7:13 pm

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. :lol:

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Sat Sep 20, 2014 9:26 pm

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.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Sat Sep 20, 2014 10:05 pm

powerofrecall wrote:...and maybe the interactive VDP docs at the bottom of that page.
THAT, is awesome.

Post Reply