RAMBO-1 Mapper Investigation

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

NewRisingSun
Posts: 1123
Joined: Thu May 19, 2005 11:30 am

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Sat Jan 18, 2020 12:59 am

I successfully converted "Hard Drivin'" to Waixing's Mapper 176. ;)

But yes, for Skull & Crossbones, because it needs both scanline and M2 IRQ counters, VRC4 or VRC6 is probably the best choice.

pakosup
Posts: 25
Joined: Mon Apr 24, 2017 10:23 pm

Re: RAMBO-1 Mapper Investigation

Post by pakosup » Sat Jan 18, 2020 6:17 am

lidnariq wrote:
Fri Jan 17, 2020 11:57 pm
I'd think VRC4/6/7 should be doable?

You could also look at my mappers summary
Thank you for such useful table. I haven't seen it before. I gonna try vrc4.

NewRisingSun
Posts: 1123
Joined: Thu May 19, 2005 11:30 am

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Sun Jan 19, 2020 10:12 am

Ben Boldt wrote:Yes, that is true, I can control how many M2 cycles before ack'ing the IRQ. It is not triggered by the IRQ itself, but since the test stays the same through each loop, I can precisely control which M2 cycle does the ack. I tweak it see it move on the scope to find the right spot.
Is not possible that you are accidently clocking the scanline counter when you ack' the IRQ by disturbing the normal PA12 sequence?

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Sun Jan 19, 2020 11:11 am

My test code treats PA12 with a set-and-forget approach. It just remains the same until some point in the test specifically changes it. Clearing the IRQ does produce extra M2 cycles with PA12 remaining with its previous value. Also, this would be visible on the scope and I did not see any extra PA12 toggles. Good thinking though. I will be able to poke at it some more this week.

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Mon Jan 20, 2020 4:00 pm

NewRisingSun wrote:
Wed Jan 08, 2020 4:02 am
Ben Boldt wrote: Do you know, when it does write to $C001, is it writing value $00, or could it be writing a different even value?
It writes $00 to $C001. Here is the write log from within my working visually-accurate emulation:

Code: Select all

Scanline	PPUCycle	Event
241		28		NMI
258		264		$C000=$BC
258		282		$C001=$00
258		294		$E001=$00
188		292		IRQ
188		301		$E000=$00
189		41		$E001=$00
189		59		$C000=$04
193		294		IRQ
193		303		$E000=$00
194		139		$E001=$00
194		157		$C000=$17
217		309		IRQ
217		318		$E000=$00
241		30		NMI
Adding a column for PA12 -- is this correct? It seems Rolling Thunder does an ACK / disable (E000 = 00) right away after the IRQ with PA12 still high, then waits quite some time until PA12 = 0 on the next scanline before enabling (E001 = 00) and then quickly sets the new reload (C000 = xx). In my testing, I always did all 3 register writes in a row, no additional CPU cycles in between, so I would always have all 3 writes with PA12 the same. If you wouldn't mind doing a sanity check on the PA12 column, that could save me a lot of frustration in case I have an error there.

Code: Select all

Scanline | PA12 | PPUCycle | Event
---------+------+----------+---------------
241      |   0  | 28       | NMI
258      |   1  | 264      | $C000=$BC
258      |   1  | 282      | $C001=$00
258      |   1  | 294      | $E001=$00
188      |   1  | 292      | IRQ
188      |   1  | 301      | $E000=$00
189      |   0  | 41       | $E001=$00
189      |   0  | 59       | $C000=$04
193      |   1  | 294      | IRQ
193      |   1  | 303      | $E000=$00
194      |   0  | 139      | $E001=$00
194      |   0  | 157      | $C000=$17
217      |   1  | 309      | IRQ
217      |   1  | 318      | $E000=$00
241      |   0  | 30       | NMI

NewRisingSun
Posts: 1123
Joined: Thu May 19, 2005 11:30 am

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Mon Jan 20, 2020 5:03 pm

Two more samples:

Code: Select all

Scanline | PA12 | PPUCycle | Event
---------+------+----------+---------------
241      |   1  | 28       | NMI
258      |   0  | 261      | $C000=$BC
258      |   0  | 279      | $C001=$00
258      |   0  | 291      | $E001=$00
188      |   0  | 289      | IRQ
188      |   0  | 301      | $E000=$00
189      |   0  | 41       | $E001=$00
189      |   0  | 59       | $C000=$04
193      |   0  | 294      | IRQ
193      |   1  | 303      | $E000=$00
194      |   0  | 139      | $E001=$00
194      |   0  | 157      | $C000=$17
217      |   0  | 309      | IRQ
217      |   0  | 318      | $E000=$00
241      |   1  | 30       | NMI

Code: Select all

