Developers wanted for PCSX Revival!

Discussion in 'PCSX Discussion' started by Squall-Leonhart, Dec 31, 2008.

  1. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thanks! Not the result I wanted but I'll take it.

    To keep some sanity, I'll leave DSound as it is for compatibility reasons (dfsound is correct already). ;)
  2. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Update on Silhouette Mirage Serah problem:
    - Tried Xebra. Zaps the speech channel dead (no buzz) - I'm thinking this might be how the original game did it
    (there's another boss fight that did this also I think but I die a lot in this game which cures the problem)


    Thanks to edgbla, flags > 7 is ruled out.
    - I'll make sure to provide a padded EXE next time


    New finding
    - BitMaster says there's predictor #s 0-4
    - This 'damaged' block uses #7 (...) and loops forever
    (code has a table for 0-4, and assumes 5-15 never happen)

    Problem is we have to come up with programs to cleanly test possibilities of what these 'dummy' modes could mean. May take time but we're finally getting somewhere!


    Also working on hacking-combining a printgpu example to print out test results to the TV, to bypass any memcard heckling.

    There's actually quite a bit of hw functionality we need to test - feels its best to combine many of them into 1 console run.
    - if reverb on, does data wrap to $1000 or $1010 when reverb work area hit?
    - if reverb on, can we write data to the reverb work area?
    - if we go past $80000 (reverb off), wrap to $1000 or $1010
    - if we start at $1000, does it go to $1010?
    - if we start at < $1000, does it go to $1000 or $1010?
    - can the loop address be read in real-time? Eternal doesn't seem to do this.
    - does the start address change in real-time?
    - dma r/w trigger IRQs?
    - (..)
    - if voice playing goes past (reverb, voice end), where does it go? does it stop?

    And if we can find a working joypad example, we'll think of trying to make a program that reads out the 46,47,4c constants from all everyone's peripherals.
    - These devices keep disappearing so we need to grab that data!
  3. notaz

    notaz New Member

    Messages:
    10
    Likes Received:
    0
    Just posting to confirm, sounds more or less like Xebra/pSX.

    FYI I now have enough gear for printf redirection to PC, so you can use that (but lose edgbla's test results I guess. as he probably runs CDRs).
  4. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thank you to both - much appreciated!


    @notaz
    Great to see you taking a bigger role now. :)

    I'm sure we can find a use for the printf - printing text to the screen is more bothersome than I thought. :D

    =======================================
    =======================================
    =======================================

    VAG predictors - 5+


    Priority: medium


    Background:
    Silhouette Mirage - Serah boss

    Tosses two electricity fireballs. Shyna gets hit by the opposite
    color. Xebra zaps the speech channel dead (no static from it)

    Damaged block uses predictor #7.



    Program:
    Modified rootexample + printgpu by doomed/padua

    Block looping for each predictor # (0-15).



    Results:
    - Hardware = same beep (0, 5-15)
    (testers = notaz)

    - Xebra = same beep (0, 5-15)
    - DSound 1.09a (recent) = same beep (0, 5-15)

    - ePSXe spu 170 = blank (0-15)
    - Eternal 150 = blank (5-15)
    - dfsound = should be glitchy (5-15)


    Files:
    - test = hacked, unknown results

    =======================================
    =======================================
    =======================================

    Another dirty audio-only test. Screen will tell you which sample is playing (A-F text is busted).

    Test is done when you hear a short guitar riff.


    Get the same result with DSound (gaussian) + Xebra
    - 0-4 = different pitch beeps
    - 5-15 = same pitch beep
    (implies that predictor #s 5-15 behave like #0)


    If any takers for hardware testing, we're both very grateful!
    - Next would be some IRQ testing (Pete switched irq boundaries a few times)
    Last edited: Apr 5, 2011
  5. notaz

    notaz New Member

    Messages:
    10
    Likes Received:
    0
    Seems to be it, although 0 sounds different from 5-15 (attached a recording).

    (the attachment is mp3 and not a zip, forum software won't allow to upload files with mp3 etension).
    Last edited: Apr 4, 2011
  6. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Great! Thank you!


    I think beep 5-15 sound different because of the way vag works.

    Let me hack up a demo2a test to verify.


    edit1:
    You're right - a code mistake chose different sample data for beep 0.

    I'll let you know when the demo2 is re-fixed (soon).


    edit2:
    New program uploaded. Updated the sample address too early.
    (same sample now for all beep modes)

    test1 = beep 0-15
    test2 = beep 0, beep 5-15

    Sorry that took so long to hack up. ^^


    Beep 0 should sound exactly like beep 5-15 (hopefully).


    edit3:
    Code:
    spu.c
    
    predict_nr >>= 4;
    flags=(int)*start;start++;
    
    // Silhouette Mirage - Serah fight
    if( predict_nr > 4 ) predict_nr = 0;
    
    Last edited: Apr 4, 2011
  7. notaz

    notaz New Member

    Messages:
    10
    Likes Received:
    0
    And the hardware agrees.

    Looks like the right thing to commit.
  8. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Puyfect!

    This next test is more brutal (if Xebra is correct)

    ============================================
    ============================================

    IRQ - DMA behavior (part 1)


    Background:
    Battery of tests to improve understanding
    1- IRQ at DMA start
    2- IRQ at DMA end
    3- IRQ at RAM end
    4- Data address (after 3)
    5- Status debug check (after 1)
    6- Status debug check (after 2)
    7- Data address (after 2)
    8- Status debug check (after 3)
    9- Check if music plays (dma not ready flag?)


    Program:
    Modified rootexample + printgpu by doomed/padua


    Results:
    - Hardware =
    7fff0
    0004 / 0000
    0004 / 0020
    1010 / 00000200
    002e0
    (no music + many clicks)

    without bios shell:
    7fff0
    0004 / 0040
    0004 / 0060
    1010 / 00000000
    002e0
    (no music)
    (testers = edgbla)


    - Xebra =
    1 / 7fff0
    0004 / 0040
    0004 / 02e0
    1010 / 00000000
    002e0 (+ music)

    - DSound 1.09a =
    2 3 / 00030
    0004 / 0000
    0004 / 0000
    1050 / 00000200
    00000 (+ music)

    - dfsound =
    00030
    0004 / 0000
    0004 / 0000
    1050 / 00000000
    00000 (+ music)



    Files:
    - test1 = hacked, unknown results

    ============================================
    ============================================

    This one's medium-high important - results will affect how future spu tests are handled. :eek:

    I'll explain this one in more detail when any results come in (thanks!)

    (note: CD is now padded with a dummy file to avoid any read problems)
    Last edited: Apr 7, 2011
  9. edgbla

    edgbla Member

    Messages:
    41
    Likes Received:
    3
    7fff0 / 0004 / 0000
    0004 / 0020
    1010 / 00000200
    002e0
    (i don't hear music)

    without bios shell:
    7fff0 / 0004 / 0040
    0004 / 0060
    1010 / 00000000
    002e0
    Last edited: Apr 6, 2011
  10. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Oh~. This looks bad. :cringe:

    Code:
    7fff0 / 0004 / 0000
    0004 / 0020
    1010 / 00000200
    002e0
    (i don't hear music)
    
    7fff0 = either dma didn't happen or data addr reg does not update (real-time)

    (before DMA1)
    0004 = low status register (expected result)
    0000 = high status register (unknown result = nothing)

    (after DMA1)
    0004 = low status register (expected result)
    0020 = high status register (DMA done...?)

    1010 = either dma didn't happen or data addr reg does not update (real-time)

    00000200 = SPU (DMA) IRQ did happen (!!) - delayed IRQ results..? (no 1-4 #s shown)

    (before final music DMA)
    002e0 = high status register - extra bits???

    no music = final DMA never transferred



    Code:
    without bios shell:
    7fff0 / 0004 / 0040
    0004 / 0060
    1010 / 00000000
    002e0 
    
    7fff0 = either dma didn't happen or data addr reg does not update (real-time)

    (before DMA1)
    0004 = low status register (expected result)
    0040 = high status register (unknown state)

    (after DMA1)
    0004 = low status register (expected result)
    0060 = high status register (DMA done...? + ....?)

    1010 = either dma didn't happen or data addr reg does not update (real-time)

    00000000 = no SPU (DMA) IRQ (!!)

    (before final music DMA)
    002e0 = high status register - extra bits???

    no music = final DMA never transferred
    (please confirm no music?)

    ========================================
    ========================================

    This means we'll need basic survival tests to define this foreign behavior. xx(

    Need time to digest all this.
  11. edgbla

    edgbla Member

    Messages:
    41
    Likes Received:
    3
    Yes, i don't hear any music in both tests.
    But i heard many clicks, when the bios shell was used.
  12. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thanks again! That's a double strange.

    Maybe there's some dma / reset blocking pin (no shell). Might have sent trash data with (bios) - need to guess what those status pins mean.

    =========================================
    =========================================

    IRQ - DMA behavior (part 2)


    Background:
    Battery of tests to improve understanding
    0-(no shell) default irq mask
    1-plain dma - status changes
    2-irq dma - status changes
    3-mask pin?
    4-irq dma - mask pin?
    5-check music works



    Program:
    Modified rootexample + printgpu by doomed/padua




    Results:
    - Hardware =

    (caetla)
    8001000c
    8040 0004 0040
    8060 0004 02e0
    8060 0004 02e0
    8060 0004 02e0 00090000
    02e0
    8060 0004 02e0
    8060 0004 0060 00090000
    (+ music)
    (testers = notaz)


    - Xebra =
    (bios shell)
    0000000c
    8040 0004 0040
    8060 0004 02e0
    8060 0004 02e0
    8060 0004 02e0
    8060 0004 02e0 00000000
    02e0
    8060 0004 02e0
    8060 0004 02e0 00000000
    (+ music)



    Files:
    - test1 = hacked, unknown results

    =========================================
    =========================================

    Preferred results would be 'no shell' - more raw data (thanks again!).
    - Small, incremental steps of seeing what's going on (no error throwing this time)

    Thinking of setting up a printf loop to grab all the default spu regs at first catch later.


    edit:
    Found some of bitmaster's work floating around.

    Code:
    	spu_status = spu[SPU_STAT] & 0x7ff;
    	spu[SPU_ADDR] = spu_addr >> 3;
    	wait();
    
        ptr = (short *) addr;
    
    	while( size > 0 ) {
    		block_size = ( size > 64 ) ? 64 : size; 
    		for( i = 0; i < block_size; i += 2 )
    			spu[SPU_DATA] = *ptr++;     
    
         	d = spu[SPU_CTRL];
         	d = ( d & 0xffcf ) | 0x10;
         	spu[SPU_CTRL] = d;				// write Block to SPU-Memory
    		wait();
    		     	
         	time_out = 0;
        	while( spu[SPU_STAT] & 0x400 ) {
        		time_out++;
        		if ( time_out == 3840 ){
        			return( "SPU:T/O wait (wrdy H -> L)\n" );
        		}
        	}
        	wait();
        	wait(); 	
    		size -= block_size;
    	}     
    
    	spu[SPU_CTRL] &= 0xffcf;
    
    	time_out = 0;
    
    	while( ( spu[SPU_STAT] & 0x7ff ) != spu_status ) {
    		time_out++;
    
        	if ( time_out == 3840 ){
        		return( "SPU:T/O dmaf clear/W\n" );
        	}
    
    Curiously it buffers the data. He sends a non-dma status bit and immediately auto-commits the changes.
    Last edited: Apr 7, 2011
  13. notaz

    notaz New Member

    Messages:
    10
    Likes Received:
    0
    I'm getting this output, but I also get music! I'm running my tests through caetla ROM, so it might be initializing some things (it does bypass BIOS boot screen though). I have SCPH-5552 machine, maybe models have differences too.

    Note that those tests do printf heavily, which in my case is hooked by caetla to forward data to PC, which might be affecting timing.

    I think the addr reg never updates, I'm working on another project involving sound and never seen addr reg to update.

    Maybe try clearing whole SPU address space on startup for more consistent results (me vs edgbla)?

    EDIT: demo3b:
    EDIT2: forgot to state that it does play music
    [​IMG]
    Last edited: Apr 7, 2011
  14. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thanks for adding to the discussion. ;)

    I've realized that 'no bios' does not unmute the spu (pcsxr test) - caetla maybe does.


    I'm starting to agree. It'd be so convenient if it did. :(


    When we get some of the 'no shell' testing done, I'm definitely going to init some extra regs and other stuff.
  15. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Update on the problems, from looking at notaz' new data.

    1) notaz would be right - timing (between consoles) and spu itself
    - I dislike timing; going to avoid this area

    Also fully agree with him that data addr is write-only updated

    Probably explains some differences with Xebra and real console. And bad play perhaps (unverified).


    2) Going to ignore 'raw' behavior now
    - Not going to focus on 'bios boot' state behavior (Caetla is fine+)


    3) Program is turning on irq too early (before test1)
    - Irq address is default set at 0
    - Decoded buffer is _always_ running 0-3ff, 400-7ff, 800-bff, c00-fff
    (triggers an irq naturally)

    Disable irq. Set irq address. Then turn on irq.


    4) Finding #1
    - 1dac = write-only updated (ctrl reg2?)
    - 1dae = read-only (spu status)

    The moment IRQ gets turned on (ctrl reg) this pin turns on
    - 1dae = $0040 = IRQ enabled (from ctrl register)

    So when docs say to check for 3ff = 0, remember to ignore the IRQ pin (!)
    (unreleased test bug)


    5) (guess) When IRQ is hit, you must reset the IRQ ctrl state to send another one

    Going to spend lots of time with Xebra and update findings here. Then write a big program to certify everything Dr. Hell's likely already figured out.

    And insert some post-wait loops to make sure the spu is fully idle.
  16. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thanks to everyone's results, I believe we have a working program.

    =========================
    =========================

    SPU behavior (part 1)


    Background:
    Battery of tests to improve understanding


    Xebra =
    0000 (default)


    status register (1dae)
    000 - 0000 (spu on)
    001 - 0840 ($40 = irq enable)

    002 - 0800 (unmute)
    003 - 0000 (noise)
    004 - 0800 (reverb on)
    (nothing)

    005 - 0010 (dma mode 01 = $10 = ...?)
    006 - 0ab0 (dma mode 11 = $10 / $20 / $80 / $200...?)
    007 - 0010 (dma mode 10)
    008 - 0800 (dma mode 00)
    (unknown behavior)

    009 - 0008 ($08 = external reverb active)
    010 - 080c ($04 = cd reverb active)
    011 - 000e ($02 = external audio active)
    012 - 080f ($01 = cd audio active)
    (extra flags)

    013 - 000f (reg2 - $04)
    014 - 080f (irq addr $40000)
    015 - 000f (irq addr $3fff8)
    016 - 080f (irq addr $0)
    (nothing)


    basic irq testing
    (WARNING: changing ctrl settings not immediately effective)
    (ex. $8000 on)
    100 - 0840 0001 (irq test / irq address 0)
    101 - 0040 0200 (reset 1070 pin only / 1-time IRQ sent)
    102 - 0840 0000 (re-IRQ enable while active + 3x wait)
    103 - 0000 0000 (turn off IRQ enable)
    (1-time IRQ)

    104 - 0840 0001 (repeat 100 test - irq allowed)
    105 - 0840 0000 (reset 1070 pin / no wait)
    106 - 0040 0200 (wait)
    107 - 0840 0000 (wait)
    (disable - enable to reset IRQ)

    108 - 0040 0000 (set irq address to 7fff0)
    109 - 0840 0001 (wait)
    110 - 0040 0000 (wait)
    (irq active - no dice)

    111 - 0040 0000 (repeat IRQ / irq address 200)
    112 - 0840 0201 (wait - $800 = decoded buffer 2nd half)
    113 - 0040 0000 (wait)
    (decoded buffer flag)

    114 - 0800 0000 (no irq enable / wait)
    115 - 0000 0000 (wait)
    116 - 0800 0001 (wait)
    (irq disable - no dice)


    extra irq testing
    200 - 0200 (dma-w 1010+40 / irq 1010)
    201 - 0001 (dma-w 1010+40 / irq 1050)
    202 - 0001 (dma-w 1010+40 / irq 1008)
    203 - 0201 (dma-w 1010+40 / irq 1048)
    (check irq + bump ptr)

    204 - 0201 (dma-r 1010+40 / irq 1010)
    205 - 0001 (dma-r 1010+40 / irq 1050)
    206 - 0001 (dma-r 1010+40 / irq 1008)
    207 - 0201 (dma-r 1010+40 / irq 1048)
    (check irq + bump ptr)

    208 - 0200 (mode = dma-r + dma-w 1010+40 / irq 1010)
    209 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1050)
    210 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1008)
    211 - 0201 (mode = dma-r + dma-w 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    212 - 0201 (mode = dma-w + dma-r 1010+40 / irq 1010)
    213 - 0001 (mode = dma-w + dma-r 1010+40 / irq 1050)
    214 - 0001 (mode = dma-w + dma-r 1010+40 / irq 1008)
    215 - 0201 (mode = dma-w + dma-r 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    216 - 0201 (mode = non-dma + dma-w 1010+40 / irq 1010)
    217 - 0001 (mode = non-dma + dma-w 1010+40 / irq 1050)
    218 - 0001 (mode = non-dma + dma-w 1010+40 / irq 1008)
    219 - 0201 (mode = non-dma + dma-w 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    220 - 0201 (mode = non-dma + dma-r 1010+40 / irq 1010)
    221 - 0001 (mode = non-dma + dma-r 1010+40 / irq 1050)
    222 - 0001 (mode = non-dma + dma-r 1010+40 / irq 1008)
    223 - 0201 (mode = non-dma + dma-r 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    224 - 02e0 (status check - illegal above ops)
    (no unusual flags?)

    (+ music)


    Program:
    Modified rootexample + printgpu by doomed/padua




    Results:
    - Hardware =

    0000 (default)


    status register (1dae)
    000 - 0000 (spu on)
    (*) 001 - 0000 (no irq enable bit)

    002 - 0800 (unmute)
    003 - 0000 (noise)
    004 - 0800 (reverb on)
    (nothing)

    005 - 0010 (dma mode 01 = $10 = ...?)
    (*) 006 - 01b0 (dma mode 11 = $10 / $20 / $80 / $100...?)
    007 - 0010 (dma mode 10)
    008 - 0800 (dma mode 00)
    (unknown behavior)

    009 - 0008 ($08 = external reverb active)
    010 - 080c ($04 = cd reverb active)
    011 - 000e ($02 = external audio active)
    012 - 080f ($01 = cd audio active)
    (extra flags)

    013 - 000f (reg2 - $04)
    014 - 080f (irq addr $40000)
    015 - 000f (irq addr $3fff8)
    016 - 080f (irq addr $0)
    (nothing)


    basic irq testing
    (WARNING: changing ctrl settings not immediately effective)
    (ex. $8000 on)
    100 - 0040 0200 (irq test / irq address 0)
    101 - 0040 0000 (reset 1070 pin only / 1-time IRQ sent)
    102 - 0040 0001 (re-IRQ enable while active + 3x wait)
    103 - 0800 0000 (turn off IRQ enable)
    (1-time IRQ)

    104 - 0040 0200 (repeat 100 test - irq allowed)
    105 - 0040 0000 (reset 1070 pin / no wait)
    106 - 0040 0000 (wait)
    107 - 0840 0001 (wait)
    (disable - enable to reset IRQ)

    108 - 0040 0000 (set irq address to 7fff0)
    109 - 0040 0000 (wait)
    110 - 0840 0000 (wait)
    (irq active - no dice)

    111 - 0000 0001 (repeat IRQ / irq address 200)
    (*) 112 - 0840 0200 (wait - $800 = decoded buffer 2nd half)
    113 - 0040 0000 (wait)
    (decoded buffer flag)

    114 - 0000 0000 (no irq enable / wait)
    115 - 0000 0000 (wait)
    116 - 0000 0001 (wait)
    (irq disable - no dice)


    extra irq testing
    200 - 0200 (dma-w 1010+40 / irq 1010)
    (*) 201 - 0201 (dma-w 1010+40 / irq 1050)
    (*) 202 - 0200 (dma-w 1010+40 / irq 1008)
    203 - 0201 (dma-w 1010+40 / irq 1048)
    (check irq + bump ptr)

    204 - 0201 (dma-r 1010+40 / irq 1010)
    (*) 205 - 0200 (dma-r 1010+40 / irq 1050)
    (*) 206 - 0201 (dma-r 1010+40 / irq 1008)
    207 - 0200 (dma-r 1010+40 / irq 1048)
    (check irq + bump ptr)

    208 - 0200 (mode = dma-r + dma-w 1010+40 / irq 1010)
    209 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1050)
    (*) 210 - 0201 (mode = dma-r + dma-w 1010+40 / irq 1008)
    (*) 211 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    212 - 0201 (mode = dma-w + dma-r 1010+40 / irq 1010)
    213 - 0001 (mode = dma-w + dma-r 1010+40 / irq 1050)
    (*) 214 - 0201 (mode = dma-w + dma-r 1010+40 / irq 1008)
    (*) 215 - 0001 (mode = dma-w + dma-r 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    216 - 0201 (mode = non-dma + dma-w 1010+40 / irq 1010)
    217 - 0001 (mode = non-dma + dma-w 1010+40 / irq 1050)
    (*) 218 - 0201 (mode = non-dma + dma-w 1010+40 / irq 1008)
    (*) 219 - 0001 (mode = non-dma + dma-w 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    220 - 0201 (mode = non-dma + dma-r 1010+40 / irq 1010)
    221 - 0001 (mode = non-dma + dma-r 1010+40 / irq 1050)
    (*) 222 - 0201 (mode = non-dma + dma-r 1010+40 / irq 1008)
    (*) 223 - 0001 (mode = non-dma + dma-r 1010+40 / irq 1048)
    (check irq anyway + bump ptr)

    (*) 224 - 01b0 (status check - illegal above ops)
    (no unusual flags?)

    (testers = notaz)


    Files:
    - test1 = hacked, unknown results

    =========================
    =========================

    Xebra writeup:
    - Because of timing, results won't exactly match hardware
    (decoded buffer flags, some IRQ pins, result timing)

    - Writing to 1daa control is not real-time (use a delay)

    - Half of the status flags are uncovered
    (other part involves the dma modes)

    - IRQs are 1-time (must disable - enable to send another one)
    (this may affect nasty IRQ games - VP uses a $7 IRQ loop)

    - DMA allows IRQs (check then bump)
    - DMA allows invalid mode behavior to send IRQs (and bump)
    (ran out of screen space to try a dma mode 00 and IRQs)

    - Music should work this time - lots of delay times used to play nice with the emulator.
    Last edited: Apr 10, 2011
  17. notaz

    notaz New Member

    Messages:
    10
    Likes Received:
    0
    Ran it, some values seem to be unstable, see screenshots from different runs (you could also printf all the values for easy copy-paste).
    As for music, it doesn't really work but the notes do play and sound more like chip music (see attachment).
    Last edited: Apr 10, 2011
  18. shalma

    shalma Discontinued Emu Author

    Messages:
    1,192
    Likes Received:
    0
    Thanks again! I'll remember to add a printf for you ;)

    $800 can be ignored = normal behavior (1st / 2nd decoded buffer $000-3ff)
    - seems very consistent between both runs


    note: Xebra behaves differently (better) when run as pass-1 interpreter (dynarec bugs)


    Brief examine:
    (*) 001 - 0000 (no irq enable bit..?)
    - hw did not turn on 'irq enable $40 bit'

    (*) 006 - 01b0 (dma mode 11 = $10 / $20 / $80 / $100...?)
    - hw does $100, not $200


    200 - 0200 (dma-w 1010+40 / irq 1010)
    (*) 201 - 0201 (dma-w 1010+40 / irq 1050)
    (*) 202 - 0201 (dma-w 1010+40 / irq 1008)
    203 - 0201 (dma-w 1010+40 / irq 1048)
    - what..?



    208 - 0200 (mode = dma-r + dma-w 1010+40 / irq 1010)
    209 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1050)
    (*) 210 - 0201 (mode = dma-r + dma-w 1010+40 / irq 1008)
    (*) 211 - 0001 (mode = dma-r + dma-w 1010+40 / irq 1048)
    (check irq anyway + bump ptr)
    - what..?



    (*) 224 - 01b0 (status check - illegal above ops)
    - hmm


    Haven't checked the music yet (will later)
    - Need lots more time to think all this over
    - Maybe there's something wrong with DMA that Xebra isn't picking up either

    Definitely not what I expected at all. o_o



    edit:
    Xebra is running faster than the console (dummy loops). Need to perform 3x wait to enforce idle period
    - this might (not) affect the music playing (lol)
    - it's said that $1000-1007 (100f?) = system area (don't touch me)
    - invalid dma handling might've botched the spu (accidental $1000 writes) (mod sets regs when playback starts - done! string)


    dma mode flags still questionable
    - dma mode 01 / 10 = $10 flag
    - dma mode 11 = $10 + $20, $80, $100 status pins

    $40 irq status flag (when hit)
    - uncovered by running 2 (!) tests (good call by notaz)

    (??) dma-r mode = irq hit for any dma-w
    (??) dma-w mode = irq hit for any dma-r
    (??) non-dma mode + dma-w = $1000 addr reset + ptr bump
    (??) non-dma mode + dma-r = $1000 addr reset + ptr bump


    Going to need more tests than I wanted. :(
    Last edited: Apr 10, 2011
  19. NNYdust

    NNYdust New Member

    Messages:
    2
    Likes Received:
    0
    Hello and Good Day i am having trouble with pcsx for ppc mac (lol sounds funny). I am playing thru Resident Evil 3 Nemesis. It plays birlliantly fine but once i get thru some doors the screen goes black as in i open a door as it loads it loads nothing.So i tried runs and the faster i go thru the game the more doors it loads up on me got to a cut scene grabbed a lighter and screen goes black with no continued gameplay just stays like that.Also i would like to know where can i delete saved files on the memory cards wich i think is a huge part.By the by i would really want to help on the pcsx revival but would not know where to start i would love to learn a little more on that.Any answers acceptable and grateful i shall await an answer.God Bless You all And To All A Good Day.
  20. masta.g.86

    masta.g.86 No sir, I don't like it. Award Winner!

    Messages:
    5,282
    Likes Received:
    0
    Start a new thread instead of attempting to hijack this one or post in one that's more relevant to your issue.

Share This Page