nesdev.org

Posted: **Fri Jan 31, 2020 11:06 am**

[..DC BAFE] -> [FEDC BAFE]

1, ignore the lower 2 bits
2, ignore the higher 2 bits

that's why iceman can only dump 128K of full 512K

prg_a_out[18:13] <= {prg_d_in[7:6] | prg_d_in[1:0], prg_d_in[5:2]}

on real cart, prg data bus is strongly pulled down to GND by X1-017 chip, so it is reliable: prg_d_in[7:6] OR prg_d_in[1:0]

Posted: **Fri Jan 31, 2020 11:34 am**

So how should I rewire a 256K PRG?

Posted: **Fri Jan 31, 2020 12:17 pm**

NewRisingSun wrote: ↑Fri Jan 31, 2020 4:58 am 1. Assign new mapper and deprecate #82. Cost: a bit of redundancy.

Probably actually the best choice.

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.

I don't see any advantage of #2 over #1.

3. Redefine mapper 82. Cost: The four existing game dumps become "bad" dumps.

Don't really see any utility in this. As you pointed out, saving a mapper number when we have 4000 and haven't yet used 500 of them yet is premature optimiation.

4. Leave #82 as-is and add crazy oversize definition. Cost: messiness.

I only like this option because it's backwards compatible. But because they're not in order, it's not obvious to anyone ROM hacking, e.g. aishsha, that the bits are out of order unless they specifically like reading our wiki or emulator source.

I mean, I have two concerns.
1 is that bit-reversing is obnoxious and stupid, and yet what they did. To the original developer, the bank number is a magic number, and for any given project that's fitting into a fixed size number of banks, it doesn't matter whether they think of the number as "normal" or "bit-reversed". To an emulator author, regardless of whether it's PowerPak or Everdrive or something written in some higher-level language on a conventional computer, supporting this bit-reversing ranges from "just add an abstraction" to "use a look-up table".

This isn't really any different from the mapper 87 vs mapper 101 mess, except that there the bit-reversed definition was found first.

2 is that there's literally no PRG size variation in the games that use mapper 82. We have no existing hardware that relies on the corrected interpretation, and so it falls awry of my rule of "don't allocate mappers do hardware that doesn't exist". Yes, I'm aware that pedantically it does exist, except that to me doubly-bit-reversed doesn't count as "wrong".

We probably should go ahead with your option #1; I'm just unhappy with all of the choices.

aquasnake wrote: ↑Fri Jan 31, 2020 11:06 am [..DC BAFE] -> [FEDC BAFE]
[...]
prg_a_out[18:13] <= {prg_d_in[7:6] | prg_d_in[1:0], prg_d_in[5:2]}

on real cart, prg data bus is strongly pulled down to GND by X1-017 chip, so it is reliable: prg_d_in[7:6] OR prg_d_in[1:0]

I don't understand how this solves the problem? The 2A03 overpowers the pull-downs at the moment of writing, so the OR behavior is irrelevant.
The hardware can only pay attention to one bit or the other, so it'd be necessary that the emulator require that the user write the same bits in both the 2MSbits and 2LSbits, not just OR or AND behavior.

gorgyrip wrote: ↑Fri Jan 31, 2020 11:34 am So how should I rewire a 256K PRG?

Right now, you don't. The existing 256KB translation relies on a definition that's incompatible with the existing hardware. You'll have to add several extra parts: viewtopic.php?p=246438#p246438

Posted: **Fri Jan 31, 2020 12:27 pm**

gorgyrip wrote: ↑Fri Jan 31, 2020 11:34 am So how should I rewire a 256K PRG?

Right now, you don't. The existing 256KB translation relies on a definition that's incompatible with the existing hardware. You'll have to add several extra parts: viewtopic.php?p=246438#p246438
[/quote]
Thank you for your answer. I'll wait for the 74's to arrive.

Posted: **Fri Jan 31, 2020 12:37 pm**

