It is currently Fri Aug 18, 2017 11:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Mon Jul 31, 2017 4:15 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 250
Bah, now Klax is imperfect.

Basically, the whole problem is whether after a C001 write, the IRQ counter should be loaded with the latch +1 or with the unmodified latch.

The NesDev RAMBO-1 wiki article claimed, based on experiments, that it's always +1, although it admitted to a lack of knowledge on where the +1 comes from. Nocash/Kevin Horton claim the same.
Klax wants always +1 as well.
Hard Drivin' on the other hand always needs the unmodified latch value.
Skull & Crossbones generally wants latch +1 except for the IRQ just above the status line.

I thought I was onto something when I observed that Hard Drivin' writes first to C001 and then to C000, while S&C writes to C000 first and then to C001. But Klax turns out to mix both methods, yet consistently wants +1.

Of course we cannot rule out that there are different revisions of the Rambo 1 chip that behave differently. If I understand the Japanese description of that Hard Drivin' video I linked to earlier correctly however, the guy modified a Skull & Crossbones board to put Hard Drivin on it, which speaks against that theory.

Edit: And this guy of course put Hard Drivin' on a Klax board, so I think we can shelve the the hardware revision theory.


Last edited by NewRisingSun on Wed Aug 02, 2017 8:52 am, edited 4 times in total.

Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 5:14 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 561
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
From the Rambo-1 games on NesCartDB there's two kinds of PCBs, one with an extra logic chip and one without. Mapper chip has same markings on all.
Skull and Crossbones and Klax don't have the chip, Shinobi, Rolling Thunder and Road Runner have a 74x32 on them.
In addition to this, S&C and Road Runner have a jumper in different spot compared to others.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 10:04 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6028
Location: Seattle
The 74'32 is just there to allow the use of a 28-pin 128 KiB CHR-ROM.

I've documented specifics on nesdevwiki:Tengen RAMBO-1 pinout


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 6:54 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 43
NewRisingSun wrote:
Attached find a Nintendulator source file that runs both Skull & Crossbones, Hard Drivin', Rolling Thunder (U.S. version) and Xybots like in the various videos I posted. Basically, I am making two assumptions that are not described in the wiki:
  1. It's not IRQcounter=IRQlatch +1, but IRQcounter=IRQlatch |1.
  2. The |1 part is only done if the write sequence is C000 C001 E001 (as in Skull & Crossbones). If the write sequence is C001 C000 E001 (as in Hard Drivin'), then the IRQcounter is loaded with the unmodified IRQlatch.
These two assumptions should be testable with real hardware.


This strikes me as being unlikely to be the physical implmenentation.

I tried myself to see if I could get any good results using different assumptions.

Here were my assumptions:

1. always use latch+1
2. IRQCounter decrements immediately when reloaded via C001
3. writes to E000 clear IRQcounter as well, and thus a decrement from zero will also load latch + 1 but this will look like just latch

Using these assumptions I got Skull and crossbones and Klax to work glitch free, Hard Drivin has a blue line on the driving sections above the timer, and rolling thunder status bar moves up by 1 scanline when I shoot.

Well, not perfect, but maybe it will give someone else an idea.


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 10:38 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 250
Alyosha_TAS wrote:
Skull and crossbones and Klax to work glitch free
Have you checked all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.

I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock, instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 6:17 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3040
Location: Brazil
Well, my current proposal (wiki discussion page) seems the most correct until now. That's because the IRQ is off by -1 in all games, except Skull&Crossbones. But ya, an hardware test is required.

WHO could do such test, please?


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 9:07 am 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 43
NewRisingSun wrote:
Have you checked all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.

I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock, instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.


Ah, you're right the glitch line in the item screen is there. Well back to the drawing board i guess.

I agree that hardware testing is needed.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 9:40 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 250
I'd say kevtris or James might be the persons to ask for hardware testing. I suggest the following initial list of things to investigate:
  1. Can it be confirmed that under normal circumstances, in scanline mode, writing 0 to C000 and C001 returns in exactly one IRQ being asserted not at the next A12 rise, but the one after that, as Kevin Horton describes?
  2. Can circumstances be found under which writing 0 to C001 and C000 causes the IRQ to be asserted at the next A12 rise after all, and not at the one after that? That's what Hard Drivin' needs. Its IRQ handler that does such a thing starts at PC $FDB4. Circumstances could include the order in which registers are written to, or the timing of the register writes relative to what's happening on the A12 line.
  3. Does it make any difference whether C001 is written before C000, or vice-versa?
  4. Does writing to E000 or E001 clear the IRQ counter, as Alyosha_TAS suggested?
  5. Are any of the latch value bits written to C000 ignored, as Zepper suggests on the wiki discussion page?
  6. Is the prescaler in CPU cycle mode actually cleared every time when writing to C001, as the wiki claims? Is it cleared even when scanline mode is selected?
  7. Does anything funny happen when switching from CPU cycle to scanline mode? An earlier version of puNES' source code seems to suggest that when switching form M2 to A12 mode, the next M2 falling edge will still clock the chip even as the chip is already in scanline mode (variable tengen_rambo.irq_force_clock in puNES' mapper_Tengen.c, not in the current source code version, tough).


Top
 Profile  
 
PostPosted: Sat Aug 05, 2017 9:53 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3040
Location: Brazil
Here's my best result so far. Now, Klax is off by 1 scanline only - all the other games are perfect.
It's better than my suggestion in the discussion page. Here we go.

Code:
writes to $C000: irq_latch=data;
writes to $C001: irq_reload=true; irq_mode=data&1;
writes to $E000: irq_enable=false; IRQ acknowledge by CPU.
writes to $E001: irq_enable=true; IRQ acknowledge by CPU.

When the IRQ is clocked by CPU or scanline modes:
* If irq_reload == true:
      irq_counter = irq_latch;
      if(irq_latch != 0) irq_counter |= 1;
      irq_reload=false;
* Else if irq_counter == 0:
      irq_counter = irq_latch;
* Else irq_counter--;
* If irq_counter == 0 and irq_enable == true
      irq_delay=4 (IRQ will be fired 4 CPU cycles later)


EDIT: as side note, using irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by +2. The only interesting part is about irq_latch!=0, when the irq_counter must be ORed with 1. Perhaps it's another race condition with $2006..? Still, is the irq_counter really counting downward rather than upward, as I had suggested?


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 3:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3040
Location: Brazil
New version. Check the first message.


Top
 Profile  
 
PostPosted: Fri Aug 11, 2017 7:56 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 608
Zepper wrote:

EDIT: as side note, using irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by +2. The only interesting part is about irq_latch!=0, when the irq_counter must be ORed with 1. Perhaps it's another race condition with $2006..? Still, is the irq_counter really counting downward rather than upward, as I had suggested?


We have seen how Klax is supposed to work on a real cartridge, but no one has ever seen how Hard Drivin' is supposed to work on real hardware, right? Maybe HD does have a minor 1-scanline glitch that they did not resolve in the prototype.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Aug 11, 2017 8:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6028
Location: Seattle
FrankWDoom has a few TV pictures of his reproduction in that thread.


Top
 Profile  
 
PostPosted: Fri Aug 11, 2017 8:56 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 225
There's also this video of it running on a Skull & Crossbones cart on a famiclone:
https://www.youtube.com/watch?v=TWacLAxHZzk


Top
 Profile  
 
PostPosted: Sat Aug 12, 2017 5:47 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3040
Location: Brazil
The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.


Top
 Profile  
 
PostPosted: Sat Aug 12, 2017 6:09 am 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 43
Zepper wrote:
The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.


How rare are these carts? I'd be willing to pitch in some money towards getting them in the hands of someone who can do some exhaustive hardware testing and pinning down the exact behaviour. Maybe they are slightly different? Maybe the behaviour is still more complicated then we expect?

It would be nice to be able to wrap this issue up definitively and move on. This has wasted the time of numerous devs already with inconclusive results.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group