It is currently Mon Aug 19, 2019 2:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Jul 01, 2019 12:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8532
Location: Seattle
NewRisingSun wrote:
Edit: On second thought, I don't think it's explicit bankswitching, but instead the CHR-RAM is just getting the same lower address lines as the CHR-ROM, so different "cmds" just implicitly select different sections of the 32 KiB CHR-RAM.
Yeah, exactly that.

Given that you say commands $80 and $82 both had your signature, that implies that CHR A13 isn't connected to the RAM. Given that they used an 8 KiB RAM for PRG, I wonder why they placed a 32 KiB RAM for CHR when the PCB could never address more than 8KiB...

Looking at the patterns in the bits corresponding to which windows are which:
Code:
$80 $82 $88 $8A $C0 $C2 $C8 -- ?$ca?
$28 $00 $4C $64 $46 $7C $0A
 0   0  $40 $40 $40 $40  0  --  0?
$20  0   0  $20  0  $20  0  --  $20?
 0   0   0   0   0  $10  0  -- ?????
 8   0   8   0   0   8   8  --  0?
 0   0   4   4   4   4   0  --  0?
d/c d/c d/c d/c  2   0   2  --  0?
it implies that $CA "should" cause CHR RAM to be at either banks $20 and $21 or maybe banks $30 and $31. But obviously you found it doesn't.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 12:48 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 960
Yes, I re-checked both the dumping script that also writes the cmd values and the dumps themselves. CA dumps are identical to 90/B0/D0/F0 dumps.
lidnariq wrote:
But A14 is tied to +5V
lidnariq wrote:
that implies that CHR A13 isn't connected to the RAM
What does that mean for the CHR-RAM size in the NES 2.0 header? Does it denote 32 KiB because a 32 KiB chip is mounted, and the connection is considered part of the mapper definition, or does it denote 8 KiB because only 8 KiB are accessible?


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 1:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8532
Location: Seattle
Personally, I'd say it implies 8 KiB in the header...


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 5:41 pm 
Offline
User avatar

Joined: Mon Sep 05, 2011 5:56 pm
Posts: 295
Many years ago, i have dumped this cartridge.
here is the core code(chrram and chr rom) for vnes:
Code:
      //chr banks not 100% test.
      case 0xB000: c[0] =(V&0x0F)>>0;break;
      case 0xB400: c[0]|=(V&0x1F)<<4;break;
      case 0xB800: c[1] =(V&0x0F)>>0;break;
      case 0xBC00: c[1]|=(V&0x1F)<<4;break;
      case 0xC000: c[2] =(V&0x0F)>>0;break;
      case 0xC400: c[2]|=(V&0x1F)<<4;break;
      case 0xC800: c[3] =(V&0x0F)>>0;break;
      case 0xCC00: c[3]|=(V&0x1F)<<4;break;
      case 0xD000: c[4] =(V&0x0F)>>0;break;
      case 0xD400: c[4]|=(V&0x1F)<<4;break;
      case 0xD800: c[5] =(V&0x0F)>>0;break;
      case 0xDC00: c[5]|=(V&0x1F)<<4;break;
      case 0xE000: c[6] =(V&0x0F)>>0;break;
      case 0xE400: c[6]|=(V&0x1F)<<4;break;
      case 0xE800: c[7] =(V&0x0F)>>0;break;
      case 0xEC00: c[7]|=(V&0x1F)<<4;break;

and the chr-ram code:
Code:
   for(int i=0; i<8; i++)
   {
      if( ((c[i]&0x7E)==0x7C)&&(i<2) )////for test,not 100% sure
         SetCRAM_1K_Bank( i,c[i]&1);
      else if( ( (chr_reg[4]&6)==4 )&&((i==4)||(i==5)))////for test,not 100% sure
         SetCRAM_1K_Bank( i,c[i]&1);
      else
         SetVROM_1K_Bank(i,c[i]&0x1FF);
   }


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 5:55 pm 
Offline
User avatar

Joined: Mon Sep 05, 2011 5:56 pm
Posts: 295
lidnariq wrote:
One thing I find a little weird... In the picture "DuShenBack", the CHR RAM there appears to be a 256kibit (part number KM68257?). But A14 is tied to +5V, I can't see what happens with A13, and A12 connects to CHR ROM A12. So even though only 4 KiB of CHR RAM can be used to draw tiles on any given vertical refresh, it seems like at least 8 KiB can be stored, and the game could switch between different 4 KiB windows without having to reload tiles.

