nesdev.org

kyuusaku wrote:Game Doctors won't even start up with Tengai Makyou in their top slot so there must be a conflict.

Wow, that is really strange.
Which one did you use and what kind of power supply are you using? I had trouble with the XBand on passthrough at times due to the extra power it needed. I know, it is a long stretch here, but I can't think of what else would cause this as the Game Doctors only use the normal cartridge regions so I can't think of what would conflict.

kyuusaku wrote:Perhaps the game can be inserted into the slot after the GD is setup to passthrough conflicting areas?

Could you try this for us and let us know what happens?

kyuusaku wrote:A GDSF3 I tested is capable of running Mario Kart through the top, but I don't think it's memory mapping capabilities are as sophisticated as the GDSF7's, so maybe passthrough header flags aren't an option.

I haven't played with it much, but the memory mapping capabilities seem to be the same (even the trick $C0 byte works the same).

kyuusaku wrote:I can test with a GDSF6/7 too but I think it's because of the passthrough feature that they're the ones that require the bottom DSP adapter.

Yeah, the delay is slightly too much on the SF7 to play with a DSP on the top (it works sometimes, but I wouldn't trust it). However if you look at the datasheet for the DSP it is amazing that it responds in time as is (the cartridge itself is really pushing near the limit). I haven't had trouble with most other cartridges though, so it is at least worth a try.

-----------

kammedo wrote:So yes, it would reduce the number of components, but wouldnt a double-sram (with the U2 overbridged to the SNES bus) be more feasible?

The way I suggested would be easier to build (one chip only, much fewer connections, and no PCB required) and also to debug (if there are bad connections the effect is insular... a bad data line connection would only affect that data line ... there are no address line connections, etc.)

However, kyuusaku's method once built is superior in all ways.

Since this sounds like it is your first significant cart circuit modification, I thought it would be easiest (and most expediant) to have you build the simplest thing that does what we need. "Debugging over the internet" is painful to say the least, so I'm hoping to keep things as simple as possible.


Unfortunately, both of the SNES based ideas require the chip to run fine in passthrough on a game doctor. We need to verify and/or fix that first.

kammedo wrote:As for the GDSF7, yes it doesnt run the FEoEZ cart from the top slot...

Ouch.

kammedo wrote:I recall Darkforce telling that some changes to the GDSF were needed in order to make it run. I have the DSP exp, but at home. Ill see if I can get the GDSF to make it work. Any suggestions?

Wait, I'm confused. So you aren't home yet? How did you test the FEoEZ cart on the SF7? Or is your above comment based solely on your recollections of what Darkforce said?

By the way, you do not need the DSP connector for anything we are doing here (I wasn't sure what you were referring to there either).

caitsith2 wrote:The primary thing here, is that the game is expecting direct communication with the spc. If there is no clock going to the spc, then communication can not happen. You basically have to pass Pin 1 of the cartridge connector from the bottom side, directly to the top side somehow, as that is the clock for this chip.

My recollections were:
- for most SWC DX2 the clock line was not passed through. This indeed had to be modified. (This is what TheDumper told me, and also according to most FAQs http://defaced.co.uk/snes/SWCDX2FAQ.pdf )
- for a SF7, the clock line was passed through a logic chip (to clean up noise). I believed they used a schmitt inverter. I think I checked this / found this out myself at one point ... but my memory is too fuzy to be confident in the source of the info.


I could be wrong and the clock is not passed through on the SF7, I will try to check again tonight when I get home. Or the inverted clock is actually a problem.

I wonder how much the clock is really needed though. I would guess that without the clock the memory mapping features would still work. Furthermore, let's remember that on your dumper we designed it to be given an 8 MHz clock hoping it would be enough... it was. It doesn't seem the device is very picky about the clock: it just needs one.

I'm getting baffled by this / frustrated enough that I can't check things directly, that I decided to buy a FEoEZ cart. It should be arriving next week. In particular, it is not clear to me if there is any internal RAM at all... from Darkforce's discussion it sounds like accesses to bank $50 are nothing more than like accesses to register $4800. Also, with a cartridge I should be able to run some tests myself.

EDIT: Oh, one more thing. Caitsith, I can send you a SF3 if you want. They were really cheap for awhile so I picked up several at one point. I don't have a power supply for it though, so you'd have to pick one of those up yourself. Let me know.

I happen to own not only an FEoEZ cart, but I also own an MDH cart and a SPL4 cart. (the other 2 SPC7110 games).

All 3 of those could be good, for extracting test data (first 2 byte combos) from their data rom.


As for that 8Mhz clock being sufficient, it was, due to the fact, that when you were doing decompression runs, or any other operation that takes some time to complete, You would just poll a specific register for that completion status. If you clocked it slower, it would just take longer to complete, is all, but it would happen.

I may still be able to rebuild the rig, as I happen to still have a 62 pin connector, back from when you could find them on ebay cheaply. (They were nothing like the official nintendo ones. (you had to completely unsolder the original nintendo version, and solder the replacement in its place.)

caitsith2 wrote:I happen to own not only an FEoEZ cart, but I also own an MDH cart and a SPL4 cart. (the other 2 SPC7110 games).
All 3 of those could be good, for extracting test data (first 2 byte combos) from their data rom.


As for that 8Mhz clock being sufficient, it was, due to the fact, that when you were doing decompression runs, or any other operation that takes some time to complete, You would just poll a specific register for that completion status. If you clocked it slower, it would just take longer to complete, is all, but it would happen.

I had all three carts too, but one FEoEZ cart i used for testing (ahem), and the other two I desoldered the SPC from.
I wonder if it would be more feasible (and easier, not quicker) to build a dedicated board? As in, some kind of SPC dev board?

Could it be the difference from the $4800 register returning data in a synchronous way (as in for every read), while the $50 bank is used for "block" decompression. Sounds reasonable to me, and gives a register that wouldnt had reason to exists, well, a reason .

neviksti wrote: Wait, I'm confused. So you aren't home yet? How did you test the FEoEZ cart on the SF7? Or is your above comment based solely on your recollections of what Darkforce said?

By the way, you do not need the DSP connector for anything we are doing here (I wasn't sure what you were referring to there either).

Eh, I have two homes at the moment (I moved). All my stuff is scattered in two different (not too close) countries.

I had a chat with Darkforce yesterday. What is needed for the GDSF is

a) clock chip passed through
b) IRQ pin passed through
c) CIC of GDSF bypassed / disabled. It should use the one in the cart instead.

Also, for using a test program from the GDSF, you would have to map the $50 bank in passthrough, and switch to cart mode via a software reset.
I have to ask the details. I will see to get FEoEZ to work on my GDSF for now, while I wait to get the components for the cart mod.

I was looking around for some information on the GDSF, and crossed this page at digipress (the list is taken from tototek i think): http://www.digitpress.com/forum/archive ... 94574.html

where the following list of games looked relevant to me :

PLGS (SPC7110 - ROM types 0xF5 & 0xF9)
======================================
Dai Kaijyu Monogatari 2 (J)
Far East of Eden Zero (J)
Large Shell Beast Story 2
Super Power League 4


Never heard that Large Shell Beast Story 2 and Dai Kaijyu Monogatari 2 would had the SPC7110 in them.. I recall Dai Kaijyu Monogatari having some kind of RTC in it.

EDIT : the names refer to the same game apparently. Is that correct? also, that game has a S-RTC in it.
Edit : Daikaijyu is fom Hudson.

Alright, I took my SF7 apart to do some tests. And since it was apart anyways, I figured I'd finally answer some other questions I was curious about as well. Here's the results for those interested.

External cartridge connector:
pin 1 CLK - discussed below
pin 2-22 connected to SNES connector
pin 23 /RD - connects to pin 6 of ASIC
pin 24 CIC dataout - unconnected
pin 25-47 connected to SNES connector
pin 48 BA7 - pin 10 of ASIC
pin 49 /CART - pin 9 of ASIC
pin 50-53 connecto to SNES connector
pin 54 /WR - pin 4 of ASIC and also _TO SNES CONNECTOR_!!
pin 55 CIC dataout - unconnected
pin 56-62 connected to SNES connector


CLK line goes through 220 ohm (R36) to base of Q1 (surface mount NPN transistor, or Q2 can be populated instead which is a through hole part labelled 2N3904). Q1 Collector attached to Vcc, emitter connected to external cart pin 1 and also through 1k ohm (R37) to ground. So it is NOT inverted, but is "amplified" (although a Schmitt buffer would have been nicer).


All of these are as expected except pin 54. It looks like one could easily _accidentally_ overwrite the external cart SRAM.
Also note, pin 18 /IRQ is connected straight through (a very quick conductivity test shows the ASIC doesn't connect to this line).

(Also of note: on the SNES connector pin 26 is connected to pin 27 through a capacitor that was clearly added as an afterthought. I can't measure the capacitance well, but it seems to only be 18pF.)

-------------------------

I also was curious about the "option pads" next to the ASIC labelled S1,S2,S3,S4. I think I checked this already but has since been eaten with the death of the CherryROMs forum. All I could remember is setting S3 would change default language to english.

BIOS registers 8018-801B seem to be mirrored to 801C-801F.
Register 8019/801D show status of the "jumpers" (which pull some ASIC pins to ground).

bit0 - 0
bit1 - 1
bit2 - S1 (low if grounded)
bit3 - S2 (low if grounded)
bit4 - S3 (low if grounded)
bit5 - S4 (low if grounded)
bit6 - 0
bit7 - 0

Sadly I forgot to pay attention to which selected which language. However one language is already default, and there are only 3 languages total, so I'm not sure what all these options could do.

(I did notice that S3+S1 grounded gave an invalid language option that pointed below the last language on the list (Japanese), but it displayed just like Japanese.)

Now that the registers are known, someone can probably track down what they do (if anything) by looking at the BIOS code.

------------------------------

Other "option pads" I noticed on the board.

Disk Drive controller -
There were four near the disk drive controller in two pairs, one labelled "26 pin" and one labelled "34 pin". Each pair had one selected. I'm not sure what is special about those pins, but the FDD cable is 34 pin.

Security (CIC) chip -
There are two option pads to connect pin 1 of the CIC socket to external cartridge pad 24 (CIC data out), and pin 2 of the CIC socket to external cartridge pad 55 (CIC data out).

caitsith2 wrote:I happen to own not only an FEoEZ cart, but I also own an MDH cart and a SPL4 cart. (the other 2 SPC7110 games).

All 3 of those could be good, for extracting test data (first 2 byte combos) from their data rom.

That's great. Especially if you get your cart dumper working again.

caitsith2 wrote:As for that 8Mhz clock being sufficient, it was, due to the fact, that when you were doing decompression runs, or any other operation that takes some time to complete, You would just poll a specific register for that completion status. If you clocked it slower, it would just take longer to complete, is all, but it would happen.

Reading the decompression activation sequence, that seems completely logical. I hope that is the case, which means we could use _anything_ for the clock.

-------------

kammedo wrote:I had a chat with Darkforce yesterday. What is needed for the GDSF is

a) clock chip passed through
b) IRQ pin passed through
c) CIC of GDSF bypassed / disabled. It should use the one in the cart instead.

Also, for using a test program from the GDSF, you would have to map the $50 bank in passthrough, and switch to cart mode via a software reset.
I have to ask the details. I will see to get FEoEZ to work on my GDSF for now, while I wait to get the components for the cart mod.

Can you ask Darkforce to join this discussion?
Has he gotten it to run on the SF7 or SF3?

Step c does not make sense. For some co-processors, the CIC is built in. For the SPC7110 this is not the case, so it is not clear how this would make a difference. Also, the SF7 passes through the CIC lines from the SNES master CIC (it just sends the output from an internal CIC instead of the external, which since the cartridge CIC is in slave mode, it can't tell the difference if its output is ignored).

Step b is already standard on the SF7.

Step a is already provided by the SF7 as well (although it does not pass straight through it seems to be buffered/"amplified").

I have a feeling that Darkforce was helping by giving educated guesses instead of instructions.

neviksti wrote: Posted: Mon Jun 09, 2008 3:06 am

Hope you are not going to work tomorrow if you are actually in that time zone.

Yes I talked with Darkforce about this already, didnt directly ask him but I will today (dropping him a mail). I think he mentioned something about a GDSF back then, but I know he owns a SWC DX2, so its likely he modded that for doing his FEoEZ hacks.

Also, thanks for the GDSF information. As it seems you haven't lost your feeling with emulation, which is nice! I am taking the liberty to track this information in the GDSF doc i have on the YnT site, mind if I do?

Also, I was thinking about trying to bridge the Pin1 directly, to see if that's what makes the FEoEZ cart not work or not. Of course, amplifying the signal shouldnt make any difference, but perhaps creates some timing issues (before kyu shoots me down, im guessing here ). Would be nice to have bought that logical analyzer some time ago :/. Oh well.

Okay, I checked the SF3 now.

All cartridge pins go straight through except:
1 CLK
24 CIC data out
25 CIC data in
48 BA7
49 /CART
55 CIC data out
56 CIC clk

CLK goes through a 74LS00 (NAND gate) with pin8=cart CLK, pin9 =SNES CLK, and pin10=Vcc. So it IS inverted on this one.

As for options, the only ones I saw were:
4 pads by the CIC chip (I didn't check but I assume it is to use the external cartridge CIC instead)
and the 2 pairs of Disk controller option pads like before

Does anyone with more experience with disk controllers have a good guess as to what these options are?

---------------------
All my equipment has serious connectivity issues. I've tried cleaning everything the best I can but I still need to insert cartridges, or jiggle the Game Doctors around, several times before things work. For this reason I can never tell if there is an actual impossibility of a situation, but instead just that connection is bad again.

I tried the Super Game Boy on pass through in the SF3. After many tries I finally got it to start and at first didn't like the connection with the game boy game. A little more fiddling and that started to work okay as well. The game would run fine, but the graphics weren't quite lined up correctly on the screen. This seemed to be a problem somewhere before the super cartridge because the game boy game didn't crash or have any real trouble. I fiddled with the connections some more and could never get all three started again (game doctor, super gameboy, gameboy game). Fluke? I don't know.

I was able to play Stunt Race FX on passthrough on the SF7. I was even able to play an SDD1 game (Street Fighter Alpha 2) on the SF7, but the graphics weren't decompressing correctly (everything else worked fine, no crashes). Again, I can't tell if this is a connection issue, or a hardware CLK problem.

I never once could get the SF3 to boot up with the SDD1 game installed on top. I don't know if that is co-incidence, or if the SDD1 game does not respect the /CART signal (which it the only means for the SF3 to prevent conflicts).

Hopefully everyone else's equipment hasn't been neglected so long.
I'll keep trying to clean everything, but I hope you guys have better luck.

kammedo wrote:Hope you are not going to work tomorrow if you are actually in that time zone.

Actually it's worse. I'm +2 Hrs from that.
Oh well, I'll just be tired tomorrow/today.

kammedo wrote:Yes I talked with Darkforce about this already, didnt directly ask him but I will today (dropping him a mail). I think he mentioned something about a GDSF back then, but I know he owns a SWC DX2, so its likely he modded that for doing his FEoEZ hacks.

Do you have a SWC DX2 as well? I don't, so I don't know as much about them, but we probably could get that going if we needed to.

kammedo wrote:Also, thanks for the GDSF information. As it seems you haven't lost your feeling with emulation, which is nice! I am taking the liberty to track this information in the GDSF doc i have on the YnT site, mind if I do?

I just fixed more typos in my message since you posted. If you are taking the text verbatem, please take the text again.

kammedo wrote:Also, I was thinking about trying to bridge the Pin1 directly, to see if that's what makes the FEoEZ cart not work or not. Of course, amplifying the signal shouldnt make any difference, but perhaps creates some timing issues (before kyu shoots me down, im guessing here ). Would be nice to have bought that logical analyzer some time ago :/. Oh well.

Does this mean you've tried it on passthrough yourself and it did not work?
If it didn't work, what exactly happenned? Did the SF7 at least boot up? How it failed is important information to me, so please share all the details you have.

I do have a suggestion for improving connection reliability. Get some DeoxIT. This stuff really does improve connections. back when I first got both the 3.8 and 4.5 mm game bit, I was also given a sample of the stuff. You know the issues that nes systems seem to have where you have to blow on the connections repeatedly, to get them to work. Well, the deoxit applied to the nes cartridge, then inserted into the nes, greatly improved that, even to the point of not needing to push the game down for a complete connection. Now back to our topic.

neviksti wrote: Wow, that is really strange.
Which one did you use and what kind of power supply are you using? I had trouble with the XBand on passthrough at times due to the extra power it needed. I know, it is a long stretch here, but I can't think of what else would cause this as the Game Doctors only use the normal cartridge regions so I can't think of what would conflict.

How does the GDSF select the top connector? Perhaps gating ROMSEL isn't enough if the SPC decodes ROMSEL itself.

Power certainly isn't an issue, neither could be clock, IRQ, CIC or whatever since even with the SPC gone the ROM still starts so I think the BIOS and game ROM must conflict.

neviksti wrote:I haven't played with it much, but the memory mapping capabilities seem to be the same (even the trick $C0 byte works the same).

Well the SRAM limiting function is either different or absent from the SF3 for one.

EDIT:

neviksti wrote:Could you try this for us and let us know what happens?

The game works fine by setting all blocks to passthrough on a SF3.

kyuusaku wrote:
EDIT:

neviksti wrote:Could you try this for us and let us know what happens?

The game works fine by setting all blocks to passthrough on a SF3.

Could you try with only
a) bank $50
b) registers bank (=$00)
c) sram bank (defaults at 02 in FEoEZ)

