Direct Color Demo using DMA

Announce (tech) demos or games releases

Moderator: Mask of Destiny

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

Post by Stef » Mon Jul 23, 2012 8:07 pm

If you look closely at the first post :
Recently, a demo was uploaded that used DMA to the CRAM background color entry to do a direct color display (9 bit RGB). It's hard as hell to see if the mode is useful from the demo - the image used sucks donkey dongs.
Well Chilly Willy said the concept was already in the posted demo (i agree, he could have give your name)... Actually i don't know who originally had the idea but it is really neat, kudos to him for having the idea... kudos to you for having improved / fixed / rewrote the code and to Chilly Willy for having posted severals demos exploiting it and making that thread :)
Also it is nice to have a post in spritesmind so we keep traces...
I think it is always better to share findings and everyone can use it and even improving it...
Last edited by Stef on Mon Jul 23, 2012 8:15 pm, edited 5 times in total.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 8:09 pm

Chilly Willy wrote:First, the only thing from your demo is the loop that sets up the dma, and even that had to be rewritten for GAS syntax. Second, from what's been said and the comments, this is about the only way to get the timing, which means that whole loop is a FUNCTIONAL dependency, and thus not eligible for copyright in any case. Third, the only negative thing I had to say about the original demo was concerning the choice of image... and EVERYONE agrees that was a bad choice of image. Fourth, the praise is for the MODE, not me. Finally, you didn't originate the mode - from your own words, you merely fixed someone else's code.

SHEESH! You need to grow a thicker skin if this thread bothers you in the least.
I did not fix anything, I rewrote it. I doubt my timing is the only thing to get it to work. I just kept adding nops and moves until it worked.

The loop is the only thing important in the demo, the image data and the init code is standard and unimportant. Plus, the only way you talked about the original implementation I posted was negatively. The image sucked, "a demo was posted" (by whom? where? Not even the slightest bit of recognition.)....

Of course, I did not originate it, but as far as I can see, I was the first one to publically post (with source) a working implementation. Quite frankily I don't like your attitude in the least.

You claim our image sucked, but it has what it has, 336 unique colors, the highest value we were able to achieve. You posted.... a pixelated screenshot from an old game that probably the MD is able to display with *standard* methods just fine.

If you can't see that you're wrong, then something is seriously wrong with you and this community.

I put a disclaimer in the readme to atleast somehow control the flow of the method. Now it's all over the place. Great fucking job. Thank you.

I posted the source to allow people to learn from it and maybe even improve upon it, not to post an own demo 5 minutes later which essentially is the same exact thing in a separate thread without even any mention of where the source was obtained from. That's not "basing upon something", that's outright "stealing" which is *not* something that should be encouraged.

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

Post by Stef » Mon Jul 23, 2012 8:25 pm

It is not bad to have a separate thread for that so we can find it easily.
Also the demo you posted did not worked (at least for me) where Chilly Willy ones does which may explain why people has now more interest about the method :)

The original topic you are talking about is this one ?

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 8:28 pm

Stef wrote:It is not bad to have a separate thread for that so we can find it easily.
Also the demo you posted did not worked (at least for me) where Chilly Willy ones does which may explain why people has now more interest about the method :)

The original topic you are talking about is this one ?
I had my binary working and verified by tiido on many machines, also I tested on my own... Do not use the binary included with the zip package, I think I broke something in there.... The original BITMAP336.BIN should work (1 page earlier in the thread you linked) (maybe you have to pad it first? some flash carts are allergic to that kind of issue)

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

Post by Stef » Mon Jul 23, 2012 8:31 pm

Oerg866 wrote:
Stef wrote:It is not bad to have a separate thread for that so we can find it easily.
Also the demo you posted did not worked (at least for me) where Chilly Willy ones does which may explain why people has now more interest about the method :)

The original topic you are talking about is this one ?
I had my binary working and verified by tiido on many machines, also I tested on my own... Do not use the binary included with the zip package, I think I broke something in there.... The original BITMAP336.BIN should work (1 page earlier in the thread you linked) (maybe you have to pad it first? some flash carts are allergic to that kind of issue)
Ok, i used the binary in the zip file, others links seems to be broken :-/ At least the website return me a weird error : "550 Can't change directory to /pub/temp/BITMAP336.BIN"

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 8:35 pm

Stef wrote:
Oerg866 wrote:
Stef wrote:It is not bad to have a separate thread for that so we can find it easily.
Also the demo you posted did not worked (at least for me) where Chilly Willy ones does which may explain why people has now more interest about the method :)

The original topic you are talking about is this one ?
I had my binary working and verified by tiido on many machines, also I tested on my own... Do not use the binary included with the zip package, I think I broke something in there.... The original BITMAP336.BIN should work (1 page earlier in the thread you linked) (maybe you have to pad it first? some flash carts are allergic to that kind of issue)
Ok, i used the binary in the zip file, others links seems to be broken :-/ At least the website return me a weird error : "550 Can't change directory to /pub/temp/BITMAP336.BIN"
Oh right, I don't have the ftp setup yet haha...

