Chunky-mode: explanation and example (source) - Page 3

I guess it might be interesting to see how quick the CD system DMA will do the copy so here is the code to DMA copy buffer for TOP/FRONT loader (not sure the size value is correct so double check that). I fully expect this to be slower. Remember the 68k is in a halt state while DMA is active. I'm not even sure you can DMA into palette RAM but it would be interesting to see what happens non the less, it might for example stop the snow effect.

	lea	$ff0000,a0
	move.b	#$00,$61(a0)
	lea     $7e(a0),a1
	move.l	#$FE6DFCF5,(a1)+
	move.l	#$82BFF693,(a1)+
	move.l	#$BF2902FD,(a1)+
	move.l	#$FFFFF97D,(a1)+
	move.w	#$FCF5,(a1)
	move.l	#CHUNKY_BUFFER,$64(a0)		; source
	move.l	#PALETTES+16*2*5+2+32,$68(a0)	; destination
	move.l	#$1F20/2,$70(a0)		; size (words)
	move.b	#$40,$61(a0)			; enable DMA

Razoola (./59) :
Yup, its a fast way and only marginally slower (2 scanlines) than using longwords, defo faster than the original method, I did not think it would be so close to longword speed in this instance. The method I mentioned altering the buffer format and using longwords is going to give a little more (45 or just into 46 scanlines) but there is the buffer format change to think about which might cancel that out plus more.
In my years of experience I know using longwords is the maximum for speed when copying memory around but I did not realise that sometimes using movem with words can get you almost as close in some situations so I learned something from your initial idea Dresbenboy. Maybe you learned that with movem its sometimes good to use an address register (indirect with increment) and not as storage . And blaster has been taken out of the world of move.l (a0)+,(a1)+ and introduced to the world of movem. We all gained something and that's good for everyone.

