X1-017 testing

[krzysiobal]

X1-017 testing
I got bought `Kyuukyoku Harikiri Stadium: Heisei Gannen Ban` game to test X1-017 chip. My IC is dated 8932KX.


I will post my observation results:
* Data pins seem to be internally pulled-down to GND by the X1-011 (much stronger than the internal 20k-50k pull-ups in atmega16 in kazzo), because reading from $0000-$5fff, $73400-$7fff returns 0x00. When particular RAM region is disabled, it also returns 0x00 in every byte from it.

* Stop of M2 toggling does not seem to disable any of RAM regions

* RAM EN/DIS registers aree fully decoded (there are no mirrors in $7800-$7fff)

* All NC pins are internally connected

* Looking at the following waveform we can conclude that PRG select registers ($7efa/7efb/7efc) are in fact 6 bit wide (bits 5..0 are utilized, not 7..2 as wiki says) and this mapper supports up to 512 kB of PRG-ROM:. THe order of bit is
pin62 -> $7efa.0 (PRG-A13)
pin60 -> $7efa.1 (PRG-A14)
pin61 -> $7efa.2 (PRG-A15)
pin59 -> $7efa.3 (PRG-A16)
pin58 -> $7efa.4 (PRG-A17)
pin1 -> $7efa.5 (PRG-A18)


* Pin 55 (or 53) - seem to be delayed M2 (both edges are delayed ~100ns)
* Pin 54 - seem to be delayed M2 (only rising edge is delayed ~100ns)
I think that pin 53 (or 55) is an input used for generating chip enable to the internal RAM. They were concerned about the M2/PRG_CE delay that might cause RAM corruption so they did the delaying circuit internally and drove it outside for manual selection which will work better. (I separated shorted pins 55+53 to find which one is input and which output)



Edit: Yes - after connecting pin 53 to GND, PRG/CHR register works normally, but RAM is always disabled. This confiirms that pin 53 is used only for decoding RAM,

[lidnariq]

Any thoughts about the seeming nonfunctional /IRQ pin?

So ... how do we want to handle any oversize definition? We could enshrine a pin shuffling, and the PRG bank registers become [..DC BAFE]. This is ugly but the most transparent.

Or rewire the data bus and the CHR banking bus to the X1-017 and change the magic numbers to enable the RAM regions. ... I don't suppose one of the unknown pins happens to be the least significant bit written to $7EF0/7EF1 ?

Or rewire all six PRG banking registers out of the X1-017, and define 256KB or 512KB games to instead handle PRG banking without that initial bit shift... given that most games already came on a board that used a DIP28 PRG ROM where A13-A16 were not in the JEDEC order, this is probably nicest for hardware.

[krzysiobal]

Pin 34 is CHR_/CE (PPU_/RD or PPU_A13)

There is something weird with pins 56/46. WHen they're short, there is even more delayed (by half cycle) M2 on them:


But when I separate them, pin 46 is held HIGH and pin 56 is held LOW and mapper ignores writes to registers

If the IRQ is functional, there is probably some latch value for the counter and this should be used as a reference for correct data bus bit order. I'll check that.

[FrankWDoom]

Any thoughts about the seeming nonfunctional /IRQ pin?

So ... how do we want to handle any oversize definition? We could enshrine a pin shuffling, and the PRG bank registers become [..DC BAFE]. This is ugly but the most transparent.

Or rewire the data bus and the CHR banking bus to the X1-017 and change the magic numbers to enable the RAM regions. ... I don't suppose one of the unknown pins happens to be the least significant bit written to $7EF0/7EF1 ?

Or rewire all six PRG banking registers out of the X1-017, and define 256KB or 512KB games to instead handle PRG banking without that initial bit shift... given that most games already came on a board that used a DIP28 PRG ROM where A13-A16 were not in the JEDEC order, this is probably nicest for hardware.

When you say jedec order you mean the one typically used on 128K NES 28 pin mask roms? How likely is it that taito used roms with pinouts that are completely non standard? Couldn't it be they are standard roms and the address lines are mixed up? Bank numbers in the software are arbitrary and can be bit- ordered to match any pinout.

Do any of these carts use roms with identifiable part #s that could be used to find a datasheet? A known good reference point would help a bunch. I'm also curious how the cart with the 32 pin prg room is hooked up.

