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

All times are UTC - 7 hours





Post new topic Reply to topic  [ 68 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Tue Dec 27, 2016 4:24 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Another option could be to write a MS-DOS program that do any tests needed, assuming the PAL IC is present in the place of the BIOS ROM.
How difficult would this be?
For me, unfortunatelly, it's almost impossible :-(


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 4:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
I mean, it wouldn't be hard to build an ISA card and some software to let you try exploring what's going on.

But I doubt it would be more useful than just writing a simple NES test ROM to see what happens in a reassembled cart, replacing the existing PRG.

The VRC2 should even have a single bit of tristate-able buffer (from pin 16 to CPU D0 during reads from $6000-$6FFF) that would let us test any single output from the PAL at a time, as long as it holds state (i.e. is slow). Assuming that this pirate clone bothered to copy that part... If it doesn't work, we could still add external parts to read any latched state instead.


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

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
PRG,CHR address is VRC2

IRQ address
FF00 : not using?
FF04 : counter?
FF08 : enabled?
FF0C : disabled?

clock?


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 7:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Per the mapper hack's code, $FF04 has to be "acknowledge IRQ, do not stop", because that's how the game implements a variable number of scanlines IRQ (It uses the byte of RAM at $07F8 to count down some number of two-scanlines)


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 7:15 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
lidnariq wrote:
Per the mapper hack's code, $FF04 has to be "acknowledge IRQ, do not stop", because that's how the game implements a variable number of scanlines IRQ (It uses the byte of RAM at $07F8 to count down some number of two-scanlines)


yes,I know 0x07F8,but same pcb TNMT J. not using 0x7F8


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 7:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Are we violently agreeing and just having problems due to lack of fluency in a common language?


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 8:12 pm 
Offline

Joined: Mon Dec 12, 2011 8:15 pm
Posts: 352
lidnariq wrote:
Are we violently agreeing and just having problems due to lack of fluency in a common language?



......


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 12:27 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
lidnariq wrote:
Code:
  $C004: Acknowledge IRQ
  $C008: ?start IRQ counter?
  $C00C: Acknowledge and ?stop counter?

It looks like $C004 and $C00C both acknowledge the IRQ, and $C00C additionally resets the counter. I don't see anything that looks like it would stop the counter, but I'm not sure about preventing IRQs.

lidnariq wrote:
pin 16: not measured yet

According to the newer dump, this looks like (inverted) writes to $C00C, but it's inconsistent in some places.

lidnariq wrote:
showing a significant amount of variation is some outputs, hopefully due to violated timing constraints.

That might be fixed by using a /CE or /OE signal on pin 1, if there happens to be one available, instead of an address line.


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 6:51 am 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Well, I asked about the MS-DOS program because my dumper is just an old motherboard repurposed.
To be more precise, it's a M748LMR, on wich I have soldered a 20 pin socket at bios' side and use UniFlash to dump.
But I sure can socket a PRG ROM on the cartridge board and do any tests needed.
My next step is to invert the adress pins and dump the PAL IC again.
It'll just take a litle more time than I want.

Joe, I think I can do a fast redump by pulling pin 1 low or high, or even plugging it to /CE or /OE.
What would help more?


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 2:02 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
Fisher wrote:
Well, I asked about the MS-DOS program because my dumper is just an old motherboard repurposed.

It'd be faster for you to just scramble the address lines you're using and dump it again. Lidnariq could probably tell you which combination(s) would be the most useful. It may also help if you could invert the signals on PAL pin 2 and/or pin 3.

Fisher wrote:
But I sure can socket a PRG ROM on the cartridge board and do any tests needed.

I won't be writing test ROMs any time soon. Maybe lidnariq will.

Fisher wrote:
Joe, I think I can do a fast redump by pulling pin 1 low or high, or even plugging it to /CE or /OE.
What would help more?

I suspect /OE will be more useful than /CE, but we won't know until you try. Pulling it low or high won't tell us anything useful.

The PAL uses pin 1 to detect when the values on pins 2 through 7 are valid. On the NES, /ROMSEL is only low when the other signals are valid. On your motherboard, A0 makes no such guarantee, but hopefully /OE or /CE will.


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 2:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
... right, if you're using a motherboard to dump the PALs, that explains the glitchy behavior, because the address bus probably isn't idle between fetches...

As far as useful orders: I think the most helpful minimal change would be to try all the combinations of D0, D1 before the address lines, by moving pins 2-4 to instead connect to dumper A9-A11, rather than doing a full reversing of pins.


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 4:39 pm 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Ok, I'm really tired... Played with the kids on the park almost all afternoon.
Let's see if I understand: Ineed to solder pins 2, 3 and 4 to A9, A10 and A11. Is it correct?
I plan to do it tomorrow, probably at work. (yes, I'll procrastinate!!)


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 5:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Quote:
Let's see if I understand: I need to solder pins 2, 3 and 4 to A9, A10 and A11. Is it correct?
That's the easiest thing I can think of that should produce useful results.

I'm only confident that that will provide the information necessary to figure out whether $8008 and $800C do anything. Hopefully it'll demonstrate what's going on with $C008 and $C00C too, but I'm not certain about that yet.

Unrelatedly, I was looking more closely at the PAL16L8 datasheet, and noticed that pins 19 and 12 are always outputs, and can never be used as feedback terms inside. So they have to exclusively be a function of the other pins, which makes them really convenient for logic function reduction.

Apparently:
Pin 19 (counter clear) is 1 iff Pin 8 (Cnt=86) is 1 OR pin 16 is 0
Pin 12 (CIRAMA10) is: if Pin 17 ($9004q1 is 1) then Pin 18 ($9004q0) else Pin 7 (VRC2Mirroring)
And it turns out two more pins don't involve any feedback loops ... but we already knew these:
Pin 13 is 1
Pin 15 is 1 iff A2 is 0, or A14 is 0, or R/W is 1, or /ROMSEL is 1 → detects writes to $F004 and $F00C

The other four pins (pin 14 /IRQ, pin 17 $8004q0, pin 18 $8004q1, pin16) involve feedback loops, how inconvenient.

Pin 16 is definitely always 1 during writes to $C008. It is definitely always 0 during writes to $C00C .. but interestingly, it looks like it doesn't care about /ROMSEL?

If I look at the combination of pins 14, 15, 16, and 19, only eight of the sixteen possibilities ever exist, the following never occur:
Pins 19(CLR) and 16 both clear (duh, per above)
Pins 14(/IRQ) and 15 both clear (hmm)
all four pins high (hmm?)

I'll think about this some more and see if anything comes to mind re: pin 14 and 16.


Top
 Profile  
 
PostPosted: Thu Dec 29, 2016 7:12 am 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 569
Location: -29.794229 -55.795374
Ok, I made 3 dumps:

1- Pin 1 on /CE:
Attachment:
File comment: Pin 1 on /CE
PALKDCE.BIN [128 KiB]
Downloaded 22 times

2- Pin 1 on /OE:
Attachment:
File comment: Pin 1 on /OE
PALKDOE.BIN [128 KiB]
Downloaded 23 times

3- Lidnariq's request:
Attachment:
File comment: Lidnariq's request
PALDKLID.BIN [128 KiB]
Downloaded 21 times

Pin2 --> A9
Pin3 --> A10
Pin4 --> A11

The pinout is the same as I posted before, except for the pins I told I switched.
If there's anything else I can do just tell me and I'll make as fast as I can.


Top
 Profile  
 
PostPosted: Thu Dec 29, 2016 2:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Ok, the dump for me that tells me that writes to $8008 and $800C are no-ops also.

The dumps for Joe where socket /CE is connected to PAL pin 1=/ROMSEL does also illuminate a few things... It really looks like D4=pin16 keeps track of which of $C008 (storing 1) and $C00C (storing 0) was most recently written to. Which ... would combine with D7=pin19 to mean that, yes, $C008 is "start counter", and $C00C is "ack IRQ and hold counter at 0"


I guess I could write a simple real mode program on your DOS machine... what program are you currently using to dump things?

... but I kinda feel like I've got a complete mental model of what's happening now, so maybe there's no need?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 5 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