Well, after many weeks of typing away, reading articles and tearing my hair out, I finally have Hello World up and running! Thanks to everyone here who helped!
http://www.mediafire.com/?o27lnohcco53i2o
Here it is for critique, or in the hope that somebody else starting out finds it useful. It's by no means the fastest code in the world, I've sacrificed a lot of optimisations for code readability, and I've dissected some of the confusing bits from other samples and broken them down. Rather than load a table of registers to the 68k from the beginning, I load destination addresses as and when I need them, to group relative code together.
I have some questions:
1. Originally, to help me better understand how addressing the VDP works, I scrapped use of the AutoIncrement register and manually incremented addresses myself after each copy. For copying the palette, this worked a treat - I copy two bytes, I increment the address by two bytes - but for copying the tiles it all went wrong. However many bytes I incremented my address by after copying a longword, my tiles were garbled, and I had to rely on setting AutoIncrement to 2 to solve this, but I can't figure it out. What exactly does AutoIncrement increment, and by how much? How would I do the same operation manually?
The 68000 utilizes a 16bit bus, meaning that a longword write will cause 2 sequential 16bit accesses, in this case the first to 0xC00000 and the second one to 0xC00002. With the auto increment set to 2, the VDP will add 2 to the internal VRAM address 2 times.
If you setup the auto increment to 0, you cannot write a longword to the VDP, I think. Both 16bit halves would be written to same address.
For word writes it's equivalent: the VDP incrementing by 2 or you doing it manually...
2. VDP addressing still confuses me. I've read and understand how to break down an address using the 'RRAA AAAA AAAA AAAA ---- ---- RRRR --AA' pattern, and I found a tool
here to help me with the job, but the results didn't seem to work. To copy a tile to the VDP, I've been writing 0x40000000 to the VDP command port, as decribed in
Marc's Realm, but if I use the calculated address using that tool, I end up with 0x40000011 for a VSRAM write, which makes sense looking at the pattern but it doesn't work. Why?
0x40000011 in binary is 0100 0000 0000 0000 0000 0000 0001 0001..
You may want a 0x40000003 for VRAM 0xC000...
3. How could I animate a tile? I'd like to computationally edit a tile (perhaps increment some of the colour IDs), would I edit the data live (i.e., move the changed longword lines to the correct address in VRAM) or would I keep a tile in main RAM to modify, and at regular intervals copy it to an unused area on the VDP and set the new tile ID (a double-buffered approach)?
Your choice, you can build your tiles on RAM without having to rely on the VDP access setup/slowdowns or you can build a buffer in RAM and do a transfer to the VDP on the VBI (using DMA or not)
4. I still can't figure out what those first 15 bytes of my ROM are, I've been manually deleting them in a HEX editor. Does anyone else here use ASM68k? Any success stories? I can't find any relevant documentation. Even the Sonic2 disassemblies are set up to use ASM68k, yet I haven't found any mention of this problem anywhere else.
IIRC S2 has an extra tool that converts s2.p in s2.bin, you may want to look into that..
Thanks in advance!
Reply With Quote
Originally Posted by l_oliveira
Bookmarks