Only 64Kbits used.
sometime 256Kbits sram is cheaper than 64Kbit.


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 4:35 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 525
Location: Poland
I was thinking for a long time what chips they used for the PRG-ROM and CHR-ROM. Solving that could reveal how they routed the tracks underneath and which signals go to PALs. They definitely weren't blobs cause there weren't a empty (non-via) area in the center, so they must be TSOP chips.

My first candidate was 28f008 (found in ASDER PC-95 korean version).
Image
But the pinout wasn't really fitting it well.
Image

Neither the regular 29f040 did:
Image

And then desperately looking at previous cartridges that I analyzed I found 28f032 (in `Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)` or `Genuine Monkey`)
Image

This was a milestone, cause CHR-A18 was exactly needed in that place:
Image.

After that I was able to completely finish tracing the PCB and improve my previous ideas:
Image Image Image

* VRC4 has its A13 and A14 connected directly to CPU-A13 and CPU-A14, making it behave normally
* 74174 latches D0..D5
* D0..D3 are connected to 74157 which multiplexes PRG-A13..A16 between those from VRC and 74174
* D4 is connected to P_1 which does the same
* D5 is not connected to anything
* VRC4 x=PPU_A13, y=PPU_!RD, z=CHR_!CE are used like OR gate (z = x || y).
* This OR gate is wired as following: x = CPU_A2, y = VRC-PIN18, z = 74174's clock, so that the 74174 sits at $9C00 (mask: $9C04)
* VRC4 does not control mirroring, this is the role of P_1. Its four disconnected pins would suggest that they contain latched D0 for the four nametables:
Code:
                P_1
             .---v---.
   CPU_A0 -> |01   20| -- VCC
   CPU_A1 -> |02   19| -> PRG_ROM_A17
   CPU_A2 -> |03   18| -> BANK_nREG/VRC
  CPU_A13 -> |04   17| <- REG_D4
  CPU_A14 -> |05   16|
VRC_PIN18 -> |06   15|
   CPU_D0 -> |07   14|
  PPU_A10 -> |08   13|
  PPU_A11 -> |09   12| -> CIRAM_A10
      GND -- |10   11| <- VRC_PRG_A17
             +-------+


* Because $9c00.0 is already used for banking register, nametable regs sits at $9c04.0-$9c07.0 (mask: $9C04)

That would make the PAL equations like:
Code:
PIN13 <- CPU_D0 when VRC_PIN18 = 0 and CPU_A2 = 1 and CPU_A1 = 0 and CPU_A0 = 0 --latch

PIN14 <- CPU_D0 when VRC_PIN18 = 0 and CPU_A2 = 1 and CPU_A1 = 0 and CPU_A0 = 1 --latch

PIN15 <- CPU_D0 when VRC_PIN18 = 0 and CPU_A2 = 1 and CPU_A1 = 1 and CPU_A0 = 0 --latch

PIN16 <- CPU_D0 when VRC_PIN18 = 0 and CPU_A2 = 1 and CPU_A1 = 1 and CPU_A0 = 1 --latch

CIRAM_A10 <= PIN13 when PPU_A11 = 0 and PPU_A10 = 0 else
             PIN14 when PPU_A11 = 0 and PPU_A10 = 1 else
          PIN15 when PPU_A11 = 1 and PPU_A10 = 0 else
          PIN16

BANK_nREG/VRC <= 0 when CPU_A14 = 1 and CPU_A13 = 0 else 1
PRG_ROM_A17 <= REG_D4 when CPU_A14 = 1 and CPU_A13 = 0 else VRC_A17


Code:
  +--------------------------------+
  |               P_2              |
  |            .---v---.           |
  +----------> |01   20| -- VCC    |
VRC_CHR_A11 -> |02   19| -> -------+
VRC_CHR_A12 -> |03   18| -> CHR-RAM-!CE
VRC_CHR_A13 -> |04   17| <- CHR-ROM-!CE
VRC_CHR_A14 -> |05   16|
VRC_CHR_A15 -> |06   15|
VRC_CHR_A16 -> |07   14|
VRC_CHR_A17 -> |08   13|
    PPU_!WE -> |09   12| <- PPU_A13
        GND -- |10   11| -- GND
               +-------+


