Page 3 of 25 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 245

Thread: Nes

  1. #21
    Moderator aprentice's Avatar
    Join Date
    Nov 2001
    Posts
    1,337
    Mentioned
    0 Post(s)
    Quote Originally Posted by hap
    aprentice: will you ever continue with your NES emu ?



    these are the basics for when to hit vblank.

    dummy scanline (341 ppu cycles)
    240 visible scanlines (341*240 ppu cycles)
    dummy scanline (256 ppu cycles, so no hblank here), then hit vblank, and let the cpu run out of cycles before starting a new frame

    1 cpu cycle=3 ppu cycles
    cpu cycles start at ~1789773/60, so vblank hits at cycle (1789773/60)-((256+341+(240*341))/3)=~2350
    what specifies hblank and vblank and what does dummy scanlines mean?
    are you also saying scanline 240 is 85 cpu cycles?

  2. #22
    EmuTalk Member hap's Avatar
    Join Date
    Jan 2005
    Posts
    188
    Mentioned
    0 Post(s)
    I was away for a few days, so I didn't see your PM until now. I'll have a look at it later and if you're OK with it, I'll give info/hints in this thread instead of PM world.

    hblank: nothing specifies it.
    vblank: most significant bit of ppu status register is set.
    As for the dummy scanlines, i think the first one is there so the PPU can put the first few tilelines into the pipeline, and prefetch the sprites for the next scanline. Last scanline (242, not 240) I'm unsure about why it's there, but the docs say so, and I'm also unsure whether to hit vblank at cc 113 or cc 85, but 85 gives better results here.

    *edit* oh, and don't let this timing thing scare you about black screens and non-booting games. i've had plenty of bugs fixed in my timing, and games were already up and running way before that
    Last edited by hap; March 3rd, 2005 at 03:39.

  3. #23
    Moderator aprentice's Avatar
    Join Date
    Nov 2001
    Posts
    1,337
    Mentioned
    0 Post(s)
    Quote Originally Posted by hap
    I was away for a few days, so I didn't see your PM until now. I'll have a look at it later and if you're OK with it, I'll give info/hints in this thread instead of PM world.

    hblank: nothing specifies it.
    vblank: most significant bit of ppu status register is set.
    As for the dummy scanlines, i think the first one is there so the PPU can put the first few tilelines into the pipeline, and prefetch the sprites for the next scanline. Last scanline (242, not 240) I'm unsure about why it's there, but the docs say so, and I'm also unsure whether to hit vblank at cc 113 or cc 85, but 85 gives better results here.
    its fine with me.
    Btw, which is the dummy scanline, 242, or 0?

  4. #24
    EmuTalk Member hap's Avatar
    Join Date
    Jan 2005
    Posts
    188
    Mentioned
    0 Post(s)
    not 0, but 1. or 0 and 241 ;p

    But anyway, i'd say they're both dummies, since no graphics are drawn onto the screen at these 2 scanlines. but if you want the dummiest one, it's 242, cause the ppu seems to be doing nothing useful at all there.

  5. #25
    EmuTalk Member hap's Avatar
    Join Date
    Jan 2005
    Posts
    188
    Mentioned
    0 Post(s)
    your cpu core:
    zero page, zp x, zp y: why pc+1 ? a typo i hope ?
    abs x, ind x, ind y: be sure to burn an extra cycle on page overflow
    stack: stackpointer is 1 byte, not 2, stack however is at 0x100-0x1ff
    adc: overflow is about twos complement, so it will be set when the result is lower than -128, or higher than 127
    other flag manipulators: reset the affected flags first before setting them, eg. result of asl is not 0, and the zero flag was set before asl was called, the zero flag should be 0 (now that i've looked further, it only seems to be bugged at asl)
    jsr: push pc-- on stack, not pc++

  6. #26
    Moderator aprentice's Avatar
    Join Date
    Nov 2001
    Posts
    1,337
    Mentioned
    0 Post(s)
    Quote Originally Posted by hap
    your cpu core:
    zero page, zp x, zp y: why pc+1 ? a typo i hope ?
    abs x, ind x, ind y: be sure to burn an extra cycle on page overflow
    stack: stackpointer is 1 byte, not 2, stack however is at 0x100-0x1ff
    Fixed a bunch of the addressing modes and a couple opcodes, stupid mistakes, thats what happens when you write the whole cpu core in an hour

    adc: overflow is about twos complement, so it will be set when the result is lower than -128, or higher than 127
    another stupid mistake

    other flag manipulators: reset the affected flags first before setting them, eg. result of asl is not 0, and the zero flag was set before asl was called, the zero flag should be 0 (now that i've looked further, it only seems to be bugged at asl)
    you kinda lost me here

    jsr: push pc-- on stack, not pc++
    i thought it was push pc+2 to stack?

  7. #27
    EmuTalk Member hap's Avatar
    Join Date
    Jan 2005
    Posts
    188
    Mentioned
    0 Post(s)
    you kinda lost me here
    at asl you do:
    if result=0, status=status|2
    while it should be:
    if result=0, status=status|2, else status=status&~2


    i thought it was push pc+2 to stack?
    hmm, only if you're not executing that opcode like any other, in my case i do:

    fetch opcode (jsr)
    pc++

    do addressingmode:
    it's abs, so pc++, and pc++ again

    execute opcode (jsr):
    pc--
    push pc
    pc=addressbus

  8. #28
    EmuTalk Member hap's Avatar
    Join Date
    Jan 2005
    Posts
    188
    Mentioned
    0 Post(s)
    and you've got stackpointer incrementing/decrementing wrong:

    your version is reversed:
    pull: read, sp--
    push: sp++, write

    correct:
    pull: sp--, read
    push: write, sp++

  9. #29
    Moderator aprentice's Avatar
    Join Date
    Nov 2001
    Posts
    1,337
    Mentioned
    0 Post(s)
    Quote Originally Posted by hap
    and you've got stackpointer incrementing/decrementing wrong:

    your version is reversed:
    pull: read, sp--
    push: sp++, write

    correct:
    pull: sp--, read
    push: write, sp++
    eh, are you sure about that? I have it that way in my gameboy emu and it works perfectly fine, i dont understand why we decrement before we pull if its last on first off.

  10. #30
    Moderator aprentice's Avatar
    Join Date
    Nov 2001
    Posts
    1,337
    Mentioned
    0 Post(s)
    Quote Originally Posted by hap
    and you've got stackpointer incrementing/decrementing wrong:

    your version is reversed:
    pull: read, sp--
    push: sp++, write

    correct:
    pull: sp--, read
    push: write, sp++
    i've copied and pasted that routine from my gameboy emu, guess its backwards on the nes

    is this correct?

    #define PUSH8(x) mem_write8(0x100+reg.sp,x); reg.sp++
    #define PUSH16(x) mem_write16(0x100+reg.sp,x); reg.sp+=2

    #define POP8() mem_read8(0x100+reg.sp-1); reg.sp--
    #define POP16() mem_read16(0x100+reg.sp-2); reg.sp-=2
    Last edited by aprentice; March 4th, 2005 at 02:58.

Page 3 of 25 FirstFirst 1234513 ... LastLast

Similar Threads

  1. How to make a Usb Nes controller.
    By Fender432 in forum Jnes
    Replies: 3
    Last Post: November 10th, 2004, 14:30
  2. Get 700+ games for nes
    By GlM in forum Jnes
    Replies: 5
    Last Post: July 23rd, 2004, 01:24
  3. Palm OS5 NES emulator?
    By jgyurkovitz in forum Jnes
    Replies: 0
    Last Post: January 5th, 2003, 08:53
  4. NES Emulation
    By mexican(Aus) in forum NES Emulation
    Replies: 4
    Last Post: September 8th, 2002, 02:25
  5. NES Gun Games
    By Tekken in forum NesterDC
    Replies: 0
    Last Post: January 1st, 2002, 18:26

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •