Megadrive 16bit adres boundaries

Discussion of development of software for any "obsolete" computer or video game system.
Post Reply
klonoa
Posts: 74
Joined: Mon Nov 21, 2011 3:53 pm

Megadrive 16bit adres boundaries

Post by klonoa » Mon Oct 19, 2020 6:24 am

Hey all,

I'm making a simple tic-tac-toe game for the megadrive just to kinda get to know the system.

I was working on a function that would display a block of text so I typed up this:

Code: Select all

BiggerText:
	DC.B 'Hi this is a text with more lines',$0D
	DC.B "It's quite handy writing these lines in the editor",$0D	
	DC.B "Here's just one more line for good measure",$0D,$03

COLORPALATE:
	DC.W $0000,$0000,$000E,$00E0,$0E00,$0002,$0004,$0006,$0008,$000A,$000C,$000E,$0020,$0040,$0060,$0080
But then it would crash when loading the color palate.

I quickly found out that it's a common beginners trap: http://www.easy68k.com/paulrsm/doc/trick68k.htm

So the address of the color palate has to be even, because the cpu reads 16bit words, so an uneven address would simply point to the higher
byte of a word making it an illegal instruction.
Do I understand this correctly?

What would be the best way to combat this mistake?
Would it be best just to add another byte to BiggerText to make COLORPALATE even? (Like I have done now)
Or is there another (maybe better) approach to this?

Hope you're having a good day!

User avatar
Quietust
Posts: 1684
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Megadrive 16bit adres boundaries

Post by Quietust » Mon Oct 19, 2020 6:30 am

klonoa wrote:
Mon Oct 19, 2020 6:24 am
So the address of the color palate has to be even, because the cpu reads 16bit words, so an uneven address would simply point to the higher
byte of a word making it an illegal instruction.
Do I understand this correctly?
No - the CPU is "smart" enough to realize that reading a 16-bit word from an odd address would require performing two reads and splicing the results together. While some CPUs (such as the x86) will actually do this, the 68000 (and many others) instead just flat-out refuses to do so, raising an Addressing error instead (interrupt #3).
klonoa wrote:
Mon Oct 19, 2020 6:24 am
What would be the best way to combat this mistake?
Would it be best just to add another byte to BiggerText to make COLORPALATE even? (Like I have done now)
Or is there another (maybe better) approach to this?
It probably depends what assembler you're using, but there should be an "align" directive/pseudo-op which ensures that the next data (or code) is aligned to a 16-bit (or possibly 32-bit) boundary.
Last edited by Quietust on Mon Oct 19, 2020 6:46 am, edited 1 time in total.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

klonoa
Posts: 74
Joined: Mon Nov 21, 2011 3:53 pm

Re: Megadrive 16bit adres boundaries

Post by klonoa » Mon Oct 19, 2020 6:45 am

Found it! :D

For any other noobies that might see this, this is the way to do it if you're using asm68k:

Code: Select all

BiggerText:
	DC.B 'Hi this is a text with more lines',$0D
	DC.B "It's quite handy writing these lines in the editor",$0D	
	DC.B "Here's just one more line for good measure",$0D,$03

	EVEN  ;;; << Ensures an even address for COLORPALATE
COLORPALATE:
	DC.W $0000,$0000,$000E,$00E0,$0E00,$0002,$0004,$0006,$0008,$000A,$000C,$000E,$0020,$0040,$0060,$0080

Thanks for the explanation and tip! :beer: :mrgreen:

Post Reply