MD emulator on MCD, possible?

[Psy]

Would it be theoretically possible to have a Genesis/Mega Drive emulator on the SegaCD/MegaCD? Or would there be too many issues?

[Genesis Knight]

I think we've talked about this before and the answer is no. Evildragon will enter the thread shortly, I'm sure.

[Psy]

I think we've talked about this before and the answer is no. Evildragon will enter the thread shortly, I'm sure.
I recall talks of if it was possible to play roms, I'm talking full emulation where the entire SegaCD/Genesis unit is emulating a stock Genesis in a virtual machine.

[evildragon]

Not possible, plain and simple. This has been asked to death.

and no, there is not enough horse power, RAM to EMULATE.

[Psy]

Not possible, plain and simple. This has been asked to death.

and no, there is not enough horse power, RAM to EMULATE.
How about with the 32x attached?

[evildragon]

No, not possible.

It's like my Sega Mac hoax all over again. It just can't be done.

You're forgetting, that to emulate a Sega Genesis, you need about a 500MHz CPU, and even then, for reliable emulation of a Genesis on my laptop, 750MHz still skips.

[GohanX]

The simpler way of doing what you are trying to do is get a Megacart, burn a CD full of roms and have the Sega CD transfer the roms to the flash cart.

[Psy]

So what could the SegaCD emulate? SG-1000? Sega Master System?

[evildragon]

The only emulator ever developed on the Genesis, and was never really functional, was the Famicom.

[Psy]

The only emulator ever developed on the Genesis, and was never really functional, was the Famicom.
Technically the SegaCD in theory should be able to emulate something, even if it is just a PDP-1 running Space Wars. Just curious.

[evildragon]

Technically the SegaCD in theory should be able to emulate something, even if it is just a PDP-1 running Space Wars. Just curious.
You're changing the subject.

PS: I believe Space Wars used a vector screen, not a raster, like Asteroids. So, this also means more emulation power required, to emulate vectors on a raster screen, so once again, no.

[Psy]

You're changing the subject.

Slightly, still revolving around the SegaCD emulating something.



PS: I believe Space Wars used a vector screen, not a raster, like Asteroids. So, this also means more emulation power required, to emulate vectors on a raster screen, so once again, no.
So how about the Commodore P.E.T or is the SegaCD to weak to emulate that.

[Joe Redifer]

The Sega CD can't really act as the central CPU. There is a huge bottleneck between it and the Genesis, and the display hardware is all in the Genesis.

[evildragon]

It's not powerful enough dude.

Just drop it, it's not going to happen. Even if it could, no ones going to program it.

[Genesis Knight]

So Sega CD is just glorified storage?

[evildragon]

So Sega CD is just glorified storage?
And "co-processor", in it's own way. After all, it does have a good graphics ASIC, but it's only a single layer on the Genesis, and it's limited to the palette and resolution of the Genesis VDP.

[evildragon]

http://www.spritesmind.net/_GenDev/forum/viewtopic.php?t=81

[Psy]

http://www.spritesmind.net/_GenDev/forum/viewtopic.php?t=81
So the problem with the SegaCD feeding the Z-80, is without the system being in SMS mode the memory addresses will be wrong, which already would be wrong as the data would be in the SegaCDs cache and not on the cart but it would be a bigger problem as the Z-80 would be calling devices with the wrong address. Is that basically the problem with the SegaCD feeding SMS roms?

[KnightWarrior]

I'm the one who asked about the Playing Genesis/Mega Drive ROM's in the Sega CD

[Joe Redifer]

I'm still waiting for a Sega Master System emulator for the Sega Master System. That would rock!

[tomaitheous]

The only emulator ever developed on the Genesis, and was never really functional, was the Famicom.

Yeah, probably some tiny 16/32k code games with non swappable VROM banks.

[TmEE]

why would you need to emulate MD on MCD anyway ? MCD won't function without MD so... well, its pointless in all aspects. To run MD ROMs you need 32Mbits of (P)SRAM and one logic chip and a menu program on MCD side... no need for emulation of any kind, almost same applies to SMS, you need little more logic chips but the rest is same.