[lidnariq]

When you say jedec order you mean the one typically used on 128K NES 28 pin mask roms?

Yes. JEDEC standard 21C "figure 3.2.1-2 8K TO 128K BY 8 ROM IN DIP".

How likely is it that taito used roms with pinouts that are completely non standard?

It's impossible to determine that externally. The JEDEC standard doesn't specify how the external pins have to map to the internal data array anyway... And I suspect that the address pins aren't used in-order in the mask ROM inside anyway. I wouldn't be surprised in the X/Y selectors are A0-A6 on the X axis and the other lines in circumferential order are the Y axis. When making a mask ROM, all that matters is that the foundry puts the bits in the right place for what the end user expects the address lines to be.

I'm also curious how the cart with the 32 pin prg room is hooked up.

Well, BootGod has photos... http://bootgod.dyndns.org:7777/profile.php?id=3989

32-pin Mask ROM pin 28 (usu. PRG A13) connects to X1-017 pin 1 (what you called A16), which I think is the same reordering you named for the 28-pin ROMs.

But it ultimately doesn't matter how the four remaining address lines are shuffled. The problem is that for the four OEM games, they ignore the values written to the two LSbits of the existing registers.

Pin 34 is CHR_/CE (PPU_/RD or PPU_A13)

... There's no reason to think that PPU/RD or PPU A13 are used for anything else other than an OR gate here, right?

[krzysiobal]

There's no reason to think that PPU/RD or PPU A13 are used for anything else other than an OR gate here, right?

IRQ counter (if exists) might be clocked by PPU read cycles (as in Mapper 90)

[FrankWDoom]

So I'd like someone to double check but I think bit order for the prg register should be [..ABCDEF] with A=prg a13 and f=prg a18

I believe this order resolves the taito mask rom question as it puts the address lines for a13-a16 to the usual jedec pins. Again someone please verify. I compared ice man's diagram from this post http://forums.nesdev.com/viewtopic.php?p=246418#p246418 to a 28 pin datasheet that puts a16 on pin 22 and found his diagram just puts those 4 pins in reverse order.

[krzysiobal]