if(prg_d_in[7:6]) prg_a_out [18:13] = prg_d_in[7:2];
else if(prg_d_in[1:0]) prg_a_out [18:13] = {prg_d_in[1:0], prg_d_in[5:2]};
else prg_a_out [18:13] = {2'b00, prg_d_in[5:2]};

maybe it is more comprehended above

but i perfer prg_a_out [18:13] = {prg_d_in[7:6] | prg_d_in[1:0], prg_d_in[5:2]} on real hardware

when writing the register, keep the high 2-bits equl to the low 2-bits

for some kind of reason, if producing a cart that does not wire prg_d_in[7:6] or prg_d_in[1:0] to the mapper chip, it is necessary to pull the unconnected bit(s) of data bus down to ground(maybe 4.7~10k) on the mapper side. but for emulators on PC, the data bus is considered being tied all 8 bits always and must have a default value to 0

Posted: **Fri Jan 31, 2020 12:46 pm**

lidnariq wrote: ↑Thu Jan 30, 2020 8:23 pm 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?

You're genius. I should've cut it like on the left, not on the right.

Now (1=M2, 2=pin56+R+C) it indeed acts like a reset. But it rises up to 4V and it would trigger reset on every clock edge

Anyway, when I wre pin 46 to VCC, it still allows me to access RAM. I'm wondering if it's just write protection, not read protection.

-

I did more testing to the VBatteryBackup (pin 48), VBattery(pin 49) and Test Pad 2 (pin 50)
* Test Pad 2 is output pin: driven by 5V when the cartridge is powered from console (VbatteryBackup > Vbattery) is at 0v when the the cartridge is powered only by internal battery (VbatteryBackup < Vbattery). Probably it is a testing pad to check either if memory correctly switches to low-power mode or is it protected against writes when in battery backup mode.
* When the pin 49 is connected to the battery, chip sinks unmeasureable current rom battery through pin 48 (there is <0.01mV drop on serial 1k resistor meaning < 0.01mA)
* If pin 49 is disconnected from battery, pin 48 starts to sink 1.6mA from battery (maybe now chip thinks it is connected to non-battery supply)

Posted: **Fri Jan 31, 2020 12:55 pm**

lidnariq wrote:We probably should go ahead with your option #1; I'm just unhappy with all of the choices.

I will wait for a few more comments, and if there are none, go ahead with assigning NES 2.0 mapper 552 next week. In the meantime, here is my ROM conversion utility.

Edit: New version uploaded in a later post.

Posted: **Fri Jan 31, 2020 5:05 pm**

krzysiobal wrote: ↑Fri Jan 31, 2020 12:46 pm Now (1=M2, 2=pin56+R+C) it indeed acts like a reset. But it rises up to 4V and it would trigger reset on every clock edge

Maybe it isn't a reset pulse then. Especially given 1kΩ·150pF=150ns... How does the phase of pin 56 compare to the phase of pin 55/54/53 ? Maybe it's how the amount of delay is controlled?

krzysiobal wrote: ↑Fri Jan 31, 2020 12:46 pm (there is <0.01mV drop on serial 1k resistor meaning < 0.01mA)

A diode would be a good way to measure things with a wide dynamic range of currents. On the other hand, I don't think we really care about the quiescent current of the RAM inside...

aquasnake wrote: ↑Fri Jan 31, 2020 12:37 pm but i prefer prg_a_out [18:13] = {prg_d_in[7:6] | prg_d_in[1:0], prg_d_in[5:2]} on real hardware

The problem is that you're trying to be compatible here, but that's explicitly the opposite of what I want. Mapper 82 is only defined by the original X1-017 hardware, and the original hardware doesn't do this. An emulator—including an implementation in a CPLD—that supports this in order to be compatible with the 256KB translation just enables people to continue making things that don't correspond to physical hardware.

krzysiobal wrote: ↑Fri Jan 31, 2020 2:49 am I got the IRQ mechanism to work:

Awesome!

Too bad the upper bound is 4112 M2—that's only 36 scanlines. I suppose that's why the existing games didn't bother to use it.

NewRisingSun wrote: ↑Fri Jan 31, 2020 4:58 am Leave #82 as-is and add crazy oversize definition. Cost: messiness.

Stupid question: How does the implementation of [..AB CDEF] differ in messiness from the implementation of [..DC BAEF]? The bit-twiddling tricks here can be easily generalized to handle portions that should remain in order and portions that shouldn't.

Posted: **Sat Feb 01, 2020 12:39 am**

lidnariq wrote:How does the implementation of [..AB CDEF] differ in messiness from the implementation of [..DC BAEF]?

I consider [..DCBAFE] to be messy because the bits are no longer contiguous, and [..DC BAEF] to be even messier because the bits are partially reversed and partially not. If by "messier", you only mean the number of bit shift operations, then the correct bit order would be the "messiest" of all:

Code: Select all

case 0x7EFA: case 0x7EFB: case 0x7EFC:
	if (ROM->INES_MapperNum ==82)
		prg[addr -0x7EFA] =val >>2 &0x0F | val <<4 &0x30; // [..DCBAFE]
	else	// mapper 552
		prg[addr -0x7EFA] =val >>5 &0x01 | val >>3 &0x02 | val >>1 &0x04 | val <<1 &0x08 | val <<3 &0x10 | val <<5 &0x20;

Posted: **Sun Feb 02, 2020 3:39 am**

Here is a comparision of M2(CH1), pin 56(CHR2), pin55 (CH3), pin54 (CHR4).

Pin 46 must be some kind of RAM+WE because when tied to GND, I wasnt able to modify any of RAM cells.
But there is something super crazy with the writing. I put the game in console and allow it to initialize the RAM. Then I put it into kazzo, wrote $ca to $6fe7 and read $6000-$67ff for the first time, second time and third time. 1st and 2nd reads differ, but 2nd and 3rd were the same. They differed on two positions - $6000 and $6400. It looked like value at $6000 is copy of what is at $63ff and at $6400 is copy of $67ff. I disconnected the Kazzo, connected it again and reads from $6000-$67ff were still the same as 2nd and 3rd.

I repeat the whole procedure again - put the cartridge in console, run game, then put it into kazzo and the result were the same as described above.
Moreover, In Kazzo I was not able to write anything at cells $6000 and $6400 - the value in them was always the copy of $63ff and $67ff. Plus the writes in Kazzo to RAM are very unreliable.

Posted: **Sun Feb 02, 2020 11:59 am**

Maybe pin 46 is a clock input to trigger writes?

Actually, 5KB of RAM is kinda weird. It's not a square number of bits. (Neither is 1KB).

I wonder if there are multiple silicon dice inside... maybe that's why Vcc and Gnd connect to the package in multiple places?

Posted: **Sun Feb 02, 2020 2:45 pm**

lidnariq wrote: ↑Sun Feb 02, 2020 11:59 am Maybe pin 46 is a clock input to trigger writes?

No, this pin can be tied to VCC and writes still work.
I found out why the writes were unreliable - it turns out that the X1-017 latches the data to be written to RAM somewhere between 200ns and 262ns after rising edge of M2, but for sure not on rising nor falling edge (even if pins 53/46 are tied to VCC)
When I setup data to be written before M2 rises, it started to work.

RAM now works fine, except cells $6000, $6400, $6800, $6c00, $7000. It looks like they're somewhat special - they're not writable.
Reading value of cell $6000 return last read (or written - whatever was last) value from the range $6000-$63ff
$6400 -> $6400-$67ff
$6800 -> $6800-$6bff
$6c00 -> $6c00-$6fff
$7000 -> $7000-$73ff

I wonder if there are multiple silicon dice inside... maybe that's why Vcc and Gnd connect to the package in multiple places?

I'll desolder one of the VCC legs and check the internal connection to other one.

Also, the exact timing measurements:
pin 55 - Rising edge delayed of 71ns after rising of m2, falling edge delayed of 78ns
pin 54 - Rising edge delayed of 37ns after rising of m2, falling edge delayed of 40ns

Posted: **Sun Feb 02, 2020 8:38 pm**

NewRisingSun wrote: ↑Fri Jan 31, 2020 12:55 pm here is my ROM conversion utility.

Works fine for 128KB prg, but not for 256KB.
There is no sense to change a17 address bit, because its on the place already. Anyway we don't have original 256KB prg roms, and custom rom will not work without patch.
Just tried to use your tool to make correct bank order before flashing translation of sd keiji blader.(with changed bank switching subroutine).

Posted: **Sun Feb 02, 2020 9:33 pm**

Have you already patched the translation to write the necessarily different bank numbers?

Posted: **Sun Feb 02, 2020 11:22 pm**

pakosup wrote:Works fine for 128KB prg, but not for 256KB.

Of course not; there is no finalized definition on what an oversize 256 KiB mapper 82 ROM would look like, so I don't know how to convert that. Current NintendulatorNRS supports mapper 552 with the correct [..ABCDEF] bank order, if you need something to test with.

nesdev.org

X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing

Re: X1-017 testing