EDIT: quite some logic chipd are required...

[Joe Redifer]

Can the Genesis be made to emulate the 3DO?

[TmEE]

sure it can, I guess with some heavy ASM code, Saturn is possible too

[Zebbe]

I want to play Night Trap on my SNES !!!!111010101

[playgen]

It does work, honest!

http://homepage.ntlworld.com/paul.james21/DCP02928.jpg

You have to be careful when you play the game and the disk starts spinning, or you might lose some fingers.

[Zebbe]

But I thought Howard Lincoln went to all homes with SNESes and re-engineered them not to work with that game!

[lilmul123]

What is all this discussion about a mega drive EMULATOR? There is a physical mega drive connected TO the megaCD. Why can't something be programmed to simply take the data off the CD to the system itself?

And what is this talk about a famicom emulator? if that's true, it'd be really sweet.

[Genesis Knight]

Yuji Naka (Sonic programmer) did a NES emulator on the Genesis waaaay back in the day that ran Mario.

[lilmul123]

Man. I really want to see this emulator in action. That sounds like a hell of a feat.

[Genesis Knight]

I'm 100% positive that no data of it exists.

[evildragon]

What is all this discussion about a mega drive EMULATOR? There is a physical mega drive connected TO the megaCD. Why can't something be programmed to simply take the data off the CD to the system itself?

And what is this talk about a famicom emulator? if that's true, it'd be really sweet.
You can't say, load an MD game directly from the CD.. Memory mapping is drastically different.

[lilmul123]

I'm 100% positive that no data of it exists.

How do we know Mr. Naka wasn't lying then? I could just as easily say I made an Xbox 360 emulator for the Atari 2600, but people wouldn't believe me unless I showed SOME proof.

And yeah, that's what I was thinking. How about a cartridge that loads ROMs from a CD then and then maps them itself? Isn't there something called a utility cart in existence or something?

[evildragon]

How do we know Mr. Naka wasn't lying then? I could just as easily say I made an Xbox 360 emulator for the Atari 2600, but people wouldn't believe me unless I showed SOME proof.

And yeah, that's what I was thinking. How about a cartridge that loads ROMs from a CD then and then maps them itself? Isn't there something called a utility cart in existence or something?
Yea, it's called the MegaCart from Tototek.

[Joe Redifer]

How do we know Mr. Naka wasn't lying then? I could just as easily say I made an Xbox 360 emulator for the Atari 2600, but people wouldn't believe me unless I showed SOME proof.
I highly doubt Naka even cares if anyone believes him. He was probably just messing around, showing off his mad programming skillz to coworkers. Getting Super Mario Bros to run probably wouldn't be a big feat, and the sound probably wasn't perfect. Getting games with MMC chips to run would be much harder.

[Genesis Knight]

We believe him because he's too much of an obsessive perfectionist to lie. And because he has no reason to.

[lilmul123]

We believe him because he's too much of an obsessive perfectionist to lie. And because he has no reason to.

I just think...if it was possible for him to do it, why isn't it possible now? We have hackers now that know much more about electronics and computing than he did, yet no one has made a NES emulator...or really ANY homebrew for the genesis. This just perplexes me.

[Joe Redifer]

I dunno, Naka was quite the coder. I don't think anyone can really say that some hacker who reverse-engineered a Genesis knows more about the system and how to program optimized code for it than Naka did.

[Genesis Knight]

Has anyone tried? On the other hand, maybe it required some sort of dev hardware.

BTW, there's been tons of homebrew on Genesis.

[lilmul123]

Are there any homebrews I can burn onto a CD and play through the SegaCD? I'd like to check these out.

[evildragon]

Are there any homebrews I can burn onto a CD and play through the SegaCD? I'd like to check these out.
It would have to be a Sega CD homebrew..

[lilmul123]

Yeah, there are some examples I've found.

http://www.zophar.net/wwwthreads/showthreaded.php?Cat=&Board=general&Number=279584&page=9&view=collapsed&sb=5&o=0&part=

