How hard would be to code a NES/SMS emulator

Ask anything your want about Mega/SegaCD programming.

Moderator: Mask of Destiny

Mask of Destiny
Very interested
Posts: 562
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Feb 14, 2007 3:06 pm

Fonzie wrote:I think that 512 (or 512-emulator) KB is quite good...
I wonder if its possible to use the segacd communication table to fake the I/O (vdp ports of the nes).
That's the way I did it when I was working on that SMS emulator.
I mean, if the maincpu runs at fullspeed on pooling the I/O, it may be no lag.
Well it will introduce some delay, but it means the main CPU can do the heavy lifting of the video emulation (which isn't that heavy in the case of the SMS, but you get the idea).
The flip/flap 128KB ram can be used to store some additional stuff on subcpu
and the emulator on maincpu...
I would push the full 256KB to the SUB CPU for SMS and split it or give it all to the main CPU if there is a CHAR ROM that won't fit in Genesis RAM. The video emulation doesn't need to be very big since the Genesis VDP is still going to do a lot of the work for us.
:D Btw, It seems I awaken some of yours old deamons, MOD ;P
What can I say? I can't resist an interesting problem.
Also, why emulating the nops? Just skipping them woundn't damage the code, isn't it?
In the case of our simple interpretter it would be slower to check for nops than to just "emulate" them. I was using nops for my timing examples because it made things simple and provided a sort of "best case" for instructions that take 2 cycles on the 6502 or 4 on the Z80. In a dynarec you'd probably skip them.
But the problem is the recompiler code itself... it's a complex stuff to do, i don't know if the recompiler code plus compiled code can fit in sega available ram :-/
If you stick with a simple dynarec that doesn't have an interpretter fallback, it would probably fit okay. Given the relatively high number of registers in the 68K versus the 8-bit procs (especially the 6502) you could use a relatively simple register mapping scheme. You could probably do a simple lookup table for many instructions with some lookahead to recognize instruction combinations that can be executed more efficiently on the 68K (i.e. 4 or more bit shifts in a row will be faster as a single 68k shift instruction). Branches are complicated of course

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Wed Feb 14, 2007 6:36 pm

The scary thing is that NES is bankswitched... and some nes games have special hardware built in... The bankswitching would be very hard to emulate with dynamic recompilation, wouldn't be?

Mask of Destiny
Very interested
Posts: 562
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Feb 14, 2007 7:40 pm

Fonzie wrote:The scary thing is that NES is bankswitched... and some nes games have special hardware built in... The bankswitching would be very hard to emulate with dynamic recompilation, wouldn't be?
So is the SMS.

It certainly brings a few complications, but I think the general task of writing a dynarec is more complicated than dealing with the bankswitching.

MERLiX
Newbie
Posts: 8
Joined: Mon Jan 15, 2007 10:45 pm

Post by MERLiX » Thu Feb 15, 2007 12:52 am

Checkout this guide.
http://www.6502.org/tutorials/6502opcodes.html

It outlines the opcodes and is quite informative with regards to possible gotchas when coding a cpu emu. Zero page being the obvious one.

I would think the emu would want to have both an interpreted mode as well as a dynamic mode, the interpreted mode keeps track of which sections of code have been executed and how many times, say like a block of code was executed more then 32 times, then that code is converted into dynamic block, with an unused opcode to then launch the correct dynamic code.

The major issue between 6502 and 68k code is the length of opcodes 6502 is fairly minimalistic in size, but 68k unfortunately is rather large, so the code transition would be more then doubled (most likely even tripled) in size. But if we are deal with specific code blocks then we should be able to handle this, say keeping the original rom(with the opcode modification) in the lower 1mb area (also useful when having to remap to another piece for the charset bank for VDP main cpu) and the upper area for dynamic code.

I would think the first challenge would be implementing the 6502 interpreted cpu, vdp and basic joystick, then use a small/basic rom like mario or bomberman to get a basic emu up, then add some more basic mappers, (save states?) whilst improving the cpu and then start adding dynamic code as needed.

Be interesting to know what games would tax the cpu or that relied on features like interrupt.

ob1
Very interested
Posts: 407
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Sat Mar 31, 2007 7:58 pm

Stef wrote:Even Z80 is here, but we can't use it for that...
Why can't we ?

User avatar
Stef
Very interested
Posts: 2722
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sat Mar 31, 2007 8:56 pm

ob1 wrote:
Stef wrote:Even Z80 is here, but we can't use it for that...
Why can't we ?
Memory mapping. On genesis the Z80 doesn't have the same memory map as on SMS, no direct rom access...can't directly access rom nor controller...

ob1
Very interested
Posts: 407
Joined: Wed Dec 06, 2006 9:01 am
Location: Aix-en-Provence, France

Post by ob1 » Sun Apr 01, 2007 7:43 am

I thought the 68k could grab the Z80 actions and remap them :
"oh, you want to write something in your RAM ? Let me dot it, I'm going to put these data in the actual RAM"
or "oh, you want some ROM data ? Let me seek them for you ... here they are.
Unfortunately, I see it is totally impossible.
What a pity !!!

User avatar
8bitwizard
Very interested
Posts: 155
Joined: Sat Feb 24, 2007 11:35 pm
Location: Austin, TX

Post by 8bitwizard » Wed Apr 04, 2007 3:56 pm

The problem is that CPU emulation is easy, but emulating the attached hardware is hard. The Atari 2600 was barely doable on a 486-25. And that's with a real memory-mapped bitmapped graphics display. The Genesis has a separate graphics bus and tile-mapped graphics.

The only reason you can run SMS games on it is because the hardware was designed to change into what the SMS wanted, and the VDP specifically had support for the SMS graphics mode.

Theoretically it might be possible to come up with some program on a PC which tries to emulate the desired system and translate stuff, producing a 68000 binary as a result, but there's really no point when 10-old PCs are fast enough to run an emulator.

User avatar
FrozenDelight
Interested
Posts: 45
Joined: Tue Aug 14, 2007 12:51 am

Post by FrozenDelight » Thu Aug 16, 2007 10:56 pm

You guys are such super hardcore coders! It's great!

Where would you recommend a mega programming newbie should start? Like really really right at the beginning.

Don't worry, I won't ask any more questions about it after this one. I know this subject can be annoying.

User avatar
8bitwizard
Very interested
Posts: 155
Joined: Sat Feb 24, 2007 11:35 pm
Location: Austin, TX

Post by 8bitwizard » Sat Aug 18, 2007 2:38 pm

Stef wrote:
ob1 wrote:
Stef wrote:Even Z80 is here, but we can't use it for that...
Why can't we ?
Memory mapping. On genesis the Z80 doesn't have the same memory map as on SMS, no direct rom access...can't directly access rom nor controller...
Actually it does... if you don't have a Genesis 3, and ground one pin on the cartridge slot.

It's not too hard to make an adapter board (the PBC was so complicated because it supported the cards too), and I have a design for one that I really should send in to get manufactured.

The only problem is, you can't do this and use the CD drive too. And it won't play any of the few games (like F-16 Fighting Falcon, which is a card anyhow) that use the TMS9918A video modes.
Last edited by 8bitwizard on Sun Aug 19, 2007 8:23 pm, edited 1 time in total.

Chilly Willy
Very interested
Posts: 2551
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Aug 18, 2007 8:21 pm

Thinking back to when my brother and I did an Apple ][ and an Atari 400/800 emulator for the Amiga, we could get close to full speed on a 14 MHz 020 on some things with dynamic recompilation. It depended on how complex the graphics were as the same CPU had to do that as well. If you want to look at some OLD dynarec (6502 to 68020), you can get the source from my old home page here: http://www.geocities.com/jlfenton65/computer.html

Just rename the files from .lha.bin to .lha. Stupid GeoCities wouldn't accept .lha, so I added .bin to the end to get them on the site.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Tue Sep 11, 2007 9:35 pm

Hmm - if the SUB cpu emulating the 6502 core and the main CPU emulating the I/O ports, that might just work. Also, don't forget that each 6502 machine cycle = 1 clock cycle, so even though it's 1.79mhz quite a few instructions are 2-3 times faster than the Z80. A 12.5mhz 68k should be able the CPU emulation as well as the bank switch emulation.

Try out something small like Dragon Warrior (less than 64k code space). Since the game uses VROM, just upload the VROM banks to the MAIN CPU memory and have it emulate switching VROM banks.

As for emulating bank switching, just reserve a register as an offset (most early games only use 1 addressable area of memory for bank switching) as the offset into the absolute address of the rom, adding it to that specific address area. When a bank switch is initiated, just recalculate the offset.

As far as emulating the sound channels, I would use the PCM channels to emulate the two square duty cycles and triangle pattern as samples. This is what I did on the PC Engine to emulate the NES sound arch. Maybe the z80 could emulate the noise channel.

commodorejohn
Very interested
Posts: 70
Joined: Tue Mar 06, 2007 6:30 pm

Post by commodorejohn » Thu Sep 13, 2007 3:08 pm

I don't think you could use the square-wave channels to do the NES's pulse channels for two reasons: one, the NES has adjustable pulse width where the Genesis's chip does not, and two, the Genesis's chip, in the grand Yamaha tradition, uses logarithmic volume levels where everybody else, NES included, uses gradiated volume levels.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Thu Sep 13, 2007 3:44 pm

commodorejohn wrote:I don't think you could use the square-wave channels to do the NES's pulse channels for two reasons: one, the NES has adjustable pulse width where the Genesis's chip does not, and two, the Genesis's chip, in the grand Yamaha tradition, uses logarithmic volume levels where everybody else, NES included, uses gradiated volume levels.
A bit of offtopic. 'Square-wave channels' in SMD produced not by Yamaha's chip but by Texas Instruments chip (SN76489). And about log/linear volume levels - Yamaha did copy log volume levels in case with YM2149F from General Instruments AY-3-8910. So it's not Yamaha's own grand tradition.

Chilly Willy
Very interested
Posts: 2551
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Sep 13, 2007 5:54 pm

Log volume is used because that's the way the ear works. Most biological systems are logarithmic in response to stimuli. So log volume sounds linear, where linear volume does not.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest