Page 1 of 1
Bad pixellation.
Posted: Thu Oct 02, 2014 4:40 am
by Count SymphoniC
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?
Posted: Thu Oct 02, 2014 6:06 am
by r57shell
This is common for digital screens, they making some sort of conversion from analog signal to digital picture.
Posted: Thu Oct 02, 2014 7:57 am
by Stef
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).
Posted: Thu Oct 02, 2014 8:31 am
by BigEvilCorporation
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.
Posted: Thu Oct 02, 2014 9:21 am
by TmEE co.(TM)
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.
Posted: Thu Oct 02, 2014 4:56 pm
by Count SymphoniC
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.
Posted: Thu Oct 02, 2014 9:52 pm
by BigEvilCorporation
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
Posted: Thu Oct 02, 2014 10:00 pm
by Count SymphoniC
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.