*burns*

edit: gah, the link is dead. sure wish I could find a working link.

[evildragon]

That crashes on real hardware, quite randomly.

[lilmul123]

You've tried it?

[evildragon]

Of course.. Wouldn't have said it crashes on real hardware without actually testing it.

Has to do with the Z80.

[Dirt Ball Gamer]

I dunno, Naka was quite the coder. I don't think anyone can really say that some hacker who reverse-engineered a Genesis knows more about the system and how to program optimized code for it than Naka did.

Agreed. I thought i read a long time ago he actually had to build some hardware attachment to make it play but perhaps that was false. That sonic 1-2 on cd looks interesting I had not heard of that. I wonder if it can be worked on further to make it more playable on real hardware.

[lilmul123]

I actually want to try that Sonic thing even though it may be broken. I can't get it though because that link is dead.

I found a torrent, but there's only one leecher, and zero seeders.

[Joe Redifer]

Fellow forum member Fonzie took a video I e-mailed him of myself and made it run on the Sega CD. It works on a real system as well, not just an emulator. Also let's not forget Pier Solar, the upcoming game. It can be classified as homebrew and will have Sega CD and cartridge versions. I am still at a loss over which one to get.

[108 Stars]

I just think...if it was possible for him to do it, why isn't it possible now? We have hackers now that know much more about electronics and computing than he did, yet no one has made a NES emulator...or really ANY homebrew for the genesis. This just perplexes me.

Well, Pier Solar is homebrew to it´s very core. All programming tools, engines etc and of course gfx and sound are coded 100% by homebrewers. Tiido has made the homebrew-mini-game Glass Breaker and is doing a run´n gun now...I´ve seen a homebrew of Yie Ar Kung Fu...Frog Feast is a homebrew too.
About NES-emulation...
It might be possible soon...;)
I do know that several people in the scene are working on it, since it is a very attractive thought...after all, Naka has got it working, so today´s homebrewers will most likely pull it off too.

[TmEE]

People know that a NES emu was made on MD, but nobody knows how well it ran... making a emu is not that difficult, but getting it working at playable speed is (if not impossible on MD, even though VDP does quite a lot of work for you). And there's plenty of homebrew for MD, not much games though... I have over 100 homebrew ROMs, which of 25% is mine :P

[playgen]

I really don't think the Megadrive is capable of nes emulation at anywhere near acceptable speed. Just try Nes emulation on other 68k machines to see, the 68000 isn't remotely upto it. Believeing that Naka had some secret knowledge that makes the 68000 perform like a 68060 is just wishful thinking, nes emulation simply requires a lot more processing power than the megadrive has, which will be why this emulator has never been seen.

[tomaitheous]

If he did make an NES emulator for the Genesis, it would have been extremely slow.

A couple of scenarios:

1)
He put 6502 processor on the cart and redirected memory mapped ports onto the MD cpu side. The cart would have to have a backend code rom for the genesis CPU. The card would run the 6502 and it's code from separate memory mapped to it, and the MD cpu would simulate the video and audio hardware I/O interface. This is pretty doubtful that he did this.

2)
He disassembled the rom and used a macro based assembler to convert the 65x code into native 68k code, simulated some stuff like ram, and completely changed the graphic routines/etc (Like the SNES FF ports on PSX). There is no automatic process to correct disassemble 65x code and requires lots of fixing and combing the output, so it would have be done prior to running the game. This isn't emulation. But this has also been done before for other consoles (illegally of course).

3)
He did write an emulator and overall it ran like 10% of the NES real speed.

4) He coded the game engine from scratch, but reused data from the original rom (i.e. gfx, maps, sound and music format).

[Joe Redifer]

The Genesis has Blast Processing™ so that is why it can run an NES emulator faster than any other 68K machines.

[Epicenter]

The only emulator ever developed on the Genesis, and was never really functional, was the Famicom.
If someone can find this, I'd like to try it on my MD at 27 MHz :) You might break the "10 FPS barrier".


