It is currently Wed Aug 21, 2019 12:52 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Mon Mar 21, 2016 3:40 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
Might try that.

Also, I forgot to add. It ONLY works on NOAC clones.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 5:59 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 972
lidnariq wrote:
Code:
            +--v--+
 /ROMSEL -> |01 20| -- Vcc
 CPU A14 -> |02 19| -> PRG RAM /CE
 CPU A13 -> |03 18| -> 74'670 /WE (PRG)
 CPU A12 -> |04 17| -> 74'670 /WE (CHR)
 CPU A11 -> |05 16| <- CPU M2
 CPU A10 -> |06 15| -> SRAM R/W
  CPU A9 -> |07 14| <- CPU A4 (PRG ROM A5)
  CPU A8 -> |08 13| <- CPU A5 (PRG ROM A8)
  CPU A7 -> |09 12| -> 74'670 /RE (PRG)
     Gnd -- |10 11| <- CPU A6
            +-----+

Some ideas...

M2 - Rather unlikely: Some carts seem to detect reset by measuring inactivity on M2 (aka PHI2), but I don't see how the hardware on the PCB could do that... it would require something to detect if M2 is inactive for a "longer period", ie. some kind of timer or capacitor.
Anyways, let's say it could somehow do that: Then the next problem would be that the 74670's don't have any reset-input, but resetting that work nethertheless: The GAL could issue a /WE=LOW signal to 74670's (and hope/assume that console does output D0-D7 all HIGH during reset; which might differ on real Famicom vs Famiclone).
But that idea wouldn't explain why the GAL outputs the /RE signal (apart from probably being unable to sense M2 inactivity).

/RE - More likely: /RE might get HIGH any time when reading from an address higher than FFC0h (the Reset code and reset vector are all located at FFD0h..FFFFh). So /RE wouldn't restricted to boot-up time, but would also keep affecting the memory mapping after booting (eg. if the game would fetch the IRQ vector from FFFEh; it doesn't use IRQs, and thus doesn't ever so though).
If you have some cartridge-dumping hardware (and can modify the dumping software): You could check if it's forcing FFC0h..FFFFh to be mapped to a fixed bank: There are four 8K ROM windows, the first three windows (at 8000h-DFFFh should allow to read the "plain" ROM content, but trying to read from the fourth window at E000h-FFFFh should always map the same data in last 40h bytes of each 8K bank).

For the 74640's open-bus outputs when /RE=HIGH. I've never seen an open-bus or HighZ signal being 2V, from my experiences open bus stuff is either a clean HIGH or a clean LOW level most of the time. The main problem might be raising edges being quite slow (not immediately reaching HIGH levels on LOW-to-open-bus transitions).
So the cartridge might require the console to output address FFC0h..FFFFh before and during booting. If a real Famicom outputs 0000h during Reset, then it might fail. And if the CPU should happen to output 'wrong' address values during executing the bootcode at FFD0h and up, then it might fail, too. I've never cared too much what the NES is doing in such cases - could it change the address levels on internal-opcode cycles? Or change the address levels for a few nanoseconds on gaps between opcode cycles?

Anyways, I would suggest to add pull-ups to 74670's outputs, too. Or did you already do that? Something like 10Kohm should be fine, or try 3.3Kohm if you want to be more aggressive and make sure that you get fast rising edges.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 6:06 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
Thanks for all the help. I will test pull-up resistors later.

As for dumping software. I have a Kazzo Dumper but no script for mapper 246 yet.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 6:30 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 972
The PRG ROM is 512Kbyte with 64 banks of 8Kbyte, so six resistors should do it (or just to be sure not to use the wrong pins: simply use 8 resistors, wired to all PRG bank outputs).

Dumper with scripts sounds as if it could be used to test if it's doing that special mapping for address FFC0h-FFFFh. Is there anybody familar with that script stuff?

