Genesis Plus preview

Post by **Quzar** » Thu Jul 08, 2004 9:40 am

why would it be twice as much work, and not just twice as much data? the way i see it either way you have to update one data set each frame. this way you would still be updating one data set, but just alternating between two that you would be altering, one at a time.

BlackAura · Post by **BlackAura** » Thu Jul 08, 2004 10:09 am

why would it be twice as much work, and not just twice as much data? the way i see it either way you have to update one data set each frame. this way you would still be updating one data set, but just alternating between two that you would be altering, one at a time.

And what happens when a game updates some tiles, and then keeps using them for a while? One copy of the images will be correct, and the other will contain whatever was in there before, resulting in even more graphical distortions, which will effect the entire frame on 100% of all games. But the bits that are currently corrupted will look fine.

Example: Most games load all the background tile data in one shot at the beginning of a level. If we only upload that tile data to one of the two textures in VRAM, then the display will keep alternating between the two of them, so any graphics that haven't been modified this frame will continually flip between the correct graphics, and garbage.

The key thing is that we're only updating part of each data set on each frame. Twiddling takes so long that we can't really afford to keep re-twiddling and copying stuff that doesn't need it. If we didn't have to twiddle anything, I'd just DMA the thing over and be done with it.

Unfortunately, there's no way to do a VRAM->VRAM copy on the DC without reading through the SH-4 (slow), or just copying it back from wherever we got it from (which means re-twiddling it too).

Post by **Quzar** » Thu Jul 08, 2004 10:23 am

ok. thanks i understand now

(sometimes it takes a while =P). For some reason i was thinking that there may be a smart way of determining if it has been changed, and if it hasnt then dont flip to the other set. this would probably require a full compairison of the data or something =\.

InternetAddict · Post by **InternetAddict** » Sat Jul 10, 2004 3:08 am

so BlackAura when will you be releasing a new version of genesis plus?

BlackAura · Post by **BlackAura** » Sat Jul 10, 2004 8:52 am

Actually, I haven't released anything yet...

The answer is: when it's done. There are still a few more features that need implementing, a few things that need fixing, and a couple of bits which still aren't as good as I'd like them to be.

Link2k4 · Post by **Link2k4** » Sat Jul 10, 2004 5:23 pm

sounds good,BA, look forward to it :}

Post by **Christuserloeser** » Sat Jul 10, 2004 7:25 pm

There surely must be a way to fix the display problem. I am sure you'll find it someday

Chris

DcSteve · Post by **DcSteve** » Sun Jul 11, 2004 3:22 am

i still believe that stef knows how to work this through, in a quicker and more efficient way. look at c64k, its an unbelievable creation in itself and didnt take to long to code.

weeperofsouls · Post by **weeperofsouls** » Sun Jul 11, 2004 3:27 am

ive been wondering something for a while....

what exactly makes stef d's core so good over existing cores? is it a new design, optomization tricks, or what?

DcSteve · Post by **DcSteve** » Sun Jul 11, 2004 3:53 am

3x faster than the older common used core (musahi)- and i believe its written in C

. That is why the last preview of genesis plus is fullspeed on every game i played with minor hero graphic glitches and some 3d looking stage stuff. This is WITH messed but working 22mhz sound( which i believe has been privately hacked and rewritten to a much better state by warmtoe and blackaura! )

Post by **Quzar** » Sun Jul 11, 2004 4:12 am

DcSteve wrote:i still believe that stef knows how to work this through, in a quicker and more efficient way. look at c64k, its an unbelievable creation in itself and didnt take to long to code.

Stef had been working on his core for a very VERY long time. He had just not come public about it until it was almost done. In the very first post in which he mentions it over at dcemu.co.uk, he said he had it almost done, then it was still iirc 2 weeks before he released a full version. Not to knock it, it is an amazing core, but it didnt happen overnight.

Oh, also its C68k not c64k and the C in it stands for (i believe) C which is what it is programmed in.

weeperofsouls · Post by **weeperofsouls** » Sun Jul 11, 2004 4:43 am

ive noticed that the core was used in the neo cd emulator, as well as genesis plus. are there any other emulators it could possibly be adapted to, say dreamsnes, super famicast, nesterdc, smsplus, ect....

sorry, im a bit of a nosy bastard. lol.

doragasu · Post by **doragasu** » Sun Jul 11, 2004 4:57 am

I'd love to see Wowpacks with this core and the new Z80 core (when it is done).

uncleben · Post by **uncleben** » Sun Jul 11, 2004 7:37 am

not for dreamsnes, super famicast, nesterdc and smsplus because the systems do not use the 68000 processor

BlackAura · Post by **BlackAura** » Sun Jul 11, 2004 8:35 am

It can only work in systems that use a Motorola 68000 CPU. The 68K was used in a lot of late '80s to early '90s arcade games, the Mega Drive, NeoGeo, and it was used as an auxilary CPU in the Saturn and Jaguar. That's about it for games systems though. It was used on a number of computers, like the original Apple Macintoshes, the early Amigas, the Atari ST, most of the early Unix workstations (notably from Sun and NeXT), and a lot of embedded systems. It (or, more accurately, a decendant of it) is still used today for some things, in fact.

Of course, most of those aren't very interesting or useful to emulate on a Dreamcast. Of those that are of interest, we have the Amiga, Atari ST, Apple Mac, and some arcade games. The arcade games are the most interesting, and if anyone can get C68K running in MAME, we might be able to get a few more games running well which were just outside of our reach before.

The only portable Amiga emulator (UAE) won't work with C68K - it uses it's own CPU emulator which is very, very different from C68K (which was based around Musashi's interface, and designed along the same general principles) because of the Amiga's design. It would take years to write one from scratch, and it wouldn't be anywhere near as compatable as UAE. And it'd still be slow.

I don't know much about Atari or Mac emulators. I do know that the Atari ST was a simpler machine than an Amiga, and a Mac was a simpler machine than an Atari ST, so they might be possible.

az_bont · Post by **az_bont** » Sun Jul 11, 2004 10:08 am

The GP32 has a very decent Atari ST emulator that's supposed to be practically perfect. Given that, would it be too impossible for a Dreamcast one? I've never used one before, but looking through it's library of games, it would satisfy a lot of Amiga fans due to the number of shared games - and whilst not as powerful as the Amiga, the quality of graphics is fairly close.

BlackAura · Post by **BlackAura** » Sun Jul 11, 2004 10:44 am

I did have a look for the GP32 one, but I couldn't find any source code. One really odd thing is that the GP32 seems to be (a bit) better at emulation than the Dreamcast is. I think it's CPU is just more suited to it than the SH-4. Then again, the CPU in the GP32 can't do 3D graphics calculations like the SH-4, so...

law · Post by **law** » Sun Jul 11, 2004 11:22 am

http://www.codejedi.com/castaway/binari ... 130src.zip

Castaway source version 1.30

abydos1000 · Post by **abydos1000** » Sun Jul 11, 2004 7:39 pm

For a Mac emulator, I guess one could start with the vMac source code. It should doable... perhaps use the VMU as a floppy disc. It wouldn't be worth much though other than "see what is running on my Dreamcast" kind of thing.

mogorman · Post by **mogorman** » Sun Jul 11, 2004 8:34 pm

yes but it would be so awesome.
happy mac on dc would make the world a better place. trust me...