Believeing that Naka had some secret knowledge that makes the 68000 perform like a 68060 is just wishful thinking, nes emulation simply requires a lot more processing power than the megadrive has, which will be why this emulator has never been seen.
Bah, from everything I've seen Yuji Naka is an egotistical asshole. The Ecco team's programmers (Mihaly Brudnyak and Jozsef Molnar) accomplished a lot more at a better speed. :)

[Genesis Knight]

The Ecco team's programmers (Mihaly Brudnyak and Jozsef Molnar) accomplished a lot more at a better speed.

That's an odd example. I mean, when I think of the most impressively coded games on the system I don't think Ecco. I think Contra Hard Corps, Gunstar Heroes, Ranger X, etcetera.

[lilmul123]

The Genesis has Blast Processing™ so that is why it can run an NES emulator faster than any other 68K machines.

OF COURSE.

Nevermind, we've found our answer.

[Iron Lizard]

I have heard that story before but has it ever come from his own mouth? Like all things could it have been an exaggeration. Maybe he just reprogrammed it and all we are hearing is some rumor that has been told over and over again. Tg16 has a pirate version of Smb that plays fine that obviously is reprogrammed for the system. I had a "Retro" guide I picked up in Sweden from the U.K. when I was there that mentioned that story in the Mega Drive section. I believe that guide was made by NextGeneration. Maybe we should get a hold of them. Something tells me they wouldn't know either. That does it. We need a Naka interview about it.

[Genesis Knight]

Isn't it in an interview?

[evildragon]

If he did make an NES emulator for the Genesis, it would have been extremely slow.

A couple of scenarios:

1)
He put 6502 processor on the cart and redirected memory mapped ports onto the MD cpu side. The cart would have to have a backend code rom for the genesis CPU. The card would run the 6502 and it's code from separate memory mapped to it, and the MD cpu would simulate the video and audio hardware I/O interface. This is pretty doubtful that he did this.

2)
He disassembled the rom and used a macro based assembler to convert the 65x code into native 68k code, simulated some stuff like ram, and completely changed the graphic routines/etc (Like the SNES FF ports on PSX). There is no automatic process to correct disassemble 65x code and requires lots of fixing and combing the output, so it would have be done prior to running the game. This isn't emulation. But this has also been done before for other consoles (illegally of course).

3)
He did write an emulator and overall it ran like 10% of the NES real speed.

4) He coded the game engine from scratch, but reused data from the original rom (i.e. gfx, maps, sound and music format).
1, 2, and 4 wouldn't be an emulator then...

[lilmul123]

Idk...I call BS. The Genesis uses a ~7 Mhz 68000 and the NES uses a ~1.7 Mhz 6502 if my memory serves me correctly. If Naka was able to pull this off, then all it would be capable of showing still pictures of gameplay. The 68000 is just not fast enough to emulate a processor that is only a third slower than its own...then you have to figure in how much overhead there is to turn 6502 opcodes into 68000 opcodes in real-time. It just seems unfeasible; regardless of whether he was an incredible programmer or not, it would be damn near impossible to do.

Yeah...an interview would be the way to go.

[Genesis Knight]

What I meant was that he already said he did in an interview; that's where the 'rumor' comes from.

[tomaitheous]

1, 2, and 4 wouldn't be an emulator then...

Exactly my point ;)

[Iron Lizard]

Apparently its on the august 1999 Gameweek. All I can find are bits and pieces of it. I found this later interview where they ask him about it.

http://www.the-nextlevel.com/features/interviews/yuji-naka/

[Genesis Knight]

Yeah, that was the one I was referring to.


TNL: Rumors have it that you even programmed a Famicom emulator for the Megadrive at one point in time, for your personal amusement. Is this true?

Naka: Oh my. [laughs] How do you people know about that one? Well yeah, actually I did. I did it primarily for study purposes. It ran things like Dr. Mario, although it did not work perfectly, actually. It was something fun to amuse myself with at the time.

[Epicenter]