EDIT : just realized from the dumpers GDSF header file :

"Also, the S-RTC address range (DKJM2) seems to be passed through by default."

kyuusaku wrote:How does the GDSF select the top connector? Perhaps gating ROMSEL isn't enough if the SPC decodes ROMSEL itself.

For the SF3 that is the only thing it can do. For the SF7 it seems to be at most be ROMSEL (which for clarity I called /CART above) and /RD.

So that seems like a reasonable guess to work with at this moment... the cart responds during BIOS reads and the GDSF doesn't expect it to.

kyuusaku wrote:Power certainly isn't an issue, neither could be clock, IRQ, CIC or whatever since even with the SPC gone the ROM still starts so I think the BIOS and game ROM must conflict.

I'm not entirely sure I understand. You have a cartridge with the SPC removed, and the BIOS still can't start up? Since the SPC controls the chip select for both ROMs I don't think the ROM would still start without it. I have a feeling I am misunderstanding something simple here.

kyuusaku wrote:

neviksti wrote:I haven't played with it much, but the memory mapping capabilities seem to be the same (even the trick $C0 byte works the same).

Well the SRAM limiting function is either different or absent from the SF3 for one.

Yep, you're right. I double checked and I got the "Nintendo copier warning" when I tried to dump and run a game. Thanks for the info.

kyuusaku wrote:

neviksti wrote:Could you try this for us and let us know what happens?

The game works fine by setting all blocks to passthrough on a SF3.

YES! YES!

I'll try to write up some dumper code later.

Seiko Epson (JP,08-29-1997):

http://www.freepatentsonline.com/6055273.html (Text)
http://www.mediafire.com/?9mud9vxrjjl (PDF)

This talks about an adaptive RLE method. Bitplane splicing. Fundamentally simple idea.
There's some minor quirks that differ from ABS.

Currently still reading it. Might be worthwhile sharing.
Doesn't seem to be cross-referenced anywhere.