nesdev.org

DMA capability previously discussed is either done within the physical CPU (e.g. some extension/capability Sony added to the chip) itself or a separate chip on the mainboard somewhere. It is definitely not done within the PPU. Is this not mentioned anywhere in the docs? Is this done by the bus cont...

If you want me to write you some example 65816 code that shows how to do it (it's very very simple, nothing magical or amazing -- just standard code) I can do so. Nah, I was talking about the time it takes for the PPU in itself to start the DMA (since I assume it does the initialization for each of...

I don't know how DMA can ""break timing"". The CPU is held/suspended while the DMA transfers happen, so it's not like your underlying 65816 program would have any idea what's going on. DMA transfers for large sums of data are by far, "cycle-count-wise" (for lack of bet...

You can transfer more than 64KBytes using multiple DMA channels; e.g. for 128KBytes you could use channels 0 and 1. There are are total of 8 channels available to use. The CPU will block (wait) until all selected DMA transfers are done (register $420B selects which channels you want to initiate tra...

Well, here's the deal. Not long ago, a demo for Mega Drive was released that effectively would output a high color (512 colors!) linear bitmap on screen. Pretty stable, at that, the only serious issue being that VRAM refresh cycles causes some columns to be wider. Well, also that the massive DMA eat...

nintendo8 wrote:Ok it works now thank you for fixing it. Also glad to see you got Echo working I do hope the Alignment issue gets fixed because I wish to use Echo in my Sgdk project.

It was. And support for pausing was added too while we're at it.

Oi, long time I don't log in here.

You mean the MD port of G-Loc VS the MD port of Galaxy Force II, right? Because the MD port of G-Loc obviously can't hold a candle against the arcade version of Galaxy Force II. Yeah, MD vs. MD. The arcade version of G-Loc probably beats the arcade version of Galaxy Force anyways because of the 360...

Not wanting to be mean, but Galaxy Force 2 is crap... The port of G-Loc looks much better and has a higher framerate as well.

I fail to see how that improves anything. I mean, in the end all tile updates have to happen in a single vblank, so why is there that limitation?

TmEE got it. It's that or people complain because the game runs too slow.

Tepples, his post implies that any animation not aligned to even frames will be impossible. Project MD has lots of animations with sprites lasting 3 frames, for example.

Will you make the game compensate for NTSC/PAL speed differences? Project MD does, mainly because otherwise people would yell at me because the game runs at a different speed.

Also why only update sprite graphics on even frames?

The 68000 beats the 65816 mainly at 32-bit calculations. It still has more overhead compared to 16-bit calculations, but it's definitely much faster than faking it.

And the PC Engine has more colors but only one tilemap, and 8KB of RAM, and an 8-bit CPU, besides the fact that nothing was known about the SNES (was it even in active development or just research phases?). I don't see what that has to do with Sega's decision on CRAM? They most likely thought that ...

EDIT: talking about SA-1, these instructions are listed in the docs: http://srb2town.sepwich.com/junk/lolinstructions.PNG (just mentioning for the sake of it, couldn't miss the chance XD) Those are SuperFX instructions, but yes. I've tried to make a juvenile program, but haven't had much luck. Gah....

The SVP, which appears to be based on a Samsung SSP1601 core, is clocked at roughly the same speed as the FX2. I guess that explains this (make sure it seeks to 6:36): http://www.youtube.com/watch?v=PklSWesc1dM#t=6m36s Although somebody I know checked the cartridge and it seems to take the same clo...