Scanline | PA12 | PPUCycle | Event
---------+------+----------+---------------
241      |   1  | 28       | NMI
258      |   0  | 261      | $C000=$BC
258      |   0  | 279      | $C001=$00
258      |   0  | 291      | $E001=$00
188      |   1  | 295      | IRQ
188      |   0  | 304      | $E000=$00
189      |   0  | 44       | $E001=$00
189      |   0  | 62       | $C000=$04
193      |   0  | 288      | IRQ
193      |   0  | 297      | $E000=$00
194      |   0  | 133      | $E001=$00
194      |   0  | 151      | $C000=$17
217      |   1  | 303      | IRQ
217      |   0  | 312      | $E000=$00
241      |   1  | 24       | NMI

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Wed Jan 22, 2020 2:22 pm

I am rewriting a new test so that I can have accurate clocking of PPU/CPU, so I can do things in terms of PPU cycles instead of all of these assumptions I am making by converting into terms of M2 counts. This might really prove how little I know about the PPU but I have to ask -- when each scanline is in the sprite fetch region (i.e. PPU cycles 257-320), it does this sequence:

257, 258: Garbage NT byte (PA12 = 0)
259,260: Garbage NT byte (PA12 = 0)
261,262: Sprite Tile Low Byte (PA12 = 1)
263,264: Sprite Tile High Byte (PA12 = 1)
265+ repeat

So when I am in the sprite region, I need to be toggling PA12 like that to be accurate to the Famicom?? I have not been doing that. I want to make my test as accurate as possible, reproduce the Rolling Thunder sequence, then pare it down to get to the underlying behavior.

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Wed Jan 22, 2020 6:15 pm

Here is some starting of the test code, would you guys please help me review it, if it makes sense to the actual PPU behavior?

Code: Select all

void tick( void )
{
    static uint16_t master_clock_count = 0;  // This value increments each time this function is run.
    static uint16_t ppu_cycle_count = 0;
    static uint16_t scanline_count = 0;

    if( (0 == master_clock_count) || (3 == master_clock_count) )  // CPU cycle, every 3rd tick.
    {
        // Wait for appropriate moment to write to RAMBO-1 registers here.
    }
    
    if( 0 == (master_clock_count & 0x0001) )  // PPU cycle, every 2nd tick.
    {
        if( (scanline_count >= 240) && (scanline_count <= 260) )  // V-Blank scanlines
        {
            PPU_A12 = 0;
        }
        else  // Non-V-Blank Scanlines
        {
            if( ppu_cycle_count <= 256 )  // 32 Background fetches
            {
                PPU_A12 = 0;
            }
            else if( ppu_cycle_count <= 320 )  // 8 Sprite fetches
            {
                switch(ppu_cycle_count & 0x0007)
                {
                    case 1:  // Garbage NT fetch, first cycle (ex 257, 265, 273)
                        PPU_A12 = 0;
                        break;
                    case 2:  // Garbage NT fetch, second cycle (ex 258, 266, 274)
                        PPU_A12 = 0;
                        break;
                    case 3:  // Garbage AT fetch, first cycle (ex 259, 267, 275)
                        PPU_A12 = 0;
                        break;
                    case 4:  // Garbage AT fetch, second cycle (ex 260, 268, 276)
                        PPU_A12 = 0;
                        break;
                    case 5:  // Low sprite tile byte, first cycle (ex 261, 269, 277)
                        PPU_A12 = 1;
                        break;
                    case 6:  // Low sprite tile byte, second cycle (ex 262, 270, 278)
                        PPU_A12 = 1;
                        break;
                    case 7:  // Hi sprite tile byte, first cycle (ex 263, 271, 279)
                        PPU_A12 = 1;
                        break;
                    case 0:  // Hi sprite tile byte, second cycle (ex 264, 272, 280)
                        PPU_A12 = 1;
                        break;
                }

            }
            else  // 2.5 Remaining Background fetches
            {
                PPU_A12 = 0;
            }
        }
        
        // Update PPU cycle count
        ppu_cycle_count++;
        if( ppu_cycle_count > 340 )
        {
            ppu_cycle_count = 0;
            scanline_count++;
            if(scanline_count > 261)
            {
                scanline_count  = 0;
            }
        }
    }
    
    master_clock_count++;
    if( master_clock_count > 5 )
    {
        master_clock_count = 0;
    }
}

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Fri Jan 24, 2020 8:52 am

If anyone can confirm that PA12 does go low like this, I really want to confirm that before proceeding. To be an NT or AT byte, I suppose that alludes to it fetching from the region $2000-2fff but I still honestly do not know. These fetches don't normally do anything so I don't know how to be sure about it. I need a little more confidence on that before putting a bunch more work in.

PPU cycles:
257, 258: Garbage NT byte (PA12 = 0)
259,260: Garbage AT byte (PA12 = 0)
261,262: Sprite Tile Low Byte (PA12 = 1)
263,264: Sprite Tile High Byte (PA12 = 1)
265+ repeat

NewRisingSun
Posts: 1123
Joined: Thu May 19, 2005 11:30 am

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Fri Jan 24, 2020 8:55 am