* Four not-connected pins (13-16) suggest that only four bits out of A17_A11 are latched (A10 and A18 is not taken into account at all)
* Probably PIN_19 <= 0 when PPU_A13 or PPU_!WE so that only writes to $0000-$1fff are treated as bank change


* I have no idea why P_2.pin11 is tied to GND

* the thick trace at P_1.pin17 suggested me that it was VCC signal, but I believe this was just a mistake with the thickness.
Image


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 9:45 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 960
zxbdragon kindly tested all the GAL commands on the FS306 for me. All commands except $C8 are identical to the FS303's GAL. Command $C8, which on the FS303 selected CHR banks $0A+$0B, selects CHR banks $04+$05 on the FS306.

I have assigned NES 2.0 Mapper 544 to FS306.

Many thanks to Krzysiobal+lidnariq for PCB tracing and comments, and zxbdragon+MLX for dumping and CHR bank experimentation.


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 12:20 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8532
Location: Seattle
krzysiobal wrote:
I have no idea why P_2.pin11 is tied to GND
The only way to use the 16V8's D-flip-flops is to have both pin 1 as the global register clock signal and pin 11 is the global register /OE signal. So-called "Registered" mode.

For whatever reason, although someone could still implement transparent latches using the feedback paths in "Simple" or "Complex" modes, people just generally didn't.



NewRisingSun: You were disappointed earlier when krzysiobal pointed out that the PCB photos only have 2 KiB of CHR RAM. Does that pose any problems, or does it work out?


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 12:46 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 960
It works out; I was just surprised that a GAL would allocate four CHR banks to 2 KiB of CHR-RAM in some configurations that the game actually uses.

I think the VRC4's pin 18 functionality should be described on the wiki, since it is being used by this mapper. I am not sure how to describe it --- the $9C00 register reminds me of the AY-8910's "general purpose I/O port", so pin 18 would be "General Purpose I/O Chip Select"?


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 1:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8532
Location: Seattle
As I said then, I'd first want someone to check whether that is something present in the original VRC4 - and our documentation is inadequate - or whether it's something added later.


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 1:44 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 160
lidnariq wrote:
For whatever reason, although someone could still implement transparent latches using the feedback paths in "Simple" or "Complex" modes, people just generally didn't.


Suppose one wants to design a latch that will hold its value if LatchEnable is low, or copy the state of D0, D1, D2, or D3 based upon two select inputs. If one were using a registered output, that would require four product terms. To get reliable results using a combinatorial output would require nine. Not only would one need product terms:
Code:
- /LatchEnable & CurrentOutput
- LatchEnable & /Sel0 & /Sel1 & D0
- LatchEnable &  Sel0 & /Sel1 & D1
- LatchEnable & /Sel0 &  Sel1 & D2
- LatchEnable &  Sel0 &  Sel1 & D3

but one would also need
Code:
- CurrentOutput & /Sel0 & /Sel1 & D0
- CurrentOutput &  Sel0 & /Sel1 & D1
- CurrentOutput & /Sel0 &  Sel1 & D2
- CurrentOutput &  Sel0 &  Sel1 & D3

If one is using tools that would recognize the last four product terms as redundant and eliminate them, the resulting PLD might usually work, but fail to do so reliably.


Top
 Profile  
 
PostPosted: Tue Jul 02, 2019 5:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8532
Location: Seattle
supercat wrote:
but one would also need
You're right that there's a hazard from the moment that neither LatchEnable nor /LatchEnable is true — and I have no idea whether the the structure of any given PAL allows that — but your example seems to be illustrating the worst case for a transparent latch and best case for a registered design. Only because no values are retained across the ↑clock signal is it the case that N AND rows are sufficient; a transparent latch requires keeping track of the old state for hazard prevention and so needs 2N+1 rows.

But an addressable latch, like used on the mirroring control PAL here, needs multiple AND rows in the first place (at least one for retention, at least one for inputting the new value) and adding the hazard prevention for a design with a transparent latch only adds one AND row.


Top
 Profile  
 
PostPosted: Thu Jul 04, 2019 3:47 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 525
Location: Poland
I've analyzed the DuShen PCB - the GAL pinout seems to be the same like P_2.
Blob pinout matches exactly MMC3 (they even routed RAM+CE out of blob, which is connected only to test pad)

Image Image Image

I ordered one genuine VRC4 game to check if pin 18 has the same function there as in pirate one.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 6 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