That's an odd example. I mean, when I think of the most impressively coded games on the system I don't think Ecco. I think Contra Hard Corps, Gunstar Heroes, Ranger X, etcetera.
Those are all good examples and proof it isn't uncommon to be a better programmer than Yuji Naka... he has a lot of undeserved fame that's given him a huge ego, to the point he threatened to quit again and again if Sega wouldn't meet his whiny demands, refusing to let his NiGHTS engine be used for Sonic Xtreme (had he allowed it, it probably never would have been canned. I thought the game looked awful either way, but I digress.)

I mentioned Ecco's engine since I'm intimately familiar with it. The 2nd game (Tides of Time) performs some extremely stressful algorithms while still achieving the blindingly fast scroll speed (actually, faster) than Sonic games managed. And usually with less slowdown than Sonic. Consider that this engine was mostly C, and Sonic was ASM!

[Joe Redifer]

Sonic only slowed down when a shitload of rings are all over the place. I rarely see many sprites at all in any Ecco game.

[Epicenter]

If you don't call any of those graphics you see on the screen "Sprites". :P Other times Sonic slows down: Collapsing hillsides in Green Hill Zone, especially if there are 2 of them. Lava pillars launching up in Marble Zone. Sonic 2: Pretty much all the time in 2P mode, it never really achieves 60 FPS. (At least not on an NTSC machine. Not tried it on a PAL one.) Some light slowdown during the explosions at the end of Death Egg zone. A little during the last boss, too, but it's fairly uncommon. There's not much slowdown, but the Sonic games aren't really doing anything too impressive with the MD hardware (except the audio parts. They make terrific use of it.)

The more interesting things in Ecco that required a lot of CPU processing for each tile (like rings) would be the multisegmented enemies or other objects like the Asterite, which filled the entire screen. Or rather 3 times the screen's height. :) Or those neat fluidly moving vortex eels. Or the 'wiggling' sides of the water tubes in Sky Tides/Aqua Tubeway, etc.

[tomaitheous]

I mentioned Ecco's engine since I'm intimately familiar with it. The 2nd game (Tides of Time) performs some extremely stressful algorithms while still achieving the blindingly fast scroll speed (actually, faster) than Sonic games managed. And usually with less slowdown than Sonic. Consider that this engine was mostly C, and Sonic was ASM!

Ohh? Is it obvious from from stepping through the code or was that printed somewhere (magazine,etc)? The 68k was definitely a HL language friendly processor in its day and after.

[Epicenter]

Ohh? Is it obvious from from stepping through the code or was that printed somewhere (magazine,etc)? The 68k was definitely a HL language friendly processor in its day and after.

I interviewed Mihaly Brudnyak about a year ago, you can read some excerpts from what he said here:
http://ecco-darksea.com/int_brudnyak.php

The 68K was very C-friendly, yes. I consider it an accomplishment when a game coded in C, however, matches or outperforms the performance of software coded entirely in ASM. Take a look at Sonic Spinball-- it was written in C and it positively crawls compared to any other Sonic game on the system.

[evildragon]

I don't see any slow down with laval pillars in sonic, and barely with collapsing hillside..

I could even record it into my DVD recorder if I had to, to prove it..

[tomaitheous]

The 68K was very C-friendly, yes. I consider it an accomplishment when a game coded in C, however, matches or outperforms the performance of software coded entirely in ASM. Take a look at Sonic Spinball-- it was written in C and it positively crawls compared to any other Sonic game on the system.

Yeah, but the gap is much closer on the 68k between a C compiler and your average non optimized assembly code(which is fairly common). Still, that's pretty cool though.

Also, he mentions vblank as 1/30 of a second. Is that a mistype or is he refer to interlaced mode? Nice site by the way.

[Joe Redifer]

If you don't call any of those graphics you see on the screen "Sprites"..
I said "many" not "any". And all of the things you mentioned which slow Sonic down are composed of many independent sprites moving at different speeds (and often directions) than the others. The rings have collision detection which makes them much slower than they would be otherwise. No Ecco game really puts much on the screen at any one time, especially things with collision detection programmed into them. Please post screenshots to prove me wrong.