Bad pixellation.

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

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

Bad pixellation.

Post by Count SymphoniC » Thu Oct 02, 2014 4:40 am

Thanks to TascoDLX and Jazzmarazz for helping get this tracker working on real hardware. Now a new issue is apparent. These are the pictures Jazzmarazz posted of YMDJ being run on a model 3 Sega Genesis and HD screen.

Image
Image
Image

Everthing seems to work ok, but this pixellation is horrible. Is this common for HD screens to do this with Genesis games? I can't imagine what I could've done wrong in my code to cause it, unless the code isn't playing nice with h/vblank. What seems to be the problem?

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Thu Oct 02, 2014 6:06 am

This is common for digital screens, they making some sort of conversion from analog signal to digital picture.
Image

Stef
Very interested
Posts: 3036
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Oct 02, 2014 7:57 am

I would say that is the classical bad composite signal mixing and the red component is the worst so it would be preferable to choose another main color if you want to improve the quality on composite output (blue component is the less affected i believe).

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » Thu Oct 02, 2014 8:31 am

My Cross products kit is hooked up via SCART to quite a high quality Samsung, send over the ROM and I'll get you some photos of it running.
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

TmEE co.(TM)
Very interested
Posts: 2392
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Oct 02, 2014 9:21 am

That looks to me like typical composhit signal artifacts.

S-video will have much less of that and RGb won't have any.

You would want to use grey colors or bright colors ones to minimize this kind of effect.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

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

Post by Count SymphoniC » Thu Oct 02, 2014 4:56 pm

If that's the problem then I won't worry about it too much. I'm eventually going to add in the option for the user to completely customize the color palette to their tastes.

http://www.mediafire.com/download/t7gx8 ... Jreg80.bin

That's the most recent working one. But the current version I'm working on is not available as I'm rewriting code for much more efficient use of ram, as well as adding another table for transposing in the Chain Editor. So far so good.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » Thu Oct 02, 2014 9:52 pm

I'm guessing whatever hardware you tried had clean VRAM? My kit contains garbage on startup (and I assume retail machines will behave in the same way), I've had to start clearing pretty much everything on startup.

Emulators are too kind :)

Image

Try this, after initialising the registers:

Code: Select all

	; ************************************
	; Clear VRAM with DMA fill
	; ************************************
	move.w #0x8F01, vdp_control     ; Set autoincrement to 1 byte
	move.w #0x93FF, vdp_control     ; Set bytes to fill (lo) (reg 19)
	move.w #0x94FF, vdp_control     ; Set bytes to fill (hi) (reg 20)
	move.w #0x9780, vdp_control     ; Set DMA to Fill (reg 23, bits 0-1)
	move.l #0x40000080, vdp_control ; Set destination address
	move.w #0x0, vdp_data           ; Value to write

	@WaitForDMA:                    
	move.w vdp_control, d1          ; Read VDP status reg
	btst   #0x1, d1                 ; Check if DMA finished
	bne.s  @WaitForDMA

	move.w #0x8F02, vdp_control     ; Set autoincrement to 2 bytes
	move.w #0x8ADF, vdp_control     ; Set H interrupt timing

	; ************************************
	; Clear CRAM
	; ************************************
	move.l #vdp_write_palettes, vdp_control ; Write to palette memory
	move.l #0x3F, d1                        ; CRAM size (in words)
	@ClrCRAM:
	move.w #0x0, vdp_data                   ; Write 0 (autoincrement is 2)
	dbra d1, @ClrCRAM
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

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

Post by Count SymphoniC » Thu Oct 02, 2014 10:00 pm

What the...

Okay well it was tested on a Genesis model 3, by Jazzmarazz. I'll try it and see what happens!

EDIT: https://www.mediafire.com/?ww9vp5vh5h5xhgo
There it is. This is actually the version I'm currently rewriting, so nothing beyond the song screen works properly and is liable to crash, even on an emulator.

Post Reply