http://oerg866.mdscene.net/BITMAP336.BIN should work ;)

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

Post by Stef » Mon Jul 23, 2012 8:43 pm

Ok thanks, i'll try it :)

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

Post by Stef » Mon Jul 23, 2012 8:56 pm

Working perfectly :)
And i have to agree with you, the image looks great. At least it is exactly what kind of image we imagine for a direct color mode demo. Having others examples is nice too but that demo also show us that 512 colors is definitely not enough to do nice gradients :-/ too bad we cannot combine that direct color mode with hilight shadow. If we enable hilight shadow the background color is always displayed in shadow mode (as far i remember), i wonder if someone already made some tests to use the last palette entries (0x3E & 0x3F) as background color with hilight turned ON. Maybe it could affect the way color is interpreted as it is with sprite pixels :p

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 9:00 pm

Stef wrote:Working perfectly :)
And i have to agree with you, the image looks great. At least it is exactly what kind of image we imagine for a direct color mode demo. Having others examples is nice too but that demo also show us that 512 colors is definitely not enough to do nice gradients :-/ too bad we cannot combine that direct color mode with hilight shadow. If we enable hilight shadow the background color is always displayed in shadow mode (as far i remember), i wonder if someone already made some tests to use the last palette entries (0x3E & 0x3F) as background color with hilight turned ON. Maybe it could affect the way color is interpreted as it is with sprite pixels :p
Heh thanks :)

The fact though that the display is turned off during the entire dma doesnt help... which is why I suggest to simply only use half the screen for idrect color and use other half for other business. Should work miracles since it's cumpletely unrestricted and can use all 4 pallette lines still!

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

Post by Stef » Mon Jul 23, 2012 9:14 pm

Hehe i was speaking about highlight / shadow because i though about insane stuff as modifying the background VDP register from Z80 while the 68k was lock by DMA. Anyway crazy idea as we probably cannot write 16 bits port correctly from Z80 as the VDP would probably not accept any external command when a DMA is occuring...
Using direct color on half of screen could be an idea too. A problem of the direct color mode is that it eat a lot of CPU time too... too bad as it would be a perfect method to do a bitmap mode. Hehe that gimme some ideas :)

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 9:32 pm

Okay, my apologies - it seems there's a few people who DO like your original image. :D

Also, I'm sorry if I stepped on your toes by releasing this demo... it was merely to give different images to demonstrate better (to me at least) how good the image could be. You'll notice that this thread is the only place I've even mentioned this subject. It will remain the only place I talk about it until I do something more my own. Is that okay with you? Also, I DO credit people where credit is due... what kind of credit do you want for your work on this method of display? I'll happily include it in everything I do with this from now on.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 9:35 pm

Chilly Willy wrote:Okay, my apologies - it seems there's a few people who DO like your original image. :D

Also, I'm sorry if I stepped on your toes by releasing this demo... it was merely to give different images to demonstrate better (to me at least) how good the image could be. You'll notice that this thread is the only place I've even mentioned this subject. It will remain the only place I talk about it until I do something more my own. Is that okay with you? Also, I DO credit people where credit is due... what kind of credit do you want for your work on this method of display? I'll happily include it in everything I do with this from now on.
Thank you for your considerations. I'm fine with an one liner saynig "based on xyz..."

No hard feelings?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 10:18 pm

Oerg866 wrote:
Chilly Willy wrote:Okay, my apologies - it seems there's a few people who DO like your original image. :D

Also, I'm sorry if I stepped on your toes by releasing this demo... it was merely to give different images to demonstrate better (to me at least) how good the image could be. You'll notice that this thread is the only place I've even mentioned this subject. It will remain the only place I talk about it until I do something more my own. Is that okay with you? Also, I DO credit people where credit is due... what kind of credit do you want for your work on this method of display? I'll happily include it in everything I do with this from now on.
Thank you for your considerations. I'm fine with an one liner saynig "based on xyz..."

No hard feelings?
None. Sorry for being a dick - I should have gotten in touch with you first about this anyway. :oops:

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jul 24, 2012 12:35 am

Anywho, back to the topic... let's take a closer look at the main loop:

Code: Select all

        move.w  #0x8154,(a3)            /* Turn on Display */
        move.l  #0x40000000,(a3)        /* write to vram */
1:
        btst    #3,1(a3)
        beq.b   1b                      /* wait for VB */
2:
        btst    #3,1(a3)
        bne.b   2b                      /* wait for not VB */

        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)
        move.w  d0,(a2)

        nop
        nop
        nop
        nop

        /* Execute DMA */
        move.l  #0x934094ad,(a3)        /* DMALEN LO/HI = 0xAD40 (198*224) */
dma_src:
        move.l  #0x95009600,(a3)        /* DMA SRC LO/MID */
        move.l  #0x97008114,(a3)        /* DMA SRC HI/MODE, Turn off Display */
        move.l  #0xC0000080,(a3)        /* dest = write cram => start DMA */
        /* CPU is halted until DMA is complete */
