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!!

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.

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!

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 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.

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...

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.

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 likeWrite '00' to $8000 while not terminal count and input nametable=0Write '00' to $8000 while terminal count and input nametable=0repeat above, but input nametable=1repeat above, but reading from $8000 insteadrepeat 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 $C00Cfinally 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...

Who is online

Users browsing this forum: No registered users and 9 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum