RAMBO-1 Mapper Investigation

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

Moderators: B00daW, Moderators

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 » Tue Dec 17, 2019 2:01 pm

NewRisingSun wrote:
Tue Dec 17, 2019 1:50 pm
Does this state diagram explain why writing to $C001 within the 16-M2-cycle time window since the last PA12=1 causes N+1 instead of N+2 behavior?
The state diagram that I drew by hand does this with the "hold from reset" state. The text description with states 16 and 17 does this with state 17. I really think there is a way to debug the hand-drawn diagram to make it work, bit it just isn't there yet and I am at a point where if I keep staring at it I will keep spinning in circles. It is also possible that my simulator has a bug but things look good when I run it step-by-step. Things will go better if I walk away from it for a while and come back later.

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

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Tue Dec 17, 2019 2:19 pm

Okay, just asked to make sure we are not going into a dead-end direction, but that does not seem to be the case. :)

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 Dec 18, 2019 4:08 pm

Progress! I discovered a mistake I made with $C001 reset in the text description of my original successful method:

Code: Select all

On M2 falling edge:

    If PA12 = 0:
        If 4-bit counter < 16: 4-bit counter++.
        else keep the same value.
    If PA12 = 1:
        If 4-bit counter = 16: Clock the 8-bit counter.
        Always reset 4-bit counter to 0.

On 8-bit counter clock:

    If value = 0:
        If IRQ is enabled, trigger IRQ (wait 1 more cycle before doing that though, regardless of PA12 next cycle...)
        Always reload counter with value in $C000.
    Else value--.

On Write to $C001 (reset):

    Reload 8-bit counter with value in $C000
    If 4-bit counter = 16:
        Set 4-bit counter to 17.
I based my new state diagram on the text description, so I was always going to "Hold from Reset" state whenever I had a reset, regardless of the present state. It should only go to "Hold from reset" if it is presently in the "Next sprite fetch counts as scanline" state. I think that this is a big,big part of why it wasn't working with the new diagram.

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

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Tue Jan 07, 2020 2:05 am

Any news on this, or any input that I can provide?

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 » Tue Jan 07, 2020 11:56 am

I haven't made any progress. All that I am doing now is trying to make my text description work with 74xx logic. The text description does appear to work in every case. I am not really sure about the value-add from the 74xx version from an emulator perspective, it will just be a different way of looking at the same thing.

Since the 74xx method will match more closely to the real hardware implementation, it is possible that additional functionality or bugfix to the text description may arise. But at least for now, this is a very good description of how to handle scanline counting:
Ben Boldt wrote:
Fri Dec 13, 2019 5:00 pm
On M2 falling edge:
  • If PA12 = 0:
    • If 4-bit counter < 16: 4-bit counter++.
    • else keep the same value.
  • If PA12 = 1:
    • If 4-bit counter = 16: Clock the 8-bit counter.
    • Always reset 4-bit counter to 0.
On 8-bit counter clock:
  • If value = 0:
    • If IRQ is enabled, trigger IRQ (wait 1 more cycle before doing that though, regardless of PA12 next cycle...)
    • Always reload counter with value in $C000.
  • Else value--.
On Write to $C001 (reset):
  • Reload 8-bit counter with value in $C000
  • Set 4-bit counter to 17.

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

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Tue Jan 07, 2020 1:39 pm

How does M2 counting mode come into this description? How is the "prescale by four" translated into the 4-bit counter operation?

Is it still "On M2 falling edge, compare counter to [$C000] << 2 | 3"? No, that cannot be, as that was written when the 8-bit counter was not yet described as counting down to zero.

Edit:
Ben Boldt wrote:If value = 0:

If IRQ is enabled, trigger IRQ (wait 1 more cycle before doing that though, regardless of PA12 next cycle...)
Always reload counter with value in $C000.
This cannot be true. "Rolling Thunder" explicitly depends on the reload occuring during the counter clock that follows the one that triggered the IRQ. During NMI, it writes $BC to $C000 and writes $00 to $C001, then at scanline $BC in its IRQ handler, it only writes $04 to $C000, not to $C001, expecting an IRQ to occur four or five scanlines later. If $C000 were reloaded on the same counter clock as the IRQ being triggered, then the reload with $04 would only occur after $BC has been counted down a second time, which clearly is not what the game expects.

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 » Tue Jan 07, 2020 9:03 pm

I am going to have to look closer at that because I completely agree, I would expect the next IRQ to happen after $BC additional scanlines regardless of writing $04 to $C000 without touching $C001 like that, so something must not be captured by the way I am testing this. In fact, I looked at this specifically and found that the $04 always waits until next time to take effect, and this is one of the data points that I had come to depend on when thinking this stuff through. Very interesting. Do you know, when it does write to $C001, is it writing value $00, or could it be writing a different even value? I believe I had done almost all testing with value $00. We only know function of bit 0 as it stands.

My setup is a little different with respect to /IRQ versus a real famicom. I am not triggering any function based on when /IRQ occurs. I have /IRQ out to the scope, but my setup does everything just M2-cycle-count-based. It is not reading back and reacting to /IRQ like a real 6502, which therein may somehow provide a different scenario than I am testing somehow. For example, I am not fetching any vectors from $FFFx,x+1 for NMI/V-Blank or IRQ, not sure how that could matter seeing as how the whole last 8k of ROM looks just the same as that, but you get my point, my setup is not a nintendo, and there may be some natural part of that process that I just didn't think of to recreate. I am only writing to registers with PA12 low for example too -- that is also unrealistic, but again debatable if it matters.

