Page 1 of 1

Colors way too dark in 0.97 on certain roms.

Posted: Sun Sep 21, 2014 5:21 am
by Count SymphoniC
Hi there. I'm working on an M68k music tracker for the Genesis. In preparation for doing the GUI I was testing loading palettes to the VDP. Although I'm not too sure I was able to successfully load a palette (which is surely my fault), I was able to successfully fill the screen with a color (any color), but they are all way too dark. The VDP debugger shows the colors at normal brightness. I couldn't figure out why, so I compiled the source code for bigevilcorp's hello world and the problem is the same. I tested other roms (one commercial and one not) and the colors are normal. I also tested my palette test on GENS and the colors display at normal brightness.

This leads me to believe there is something wrong with both mine and bigevilcorp's source code. But I can't figure out what that could be. Any ideas? :?

Posted: Sun Sep 21, 2014 6:51 am
by twosixonetwo
Have you made sure that shadow/highlight mode is turned of?
If you did not, this line should do it:

move.w #0x0C81, 0xC00004

The value 0x81 can be different if you are using 32-tile mode or if you are using interlaced mode. For further explanations you might want to look into the documentation of vdp register 0x0C.
Generally it's safer to set all register values that your code depends on in the beginning of your code, instead of trusting the mega drive/emulator to already have them set the way you need them.

Posted: Sun Sep 21, 2014 2:38 pm
by Count SymphoniC
Well after your suggestion I tried 0x0c81, 0x0c87, 0x0c06, and 0x0c00 in the main program code, and all values result in black screen. At least now, I know how to better manipulate the VDP. Thanks for pointing me in that direction.

EDIT: Putting that VDP control instruction before my palette code results in black screen, putting it in after my palette code doesn't result in black screen, but the color is still too dark. Here's the assembled bin for bigevilcorp's hello world, which suffers the same issue, if anyone wants to test it on their copy of Regen just to rule out computer problems (I doubt it is that though. But who knows it could also be the emulator.)

Posted: Sun Sep 21, 2014 4:02 pm
by twosixonetwo
Ooops, it should have been
move.w #0x8C81, 0xC00004
I am sorry.
In case of the file you've posted the reason for the dark colors is a different one: When register 0 is set, the value from 0x8020 is sent to the control port of the vdp. The value 0x20 just sets bit 5, which makes the left column blank (only rarely useful), whereas bit 2, which is needed to get full color access, is left 0. So instead of sending 0x8020 to the control address, it should be 0x8004. This value seems to be read from an array of values that are sent (I can only see the disassembly), so you might want to search for that.

Posted: Sun Sep 21, 2014 4:51 pm
by Count SymphoniC
That indeed was the problem, and you fixed it.

Code: Select all

   dc.b 0x20 ; 0: Horiz. interrupt on, plus bit 2 (unknown, but docs say it needs to be on)
   dc.b 0x74 ; 1: Vert. interrupt on, display on, DMA on, V28 mode (40 cells vertically), + bit 2
   dc.b 0x30 ; 2: Pattern table for Scroll Plane A at 0xC000 (bits 3-5)
   dc.b 0x40 ; 3: Pattern table for Window Plane at 0x10000 (bits 1-5)
   dc.b 0x05 ; 4: Pattern table for Scroll Plane B at 0xA000 (bits 0-2)
... and so on
This was used in his startup code.

This is the code that uses that array which I truncated for space saving.

Code: Select all

; ************************************
	; Init VDP
	; ************************************
	move.l #VDPRegisters, a0   ; Load address of register table into a0
	move.l #0x18, d0           ; 24 registers to write
	move.l #0x00008000, d1     ; 'Set register 0' command (and clear the rest of d1 ready)

	move.b (a0)+, d1           ; Move register value to lower byte of d1
	move.w d1, 0x00C00004      ; Write command and value to VDP control port
	add.w #0x0100, d1          ; Increment register #
	dbra d0, @CopyVDP
See I wasn't ready to make my own startup code so I borrowed his. So that's why the problem took place with my build also. Thanks to this whole hiccup though and your hints, I'm a lot more confident in understanding how to code and interact with the hardware. Now the Sega docs are making lots of sense. The registers and bits are beginning to really enter my view of understanding. Thanks.

And I have to say this is some pretty cool stuff!