It is currently Sat Nov 25, 2017 4:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 68 posts ]  Go to page 1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Dec 26, 2016 11:44 am 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Hi.
This is the thread I promissed on the Kid Dracula (Akumajō Special: Boku Dracula-kun) reverse engineering.
I'm posting the assembled card pictures first:
Attachment:
File comment: Kid Drac - Componentes
IMG-20161226-WA0006.jpg
IMG-20161226-WA0006.jpg [ 136.51 KiB | Viewed 1647 times ]

Attachment:
File comment: Kid Drac - Solda
IMG-20161226-WA0007.jpg
IMG-20161226-WA0007.jpg [ 163.82 KiB | Viewed 1647 times ]


I noticed some routing errors, there's possibly more:
1- Pins 6 and 7 of the 23c269 are swapped.
2- The CIC stun cicrcuit seems misrouted.
3- Pin 22 of the PRG? ROM is misrouted.

Next I'll post the naked board scans.
Get ready for some PCB porn!!


Last edited by Fisher on Mon Dec 26, 2016 12:54 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 11:51 am 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
As promised, some PCB porn:
Attachment:
File comment: Kid Drac - Componentes
KidDrac - Componentes.png
KidDrac - Componentes.png [ 1.66 MiB | Viewed 1646 times ]

Attachment:
File comment: Kid Drac - Solda
KidDrac - Solda.png
KidDrac - Solda.png [ 1.53 MiB | Viewed 1646 times ]


Next I plan to dump the PRG and CHR ROMs plus the PAL chip.
Can someone please tell me wich pins are inputs and wich are outputs on the PAL?
I'm with 9 guests at home (5 are kids) that will stay this whole week and part of the other, so it's better to do these dumps in a single shot!!


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 12:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
... This IRQ counts falling edges of PPU A13. Specifically, it counts 86 of them, or two scanlines.

Of the six pins that could be inputs or outputs, they are either all outputs or connected to nothing. They are probably all outputs.

Tracing completed.


Last edited by lidnariq on Mon Dec 26, 2016 3:59 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 12:51 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
Fisher wrote:
I noticed some routing errors, there's possibly more:
1- Pibns 6 and 7 of the 23c269 are swapped.
2- The CIC stun cicrcuit seems misrouted.
3- Pin 22 of the PRG? ROM is misrouted.

This board is basically identical to the one zxbdragon took pictures of in the other thread, modified to work in a NES instead of a Famicom (and use mask ROMs instead of EPROMs).

Pins 6 and 7 of the VRC2 clone are swapped because this board misroutes them. The NES swaps PPU A10 and A11 relative to the Famicom, and whoever modified this board for NES missed that key difference.

Pin 22 of a 28-pin mask ROM is A16, but the equivalent pin on EPROMs is /OE. You can see where both PRG and CHR had the trace connecting that pin to GND hastily cut, but only the CHR was correctly rerouted. The PRG was connected back to GND! The hack job connects it to the correct location.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 1:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
PAL pinout appears to be
Code:
              .--V--.
   /ROMSEL -> |1  20| -- +5V
    CPU A2 -> |2  19| -> CNT CLEAR
    CPU A3 -> |3  18| ?? nc
   CPU A14 -> |4  17| ?? nc
    CPU D0 -> |5  16| ?? nc
    CPU D1 -> |6  15| ?? nc
       R/W -> |7  14| -> /IRQ
VRC2 NTA10 -> |8  13| ?? nc
    CNT=86 -> |9  12| -> CIRAM A10
       Gnd -- |10 11| ?? nc
              '-----'

But why not just use resistors as I suggested in the other thread?


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 3:32 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
thaks!Hope to be able to solve the MAPPER


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 4:31 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 246
Location: Poland
I rev-ed your PCB, thanks for providing a lots of fun!
Image Image Image


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 4:46 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Well Lidnariq, I really want to do that circuit, but my house is a little overpopulated...
Let me explain:
My sister is visiting me with her husband, she has 3 kids, plus, my niece is here with her husband too, and she has 2 other kids.
This makes me a Uncle Grandpa!!
I really fear that some kid come near me while I'm working and get hurt by any of the tools I have on my workdesk.
So it was kind of "Metal Gear" stealth action to hide myself and try to do at least part of the job.
Hope Everything was done correctly. You know: "haste makes waste"!
They really liked me and I have past most of my free time playing with them and my own kids.

Great job Krzysiobal!!
I just need to study and understand better these inner workings!!
I still consider myself a newbie in these stuff. Hope to change this soon! :wink:

By the way, here is the PAL data I managed to dump:
Attachment:
File comment: Kid Drac PAL IC
PALKIDDR.BIN [128 KiB]
Downloaded 34 times