Please refer to my Excel chart on this question.

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Fri Jan 24, 2020 3:53 pm

NewRisingSun wrote:
Fri Jan 24, 2020 8:55 am
Please refer to my Excel chart on this question.
Oh man, sorry I forgot you did that.

krzysiobal
Posts: 636
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: RAMBO-1 Mapper Investigation

Post by krzysiobal » Wed Feb 05, 2020 6:33 am

I desoldered the pin 19 of RAMBO-1 chip and it is not internally connected to GND, it is rather some kind of input pin.
When tied to 5V (through 1k resistor for safety reasons), RAMBO-1 constantly drives the data bus with byte 0x05, no matter if this is read or write cycle. And when accessing 8000-ffff, PRG-/CE is still asserted causing potential bus conflicts. No idea if this is some kind of debug pin, or it switches its functionality to something different.

BTW. I checked the PRG/CHR modes of this chip and they agree with what nesdev.wiki says, except that when P=1, $A000=R7, $C000=R6.
No idea why on wiki this is reversed and repeated 3 times, can someone else check this on his chip?

lidnariq
Posts: 9008
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: RAMBO-1 Mapper Investigation

Post by lidnariq » Wed Feb 05, 2020 11:53 am

Any chance that pin 19 either exposes the CIC or IRQ state?

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Wed Feb 05, 2020 4:51 pm

lidnariq wrote:
Wed Feb 05, 2020 11:53 am
Any chance that pin 19 either exposes the CIC or IRQ state?
I played with pin 19 starting in the first page of this thread. It definitely puts the chip into a different mode. It prevents writing to most registers and causes other seemingly nonsensical behaviors. It is located right next to the CIC stuff, so my initial thought was that it had something to do with that, maybe a CIC region select, etc. I did not look at any CIC stuff when playing with this pin. Register contents generally seem to stay intact and resume normal operation when toggling this pin.

User avatar
Ben Boldt
Posts: 486
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: RAMBO-1 Mapper Investigation

Post by Ben Boldt » Wed Feb 05, 2020 5:29 pm

krzysiobal wrote:
Wed Feb 05, 2020 6:33 am
I desoldered the pin 19 of RAMBO-1 chip and it is not internally connected to GND, it is rather some kind of input pin.
When tied to 5V (through 1k resistor for safety reasons), RAMBO-1 constantly drives the data bus with byte 0x05, no matter if this is read or write cycle. And when accessing 8000-ffff, PRG-/CE is still asserted causing potential bus conflicts. No idea if this is some kind of debug pin, or it switches its functionality to something different.

BTW. I checked the PRG/CHR modes of this chip and they agree with what nesdev.wiki says, except that when P=1, $A000=R7, $C000=R6.
No idea why on wiki this is reversed and repeated 3 times, can someone else check this on his chip?
I actually tested the Rambo-1 banking quite extensively, see attached excel doc. Reviewing this, I confirmed what you are saying, that this is an error in the wiki. The wiki even goes so far as to say "NOT R7 / NOT R6"... Not sure if I made that mistake or if it was preexisting, but I will fix it. Sorry if it is my error.

Here is the explanation of my test and how it correlates to the Excel doc:

The first and second column refer to the value written to register $8000. (First column is dec, second column is hex.) Then the next 8 columns are the test result for PRG banking. The remaining columns are for CHR banking. I will explain just the PRG banking.

Step 1. For each value $00 to $0F, write that value to $8000, followed by writing $00 to $8001. i.e. set all internal R(x) bank registers to to $00.

Step 2. Write value XX to $8000, then $55 or $AA to $8001. XX being the 1st/2nd column of the row in the spreadsheet that you want to test. Each loop through the test, alternate between $55 and $AA.

Step 3a. Read from $8000, toggle debug pin
Step 3b. Read from $8001, toggle debug pin
Step 3c. Record PRG bank from PRG-ROM address pins into column "55, $8000" (or "AA") in spreadsheet.

Step 4a. Read from $A000, toggle debug pin
Step 4b. Read from $A001, toggle debug pin
Step 4c. Record PRG bank from PRG-ROM address pins into column "55, $A000" (or "AA") in spreadsheet.

Step 5a. Read from $C000, toggle debug pin
Step 5b. Read from $C001, toggle debug pin
Step 5c. Record PRG bank from PRG-ROM address pins into column "55, $C000" (or "AA") in spreadsheet.

Step 6a. Read from $E000, toggle debug pin
Step 6b. Read from $E001, toggle debug pin
Step 6c. Record PRG bank from PRG-ROM address pins into column "55, $E000" (or "AA") in spreadsheet.

Step 7. Loop to step 2.

I neither expected nor found any discrepancies between $xxx0 and $xxx1 but included it in the test so I would have been able to see it if anything ever didn't line up with any of those pairs.
Attachments
rambo1banking.xlsx
(20.11 KiB) Downloaded 5 times

Post Reply