It is currently Mon Aug 20, 2018 11:51 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 85 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sat Mar 26, 2016 1:55 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7400
Location: Seattle
After having traced everything, I noticed that
1- The PRG is wired in order, not scrambled as I had initially misparsed.

2- GAL pin 14 is connected to CPU A2, not CPU A4. So the registers are where they're documented to be.
(Correspondingly, that means that the four outputs are, with the GAL fusemap, at:
Write to $6000-$6003, $6008-$600B, $6010-$6013, $6018-$601B → PRG bank write
Write to $6004-$6007, $600C-$600F, $6014-$6017, $601C-$601F → CHR bank write
Access $6800-$6FFF → PRG RAM I/O
Access $FFE4-$FFE7, $FFEC-$FFEF, $FFF4-$FFF7, $FFFC-$FFFF → instead access bank where PRG A17 is high instead (i.e. each second 128 KiB quarter)

In fact, Ice Man's dumps exactly agree with that:
Attachment:
via8000-vs-via-e000.gif
via8000-vs-via-e000.gif [ 29.14 KiB | Viewed 2155 times ]

)

3- The battery switchover circuit that nocash is objecting to would be almost correct if that single trace was removed. Given how the traces look like "Autorouters Gone Wild!" I wouldn't be surprised if the connectivity had been specified by naming nodes and they accidentally used the same name for "battery voltage" and "UPS-ed voltage"


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 2:33 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
[-- wrote this before/while lidnariq posted the above --]

Yet another oddity: U6.Pin11 is GNDed.
So that PRG A13,A14,A15,A16 would always come from whatever is in U6 (which is uninitialized on power up).

On the contrary, U7.Pin11 is the "/RE" signal from GAL.Pin12.
So that PRG A17,A18 would be somehow affected by the GAL. PRG A17 with the additional 4.7K pull-up.

The differences in the "PRG 6000-8000" vs "PRG 6003-E000" dumps are somewhat related to the above wiring. The bytes seem to be read from the selected A13,A14,A15,A16 address bits, but A17 seems to be forced high (by the pull-up?) and A18 seems to be low.
Ie. the "different" bytes at offset 1FF4h, 3FF4h, 5FF4h, etc. in "PRG 6003-E000" are same as data at 21FF4h, 23FF4h, 25FF4h, etc. in "PRG 6000-8000". Which is, well, not actually explaining how it could ever map the reset vector on power-up.

There are more and more odds than ends. The only thing that is becoming clearer and clearer is that it's absolutely impossible that the cartridge could work on a NES or Famicom.
I've no idea how it could work on NOAC clones - the whole design seems to rely on electrosmog being produced by the Joypad or TV Set.

[-- after lidnariq's post --]

A4 is actually A2 ??? I thought that I had verified that signal on the photo, too. Gotta check again. But of course, that would explain at least half of the problems.
Yes, you are right. Maybe the shadow on the photo made it look as if the wire would be shorter, and would only go far enough to connect to A4, not to A2. But yup, it's A2.

For the battery-shortcut, the earlier photos in first post viewtopic.php?f=9&t=13969#p166351 actually show no connection in that place, so the "wire" seen in later photos seems to be just some dirt/scratch, not a real wire.


Last edited by nocash on Sat Mar 26, 2016 3:31 pm, edited 3 times in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 2:34 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Corrected the GAL pinout again.

Pin 14 to CPU A2
Pin 13 to CPU A5 (not to PRG A8 but to PRG A5, too).


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 3:58 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
Trying to understand what is happening on reset...
Maybe the circuit simply assumes that the 74670's tends to boot up with all-bits-set on power up, then all PRG banks would be initially 3Fh.
And the GAL's /RE output would somehow modify the upper two bits, A17=Pulled-HIGH and A18=Floating-LOW, thus changing bank 3Fh to 1Fh on certain addresses.

Then the reset vector at FFFCh and the bootcode at FFD0h..FFF9h would be processed as so:
Code:
  FFD0h..FFE3h  14h bytes  bank 3Fh                ;\
  FFE4h..FFE7h  4 bytes    redirected to bank 1Fh  ; bootstrap at
  FFE8h..FFEBh  4 bytes    bank 3Fh                ; FFD0h..FFF9h
  FFECh..FFEFh  4 bytes    redirected to bank 1Fh  ;    EDIT: during execution, the bootstrap will set [6003h]=03h,
  FFF0h..FFF3h  4 bytes    bank 3Fh                ;    so some of the later opcodes are from bank 03h, or
  FFF4h..FFF7h  4 bytes    redirected to bank 1Fh  ;    redirected to bank 13h
  FFF8h..FFF9h  2 bytes    bank 3Fh                ;/
  FFFAh..FFFBh  2 bytes    bank 3Fh                ;-NMI vector
  FFFCh..FFFFh  4 bytes    redirected to bank 1Fh  ;-Reset and IRQ/BRK vector

That would wildly toggle between bank 3Fh and 1Fh (edit: and bank 03h and 13h) during execution of the bootcode, but it could work as all of those banks seem to contain a copy of the bootcode. I've no idea if a 74670 would really tend to contain all-ones on power-up though.

And as for WHY the circuit might work as above:
Either the developer tried to implement some hardware logic (and then decided to store copies of the bootcode in different banks when it turned out that the logic didn't work as planned). Or, there is some idea behind it (like a copy-protection that would verify the exact behaviour of the crazy memory mapper at some later stage in the game).


Last edited by nocash on Sun Mar 27, 2016 4:08 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 4:53 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7400
Location: Seattle
nocash wrote:
And the GAL's /RE output would somehow modify the upper two bits, A17=Pulled-HIGH and A18=Floating-LOW, thus changing bank 3Fh to 1Fh on certain addresses.
As near as I can tell, A18 seems to be unchanged (as a HiZ output "should" be with the parasitic capacitance of the traces) ... and that's what I see in Ice Man's dumps.

Another inexplicable thing ... they seem to not even be using the PRG banking's features, and are just always writing N,N|1,N|2,N|3 to $6000 through $6003. i.e. it seems that you could replace the two 74'670s with just a 74'161.


Last edited by lidnariq on Sat Mar 26, 2016 6:32 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 5:53 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
I actually have a 74HC161 over that I could try. But how exactly would I replace it for the 2 74'670 on the PRG side?


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 6:28 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7400
Location: Seattle
Nevermind, I just tested it in FCEUX and it crashed once the game actually started. Sigh.


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 7:39 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7400
Location: Seattle
Ok, so:

The game relies on being able to change the NMI vector by changing the bank. This explains the otherwise-inexplicable inclusion of A2 in the formula for PRG BANK /RE . But specifically what it's doing is: the NMI vector is only valid when the bank at $E000 is bank 3, other banks instead point the NMI at the reset handler.

SO: the fixed bank at $FFD0-$FFFF is from ROM offset 0x6000, or: PRG A13, 14 high; A15..A18 low. I have absolutely no idea how this was ever supposed to work, unless the 74'670s just happened to, as we previously guessed, tend to power up with the value "3" in memory.

Similarly, I have no idea what the pullup on PRG A17 is doing. It has to be too slow to be relevant, because when the game fetches the NMI vector it fetches the good NMI vector of $8086 instead of the bad NMI vector of $FFD0.


With that in mind, we should be able to generate a fusemap for the GAL that will achieve the desired behavior without changing the PRG.
* If CPU accesses $FFFC-$FFFF (or corresponding addresses from $FFE4 up), set PRG BANK /RE high. The game doesn't use IRQs, so this catches only the reset vector (and reset handler)
* If CPU accesses $8xxx-$Bxxx, set PRG BANK /RE low
* Otherwise, PRG BANK /RE should be unchanged
* Disconnect PRG BANK LOW /RE from ground, and connect it to PRG BANK HIGH /RE
* Pullup resistors on PRG A13 and A14—this only needs to last for the initial powerup, and the initialization routine is present at the end of each 32 KiB so we don't need pullups on the other lines.


The fusemap should be
pin = pin AND NOT LOWERCONDITION OR RAISECONDITION
LOWERCONDITION = /ROMSEL=0 AND A14 = 1
NOT LOWERCONDITION = /ROMSEL=1 OR A14 = 0
pin12 = AND(pin12,/ROMSEL) OR AND(pin12,NOT A14) OR AND(NOT /ROMSEL,A14…A5,A2) ... that's only 2 ORs (GAL16V8 supports 6 or 7) so this should work.


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 4:02 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
lidnariq wrote:
As near as I can tell, A18 seems to be unchanged (as a HiZ output "should" be with the parasitic capacitance of the traces) ... and that's what I see in Ice Man's dumps.

You mean, as if one of the previous bytes was fetched from a "normal" address (with /RE=low), then A18 would stay at the same level for next some microseconds for any bytes that are fetched from "floating" addresses (those with /RE=high). Yes, that would make sense, and seems to match better with Ice Man's dumps (as there are no "differences" occuring in last hundred kilobytes).

lidnariq wrote:
The game relies on being able to change the NMI vector by changing the bank.

Yes, no. The NMI vector is somewhere inbetween the weird /RE areas, but it isn't part of the obscure /RE=high regions.
The pull-up on A17 doesn't affect the NMI.
Concerning NMI, the cartridge is just working as it has been excepted throughout past some years.
All the game needs to do is never to set 6003h to other value than 03h, then NMI should work fine. If the game wants to access other PRG banks, then it must probably do that via other ports, like 6002h or so.

lidnariq wrote:
I have absolutely no idea how this was ever supposed to work, unless the 74'670s just happened to, as we previously guessed, tend to power up with the value "3" in memory.

Yes, sorts, of. The reset vectors exist at end of each 32K bank (aka at end of each fourth 8K bank), so the lower 2bit of the bank number must tend to "3" on power-up, but any other value with lower 2bits set should works too, like 7, 0Bh, 0Fh, 13h, etc. Most likely it's just all bits tending to be set, hence my guess on 3Fh being the initial 6bit bank number.

----

For reprogramming the GAL, I think two solutions should work:

1) the /RE stuff seems to be solely switching between "normal" and "floating" banks during execution of the bootstrap code, there is absolutely no good reason for doing that, so one could just program the GAL to always output /RE=low (or just leave the GAL as is, and instead shortcut /RE to GND; ie. wire U7.Pin11 to GND, and (to avoid a harmless shortcut) disconnect GAL.Pin12).
After all, emulators seem to work well without reproducing the /RE stuff.

2) the /RE stuff seems to be totally useless, but it shouldn't disturb anything. I think the famicom-compatibility issue is just caused by different M2 timing, M2 might be important for WRITE operations (like SRAM access, or I/O port access), but for READ operations it's rather nonsense to output the read-address ONLY during M2. So one could just use the GALs original formulasand omit M2 from the /RE formula and leave everything else unchanged.

EDIT: The "pin = pin AND NOT LOWERCONDITION OR RAISECONDITION" idea also looks elegant. I thought somebody told me that GALs or PALs wouldn't be too reliable about memorizing "states" (when trying to figure out if/how the SNES six-player adaptors could work). But if it works, then it would be fine. I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)

Oh, or third idea: remove the second resistor from left, that one pulls A17 high when entering the "weird" /RE=high state, if /RE gets switched too early then it would smash A17, but without the resistor A17 might stay floating intact due to impedance reasons.


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 6:04 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Removed the 2nd 4.7k resistor. A white dot on the top left appeared on the monitor, but game still did not boot. With the resistor in place I only get a black screen.


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 9:06 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7400
Location: Seattle
Ice Man, could you easily throw the 74'670s in a breadboard to find out what values your ICs tend to power up containing? Should be something easy like: tie /WE high, D0-D3 don't matter, Wa-Wb don't matter, Q0-Q3 to resistor+LEDs, /RE low, Ra-Rb high (or to switches)

nocash wrote:
All the game needs to do is never to set 6003h to other value than 03h, then NMI should work fine. If the game wants to access other PRG banks, then it must probably do that via other ports, like 6002h or so.
But it does. I added some tracing statements to FCEUX and got bank layouts like <00 01 02 03>, <08 09 0A 0B>, <08 2F 0A 0B>, <08 60 0A 0B>, <1C 1D 1E 1F>, <20 21 22 23>, <30 31 32 33>

nocash wrote:
I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)
Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.