The pinout I used:
Code:
           .--V--.
     A0 -> |1  20| -- +5
     A1 -> |2  19| -> D5
     A2 -> |3  18| -> D4
     A3 -> |4  17| -> D3
     A4 -> |5  16| ?? A10
     A5 -> |6  15| -> D2
     A6 -> |7  14| -> D6
     A7 -> |8  13| -> D1
     A8 -> |9  12| -> D0
    Gnd -- |10 11| <- nc
           '-----'

It's the same circuit I used to get that Gradius 2's PAL data, I only changed pin 14 to D6.
Hope this helps clarify even more how the IRQ circuit works.

If someone is interested, here is the ROMs dump, I just don't know who is who.
Edit: Discovered who is who by comparing the CRC32 with Bootgod's site.

PRG ROM:
Edit: Removed to avoid future problems, as suggested.
For reference:
NCN-18A.BIN CRC32 6a50b553
If someone needs it here's an IPS patch:
Attachment:
File comment: PRG ROM patch
NCN-18A.ips [1.11 KiB]
Downloaded 29 times

Apply it to the original PRG ROM, CRC32 93794634

CHR ROM:
Edit: Removed to avoid future problems, as suggested.
For reference:
NCN-18B.BIN CRC32 c5d1196e
The same CRC32 as the original.

If there's some problem posting this kind of stuff here, please, remove it.
Edit: Removed possibly copyrighted material, as suggested.

Edit2: Fixed the NCN-18A.BIN, it was the same NCN-18B.BIN. Sorry...
Edit3: The CHR-ROM (NCN-18B.BIN) has the same CRC as the original.


Last edited by Fisher on Tue Dec 27, 2016 3:12 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 6:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Probably should delete the PRG and CHR dumps; unfortunately.

This exact dump is already in GoodNES 3.14 as "[p1][t1]"

(Interestingly, the PRG is also multiply present in multiple dumps, marked as "[b2]", "[p1][t1][b1]", and "[p1][t1]", and the CHR is "[!]", "[p1][t1]", "[t1]", and "[t2]")

Anyway, the PAL:
Pin 13 / D1 - does nothing at all, is always high.
Pin 15 / D2 - is low when writing to ((address & 0xC00C) == 0xC004) (edit, braino)
all other pins (12,17,18,19,14 = D0,3,4,5,6) are complicated, using feedback paths inside the PAL

So ... the PAL probably latches D0, D1 sometimes, and may count some number of overflows from the interrupt handler also. (Uh-oh)

Also, if you could re-dump with PAL pin 16 as an output that'd be nice.


Last edited by lidnariq on Tue Dec 27, 2016 1:09 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 7:10 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
lidnariq wrote:
Probably should delete the PRG and CHR dumps; unfortunately.

This exact dump is already in GoodNES 3.14 as "[p1][t1]"

(Interestingly, the PRG is also multiply present in multiple dumps, marked as "[b2]", "[p1][t1][b1]", and "[p1][t1]", and the CHR is "[!]", "[p1][t1]", "[t1]", and "[t2]")

Anyway, the PAL:
Pin 13 / D1 - does nothing at all, is always high.
Pin 15 / D2 - is low when writing to ((address & 0xC00C) == 0xC008)
all other pins (12,17,18,19,14 = D0,3,4,5,6) are complicated, using feedback paths inside the PAL

So ... the PAL probably latches D0, D1 sometimes, and may count some number of overflows from the interrupt handler also. (Uh-oh)

Also, if you could re-dump with PAL pin 16 as an output that'd be nice.


goodnes Sorting is imperfect.
[b] rom Many are GOOD DUMP,but is pirate.

After the game Kid Dracula IRQ emu.next MMC5 Clone PCb?


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 10:42 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
So, we know that the underlying VRC2 is VRC2b shaped. So all of the mapper accesses for CHR banking have to have been adjusted from the original game's VRC4e layout (0,4,8,C → 0,1,2,3).

There are up to eight possible registers in the PAL. The mask is $C00C.
The ones at $8000 and $C000 are explicitly no-ops to minimize how intrusive the patch had to be.
The one at $9004 (i.e. $8004) is the new augmented mirroring control register (since register mirroring will fall through to the VRC2 underneath). Two of the unknown five outputs on the PAL must latch D0 and D1 to keep track of when the PAL is supposed to override the mirroring.

There's one at $F004 (i.e. $C004); it doesn't pay attention to the data bus (the IRQ handler writes the contents of A as the very first thing). By context, this must restart the IRQ timer, keeping track of the number of times before it passes to the original IRQ handler.