One script (for dumping through the upper 8K window) should do this:
For i=0 to 3Fh: [6003h]=i, dump [E000h..FFFFh], next i
and another script (for dumping through another 8K window) should do this:
For i=0 to 3Fh: [6000h]=i, dump [8000h..9FFFh], next i
then use some filecompare utility to see if the output is same/different.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 7:40 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
Here's an example script of NROM (Mapper 0):
Code:
board <- {
mappernum = 0,
cpu_romsize = 0x8000, cpu_banksize = 0x4000,
ppu_romsize = 0x2000, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump (d, pagesize, banksize)
{
cpu_read (d, 0x8000, 0x4000);
cpu_read (d, 0xc000, 0x4000);
}
function ppu_dump (d, pagesize, banksize)
{
ppu_read (d, 0, banksize);
}


Or more complex MMC3 (Mapper 4):
Code:
board <- {
   mappernum = 4, vram_mirrorfind = false, ppu_ramfind = true,
   cpu_rom = {
      size_base = 2 * mega, size_max = 4 * mega,
      banksize = 0x2000,
   },
   cpu_ram = {
      size_base = 0x2000, size_max = 0x2000,
      banksize = 0x2000,
   },
   ppu_rom = {
      size_base = 2 * mega, size_max = 2 * mega,
      banksize = 0x0400
   }
};

function cpu_dump(d, pagesize, banksize)
{
   cpu_write(d, 0xa001, 0); //disable W-RAM
   for(local i = 0; i < pagesize - 2; i += 2){
      cpu_write(d, 0x8000, 6);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 7);
      cpu_write(d, 0x8001, i | 1);
      cpu_read(d, 0x8000, banksize * 2);
   }
   cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i+=4){
      cpu_write(d, 0x8000, 2);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 3);
      cpu_write(d, 0x8001, i | 1);
      cpu_write(d, 0x8000, 4);
      cpu_write(d, 0x8001, i | 2);
      cpu_write(d, 0x8000, 5);
      cpu_write(d, 0x8001, i | 3);
      ppu_read(d, 0x1000, banksize * 4);
   }
}

/*
http://nesdevwiki.org/wiki/MMC3
 PRG RAM protect ($A001-$BFFF, odd)
7  bit  0
---- ----
RWxx xxxx
||
|+-------- Write protection (0: allow writes; 1: deny writes)
+--------- Chip enable (0: disable chip; 1: enable chip)
*/
function cpu_ram_access(d, pagesize, banksize)
{
   cpu_write(d, 0xa001, 0x80);
   cpu_ramrw(d, 0x6000, banksize);
   cpu_write(d, 0xa001, 0x40);
}

/*
CPU memory bank for T*ROM
cpu address|rom address    |page|task
$8000-$9fff|0x02000-0x03fff|1   |write 0x2aaa
$a000-$bfff|n * 0x2000     |n   |write area
$c000-$ffff|0x7c000-0x7ffff|fix |write 0x5555, boot area

PPU memory bank for TLROM TKROM TKSROM
ppu address|rom address    |page|task
$0000-$07ff|0x02800-0x02fff|0x0a|write 0x2aaa
$0800-$0fff|0x05000-0x057ff|0x14|write 0x5555
$1000-$1fff|n * 0x1000     |n   |write area
*/
function program_initalize(d, cpu_banksize, ppu_banksize)
{
   cpu_write(d, 0xa001, 0); //disable W-RAM

   cpu_command(d, 0x0000, 0xa000, cpu_banksize);
   cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
   cpu_command(d, 0x5555, 0xc000, 0x4000);
   cpu_write(d, 0x8000, 7);
   cpu_write(d, 0x8001, 0);
   cpu_write(d, 0x8000, 6);
   cpu_write(d, 0x8001, 1);

   ppu_command(d, 0x0000, 0x1000, ppu_banksize);
   ppu_command(d, 0x2aaa, 0x0000, 0x0800);
   ppu_command(d, 0x5555, 0x0800, 0x0800);
   cpu_write(d, 0x8000, 2);
   cpu_write(d, 0x8001, 0);
   cpu_write(d, 0x8000, 0);
   cpu_write(d, 0x8001, 0x0a);
   cpu_write(d, 0x8000, 1);
   cpu_write(d, 0x8001, 0x14);
}

function cpu_transfer(d, start, end, cpu_banksize)
{
   for(local i = start; i < end - 2; i += 1){
      cpu_write(d, 0x8000, 7);
      cpu_write(d, 0x8001, i);
      cpu_program(d, 0xa000, cpu_banksize);
   }
   cpu_program(d, 0xc000, cpu_banksize * 2)
}

function ppu_transfer(d, start, end, ppu_banksize)
{
   for(local i = start; i < end; i += 4){
      cpu_write(d, 0x8000, 2);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 3);
      cpu_write(d, 0x8001, i | 1);
      cpu_write(d, 0x8000, 4);
      cpu_write(d, 0x8001, i | 2);
      cpu_write(d, 0x8000, 5);
      cpu_write(d, 0x8001, i | 3);
      ppu_program(d, 0x1000, ppu_banksize * 4);
   }
}


And last not least a 63in1 script:
Code:
board <- {
    mappernum = 130, //Need to convert to UNIF format with BMC-Ghostbusters63in1
    cpu_romsize = 0x180000, cpu_banksize = 0x8000,
    ppu_romsize = 0, ppu_banksize = 0x2000,
    ppu_ramfind = false, vram_mirrorfind = false
};

