SpritesMind.Net

I will wait for your result.

By the way don't you know why the direct colour demo doesn't work?
Few lines are drawn in emulator and black nothing on sega md hardware.

Yes, the DMA direct color mode uses nearly all the CPU time just on the display. Clearly, it's not right for everything or everybody. It might be handy for static displays in some games, or very simple games that don't need much cpu time. Mainly, I think it's a mode for certain CD games... especially first person style games. It gives a straight, plain bitmap mode that just happens to use direct colors rather than a palette... just what certain games need. In the end, it's just another tool available for programmers to use if it suits the need.

chilly willy why your direct colour demo doesnt work on my hardware and emulator?

greatkreator wrote:chilly willy why your direct colour demo doesnt work on my hardware and emulator?

It worked on my sega cd but the reason why it does not work in emulators is because of how they sync up with the other processor. Regen shows a blank image so that means it updates the vdp every frame. Kega fusion shows one pixel stretched out to the whole line that means kega fusion updates the vdp every line. For direct color to work on an emulator the vdp needs to be updated every other pixel.

More exactly, Kega is processing DMA line by line while Regen/Gens are processing all DMA lines at once then hang the CPU for the DMA processing time. For commercial games, line granularity for DMA is enough (and for 99% of games, doing like Regen/Gens is enough as well because DMA is done when display is inactive) but for these demos, DMA must be processed at VDP RAM access slot granularity.

Even Retrocopy, which claims to have cycle-accurate VDP (and is showing a little bit differently because it allows mid-line changes) still displays garbled lines because these demos expect exact timings, not approximations.

greatkreator wrote:chilly willy why your direct colour demo doesnt work on my hardware and emulator?

Which one? If the CD, it's because the iso I made uses the US boot loader. You have your choice of US, EU, and JP on the CD... I'm not aware of any way to make a "region-free" CD that doesn't involve changing the CD BIOS.

Emulators can take the "easy way out" on this mode - add detection of a "large" DMA to the background color entry with INC=0 and then just convert/display the bitmap at the DMA location directly. Problem solved.

chilly whilly is the direct colour demo available for mega drive?

greatkreator wrote:chilly whilly is the direct colour demo available for mega drive?

The first several links in the direct color demo thread are rom images meant for folks with a flash cart. They should work on any flash cart (MD-Pro, Everdrive, NeoMyth) on any region or model Sega. The last link was a CD image for US Sega CDs. If you want me to make an iso for a different region CD, let me know. It wouldn't take but a few seconds to compile.

If you have a MegaCart, NeoMyth, or Everdrive, there are hacked CD BIOSes that allow running different region CDs on your Sega CD/Mega CD. For example, if you were in Europe on a MegaCD and wished to run a US CD, you would load the hacked US BIOS and that would load the US CD on your European CD. Some games also check the hardware region info after loading, but my demo doesn't, so it should work that way.

EDIT: Here's a European CD... it works in Gens/GS set to European BIOS, but I don't have real hardware to test on... all my stuff is US.

http://www.mediafire.com/?3pss9hims4aray9

My emulators says it misses US bios as well as EU bios.

Chilly Whilly what does this demo contain? The rgb lines made by scrolling as you did recently?
Is that it?

greatkreator wrote:My emulators says it misses US bios as well as EU bios.

Chilly Whilly what does this demo contain? The rgb lines made by scrolling as you did recently?
Is that it?

You cannot use this with current emulators. It does RGB directly by turning off the display and using the VDP DMA to fetch and store RGB values directly to the background color palette entry. It ONLY works on REAL HARDWARE. Now if this catches on, it might get added to emulators, but no existing emulator will show the correct display right now.

It is clear.

By the way Chinese clones don't work as well.
Unfortunately I own one yet.
Soon will have original.

greatkreator wrote:It is clear.

By the way Chinese clones don't work as well.
Unfortunately I own one yet.
Soon will have original.

Most current clones use ARM SoC with an emulator, so they won't work for certain. Anything that actually uses SEGA chips, licensed or clone, should work. Now what I'd like to see reports on are those later ToyTec Model 3 MegaDrives, or the older clones that used ToyTec chips.

Direct color isnt' actually as blocking. If you only use it while you need it to be, you can squeeze out a lot of CPU time.

Example:

One part: Image with direct color.

Other part, Image with regular tiles/palette maybe? something other, like animation perhaps?

And during that, use a sound driver that acutally manage to stay alive with very little CPU time, like echo

What would suffer the most with DMA direct color is PCM via the YM2612 - unless you only did a line or two, you'd have a BIG click everyframe. Even a low sample rate wouldn't help. But just using FM updated in the vblank wouldn't have a problem.

Chilly Willy wrote:What would suffer the most with DMA direct color is PCM via the YM2612 - unless you only did a line or two, you'd have a BIG click everyframe. Even a low sample rate wouldn't help. But just using FM updated in the vblank wouldn't have a problem.

Actually no, it's not that big of a deal. We once did DMA stuff with music, the engine survives with minimal cpu time. You'll notice a little flakyness. But in honesty, you either skillfully use the YM and PSG to their fullest without relying on PCM too much or you just don't belong in that field, end of story. PCM-Only stuff on Mega Drive is LAME.