The first write ($8154) sets VDP register 1 to $54; that enables the display, disables vblank interrupt, and sets V28 (224 height) mode.

The second write ($40000000) sets the VDP to write to vram at address 0. Remember that the VDP INC register has already been set to 0 by this point, so the pointer doesn't increment when we write data.

Next we have two loops: the first waits for the VB bit to be set, telling us we are in the vblank period; the second waits for the VB bit to be clear, telling us we are no longer in the vblank period.

We are now in the active display area and the VDP is busy trying to load graphics data. This means that a tight write loop can fill the write FIFO in the VDP interface to the 68000. So 13 words are written all in a row to the VDP. This exactly fills the FIFO - more or fewer doesn't work.

We then do four nops - this gives the FIFO time to empty a bit.

We then write the DMA length registers, then write the DMA source address, write register 1 to turn off the display, then start the DMA with a write of $C0000080.

All the points are very strict or you don't activate the DMA at the same time every frame. The issue is we don't have a way to sync the CPU to the video frame. On the Atari 8-bit, you would do STA WSYNC and you'd be at the exact same point of an H line every time. Remember that loop to check the VB bit? That is only good to the resolution of that loop - we could have more than twenty clock cycles difference each loop. Hence the need to saturate the FIFO.

Saturating the FIFO is pretty strictly 13 words. I could replace the word stores with this and still work:

Code: Select all

        move.l  d0,(a2)
        move.l  d0,(a2)
        move.l  d0,(a2)
        move.l  d0,(a2)
        move.l  d0,(a2)
        move.l  d0,(a2)
        move.w  d0,(a2)
Once you've saturated the FIFO, activating the DMA takes careful track of the cycles as the FIFO empties. You would think this would work in place of the immediate long moves:

Code: Select all

        /* Execute DMA */
        move.l  d2,(a3)                 /* DMALEN LO/HI */
        move.l  d3,(a3)                 /* DMA SRC LO/MID */
        move.l  d4,(a3)                 /* DMA SRC HI/MODE, Turn off Display */
        move.l  d5,(a3)                 /* start DMA */
It doesn't. The bus cycles are wrong. THIS does work:

Code: Select all

        /* Execute DMA */
        nop
        nop
        move.l  d2,(a3)                 /* DMALEN LO/HI */
        nop
        nop
        move.l  d3,(a3)                 /* DMA SRC LO/MID */
        nop
        nop
        move.l  d4,(a3)                 /* DMA SRC HI/MODE, Turn off Display */
        nop
        nop
        move.l  d5,(a3)                 /* start DMA */
because it has exactly the same bus cycles as the move long immediates. The slightest deviation from the cycles represented in the code results in jitter from frame to frame.

To give you an idea of how sensitive this is, the loop in work ram starts the DMA 6 pixels earlier than the same code in rom.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Jul 24, 2012 3:33 am

Notes on other methods tried:

Read HCOUNTER: bit 0 of the horz line position is not accessible on the Genesis, so using the HCOUNTER give a jitter of a couple pixels.

Use HINT: I just tried this

Code: Select all

        /* init VDP regs */
        move.w  #0x8F00,(a3)            /* clear INC register */
        move.w  #0x8A01,(a3)            /* HINT value is 1 */

        /* loop - turn on display and wait for vblank */
dma_loop:
        moveq   #0,d0
        move.w  #0x8154,(a3)            /* turn on display (no VB int, DMA enabled, V28 mode) */
        move.l  #0x40000000,(a3)        /* write vram address 0 */
1:
        btst    #3,1(a3)
        beq.b   1b                      /* wait for VB */
2:
        btst    #3,1(a3)
        bne.b   2b                      /* wait for not VB */

        move.w  d0,(a2)
        move.w  #0x8014,(a3)            /* enable hint */
        move.w  #0x2300,sr              /* allow hint */
3:
        bra.b   3b                      /* wait for hint */
        .global dma_hint
dma_hint:
        move.w  #0x8114,(a3)            /* turn off display */
        move.w  #0x8004,(a3)            /* disable hint */
        move.w  #0x2700,sr
        addq.l  #6,sp                   /* pop exception frame */

        /* Execute DMA */
        move.l  d2,(a3)                 /* DMALEN LO/HI */
        nop
        nop
        move.l  d3,(a3)                 /* DMA SRC LO/MID */
        nop
        nop
        move.l  d4,(a3)                 /* DMA SRC HI/MODE, Turn off Display */
        nop
        nop
        move.l  d5,(a3)                 /* start DMA */
        /* CPU is halted until DMA is complete */
Has a jitter of four pixels. :(

Having or not having the nops makes no difference. I would have given the HINT method the best odds of giving a stable start time, but it doesn't. The HCNT method was actually more stable. :lol:

EDIT: I also tried HINT = 2 in case the first h int was unstable for some reason. It acts just the same for 2 lines before the h int.

Post Reply