I can say though that my text description passes all tests that I have conjured up thus far, so it must be really close. I will have to focus on how you have described rolling thunder, and also consider realistic famicom conditions to find better test cases.

To keep my timing in perspective on this, this is an after-work project for me. I just stay late once in a while after work to do it, and I have been on holiday the last 2 weeks. That and competing projects... I was working on an adapter to put a 72-pin cart into a 60-pin famicom the last couple days. that one is more of a mechanical challenge, to key the 72-pin cart with the adapter, prevent backwards insertion. Hobbies always depend what you're in the mood for, right? ;) Soon I will be itching to solve the Rambo-1 mysteries again.

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

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » 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

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 08, 2020 6:59 am

You know, the more I think about it, wasn't it the CPU timer mode that waited until next time to reload like that? Maybe I am getting confused with that and never really tried this aspect in scanline mode.

aquasnake
Posts: 84
Joined: Fri Sep 13, 2019 11:22 pm

Re: RAMBO-1 Mapper Investigation

Post by aquasnake » Wed Jan 08, 2020 9:35 am

i guess $C000 is just for latching the databus, $C001 here is to reload the counter.

only $C001.bit[0] is meaningful, which selects scanline or cpu counter irq.

if writing $0 to $C001, the mapper wont change the irq mode anyway, it is still scanline irq mode by default

like this:

Code: Select all


3'b100:  begin // $C000-$DFFE, even (IRQ latch)
	irq_scanline_latch[7:0] = cpu_data_in;
	irq_cpu_latch[7:0] = cpu_data_in;
end
3'b101:  begin // $C001-$DFFF, odd
	irq_cpu_value[9:0] = {irq_cpu_latch[7:0], 2'b00};
	irq_mode = cpu_data_in[0];
end
3'b110: // $E000-$FFFE, even
	if (irq_mode) 
		[stop cpu counter]
	else
		[stop scanline counter]
3'b111: // $E001-$FFFF, odd
	if (irq_mode) 
		[start cpu counter]
	else
		[start scanline counter]
	

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 15, 2020 3:39 pm

Just now getting back to this. With my test setup using the actual RAMBO-1 chip, no matter what I try, I have not been able to get it to accept a new $C000 write immediately yet -- it still always hangs on to the previous value until next time... I will keep trying.

My test works like this:

1. Write 00 to E000 (disable/ack IRQ)
2. Write 05 to C000 (trigger on scanline 5+?)
3. Write 00 to C001 (set scanline mode and reload the counter)
4. Write 00 to E001 (Enable IRQ)
5. Read from $8000 171 times with PA12 = 0
6. Read from $8000 43 times with PA12 = 1
7. Read from $8000 13 times with PA12 = 0
8. Increment test variable "scanline_count"
9. If scanline_count <= 261, goto 5, else clear scanline_count, goto 1.

Amongst steps 5/6/7:
I check scanline_count and the number of $8000 reads. If it matches the test case, do this sequence:
A. Write $00 to E000
B. Write $00 to E001
C. Write $01 to C000 <<=== This should make the next IRQ in fewer scanlines than leaving C000 set as 05 from before.

I set the test case to happen before and after the IRQ. Typically I triggered at scanline_count = 7, reads = 100. I rearranged several different orders of steps A/B/C. I tried step C values greater than 5 as well. I have not found any way to preempt the registered $C000 value yet as Rolling Thunder does.

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

Re: RAMBO-1 Mapper Investigation

Post by NewRisingSun » Thu Jan 16, 2020 11:54 am

I don't quite understand how you get to a scanline length of 227 M2 cycles, but it should not matter for the purpose of the test, as long as the PA12 rise and fall is appropriately spaced.
Ben Boldt wrote:I check scanline_count and the number of $8000 reads. If it matches the test case, do this sequence: (...) I set the test case to happen before and after the IRQ.
Edit: As I now understand it, you time your test case separately from the IRQ itself?

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 » Thu Jan 16, 2020 4:18 pm

NewRisingSun wrote:
Thu Jan 16, 2020 11:54 am
I don't quite understand how you get to a scanline length of 227 M2 cycles, but it should not matter for the purpose of the test, as long as the PA12 rise and fall is appropriately spaced.
Ben Boldt wrote:I check scanline_count and the number of $8000 reads. If it matches the test case, do this sequence: (...) I set the test case to happen before and after the IRQ.
Edit: As I now understand it, you time your test case separately from the IRQ itself?
227 is just junk left over from a previous test, I thought it was approximately close enough so I let it be. I will get this to work, you described in good detail how Rolling Thunder does that and there is a lot I can do to better replicate those conditions you described. We have a big snowstorm coming here, I don't expect any progress on it tomorrow but I will look at it soon.


Edit:
NewRisingSun wrote:
Thu Jan 16, 2020 11:54 am
Edit: As I now understand it, you time your test case separately from the IRQ itself?
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.

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

Re: RAMBO-1 Mapper Investigation

Post by pakosup » Fri Jan 17, 2020 11:19 pm

NewRisingSun, do you know any mapper that can be used instead of rambo-1? I mean the same bank organization and IRQ. E.g. I converted "Shinobi" to mapper 80, but this game is not using IRQ, so I can't use the same approach for "Skull & Crossbones".

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

Re: RAMBO-1 Mapper Investigation

Post by lidnariq » Fri Jan 17, 2020 11:57 pm

I'd think VRC4/6/7 should be doable?

You could also look at my mappers summary

Post Reply