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: )
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"
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.
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: Select all
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
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).
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.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.
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.
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: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.
Yes, no. The NMI vector is somewhere inbetween the weird /RE areas, but it isn't part of the obscure /RE=high regions.lidnariq wrote:The game relies on being able to change the NMI vector by changing the bank.
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.
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.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.
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.
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: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.
Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.nocash wrote:I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)
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.
Good to know that it didn't work that simple. Thanks for testing!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.
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).Ice Man wrote:Wish I had a breadboard for testing here. Sorry. :(
Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.
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: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)
Oh, okay. Then I don't know how the game works in no$nes (or if works beyond reaching the title screen).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>
It might have NMI's disabled while switching banks without NMI vector; or take care to map bank 03h before vblank occurrs.
Yah, that should be good enough to see if it gets the game working, although in reality in would work slightly different.lidnariq wrote:Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.nocash wrote:I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)
For the NMI, yes, should be so (=bank 03h).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 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).
Will try that one later and report how it turns out!nocash wrote:Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.
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.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.
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?
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: Select all
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 '-----------'
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.