function cpu_dump(d, pagesize, banksize)
{
    // ROM Chip. Only 0, 2 and 3 are used
    for(local chip = 0; chip < 4; chip += 1){
        if (chip != 1) {
            // High bit for ROM chip select
            cpu_write(d, 0x8001, chip >> 1);

            // Bank. 512/32 = 16 banks per chip
            for(local i = 0; i < 16; i += 1){
                // Low bit for ROM chip select + bank select.
                cpu_write(d, 0x8000, ((chip & 1) << 7) + (i << 1));
                cpu_read(d, 0x8000, banksize/2);  //Read 32KB bank from $8000-FFFF
                cpu_read(d, 0xC000, banksize/2);  //Read 32KB bank from $8000-FFFF
            }
        }
    }
}


Maybe someone get the idea and could make a script for mapper 246 so I can dump the cartridge and provide the differences?


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 8:01 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
The only complexity for dumping the game comes from figuring out what conditions makes the GAL drive /RE low (assuming that it powers on as high).

Given that GAL pin 1 (the GAL's latch enable) is connected to /ROMSEL, it has to involve reading from or writing to some address in ROM.

After that, you should just be able to use something similar to MMC3's dumper script, with its 8 KiB banks.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 8:49 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
Just one more thing to make sure. For pull-up resistors: Do I just connect 10k Ohm resistors between Q1-Q4 to VCC or lift the pins and connect the 10k between Q1-Q4 and the holes they're connected to?

I haven't used any pull-up/pull-down resistors yet.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 8:52 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
Do not lift pins. This is just an extra thing, one resistor for each address line, connected to the address line on one side and +5V on the other.


Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 11:00 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
That's what I did.

Added a 10k resistor to each output of both PRG '670 and connected the other side to 5V.

Game didn't boot.


Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 7:09 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
I'm out of ideas, I'm sorry.

Somehow, the GAL has to be driving 74'670 /RE high or low according to specific reads or writes from some portion of the FC's memory, and short of desoldering the GAL and dumping its function, I have no idea what it's relying on that's making it work on a NOAC but not on a famicom.

If you want to send it to me in the US, I could take a look and see if I could figure out what's going on.
(There are other people who may be more accessible)


Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 8:44 am 
Online

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 343
Okay, so I desoldered the GAL carefully and read it with my TL866.
This is what it gave me:

Code:
Device    :    GAL16V8D

Created By:    http://www.autoelectric.cn

Date      :    2016-03-22 16:41

*QP20

*QF2194

*G0

*F0

*L00000 11111111111111111111111111111111

*L00032 01010111101101011111111111111111

*L00256 11111111111111111111111111111111

*L00288 01010111101110011010101010101010

*L00512 11111111111111111111111111111111

*L00544 01010111101110011010100110101010

*L01792 11111111111111111111111111111111

*L01824 01100111011101010111010101010101

*L02048 00011111000000000000000000000000

*L02112 00000000111111111111111111111111

*L02144 11111111111111111111111111111111

*L02176 111111111111111111

*C2505


Also added the .JED for attachment.


Attachments:
Fong Shen Bang.zip [386 Bytes]
Downloaded 78 times
Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 9:41 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
I found http://www.brouhaha.com/~eric/retrocomp ... mi/palasm/ which mentions jed2eqn, which in turn generates:

Code:
;$GALMODE MEDIUM

chip FONGSH~2 GAL16V8

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
f13=13 f14=14 f15=15 f16=16 o17=17 o18=18 o19=19 VCC=20

[...]
equations

/o19 = i2 * i1 * i3 * /i4 * i5 * f16
o19.oe = vcc
/o18 = i2 * i1 * i3 * /i4 * /i5 * f16 * /i6 * /f15 * /i7 * /f14 * /i8 * /f13 * /i9 * i11
o18.oe = vcc
/o17 = i2 * i1 * i3 * /i4 * /i5 * f16 * /i6 * /f15 * /i7 * f14 * /i8 * /f13 * /i9 * i11
o17.oe = vcc
f16 = gnd
f16.oe = gnd
f15 = gnd
f15.oe = gnd
f14 = gnd
f14.oe = gnd
f13 = gnd
f13.oe = gnd
o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11
o12.oe = vcc
which ... I'll have to sit down and convert these into the names we previously came up with.

Have to admit I'm pretty confused by /o19 = PRG RAM /CE = (/ROMSEL * CPU A14 * CPU A13 * CPU A11 * CPU/A12 * CPU M2). Maybe the disassembler is doing something wrong?


Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 10:55 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21560
Location: NE Indiana, USA (NTSC)
Normally (that is, in Family BASIC and a family of ASICs), WRAM /CE is NAND(/ROMSEL, M2, A14, A13). Something that looks like NAND(/ROMSEL, M2, A14, A13, /A12, A11) may fully decode a 2Kx8 SRAM at $6800-$6FFF.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 2:22 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 972
Are there any timing diagrams showing the NES bus signals (PHI2, R/W, ROMSEL, Address, Data)?
And diagrams for the NOAC clones, in case they have different timings?

Some diagrams that I've found are:
viewtopic.php?f=3&t=10029&start=15#p111615 - NES Addr, Phi2, PPU /CE
http://www.geocities.co.jp/SiliconValle ... glish.html - General 6502 stuff...
http://www.geocities.co.jp/SiliconValle ... Timing.png - General 6502 Write Timing
http://www.geocities.co.jp/SiliconValle ... Timing.png - General 6502 Read Timing

GAL logic dump is great! I just can't figure out how it's supposed to work...

The "o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11" seems to translate to
Code:
  /ROMSEL=LOW           ;rather nonsense
  AND
  A14 ... A7 = HIGH     ;okay
  AND
  PHI2 = HIGH           ;uhm, why???
  AND
  A6 = LOW              ;uh, what LOW ???
  AND
  A5 ... A4 = HIGH      ;uh, what ???

So /RE would be HIGH for address FFB0h..FFBFh, which would be totally wrong.
It should HIGH for the Reset vector at FFFCh-FFFDh and for the bootcode at FFD0h..FFF9h (or just for the whole FFC0h..FFFFh area).
Could there still be some mistake in the GAL dump, or in the chip/pcb pinout? Especially A4,A5,A6 are looking totally wrong to me.

Decoding /ROMSEL and PHI2 doesn't make any sense for the /RE signal. At worst it could increase "open-bus issues" with the unstable raising edges on the HighZ outputs.

On the other hand, the thing that is really needed (and probably intended by the manufacturer) is checking that A14..A7 are all HIGH. You could cut the /RE signal, and produce your own /RE using some external AND gate. Or easier: Using 8 diodes and a pull-up resistor:
Code:
A7  ---|<|---.
             |
A8  ---|<|---+
             |
A9  ---|<|---+
             |       VCC
A10 ---|<|---+        |
             |        |
A11 ---|<|---+       .'.
             |       | |
A12 ---|<|---+       | |
             |       '.'
A13 ---|<|---+        |
             |        |
A14 ---|<|---+--------+-------- /RE


Top
 Profile  
 
PostPosted: Tue Mar 22, 2016 2:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8533
Location: Seattle
Quote:
PRG RAM /CE = /o19
= i1 * i2 * i3 * /i4 * i5 * f16
= /ROMSEL * A14 * A13 * /A12 * A11 * M2
-> 2 KiB from $6800 to $6FFF
PRGBANK/WE = /o18
= i1 * i2 * i3 * /i4 * /i5 * /i6 * /i7 * /i8 * /i9 * /i11 * /f13 * /f14 * /f15 * f16
= /ROMSEL * A14 * A13 * /A12 * /A11 * /A10 * /A9 * /A8 * /A7 * /A6 * /A5 * /A2 * R/W
-> writes only to $6000-$6003 (and $6008-$600B, $6010-$6013, $6018-$601B)
CHRBANK/WE = /o17
= i1 * i2 * i3 * /i4 * /i5 * /i6 * /i7 * /i8 * /i9 * /i11 * /f13 * f14 * /f15 * f16
= /ROMSEL * A14 * A13 * /A12 * /A11 * /A10 * /A9 * /A8 * /A7 * /A6 * /A5 * A2 * R/W
-> writes only to $6004-$6007 (and $600C-$600F, $6014-$6017, $601C-$601F)
PRGBANK/RE = o12
= /i1 * i2 * i3 * i4 * i5 * i6 * i7 * i8 * i9 * //i11 * f13 * f14 * f16
= //ROMSEL * A14 * A13 * A12 * A11 * A10 * A9 * A8 * A7 * //A6 * A5 * A2 * M2
-> bank is HiZ while accessing $FFE4-$FFE7 (and $FFEC-$FFEF, $FFF4-$FFF7, $FFFC-$FFFF)

In summary, wut. This doesn't make sense, and this still mostly disagrees with Disch's previous notes about mapper 246.

edit: nocash's observing the weirdness with the /i11 input
edit2: connected to CPU A2, not CPU A4

ON THE OTHER HAND, since you've desoldered the GAL and have access to the TL866 programmer, we can change the program for o12=PRGBANK/RE to be what we think it "should" be and see if that works any better. You should be able to play around with Opal Jr in dosbox until its functionality is what we think it should be instead (namely, /i11 becomes +i11, and remove f13 and f14). Socketing it would obviously be a good idea :)


Last edited by lidnariq on Mon Nov 07, 2016 8:29 am, edited 2 times in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 87 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 2 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