If for some reason the feedback path doesn't work, it also seems to work (at least in an emulator) to just force the memory region from $FFC0-$FFFF to always come from ROM offset $7FC0-$7FFF.


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 9:31 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Wish I had a breadboard for testing here. Sorry. :(


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 9:53 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
Ice Man wrote:
Removed the 2nd 4.7k resistor. A white dot on the top left appeared on the monitor, but game still did not boot. With the resistor in place I only get a black screen.

Good to know that it didn't work that simple. Thanks for testing!

Ice Man wrote:
Wish I had a breadboard for testing here. Sorry. :(

I guess you could improve something if needed: Wire directly to the raw chip. Or make your own breadboard by wiring to socket (maybe with a small PCB to make the socket more robust).

Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.

lidnariq wrote:
Ice Man, could you easily throw the 74'670s in a breadboard to find out what values your ICs tend to power up containing? Should be something easy like: tie /WE high, D0-D3 don't matter, Wa-Wb don't matter, Q0-Q3 to resistor+LEDs, /RE low, Ra-Rb high (or to switches)

Yeah, would be nice to test that! But pick the right one (the one that you had marked "U6 - 74'670 Lower PRG Side"), the chips seem to be from different manufacturers, and might behave differently (at least I've spotted such effects in SRAMs from different manufacturers). I hope you still know which chip was U6 before you desoldered them - if you swapped the 74670's around then the cart might have stopped working even on NOACs.

lidnariq wrote:
I added some tracing statements to FCEUX and got bank layouts like <00 01 02 03>, <08 09 0A 0B>, <08 2F 0A 0B>, <08 60 0A 0B>, <1C 1D 1E 1F>, <20 21 22 23>, <30 31 32 33>

Oh, okay. Then I don't know how the game works in no$nes (or if works beyond reaching the title screen).
It might have NMI's disabled while switching banks without NMI vector; or take care to map bank 03h before vblank occurrs.

lidnariq wrote:
nocash wrote:
I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)
Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.

Yah, that should be good enough to see if it gets the game working, although in reality in would work slightly different.

lidnariq wrote:
If for some reason the feedback path doesn't work, it also seems to work (at least in an emulator) to just force the memory region from $FFC0-$FFFF to always come from ROM offset $7FC0-$7FFF.

For the NMI, yes, should be so (=bank 03h).

For Reset, another oddity is that Ice Man's dump doesn't have a valid reset vector in bank 03h (almost everywhere else, but not in that bank). I think the A17 pull-up might be intended to force Reset to work (if bank 03h is selected, then it would become bank 13h).
If the initial bank on power-up is 3Fh, then the above pull-up would be needed only if somebody pushes reset-button while the game has mapped bank 03h. Dunno if the NOAC's have reset-buttons at all though.

For the different vectors in bank 03h dumps. I think that all ROMs might be always containing the values that Ice Man has dumped, the dumps that have FFD0h vectors in bank 03h might be due dumping the ROMs differently (by mapping 4 banks via 6000h..6003h, and then reading 32Kbytes at once from 8000h..FFFFh; that should theoretically replace FF00h from bank 03h by FFD0h form bank 13h).


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 10:14 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
nocash wrote:
Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.


Will try that one later and report how it turns out!

nocash wrote:
Yeah, would be nice to test that! But pick the right one (the one that you had marked "U6 - 74'670 Lower PRG Side"), the chips seem to be from different manufacturers, and might behave differently (at least I've spotted such effects in SRAMs from different manufacturers). I hope you still know which chip was U6 before you desoldered them - if you swapped the 74670's around then the cart might have stopped working even on NOACs.


I replaced all 74'670 with newer ones. Dumping the game didn't make any difference with either. Dumped it before and after replacing them.

However, how exactly would I improve to make a breadboard (using wires only). I mean, where would I connect the wires to after all?

EDIT: Connected U7.Pin11 to ground. Nothing happened, but after that the game always displays the white dot on the upper left corner on the monitor and upon reset I get a full screen of garbage of for a split second (this also happens in FCEUX but the game start). However, when CHR is missing (only PRG) the game does not restart but get stuck. Is it possible that the problem lies within CHR and not PRG?


Top
 Profile  
 
PostPosted: Sun Mar 27, 2016 1:07 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 605
Theroretically CHR could also cause problems. But I think it's rather unlikely. Of course, the whole cartridge works "rather unlikely".

A breadboard is just some test board that that allows you to connect wires to chips (via plugs, without soldering) - you could as well use a soldering iron to get the same effect. All you need is knowing where you want to connect the wires to. In this case, this connection could be fine:
Code:
                             74670
                         .----. .----.
                 +5V -- 1|D2  '-' VCC|16 -- +5V
                 +5V -- 2|D3       D1|15 -- +5V
                 +5V -- 3|D4      WA0|14 -- +5V
                 +5V -- 4|RA1     WA1|13 -- +5V
                 +5V -- 5|RA0     /WR|12 -- +5V
     test this -------- 6|Q4      /RD|11 --- GND
     test this -------- 7|Q3       Q1|10 ----------- test this
                GND --- 8|GND      Q2|9  ----------- test this
                         '-----------'

Some of the +5V pins would be don't care, but it should be easiest just to bridge all those pins without skipping don't care pins.
Important pins are VCC and GND as supply, and /WR=+5V to prevent the initial content on power up getting overwritten, and /RD=GND to cause the chip to output it's content. RA0 and RA1 to +5V selects the last bank value to be output (the one that affects E000h..FFFFh).
For the four pins marked as "test this", you could attach LEDs-with-resistor there, or just use a multimeter (in DC/volt mode) to measure the voltage (ie. connect the probes to GND and the "test" pins) (maybe also try probing GND and +5V, just to see if you got it right, it should show "5" volts then).
If the chip tends to boot up with all bits sets, then you should see around 5 volt on the test pins each time when the power supply is switched on.

If you are there, you might also try wiring /RD to +5V, just to see what kind of "floating" voltage is appearing on the four "test" pins.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 85 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: Google [Bot], NOOPr and 4 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