Bad pixellation.

Count SymphoniC · 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.

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 · 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.

Stef · 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 · 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.

TmEE co.(TM) · 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.

Count SymphoniC · 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 · 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

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

Count SymphoniC · 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.