The patch also writes to $9008, $F008, and $F00C; it's less immediately obvious what these are doing. After the nametable controls, and the idle bit, there are only two possibly volatile bits remaining. One is probably whether the IRQ is enabled... another may be whether the IRQ is currently asserted.

PAL pin 14 (dump D6) is 1 (IRQ not asserted) IF: /ROMSEL is 0 and CPUA2 is 1 and CPUA14 is 1 and R/W is 0. (i.e. $C004, $C00C)
— it's always 0 (IRQ asserted) IF: (pin 9) CNT=86, unless the immediate above line. More complicated behavior is hard to diagnose.

PAL pin 12 (dump D0) should, sometimes, be one of: pin 8 (A7) , logic 1, logic 0, depending. Additionally, it should be correlated with some other bits.
— Due to the in-order way the PAL-as-ROM was dumped, we can only tell that it does care about $8004 and does not care about writes to $8000, but write to $8008 or $800C cannot be determined.

PAL pin 17 and 18 (dump D3 and D4) appear to be the latched copy of CPUD1 and CPUD0 respectively in response to writes to the mirroring control register.

PAL pin 19 (dump D5) is asserted (i.e. reset counters) if: CNT=86.
—Otherwise, writes to $C008 seem to deassert it, and writes to $C00C seem to assert it


I'm not entirely certain what the next useful test would be. Maybe shuffling some address lines so that the dumper tickles things in a different order. Or maybe writing a test that could be put on some 'PROM to tickle the six different registers. And it would be really nice to massage the /ROMSEL input so that the PAL's latches-made-of-feedback-paths weren't glitchy...


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 8:18 am 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
Wait for Joe master


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 1:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
He may well think of something... but here's what I'm confident of:

Code:
Mask: $C00C
  $8000: no effect
  $8004: [.... ..Mm] - mirroring override
                 ||
                 |+--  0: 1-screen A mirroring, 1: 1-screen B mirroring
                 +---  0: Mirroring from VRC2, 1: Mirroring from m bit
         These two bits are stored in the PAL's outputs-
          M on pin 17
          m on pin 18
  $8008: Functionality not knowable from available dump
  $800C: Functionality not knowable from available dump
  $C000: no effect
  $C004: Acknowledge IRQ
  $C008: ?start IRQ counter?
  $C00C: Acknowledge and ?stop counter?


Separately:
pin 12: (per pinout) Nametable override
pin 13: Nothing
pin 14: (per pinout) /IRQ
pin 15: IRQ ack
pin 16: not measured yet
pin 17: nametable override
pin 18: nametable 1screen override setting
pin 19: (per pinout) 74'393 +CLEAR

If one looks directly at the dump, each byte can be though of as a sequence of accesses to memory:
write "00" to $8000, idle, write to $8004, idle, write to $8008, idle … $800C $C000 $C004 $C008 $C00C, then the same for writing "01", "10", and "11"; then 64 cycles corresponding to reads from those same locations. Then 128 cycles while the nametable mirroring input is high instead of low.
Then 256 cycles while the 74'393 and 74'21 are indicating terminal count.

This pattern is repeated 256 times throughout the dump, showing a significant amount of variation is some outputs, hopefully due to violated timing constraints.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 2:57 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
New PAL dump:
Attachment:
File comment: New PAL IC dump
NEWPALKD.BIN [128 KiB]
Downloaded 34 times

Pinout used:
Code:
           .--V--.
     A0 -> |1  20| -- +5
     A1 -> |2  19| -> D7
     A2 -> |3  18| -> D6
     A3 -> |4  17| -> D5
     A4 -> |5  16| ?? D4
     A5 -> |6  15| -> D3
     A6 -> |7  14| -> D2
     A7 -> |8  13| -> D1
     A8 -> |9  12| -> D0
    Gnd -- |10 11| <- nc
           '-----'



I'm planning to do another dump later, using interleaved address lines (A0, A2, A4, A6, A8, A10, A12 and A14).
Would this be usefull?


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 3:33 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Hm. I don't think skipping address lines would be helpful. I tentatively think reversing them should?

That would change the virtual bus behavior to instead look like
Write '00' to $8000 while not terminal count and input nametable=0
Write '00' to $8000 while terminal count and input nametable=0
repeat above, but input nametable=1
repeat above, but reading from $8000 instead
repeat above, but data bus now holds '10', then '01', then '11'
repeat above, but to $C000, then $8008, then $C008, then $8004, then $C004, then $800C, then $C00C
finally 65536 samples while /ROMSEL is high, which if my mental model is right, ought to ignore every pin other than pin 9/A8/"terminal count"

Because the 16L8 has six feedback loops, instead of registers, that means it has to be storing values in a multiplexer-like behavior, rather than caring about edges. So hopefully keeping things like this will help...


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [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