Pin45 = CHR_LO/CE (goes low when PPU_/RD=0 and PPU_A13=0 and CHR_A18 would be 0 for the actual CHR bank, else high
Pin44 = CHR_HI/CE (goes low when PPU_/RD=0 and PPU_A13=0 and CHR_A18 would be 1 for the actual CHR bank, else high
Those pins can be used if two DIL-28 128kB CHR-ROM chips with single /CE are used.

For example, if $7ef0 = $7ef2 = $7ef3 = $7ef4 = $7ef6 = $0, $7ef1 = $80 and we read the region $0000-$1fff, then we get:

[lidnariq]

So I'd like someone to double check but I think bit order for the prg register should be [..ABCDEF] with A=prg a13 and f=prg a18

I think you're absolutely right, but I don't know what to do about it. The existing dumps all assume bits in ascending order, not bit-reversed, and correcting the interpretation to the physical order of the ROM means deprecating and being completely incompatible with existing dumps. I don't even think submappers really solve the problem, because I'm under the impression that at least for legacy iNES mapper numbers, those are supposed to be used when things are close enough to at least sorta run when not differentiated by submapper.

There is something weird with pins 56/46. When they're short[ed], there is even more delayed (by [130ns]) M2 on them.
But when I separate them, pin 46 is held HIGH and pin 56 is held LOW

Any chance pin 56 is actually an open-drain output? Maybe that's how they implemented reset detection? And the RC aren't just a cold reset detection, but the capacitor is periodically drained by pin 56 during operation, and if the resistor ever pulls the pin high, pin 46 disables RAM access?

[NewRisingSun]

I don't even think submappers really solve the problem, because I'm under the impression that at least for legacy iNES mapper numbers, those are supposed to be used when things are close enough to at least sorta run when not differentiated by submapper.

Then just allocate a new mapper? Thanks to NES 2.0, we got enough of them.

LeaveiNES Mapper 082=Old incorrect layout, make new mapper number=New correct layout. The next free number on the "Asian plane" (assuming we're still following that --- I at least try) would be 552.

[FrankWDoom]

You could keep everything on the current # and leave it up to emu authors to revamp their implementations but I think that'll just make a mess of things.
A submapper is reasonable, I don't have any objection to that, but maybe more complicated than it needs to be.
Assigning a brand new mapper # and deprecating 82 might still be preferable. There are only the handful of games and they're rather obscure so it's not too big a task to manage.

Redumps will be needed in any case. I have one of the baseball carts coming this week. I have a copynes, I'll see if I can figure out how to modify the 82 script.

Does it look like the chr side has the same issue with reversed bit order? Or is it one of the standards?

[tepples]

Kyuukyoku Harikiri Stadium: Heisei Gannen Ban

"Harikiri"? "Gannen Ban"? Please tell me the title of this game doesn't translate to "commits seppuku in a ball park after making one too many terminology mistakes that hit the fandom's berserk button."

(just kidding)

[lidnariq]

A submapper is reasonable, I don't have any objection to that, but maybe more complicated than it needs to be.

Only acceptable if NES 2.0-unaware programs are allowed to completely fail on something with a nonzero submapper... which I think is discouraged?

Assigning a brand new mapper # and deprecating 82 might still be preferable.

I'm just kind of wary of assigning a new mapper number when the current definition correctly (if not pedantically) handles the existing four games. The only reason to need a corrected definition is to handle oversize ROM hacks...

So I'm left between two choices and I'm not happy with either of them

* Define an ugly out-of-order oversize definition as part of mapper 82 ([..DC BAFE])
* Define a brand new mapper that is entirely redundant to handle the exact same four existing games, because the thread-starting translation is incompatible with this corrected definition of the mapper also.

Redumps will be needed in any case.

I mean, fixing the bit-reversing isn't hard. No need to redump them. It's just that doing any kind of math on bit-reversed numbers is a pain in both 6502 and higher level languages.

Does it look like the chr side has the same issue with reversed bit order? Or is it one of the standards?

Looks fully standard.

[krzysiobal]

I got the IRQ mechanism to work:

Code: Select all

$7efd:
[VVVVVVV] 
 |||||||
 +++++++-- reload value

7efe:
[.....?IE]
      |||
      ||+- 1-enable counting, dont modify counter
      ||   0-disable counting and set counter to ($7efd == 0) ? 17 : (($7efd + 2) * 16)
      |+-- 1-enable IRQs, 0-disable IRQs
      +--  this bit must be either also 1 to enable counting or it set clock source to
           something other. however I wasn't able to make clocking work when it was
		   other than 1 (even if I toggled PPU_A12/PPU_/RD/PPU_A13)
	  
7eff:
[........] - writing any value clears the IRQ pending flag and sets the counter to ($7efd == 0) ? 1 : ((($7efd + 1) * 16))
        
On every cpu cycle, if counting is enabled, counter is decreased. If it reaches 0, IRQ pending flag is set.
Can't tell if the counter wraps and still clocks, because acking IQR by writing to 7eff modifies counter value

IRQ is asserted asynchronicaly if both IRQ pending flag is set and I bit is set, for example:
$7efd <= 0x2
$7efe <= 0
$7eff <= 0
$7efe <= 1
now do at least 64 CPU clocks, /IRQ line will be still high after that. But writing $7efe <= 2 make it go instantly low.
Next write of 0 to $7efe will make /IRQ go high, but again write $7efe <= 2 will make it low, etc.

[NewRisingSun]

So I'm left between two choices and I'm not happy with either of them

A third option would be to redefine mapper 82 completely and simply declare the dumps that follow the old specification to be bad. It would be a bit heavy-handed, but it's only four games, so I suppose it would be tolerable? It would not be the first time that such a thing has happened in the 20+ years of NES emulation.

My preference order would be (best to worst):
1. Assign new mapper and deprecate #82. Cost: a bit of redundancy.
2. Assign submapper for #82. Cost: Dumps for it will be completely incompatible with submapper 0, which goes against the intent of the submapper feature.
3. Redefine mapper 82. Cost: The four existing game dumps become "bad" dumps.
4. Leave #82 as-is and add crazy oversize definition. Cost: messiness.
I like 1 best because it combines a clean definition with compatibility. I have no problem with redundancy if it exists for a good purpose. I agree that a ROM conversion utility could be easily written; I can write one if nobody else wants to have already written one in case any solution other than 4 finds approval.