I only have little knowledge about the Neo Geo's hardware details, so I avoided the A7 variant. BTW, for the DIFF demo I coded in Easy68k without any real HW or even a set up emulator and development environment.
I come from the C64 (with crazy HW effects by tricking the VIC's flip flops etc., the Amiga (thus my 68k experience) and x86 (since 386). The Neo Geo is an interesting new experience to me!

Sounds like we have similar backgrounds. I programmed C64 and Amiga also but have long since forgotten the hardware specs for both. I don't have any real x86 experience but I do also use Easy68k

DMA seems slower than MOVEM.L-loop!?!

start line 0x014d
end line 0x0191
difference 0x0044 = 68 rasterlines

Yup, that what I expected. DMA sucks on the CD system, using it is a

I like all the DMA-stuff because it's perfect to stop (most) people from doing hacks & conversions!

Maybe you could "turn off" the screen by writing solid black fix layer tiles on the screen (for one frame) to hide the sprite layer while you are updating the palettes?
Possibly the snow effect could be hidden with fix layer tiles too?

Or if your render method is fast enough you could maybe increase the resolution by displaying only the half of the screen lines per frame
(similar to interlaced video: https://de.wikipedia.org/wiki/Zeilensprungverfahren) but it could cause the screen flicker too much.

Razoola (./63) :
Sounds like we have similar backgrounds. I programmed C64 and Amiga also but have long since forgotten the hardware specs for both. I don't have any real x86 experience but I do also use Easy68k

Nice! Today I heard a funny analogy from a colleague to explain this effect - although for a 1 year timeframe already, regarding his dissertation . He said, that he has kind of a ring buffer in his head, where everything gets overwritten quickly by any new data and experiences.

One of my long term friends is currently working on a selfmade GPU for Amiga. There are interesting options nowadays (Mega 65, FPGA based emulator platform, etc.).

NeoHomeBrew (./67) :
Maybe you could "turn off" the screen by writing solid black fix layer tiles on the screen (for one frame) to hide the sprite layer while you are updating the palettes?
Possibly the snow effect could be hidden with fix layer tiles too?

Or if your render method is fast enough you could maybe increase the resolution by displaying only the half of the screen lines per frame
(similar to interlaced video: https://de.wikipedia.org/wiki/Zeilensprungverfahren) but it could cause the screen flicker too much.

Interlace should work. Available rendering time will be reduced, while amount of pixels to be rendered goes up. But this will always be a tradeoff between effect computation done and screen size and resolution.
Blastar already tried switching off the fix layer following one of my suggestions (see first page). Only switching off the display via REG_ENVIDEO worked:

blastar (./23) :
on real hardware:

move.b #1,REG_DISBLSPR
move.b #1,REG_DISBLFIX
=> black screen with random pixels

move.b #0,REG_ENVIDEO
=> black screen without random pixels

Dresdenboy (./68) :
Blastar already tried switching off the fix layer following one of my suggestions (see first page).

What I wanted to describe is quite the opposite - turning on the fix layer and filling the screen with black solid "fix layer sprites" would hide all
regular sprites because the fix layer has the highest priority on screen and would "overwrite" everything what's rendered in the "chunky" window.
The Question is, how fast could the screen been overwritten with fix tiles and how fast could the be fix cleared after one frame.
I guess it could be to slow but it came to my mind today and I wanted to suggest it.

NeoHomeBrew (./69) :

Dresdenboy (./68) :
Blastar already tried switching off the fix layer following one of my suggestions (see first page).

What I wanted to describe is quite the opposite - turning on the fix layer and filling the screen with black solid "fix layer sprites" would hide all
regular sprites because the fix layer has the highest priority on screen and would "overwrite" everything what's rendered in the "chunky" window.
The Question is, how fast could the screen been overwritten with fix tiles and how fast could the be fix cleared after one frame. I guess it could be to slow but it came to my mind today and I wanted to suggest it.

Ok, I understand. My impression from what I heard so far is, that even a black color, if still fed from palette RAM, would suffer from these effects, as this is a more low level stuff happening on the bus than any priority thing. But it might work, I don't know enough about the gfx chips there. ^^ I'm more a microprocessor guy.

Yes that's right, so far the only known way to stop the snow is to update the palette while outside the visible screen area or disable the screen totally (REG_ENVIDEO). Its a pity such a register does not exist on the MVS/AES.

There are a couple of areas where the NeoGeo shoots itself in the foot and the palette situation is one of them. It would have been of great benefit if the non active palette RAM bank was connected to the 68000 bus, say from 0x402000 to 0x403FFF. Then one could update palettes to this region with no adverse affect and then simply toggle it once complete. That is a bit of an oversight on the part of the designers of the hardware

ohh, I missed 'REG_ENVIDEO' is only available on NGCD! so no 60fps or higher 'resolution' on mvs/aes?

Kuk will be happy: now, he can say that the NeoGeo CD is better than the AES/MVS

Folco (./38) :
Hi guys,Are you really hunting all bytes and cycles that you can on the Neo-Geo ?

Yes in this case. Every cycle counts as this loop is executed every screen update and influences image quality in a way.

Yes blaster its unfortunate but I believe you cannot disable video on the MVS/AES with 'REG_ENVIDEO' . There may be an undocumented way to do it however which has yet to be discovered. If there is one I would like to know what it is because it would come in handy in a few places for the unibios.

I think you require the palette update to complete in 40 scanlines on an NTSC (MVS/AES) system to avoid snow. The fastest way we found is 47 scanlines without adjusting the buffer more.

You can think about getting those last 7 scanlines by doing some of the move in the area between each scan line (hblank), The first movem.l from the buffer can happen in the visible area no problem. Its just a case of if the movem.l into palette ram can be timed to happen in the off screen area and if there is enough time for it to complete without coming into the next scanline. You'll again want to avoid interrupts (if possible for every scanline) because that's going to kill many cycles for nothing and I'm not even sure the interrupt will trigger in the optimal place.

On blank rasterlines, the current code updates about 5.2 palettes (3.7 with DMA as can clearly be seen in Blastar's screenshot). This would leave about 42 palettes to be written during the horizontal blank area.

The theoretical maximum amount of write cycles per blank area should be 128, barely enough for 32 colors or 2 palettes. If the screenshot is an indication, there might be some border pixels affected as well. The movem setup cycles (8 to 20 cycles in our variants) might already start in the display area. Assuming, that we now have enough time to prepare all registers in time even with the unmodified buffer, we'd at least need 21 additional rasterlines, more with the cycles lost while synchronizing with the border, etc.

Just tried this and it looks great. Well done Blastar . I like the way everyone collaborated to optimise the code. Would be amazing if someone could work out a Doom-style FPS on Neo Geo.

Hope someone can figure out how to get it working well on the AES/MVS.

Incidentally I read (direct from the programmer) that the tunnel section in Stardust (the original A500 version, not sure about the AGA version) was just an optical illusion. It doesn't actually alter perspective. It just appears too. It's really just a bigger-than-than-the-screen animated background.

How about the different pixel mappings used in this demo?