Next console to emulate?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Next console to emulate?

Post by ehguacho » Fri Jul 01, 2011 9:06 pm

Hi everyone! Now I have a stable NES emulator, I want to move to another project a little more complex. I think Game Boy and Super NES are both good options, but I need some advices in choosing one to them. A good point to be considered is the amount and quality of the enabled technical documentation. On the other hand, i don't know wich of them is more complex. Wich console do you recommend and why?

Cheers and thank you all in advance!
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru » Sat Jul 02, 2011 2:23 am

I'd say it is quite obvious that SNES is more complex than GB.

mic_
Posts: 920
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Sat Jul 02, 2011 4:24 am

I would say the GB is even easier to write an emulator for than the NES. The GBC adds a bit of extra complexity, but it's still not a huge project.

You could try writing a GBA emulator. That's a fairly large project, but still entirely feasible for one person. And there's very good documentation available for it.

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Next console to emulate?

Post by Zepper » Sat Jul 02, 2011 7:32 am

ehguacho wrote:Hi everyone! Now I have a stable NES emulator, I want to move to another project a little more complex.
Do you plan to release it into public domain?

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Re: Next console to emulate?

Post by ehguacho » Sat Jul 02, 2011 9:12 am

Zepper wrote:
ehguacho wrote:Hi everyone! Now I have a stable NES emulator, I want to move to another project a little more complex.
Do you plan to release it into public domain?
No, I just do it as a hobby :)

thank you all for your responses!
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Sat Jul 02, 2011 8:42 pm

I wrote a GB emulator after my NES emulator. You should definitely try that and probably look into GBC support too. SNES is far more complex as the CPU certainly takes more effort than GB or NES and the PPU is extremely complex. Atleast it can be if you fully emulate it. Also the SPC audio chip might be a challenge as well, I'm not sure though.

If I were to just guess I'd say this would be easiest to hardest.
NES, GB/GBC, Genesis (ignoring add-ons), SNES.

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Post by ehguacho » Sun Jul 03, 2011 12:38 am

I'm on GB emulation now, and I can say that the jump from NES to GB is quite big. Anyway, I'm in the same condition that when started to develop my NES emulator, so I know it's all about time and effort :)

Some day I'll care about SNES (hopefully!).
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris » Tue Jul 05, 2011 9:28 am

mic_ wrote:I would say the GB is even easier to write an emulator for than the NES. The GBC adds a bit of extra complexity, but it's still not a huge project.

You could try writing a GBA emulator. That's a fairly large project, but still entirely feasible for one person. And there's very good documentation available for it.

Do not underestimate the GB like I did. Its VDP (PPU, whichever you wish to call it) is extremely complex in its behaviour vs. the NES, which is much more rigidly timed.


The GB video is extremely complex if you wish to accurately cycle time it. The VDP stalls writing pixels to the display while it fetches sprites as they are needed, and it will stop clocking the display sometimes while it continues to shift pixels out (for fine X scrolling). The way the sprites, scroll, and window interact are extremely complex and I am still unraveling the mysteries of how this works.

The number of cycles it takes to render a single scanline to the LCD can take as few as 173 cycles to possibly over 300 cycles, depending on window position, xscroll, and the number and position of sprites.
/* this is a comment */

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Tue Jul 05, 2011 9:58 am

While that's true, I don't think his goal is to emulate the system with 100% accuracy, but enough for fairly high game compatibility/playability.

User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris » Wed Jul 06, 2011 9:11 am

MottZilla wrote:While that's true, I don't think his goal is to emulate the system with 100% accuracy, but enough for fairly high game compatibility/playability.
I had a question about how necessary it is to emulate the GB to that level of accuracy... how many games rely on close LCD timing to function properly? Are there only a few games that use it, or do many games need careful timing to function? The obvious case I know of is Prehistorik Man which has a pretty insane title screen (but amusingly, pretty bland and boring in-game compared).

Speaking of, does anyone know how that game performs that black bouncing text on the title screen? I have not been able to figure it out, even using the debugger on an emulator.
/* this is a comment */

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Wed Jul 06, 2011 10:18 am

I think very few games need that accurate of timing. I think unlike NES fewer if any games use timed loops and instead rely on interrupts. But I'm not 100% on that. I'm sure there are some examples of edge cases but I would think the vast majority of commercial software would not be that sensitive to it.

tepples
Posts: 21837
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Jul 06, 2011 10:23 am

kevtris wrote:Speaking of, does anyone know how that game performs that black bouncing text on the title screen? I have not been able to figure it out, even using the debugger on an emulator.
Might it be related to the so-called "Demotronic trick"?

User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris » Thu Jul 07, 2011 10:17 am

tepples wrote:
kevtris wrote:Speaking of, does anyone know how that game performs that black bouncing text on the title screen? I have not been able to figure it out, even using the debugger on an emulator.
Might it be related to the so-called "Demotronic trick"?
Yeah that is possible... I was thinking they might've been writing to the LCD in real time, but it'd be pretty tricky to do. There's a few things about it that bug me though.

The resolution appears to be 8 pixels across (i.e. 1 character) and seems to have some modicum of fine scroll in either direction. This would require them writing a new value to the LCD control register(s) every 8 pixels, which is every 2 instructions. Possible I guess, if a load (LD A,value) and store (LD lcdreg,A) takes 4 cycles each. (or LD A,B and LD A,C for the "on" and "off" values).

I *did* find this....

http://www.mobygames.com/developer/shee ... Id,207764/

which has the following:

"Prehistorik Man identified sprites likely to cause incorrect graphics and replaced them with software sprites copied into the video ram. "

"It also ported an Amstrad CPC trick to draw big scrolling messages."

I have not been able to find any information on this "cpc trick" that he's talking about.

I watched that demotronic demo, and their trick appears to be writing to Yscroll during rendering, which is combinatorial. This causes stretching and other Y effects, which is what their demo appears to be showcasing.
It seems they get character granularity which is possible, if it's running on a GBC because there will be 16 CPU cycles per character, which should be plenty to update yscroll each character cell.


On checking CPU cycle timings for the possible Prehistorik tricks, it looks like there IS a way to do this. You can write to the LCD control register 2 different values using LD (hl),n. This instruction takes 8 cycles. They appear to play with the palette register. So, to write the scrolling message they could simply do something like this:

ld b,normalpalette ;this is the normal background palette
ld c,0ffh ;solid black palette
ld hl,0ff47h ;palette register

ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette

This code will theoretically draw alternating black bands on the LCD. This is also how the demotronic probably works, but I suspect they do something like this:

ld hl,scrollvalues ;place where Y scroll values are stored
ld de,yscroll ;LCD Y scroll register

ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
... repeated 20 times total

That will take 16 cycles per character, but on the GBC that's exactly how many cycles there are when the CPU is in 2x speed mode.

One other thing- for P.Man's fine scrolling on the large text, this is fairly easy to do using sprites. Since the sprite delays the rendering 6-11 cycles, it's possible to use them to fine tune the position on the screen where the palette changes occur. This would be required to compensate for the background scroll (which "eats" up to 7 cycles in and of itself). 2 sprites can be used then to fix the position where the palette changes occur, because a single sprite can only do 6 pixels' worth of change.

So, that's how I am guessing both tricks are done. I don't know all the ins and outs of GB yet so this is all just supposition. comments?
/* this is a comment */

Post Reply