This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES version of Balloon Fight resets on a VS red tent, why?

NES version of Balloon Fight resets on a VS red tent, why?
by on (#179029)
Over the Labor Day weekend, I decided I wanted to convert some of my favorite NES games to the VS system. So like any other self-respecting nerd, I downloaded the Balloon Fight (USA) NES ROM, stripped the NES header off of it, split it into the PRG and CHR ROMs, burned them onto (3) 2764 chips, installed them in my red tent with a 2C03 PPU, and voila! I'm playing Balloon Fight. Players 1 and 2 are swapped, and I have to press 3P for Start, but I can play the 1P game as long as I want -- but if I play 2P Battle Mode, the ROM resets after one of the player dies (or at least I think that's the pattern).

So here is the burning question:

Quote:
Does anyone know of a specific reason why the reset would happen during a 2-player game? I know the registers are swapped for player controls from the NES, but would this have anything to do with something I read elsewhere on this board about needing to read from $4017 (I think that was the location) at least once every second?


Or, if nobody knows the reason why it would happen, can anyone suggest a good investigative tactic to pinpoint the issue? I've considered bundling the ROMs up into a .ZIP and trying to debug the behavior with an emulator, but I'm not sure if the emulators out there would definitely reproduce the issue, so tips on doing that would be appreciated as well.

I'm not above modifying the ROM, if I can pinpoint with a debugger what code causes the issue.

The Why:

So Balloon Fight is a readily available game for the VS system, so why would I bother? Well, it's a 12-ROM game that requires using both sides of the red tent, with the only payoff being that each player can have their own screen. In my opinion, that's a serious design flaw and makes owning Balloon Fight on the red tent a tragedy, as it leaves the other side unavailable for something that 2 other people could be playing.

Pic of title screen
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179030)
lupin3rd wrote:
if I play 2P Battle Mode, the ROM resets after one of the player dies (or at least I think that's the pattern).
After either player dies? Or is it always after player 2 (i.e. what the Vs. System calls player 1) dies?

Quote:
I read elsewhere on this board about needing to read from $4017 (I think that was the location) at least once every second?
That's my best guess.

I assume the ROMs were in the "slave" slot ?


You should be able to get away with putting the NES Balloon Fight ROMs in the "master" slot and some actually-intended-for-the-Vs-System game into the "slave" slot, since the watchdog only cares about the slave CPU.


Quote:
trying to debug the behavior with an emulator, but I'm not sure if the emulators out there would definitely reproduce the issue, so tips on doing that would be appreciated as well.
Unfortunately, I don't think any emulators implement the watchdog timer.

However, you should be able to use any ordinary emulator-with-debugger to check if the game stopped reading from $4017 after the relevant player died.

Quote:
So Balloon Fight is a readily available game for the VS system, so why would I bother?
I suppose you don't mind the game not requiring credits either?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179033)
Quote:
I assume the ROMs were in the "slave" slot ?

Actually, they were on the slave side of the board... Hmm... (Runs out to garage to try swapping sides)

HOLY COW. That worked! Any idea what the technical reason is behind it? I'm just wondering if there's any type of modification I could do to the ROM image to keep that from happening if I wanted to run a different NES game on the slave side...

Quote:
I suppose you don't mind the game not requiring credits either?

Nope, not at all. This is purely a convenience for myself, friends, and family. :) Hey, I really appreciate that suggestion about trying it out on the master side!
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179036)
First thing to try is BIT $4017 somewhere in the NMI handler. It might be tough if Balloon Fight is tightly packed though.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179042)
So, yeah, it worked because the watchdog timer only watches the "slave" CPU, and not the "master" CPU.

Theoretically, the game in the "slave" slot should make sure that the "master" CPU hasn't crashed (by making sure that the "master" CPU gives RAM / asserts IRQ on the slave occasionally) and intentionally fail the watchdog if so. But I can't imagine any games actually do that, other than the explicitly two-screen games.


It shouldn't be too hard to inject the necessary extra reads from $4017 in an Not-for-Vs-System game; it's very rudimentary ROM hacking, but specifics really want a bit of comfort with 6502 assembly.


On an entirely unrelated note, would you be willing to run the Vs. System characterization ROM I wrote? We do already have data from Memblers's Vs. System, but it'd be nice to get a second data point at all.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179050)
Quote:
On an entirely unrelated note, would you be willing to run the Vs. System characterization ROM I wrote? We do already have data from Memblers's Vs. System, but it'd be nice to get a second data point at all.

Hey, that sounds like fun! I read the whole thread you linked me to, but I'm not sure what objectives we're testing here.

I have several revisions of the VS board, but I think only 2 of them are currently working correctly. That may help identify any potential issues as well. I downloaded the file and extracted it, but I might need a little more information about what's going on in there. (Didn't see a README file in the archive)

Just throw me a hint about what to do with the files. Am I just using my own copy of SMB ROMs, and then burning and subbing in the CHR file in this archive? You can PM me if you want to take the conversation out of this thread, but I'm turning in for tonight.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179051)
If you already have a Vs. SMB ROM set around, you can just use its CHR (i.e. use it for ROM 2A or 8A).

If you don't have a Vs. SMB, then ... uh. The contents of the 768-byte CHR file are the minimal font-only copyright-not-infringing subset of the SMB CHR, and you could either program it in a 4 KiB ROM ... or just extract the CHR from the bundled NES ROM and program that into a 8 KiB ROM. Or I could quickly spin up another build for whatever CHR you already have programmed (just tell me what game)

Program the "e000.bin" file and run it in 1A or 6A.

The tests worth repeating are:
• "watchdog timeout" (only when running from "slave" CPU; this test should fail when running on the "master" CPU)
• "coindrop duration" (both CPUs)
• "coin counter speed" (both CPUs)
and, because I added this after Membler's test, the "2002 readback" and "dipswitches" values at the bottom of the main screen
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179083)
lidnariq wrote:
If you already have a Vs. SMB ROM set around, you can just use its CHR (i.e. use it for ROM 2A or 8A).

Yeah, I probably have 2 sets, so no worries there. Sounds easy enough. So am I understanding correctly, that this is basically a tool to test/time some behavior on the hardware? Is there any reason to run the tests on both sides, or does it really only make sense to run it on one side? If that's the case, should it be the master or slave side?

My apologies for all the questions, but I'm a bit of a stranger on this forum, so I don't have a lot of knowledge about everyone's projects or really any context about what's happening around here. :) I am super stoked to help out with this testing, though. I think I'm using the MDS-04-CPU board, but I think I also have an -05 and an -02, just not sure which ones are working currently. Results may vary slightly on the revisions I'm sure.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179107)
lupin3rd wrote:
this is basically a tool to test/time some behavior on the hardware?
By now, yes. The other lines in the test framework were originally verifying some weirder things that I wasn't certain about from the schematic.
Quote:
Is there any reason to run the tests on both sides, or does it really only make sense to run it on one side? If that's the case, should it be the master or slave side?
Slave side is necessary to test the watchdog timeout; testing the other properties on the master side would just get another round of duplication.

All the coin counter and coin drop tests are actually testing properties of the cabinet... but since the Vs. System isn't JAMMA that's still related.


One (minor) reason to test on both sides is that I very recently just noticed that there's theoretically one bit (in the "dipswitches" value) that should differ when running on the "master" and "slave" sides, and verification would be nice.

Quote:
My apologies for all the questions
Perfectly fine!
Quote:
Results may vary slightly on the revisions I'm sure.
AFAIK, the "dipswitches" value and the watchdog timeout are the only places I'd expect variation across mainboard versions.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179196)
Here's the results of my tests. I'm not sure if I was comprehensive enough, or if my captions to these photos make sense. Ultimately, we ran the tests on the Slave side first, and then the master side. The only weird anomalies were that none of the coin counter operations worked as expected, we never even saw the counter move; also, the test suite wouldn't run if switch 8 on bank 1 was in the off position.

Album of test results
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179197)
I think that covered everything? Thank you! It's good to know that your machine's coin drops are a little faster than Memblers's.

That DIP switch behavior ... The characterization ROM doesn't do anything with the DIP switches except print the value to the screen there. The number in that last photo only indicates all DIP switches are ON... could something else be wrong?

Also, in what order do the pictures of the slave side DIPs go? Is that https://i.imgur.com/eEvZjPV.jpghttps://i.imgur.com/33LEHbm.jpg and https://i.imgur.com/mDWg5AR.jpghttps://i.imgur.com/mDWg5AR.jpg ... or vice versa?


I have to admit I'm confused about the coin counter. I'm certain I didn't change any of that from the previous version I'd asked Memblers to run. (I assume it worked on the games you had?)

Transcribing contents of photos:
• Slave Side: 2002 READBACK IS 00 1F / DIPSWITCHES ARE 80 00 / RP2C04-0004
• Slave Side: Watchdog 043227 [ ≈ 1.24s ]
• Slave Side: Coin Drop 1E6E 1A64 [ ≈ 48.3ms 41.9ms ]
• Slave Side: Shared memory test [ RAM always enabled as expected ]
• Dips Both Banks Off
• Slave Side Dips: $98 $FC [ when a DIP switch is "on" it shorts the pin to ground, corresponding to logic 1 thanks to 74LS240 ]
• Dips All On
• Master Side: Watchdog did not occur [as expected]
• Master Side: Shared memory test: as expected ($4016.1 clear disables master's access to RAM; $4016.1 set enables it; there's 2 KiB of it and it's mirrored in a 8KiB window)
• Master: Dips all off except bank 1, switch 8: Test PRG wouldn't boot without it set
• Master Dips: 18 FC / RC2C03
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179199)
Okay, so maybe a little clarification is in order. The test ran fine on the slave side regardless of dip switch status. It was only after moving to the master side that it suddenly took issue with switch 8 in bank 1. Disclaimer: I was lazy, so I left my quirky NES Balloon Fight in the system (but on the slave side) during the characterization test on the Master side. In hindsight, this was probably a bad idea.

Question: There are 2 different types of CPUs in my collection of VS hardware. A 2A03 and 2A04. My understanding is that the 2A04 is for use on the master side, when only one game is installed on the board (in the slave side). So is this a dummy CPU? For my tests, I had a 2A03 on both sides... should I have had a 2A04 on the master side?

I can run more tests for you, if you like. I'm not above shooting video either, so the order of steps and results makes more sense. I had not tried dropping coins into my machine since I had owned it, and the coin mechs were slightly bent. I couldn't even run the test because the switches would get stuck in the closed position. After fixing the bends, the switches would spring back correctly.

My friend Brian came over, and he's been hanging around reading this page and its contents for the last 10 years or more -- he was stoked to help too. If you add new tests or want me to try running it on my other working board, I can do that too. Also, if you prefer that I run a real VS game on the opposite side (or no game), then I can oblige those requests as well. :)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179203)
2A04 just allows the other side to take control of the shared RAM, I think. That's why you can't run two Vs. SMB: it needs the RAM to cache things, probably level data or something read out of CHR ROM.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179206)
lupin3rd wrote:
It was only after moving to the master side that it suddenly took issue with switch 8 in bank 1.
To make sure I understand: DIP switch bank 1 is the bank for the master CPU, and DIP switch bank 2 is for the slave CPU?

So theoretically, whatever is in the master CPU shouldn't be able to care about what's going on in bank 2, and vice versa?

What's confusing me is the bit where your picture in the album ( https://imgur.com/KlZBirb ) shows DIP switches 1-7 as OFF, but the value on-screen ( https://imgur.com/V45mBgb ) shows all DIP switches as ON. Hence asking about temporal order. And also asking if anything's seemed suspicious when games are run on the master side of this specific board.

Quote:
I left my quirky NES Balloon Fight in the system (but on the slave side) during the characterization test on the Master side.
I would have assumed that would have caused the system to reboot every... oh, right, it only fails the watchdog after a 2 player game when the first player dies. Right. Ok. No, I don't think that should change things.

Quote:
My understanding is that the 2A04 is for use on the master side, when only one game is installed on the board (in the slave side). So is this a dummy CPU?
As far as we know, the 2A04 is "just" a jumper between pin 20 and pin 38, causing the shared RAM to always be granted to the "slave" CPU. (For example, Vs. SMB relies on having access to that extra 2 KiB of RAM, but its documentation also says several other games—but not all—are sufficiently equivalent to the 2A04)

If you're willing to sit down with a multimeter and see if that is true, that would be helpful! (And maybe see if any other pins are shorted, too?)

Quote:
I can run more tests for you, if you like. I'm not above shooting video either, so the order of steps and results makes more sense. I had not tried dropping coins into my machine since I had owned it, and the coin mechs were slightly bent. I couldn't even run the test because the switches would get stuck in the closed position. After fixing the bends, the switches would spring back correctly.
Well, thefox wrote this test that detects the not-missing PPU pixel on the 2C03. I guess it would be nice to verify the same is true on the 2C04... except that it's no longer accessible :(

There's a few other things mentioned on the wiki here that we don't know, but determining them might require writing some more tests. (And possibly adjusting the CRT image position, but we'll try to work around that)

If we do write some tests, do you have any of the Vs. System daughtercards that add a more complicated memory manager hardware (e.g. 108 or VRC or MMC1)? And/or have you modified your mainboard to support Vs. Gumshoe?

[From other thread] Oh, you have the UNROM daughterboard. Could you try tepples's test suite? A lot of the tests won't be relevant on a SD CRT, or sensible on a RGB PPU, but a few (like the "overscan" test) would be nice to have data from.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179209)
lidnariq wrote:
Well, thefox wrote this test that detects the not-missing PPU pixel on the 2C03. I guess it would be nice to verify the same is true on the 2C04... except that it's no longer accessible :(

I can rehost the test, but I guess it would be better if somebody rewrote it altogether to be more robust and to provide a non-boolean result. :) I guess it might work best if it tracked the number of VBLs with NMI during the delay loop, and also measured the time to the last VBL after the delay loop exits.

(Or maybe that nocash test that he posted further down is sufficient, I'm not exactly sure what it's measuring.)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179221)
lidnariq wrote:
To make sure I understand: DIP switch bank 1 is the bank for the master CPU, and DIP switch bank 2 is for the slave CPU?

Yes.
lidnariq wrote:
So theoretically, whatever is in the master CPU shouldn't be able to care about what's going on in bank 2, and vice versa?

That is my understanding, as I didn't see Balloon Fight resetting or any other weird behaviors. I was asking the same question, though, as I'm not sure. :)
lidnariq wrote:
What's confusing me is the bit where your picture in the album ( https://imgur.com/KlZBirb ) shows DIP switches 1-7 as OFF, but the value on-screen ( https://imgur.com/V45mBgb ) shows all DIP switches as ON. Hence asking about temporal order. And also asking if anything's seemed suspicious when games are run on the master side of this specific board.

I may have gotten one of the pictures out of sequence, although I do remember the reported dip values seeming odd on 1 or 2 occasions. I'll try to re-test late tonight and clarify the dip settings.
lidnariq wrote:
As far as we know, the 2A04 is "just" a jumper between pin 20 and pin 38, causing the shared RAM to always be granted to the "slave" CPU. (For example, Vs. SMB relies on having access to that extra 2 KiB of RAM, but its documentation also says several other games—but not all—are sufficiently equivalent to the 2A04)

So does that mean it isn't a CPU at all, and literally just a DIP package jumping pins 20 and 38?
lidnariq wrote:
If you're willing to sit down with a multimeter and see if that is true, that would be helpful! (And maybe see if any other pins are shorted, too?)

That is absolutely something I'm willing to do. I've got a decent meter, and I can check those things easily for you.
lidnariq wrote:
Well, thefox wrote this test that detects the not-missing PPU pixel on the 2C03. I guess it would be nice to verify the same is true on the 2C04... except that it's no longer accessible :(

I'm not sure I'm following, unless you meant the 2 palette colors that are different on that PPU.
lidnariq wrote:
If we do write some tests, do you have any of the Vs. System daughtercards that add a more complicated memory manager hardware (e.g. 108 or VRC or MMC1)? And/or have you modified your mainboard to support Vs. Gumshoe?

OH YEAH. I got you covered there, I think I have almost all of them, except for 1, and a friend has that one. I also have almost all of the varieties of PPUs, if that helps anyone. FYI, the auto detect of PPUs didn't seem to work for the RC2C03B PPU that I was using. I always had to press right once to select that PPU. Edit: My boards do not appear to have the memory mod on either one of them. I wouldn't mind doing it on one of the boards if it helps anyone here out.
lidnariq wrote:
[From other thread] Oh, you have the UNROM daughterboard. Could you try tepples's test suite? A lot of the tests won't be relevant on a SD CRT, or sensible on a RGB PPU, but a few (like the "overscan" test) would be nice to have data from.

Yes, that should be no problem. In fact, if we want to know what happens on an SD TV, I have a NES-pulled PPU that we could drop in, and I could run the composite line to a nearby Sony monitor that I have...
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179229)
lupin3rd wrote:
lidnariq wrote:
Well, thefox wrote this test that detects the not-missing PPU pixel on the 2C03. I guess it would be nice to verify the same is true on the 2C04... except that it's no longer accessible :(

I'm not sure I'm following, unless you meant the 2 palette colors that are different on that PPU.

The NTSC NES PPU (2C02) takes a 945/44 = 21.4773 MHz clock input and produces a video signal that's 1364 master clocks (341 pixels) wide by 262 scanlines tall, including blanking, for a total of 357368 master clocks per field. But when rendering is enabled, every other field is shorter by four master clocks (one pixel) because one pixel is removed from the horizontal blanking between the pre-render line and the first picture line. This is done to align the color subcarrier from one field to the next, producing a 2-frame cycle that TVs may handle better than a 3-frame cycle. Thus the average field is (357368 + 357364) = 357366 master clocks long, for a field rate of 945/44*1000000/357366 = 60.0988 Hz.

But because the RGB PPU (2C03, 2C04, 2C05) doesn't have a color subcarrier, it doesn't need to drop the extra dot. Thus every field is 357368 master clocks long, for a field rate of 945/44*1000000/357366 = 60.0985 Hz.

The difference between 357366 and 357368 master clocks is one CPU cycle (12 master clocks) every six fields. By waiting for this difference to accumulate over the course of several fields, such as while a copyright notice is displayed, a program can distinguish an RGB PPU from an NTSC PPU. A homebrew game might use this information to A. replace $2D gray with $00 gray or B. use (slower, less smooth) palette modifications instead of color emphasis.

lupin3rd wrote:
FYI, the auto detect of PPUs didn't seem to work for the RC2C03B PPU that I was using. I always had to press right once to select that PPU.

How does the autodetect work? Is there really a difference between 2C03 and 2C04 other than the palette ROM inside the PPU? I know 2C05 has swapped $2000 and $2001 and a signature on $2002, but are 2C05 PPUs common enough in the wild that Vs. homebrew ought to support them?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179240)
lupin3rd wrote:
OH YEAH. I got you covered there, I think I have almost all of [the daughterboards], except for 1, and a friend has that one.
There are a few lot of questions about the daughterboards, actually..
1- For the VRC-using one (for Vs. Goonies and Vs. Gradius), could you find out what (if anything) VRC pins 15 and 17 are connected to?
(Maybe also verify the pins with question marks next to them on http://wiki.nesdev.com/w/index.php/VRC1_pinout ? )
2- Do you have any of the 108-using ones with the additional copy protection ICs? (126 for "TKO Boxing", 127 for "Atari RBI Baseball", and ??? for "Super Xevious")
If so, I'd like to write a test that will shed some more light on what they're doing. All we have right now is Nocash's notes.
2b- Actually, I'd like to run some arbitrary code on a 108 to see if we can figure out more specifics about a bug that Naruko found.
3- If you have the SUNSOFT-3 using Vs. Platoon, we don't have a pinout for that chip. It'd be nice to get one.

4- Lots of the daughterboards have extra hardware (DIP switches, other ICs) on them but the manuals don't say anything about them. It'd be nice to know what's going on with them...
(For example: the VRC-using 302163 has a 74LS00 and a 74LS32. Vs. Platoon has a 74LS04 and four switches. RBI has a 74LS139 and two 74LS00s. What are all these things doing?)

Quote:
I also have almost all of the varieties of PPUs, if that helps anyone.
there is a question about the 2C05-02: wiki talk. It'll need another test written.

Quote:
FYI, the auto detect of PPUs didn't seem to work for the RC2C03B PPU that I was using. I always had to press right once to select that PPU.
The autodetection can only detect the 2C05. I don't think there's any way for the software to detect which of the other five PPUs it's running on.

tepples wrote:
are 2C05 PPUs common enough in the wild that Vs. homebrew ought to support them?
As far as I know, the 2C05s each matched to one game and only one game. I don't think they're meaningfully differently rare than each of the 2C04 PPUs...

For a characterization test it was easy enough to add the logic to detect 2C05s and automatically switch $2000 and $2001 as appropriate.

And for "ordinary" use it's utterly trivial to change two assemble-time constants to support them, and that's easier than reworking all the palette handlers for the 2C04s...

lupin3rd wrote:
My boards do not appear to have the memory mod on either one of them. I wouldn't mind doing it on one of the boards if it helps anyone here out.
Nah, no need. It only would have been useful if we'd had a set of tests we wanted to put together and you hadn't had any daughterboards.

lupin3rd wrote:
Yes, that should be no problem. In fact, if we want to know what happens on an SD TV, I have a NES-pulled PPU that we could drop in, and I could run the composite line to a nearby Sony monitor that I have...
Tepples has been developing the 240p test suite against a SD CRT TV, so most of that behavior is known. It's mostly just figuring out how the RGB PPUs differ.


Here's a list of a few other things that might be interesting to check, but will need tests written or found:
• Do writes to $2003 corrupt the sprite table (like the 2C02)?
• Does leaving the value in $2003 at a value of 8 or higher corrupt the sprite table (like the 2C02)?
• Is it possible to read back the sprite table via $2004 (like the 2C02E and 2C02G, unlike the 2C02, 2C02A, 2C02C)?
• Is palette readback completely missing? (previous test implies yes)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179243)
Okay, so I have the following daughterboards:

  • Gradius (Goonies) board
  • Atari RBI Baseball
  • VS Castlevania

I think that's all I have currently. So there are definitely more that I don't have, but I wasn't making the distinction between the different types of copy protection, etc. And I also have access to a VS Dr. Mario board. I'm actively working on fleshing out my collection of these items, so this list may be subject to change.

I can definitely figure out where some of those pins are going.
lidnariq wrote:
there is a question about the 2C05-02: wiki talk. It'll need another test written.

Is that the Gumshoe PPU? If so, I have it, but I have not verified that it works since i don't have a gun setup yet. I may be able to help there. If it's NOT the Gumshoe PPU, I don't have it.
lidnariq wrote:
The autodetection can only detect the 2C05. I don't think there's any way for the software to detect which of the other five PPUs it's running on.

Okay, since it said "auto detecting PPU" and came up with nice colors, I assumed it worked -- but I guess I was using an SMB PPU 2C04-0001, which is probably the default for the test suite. Since you can't read palette data back, and there is no difference with registers, that makes sense.

I believe I have the following PPUs (at your disposal, if you want testing done with any of them):

  • 2C02G (or whatever a standard USA NES-001 used)
  • RP2C04-0001 (Works)
  • RP2C04-0002 (Works)
  • RP2C04-0003 (Works)
  • RP2C04-0004 (Works)
  • RC2C03B (Works, but I have to be careful with it, because it has about 8 leg-repairs on it; chip was corroded when I got it)
  • RC2C05-03 (Not sure if working)

I have one NES that is in a desoldered state, where the RAM, CPU, PPU, and CIC chips have all been removed. I was planning on socketing all of it, so that I could begin some of my own experiments. Doubtful it would help anyone, but if any weird Frankenstein testing is needed, that too is available.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179245)
lupin3rd wrote:
Atari RBI Baseball
Oo. Ok.

We know the pinout of the 108 ... as well as the CPU and PPU and ROMs.

Certainly right now I could write something that would just dump more bits of the stream that nocash wrote about, but to do anything more clever I'd need to know how the other ICs are attached.

lupin3rd wrote:
Is [the 2C05-02] the Gumshoe PPU? If so, I have it, but I have not verified that it works since i don't have a gun setup yet. I may be able to help there. If it's NOT the Gumshoe PPU, I don't have it.
No, it's the Mighty Bomb Jack PPU. Gumshoe is the 2C05-03...

Quote:
I believe I have the following PPUs (at your disposal, if you want testing done with any of them):
I don't think there's any tests we'll need to try the other PPUs for, other than the two you have in your red tent right now.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179246)
lidnariq wrote:
... but to do anything more clever I'd need to know how the other ICs are attached.

Okay, I can do some tracing on the Atari RBI Baseball daughterboard to see where the pins in question are going.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179266)
lidnariq wrote:
1- For the VRC-using one (for Vs. Goonies and Vs. Gradius), could you find out what (if anything) VRC pins 15 and 17 are connected to?

Pin 15, is a solder pad that is not connected by default, but if it were bridged, it would be circling back to pin 20 on the VRC. Pin 17: No connection.
lidnariq wrote:
(Maybe also verify the pins with question marks next to them on http://wiki.nesdev.com/w/index.php/VRC1_pinout ? )

VRC question mark pins (as found on the Gradius daughterboard labeled - MDS-EXP1-01 R-7HB KONAMI 302163):

  • Pin 25: PPU A12 (Pin 26)
  • Pin 24: No connection
  • Pin 23: No connection
  • Pin 21: CPU R/W (RP2A03 Pin 34)
  • Pin 19: PPU A13 (Pin 25)
  • Pin 18: PPU /RD (Pin 24)
  • Pin 17: No connection
  • Pin 16: LS32 (U1) 3Y (Pin 8)

lidnariq wrote:
2b- Actually, I'd like to run some arbitrary code on a 108 to see if we can figure out more specifics about a bug that Naruko found.

Let me know when the test is written, and I can give you the output. :)

lidnariq wrote:
4- Lots of the daughterboards have extra hardware (DIP switches, other ICs) on them but the manuals don't say anything about them. It'd be nice to know what's going on with them...
(For example: the VRC-using 302163 has a 74LS00 and a 74LS32... snip... RBI has a 74LS139 and two 74LS00s. What are all these things doing?)

VRC-using 302163:

74LS00 (U2) - Quad Input NAND Gate
  • Pin 7 (Gnd): GND
  • Pin 8 (1Y): 74LS32 (U1) Pin 1 (1A) and Pin 9 (3A)
  • Pin 9 (1A): CPU A15 (Pin 19)
  • Pin 10 (1B): CPU M2 (Pin 31)
  • Pin 14 (Vcc): 5V

74LS32 (U1) - Quad Input OR Gate
  • Pin 1 (1A): Connected to Pin 9 (Also 74LS00 1Y Pin 8)
  • Pin 2 (1B): GND
  • Pin 3 (1Y): Connected to 2A (Pin 4)
  • Pin 4 (2A): Connected to 1Y (Pin 3)
  • Pin 5 (2B): GND
  • Pin 6 (2Y): Connected to 4A (Pin 12)
  • Pin 7 (Gnd): GND
  • Pin 8 (3Y): VRC (Pin 16)
  • Pin 9 (3A): Connected to Pin 1 (Also 74LS00 1Y Pin 8)
  • Pin 10 (3B): Bridged to Pin 11
  • Pin 11 (4Y): Bridged to Pin 10
  • Pin 12 (4A): Connected to 2Y (Pin 6)
  • Pin 13 (4B): GND
  • Pin 14 (Vcc): 5V

74LS373 (U5) - Octal D Type Transparent Latches and Edge Triggered Flip Flops
  • Pin 1 (/OC): GND
  • Pin 2 (1Q): CHR A7 (Pin 3)
  • Pin 3 (1D): CHR Q7 (Pin 19)
  • Pin 4 (2D): CHR Q5 (Pin 17)
  • Pin 5 (2Q): CHR A5 (Pin 5)
  • Pin 6 (3Q): CHR A3 (Pin 7)
  • Pin 7 (3D): CHR Q3 (Pin 15)
  • Pin 8 (4D): CHR Q1 (Pin 12)
  • Pin 9 (4Q): CHR A1 (Pin 9)
  • Pin 10 (Gnd): GND
  • Pin 11 (C): PPU ALE (Pin 39)
  • Pin 12 (5Q): CHR A0 (Pin 10)
  • Pin 13 (5D): PPU AD0 (Pin 38)
  • Pin 14 (6D): PPU AD2 (Pin 36)
  • Pin 15 (6Q): CHR A2 (Pin 8)
  • Pin 16 (7Q): CHR A4 (Pin 6)
  • Pin 17 (7D): PPU AD4 (Pin 34) (and CHR Q4 Pin 16)
  • Pin 18 (8D): PPU AD6 (Pin 32) (and CHR Q6 Pin 18)
  • Pin 19 (8Q): CHR Q7 (Pin 4)
  • Pin 20 (Vcc): 5V
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179296)
lupin3rd wrote:
VRC-using 302163:
Pin 15, is a solder pad that is not connected by default, but if it were bridged, it would be circling back to pin 20 on the VRC.
So that solder pad would make it possible use a 28-pin 128 KiB CHR ROM ... which is almost useless because no programmable 28-pin 128 KiB ROMs were ever made. But I guess you could desolder the Mask ROM from any of the famicom VRC-using games.

Quote:
74LS00 (U2) - Quad Input NAND Gate
And the other three NAND gates aren't used? Ok, so this is generating /ROMSEL from M2 and A15, like the NES mainboard. Because the VRC needs that inverted signal...

Quote:
74LS32 (U1) - Quad Input OR Gate
This is so much weirder than I would have thought. It's using the four OR gates as a pulse-narrow-er, so that the signal rises the moment M2 or A15 falls, but takes a while to fall after both M2 and A15 are high.

Quote:
74LS373 (U5) - Octal D Type Transparent Latches and Edge Triggered Flip Flops
... Right, of course the daughterboard needs its own latch for the PPU. It doesn't plug into the CHR ROM sockets on the mainboard, so it has to re-derive that.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179321)
Let me know when you're ready to crack the mysteries of the VS RBI Baseball daughterboard.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179323)
I think I'm satisfied with the VRC now, so it'd be lovely if you could determine the connectivity of the 74'139, the two 74'00s, the DIP switches, the 127, and ... what are those two diodes (1S1588) doing?

I'm idly curious what's going on with the PRG2 socket (mostly, where does it differ from PRG1? I suppose it might be designed to take two 64 KiB 'PROMs for ROM, and part of the '139 and the DIP switches might let you control whether one socket, the other, or both sockets are available to the game?)

No need to check the 74'373, we can be confident it's identical in function (if not the exact same pinout) as when it's on the VRC board.

I've started working on something that will hopefully be able to shed light on Naruko's bug ... would you rather have to program more ROMs, or wait for me to get everything into a single image?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179347)
lidnariq wrote:
I think I'm satisfied with the VRC now, so it'd be lovely if you could determine the connectivity of the 74'139, the two 74'00s, the DIP switches, the 127, and ... what are those two diodes (1S1588) doing?

Okay, I'll report back after I've mapped those things out. May take me an extra day or two, as I'm covered up all day tomorrow.

lidnariq wrote:
I'm idly curious what's going on with the PRG2 socket (mostly, where does it differ from PRG1? I suppose it might be designed to take two 64 KiB 'PROMs for ROM, and part of the '139 and the DIP switches might let you control whether one socket, the other, or both sockets are available to the game?)

That's my understanding, too, that an additional PRG ROM could be provided, but I'm not aware of any games that actually used that option...

lidnariq wrote:
I've started working on something that will hopefully be able to shed light on Naruko's bug ... would you rather have to program more ROMs, or wait for me to get everything into a single image?

I don't mind burning additional ROMs. I like helping out around here, so if I can get info quicker to you by running tests as you make them, that's what I'll do. Plus, it may be helpful for me to run the tests as they are developed, because we might have some bug fixes/QA discoveries or additional test ideas that pop up as we move along. :)

Follow-up on Dipswitches:

  • When all dips are set in the OFF position, and running the test suite on the slave side, the system reports: 80 00
  • When all dips are set in the ON position, and running the test suite on the slave side, the system reports: 98 FC

I will run the test on the master side tomorrow to see if the dips report differently.

Just wanted to take a second to thank you guys for being so helpful with all my questions. Not used to that treatment online, and I'm awestruck with how much work you guys have put in to keep the wiki updated and accurate.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179444)
lidnariq wrote:
I think I'm satisfied with the VRC now, so it'd be lovely if you could determine the connectivity of the 74'139...

74LS139 Dual 2-Line to 4-Line Decoder / Demultiplexer
Pin 1 /1Enable: Pin 11
Pin 2 1Da: PRG1 and PRG2 A12 (Pin 2)
Pin 3 1Db: CPU A13 (Pin 17)
Pin 4 /1Y0: NC
Pin 5 /1Y1: (127) Pin 20
Pin 6 /1Y2: NC
Pin 7 /1Y3: NC
Pin 8 GND: GND
Pin 9 /2Y3: NC
Pin 10 /2Y2: NC
Pin 11 /2Y1: Pin 1
Pin 12 /2Y0: NC
Pin 13 2Db: 74HC00 Y3 (Pin 8)
Pin 14 2Da: NC
Pin 15 /2Enable: (127) Pin 22
Pin 16 VCC: +5V

lidnariq wrote:
... the two 74'00s ...

There is a 74HC00 and a 74HC08...

74HC00P Quadruple 2-input Positive NAND Gate
Pin 1 A1: GND
Pin 2 B1: GND
Pin 3 Y1: NC
Pin 4 A2: NC
Pin 5 B2: 74LS139 2Db (13) + CPU A15 (19)
Pin 6 Y2: 108 (10)
Pin 7 GND: GND
Pin 8 Y3: 127 (22) + 74LS139 /2E (Pin 15)
Pin 9 A3: CPU (31) Bridged to Pin 10
Pin 10 B3: CPU (31) Bridged to Pin 9
Pin 11 Y4: PRG1 (20)
Pin 12 A4: PRG2 (20) Bridged to Pin 13
Pin 13 B4: PRG2 (20) Bridged to Pin 12
Pin 14 Vcc: +5V

M74HC08P Quadruple 2-input Positive AND Gate
Pin 1 A1: GND
Pin 2 B1: GND
Pin 3 Y1:
Pin 4 A2: GND
Pin 5 B2: GND
Pin 6 Y2:
Pin 7 GND: GND
Pin 8 Y3: 108 (Pin 7)
Pin 9 B3: Bridged 10 -> Dip3
Pin 10 A3: Bridged 9 -> Dip3
Pin 11 Y4: PRG1 (Pin 1)
Pin 12 B4: Bridged 13
Pin 13 A4: Bridged 12
Pin 14 Vcc: +5V

lidnariq wrote:
... the DIP switches ...

Dip 1: 108 (Pin 28) - when closed - connects to 74HC08 (Pins 12+13)
Dip 2: PRG1 + PRG2 (Pins 27) - when closed - connects to same PRG1+PRG2 (Pins 27)
Dip 3: 108 (Pin 12) - when closed - connects to 74HC08 (Pins 9+10)
Dip 4: 108 (Pin 13) - when closed - connects to CHA (Pin 27)

lidnariq wrote:
... the 127 ...

Custom 1 (127):

Pin 1: CPU (Pin 40)
Pin 2: NC
Pin 3: PRG2 A7 (Pin 3) and PRG1 (Pin 3)
Pin 4: PRG2 A6 (Pin 4) and PRG1 (Pin 4)
Pin 5: PRG2 A5 (Pin 5) and PRG1 (Pin 5)
Pin 6: PRG2 A4 (Pin 6) and PRG1 (Pin 6)
Pin 7: PRG2 A3 (Pin 7) and PRG1 (Pin 7)
Pin 8: PRG2 A2 (Pin 8) and PRG1 (Pin 8)
Pin 9: PRG2 A1 (Pin 9) and PRG1 (Pin 9)
Pin 10: PRG2 A0 (Pin 10) and PRG1 (Pin 10)
Pin 11: PRG2 D0 (Pin 11) and PRG1 (Pin 11)
Pin 12: PRG2 D1 (Pin 12) and PRG1 (Pin 12)
Pin 13: PRG2 D2 (Pin 13) and PRG1 (Pin 13)
Pin 14: GND
Pin 15: PRG2 D3 (Pin 15) and PRG1 (Pin 15)
Pin 16: PRG2 D4 (Pin 16) and PRG1 (Pin 16)
Pin 17: PRG2 D5 (Pin 17) and PRG1 (Pin 17)
Pin 18: PRG2 D6 (Pin 18) and PRG1 (Pin 18)
Pin 19: PRG2 D7 (Pin 19) and PRG1 (Pin 19)
Pin 20 74LS139 /1Y1 (Pin 5)
Pin 21: PRG2 A10 (Pin 21) and PRG1 (Pin 21)
Pin 22: 74LS139 /2Enable (Pin 15)
Pin 23: NC?
Pin 24: PRG2 A9 (Pin 24) and PRG1 (Pin 24)
Pin 25: PRG2 A8 (Pin 25) and PRG1 (Pin 25)
Pin 26: NC?
Pin 27: NC?
Pin 28: +5V

lidnariq wrote:
... and ... what are those two diodes (1S1588) doing?

PPU A10 (Pin 28)
PPU A9 (Pin 29) -> D1 -> (CHR-ROM) Pin 28
PPU A8 (Pin 30) -> D2 -> (and also CHR-ROM Pin 25) -> 1A (CHR-ROM) Pin 28
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179445)
Oh, I also re-ran the Characterization test again, but on the master side this time.

With all dips OFF - System reported DIPSWITCHES: 00 00
With all dips ON - System reported DIPSWITCHES: 18 FC

Just thought I'd follow up and mention that. :)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179477)
lupin3rd wrote:
74LS139 Dual 2-Line to 4-Line Decoder / Demultiplexer
Decoder 2: detect when A15 is low and M2 is high.
Decoder 1: Detect when A15 low, M2 high, A12 high, A13 low.

... interesting, A14 isn't involved. There should be bus conflicts if the game ever read from the pointless (redundant) region at addresses $1000-$1FFF.

Quote:
74HC00P Quadruple 2-input Positive NAND Gate
NAND1: unused
NAND2: invert CPU A15 (for N108 in lieu of /ROMSEL)
NAND3: invert M2 (for '139)
NAND4: invert PRG2/CE into PRG1/CE

Does nothing ever drive PRG2/CE ? ... is it connected to N108 pin 23 (PRG A16) ?
Quote:
M74HC08P Quadruple 2-input Positive AND Gate
AND1, AND2: unused
AND3: buffers signal on far side of DIP3 to ... N108 ground? Are you sure it's N108 pin 7? By context it should be CHA pin 1.
AND4: buffers signal on far side of DIP1 to PRG1/2 A15

DIP1: shorted: 64 KiB PRG (relay N108 PRG A15). open: 32 KiB PRG (drive ROM PRG A15 with value floating on 74HC input??)
DIP2: if it only connects to itself ... who knows. By context, it looks like it was intended to control PRG A14 in the same way as the other DIP switches.
DIP3: shorted: should allow for 64 KiB CHR (relay N108 CHR A15). open: 32 KiB CHR (drive ROM CHA A15 with value floating on 74HC input??)
DIP4: shorted: allow for 32 KiB CHR (connect N108 CHR A14). open: 16 KiB CHR (ROM CHA A14 float)

Quote:
Custom 1 (127)
Oh, that's fascinating. That's pretending to be a ROM.

It's using /M2 as "ROM"/CE, and the address decoded by the '139 as "ROM"/OE.

Of course, with all these extra pins figuring out what it's doing is going to be all kinds of extra fun. Especially because we already know that the output value changes on subsequent reads.

Pin 1: CPU (Pin 40) -- but pin 40 on the CPU should be +5V?
Pin 23: NC? -- by context, if it were going to connect to anything, it'd be PRG1/2/CPU A11 (pin 23/23/15)

lidnariq wrote:
what are those two diodes (1S1588) doing?
D1: clamps PPU A9 to not exceed +5V
D2: clamps PPU A8 to not exceed +5V

... I wonder why?


lupin3rd wrote:
Oh, I also re-ran the Characterization test again, but on the master side this time.

With all dips OFF - System reported DIPSWITCHES: 00 00
With all dips ON - System reported DIPSWITCHES: 18 FC

Just thought I'd follow up and mention that. :)
Oh, good! This makes perfect sense now.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179499)
I was pretty tired when I was working on this late last night -- so I might have a few minor mistakes. I tried to be as accurate as possible, but on the pins that are marked "NC" and "NC?", maybe I just wasn't able to trace them down. I plan to review them, and post an update in the next day or two. Personal stuff is keeping me a little too busy. :)

I'll check on the questions you asked and try to firm up the details soon. Did I forget anything? You said to ignore the 74LS373, so I did -- but it may fill a few of those gaps. If I have time and I'm not too tired, I may go ahead and run those lines down too, just to be certain.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179518)
lupin3rd wrote:
I plan to review them, and post an update in the next day or two. Personal stuff is keeping me a little too busy. :)
This stuff has waited 30 years, it can wait another week.

Quote:
Did I forget anything?
I don't think so. The list of weird things is pretty short:
- e.g. why is 74'139 2Da unused rather than additionally filtering on CPU A14?
- why did they use a 74'00 as three inverters rather than an actual inverter IC?
- why did they use a 74'08 as two buffers?
- If the 74'08 were a 74LS rather than 74HC, then using the DIP switches to shrink the ROM would make sense. But ... a smaller ROM would also work. Why bother with the DIP switches?
Red Tent Research
by on (#179527)
Proposed topic rename: Red Tent Research
Lupin3rd wrote:
Just wanted to take a second to thank you guys for being so helpful with all my questions. Not used to that treatment online, and I'm awestruck with how much work you guys have put in to keep the wiki updated and accurate.
lidnariq wrote:
This stuff has waited 30 years, it can wait another week.
It is exciting to see new knowledge being gained. I am glad Lupin3rd is so forthcoming and cooperative.

edit: That is to say, I would also like to take a second to thank Lupin3rd for that.

Quote:
Quote:
Did I forget anything?
I don't think so. The list of weird things is pretty short:
- e.g. why is 74'139 2Da unused rather than additionally filtering on CPU A14?
- why did they use a 74'00 as three inverters rather than an actual inverter IC?
- why did they use a 74'08 as two buffers?
- If the 74'08 were a 74LS rather than 74HC, then using the DIP switches to shrink the ROM would make sense. But ... a smaller ROM would also work. Why bother with the DIP switches?

Conjecture: Spare stock seems most likely. If they were just trying to get an order-size discount for NANDs they wouldn't have used the AND [but instead two NAND gates,] they'd still only use two chips…but then there would be twice the delay.
Re: Red Tent Research
by on (#179548)
Myask wrote:
Proposed topic rename: Red Tent Research

Agree. Unless it's easier to have a mod split-off a new thread and move the posts occurring after the original issue was resolved to that thread. Sorry, that sentence was worded terribly.

Out of respect for the original creator of the VS Castlevania daughterboard, I have removed the links to those images. I did not mean to impose on his rights or work. 2600, if you're reading this, I'm very sorry about that.
Re: REd Tent Research
by on (#179551)
You can change it yourself, afaik, since you posted the thread, by editing the first post…ed: though a split also works!

Also, one can attach files to posts here. Perhaps not as convenient as imgur, I suppose.
Re: Red Tent Research
by on (#179553)
I'd support a split. Obvious place would be starting with this post.

Still working on verification tests.

I have this sinking suspicion that the different connectivity for N108 pin 10 will cause Naruko's bug to not show up on this hardware, but we can't know until I write my tests.



Nice UNROM-class daughterboard there. Too bad so many of the Vs system daughterboards aren't trivially clone-able.

... actually, given that a lot of the economies of scale are entirely different on Vs. system daughterboards, it might actually be reasonable to build complicated 74xxx logic versions.



I should say, A split and moving the latter half of the split to NEShw
Re: Red Tent Research
by on (#179676)
OK! Here's a small test suite. Includes a file arbib.prg which you can burn to a 64KiB 'PROM. You can reuse the Atari RBI Baseball CHA.

Slightly better programmed than the previous test.

Tests are:
• Verify that sprites work as intended; then try to elicit 2C02-style OAM damage via writes to $2003
—(specifics aren't really important, just whether screens 2 and 3 are the same or not as screen 1)
• Check whether OAM is readable via $2004 or palettes are readable via $2007 (both believed not)
• Check whether the RGB PPUs emits a colored overscan equal to the backdrop color, like the 2C02
—You ought to be able to see some portion of the overscan without adjusting your monitor
• 108 "sanity check", just making sure that the PRG and CHR banking and bank detection works as expected
—If this test fails the next one can't possibly work...
—the "PRG" test should either display 00112233445566770011223344556677 or xxxxxxxxxxxxxxxx0011223344556677. From your continuity tests, I hunch it's the latter...
• On the 108, do writes to $0000-$1FFF from code executing in $8000-$9FFF cause bankswitching
—If all eight rows of numbers are 0608090A0B0C56 then this test didn't work, possibly because the Vs. hardware is different.
• 127 stream dumper
—we don't really know what to expect out of this last one, so ... play around with it, I guess?


No test for PPU frame timing yet. I have an idea for how to do it, but it'll involve sitting down with Nintendulator and doing lots of cycle counting.
But I think it should be able to use a ≈4-second long averaging period to get quite high precision, easily capable of measuring 1/2 pixel per vblank.
Re: Red Tent Research
by on (#179679)
lidnariq wrote:
OK! Here's a small test suite. Includes a file arbib.prg which you can burn to a 64KiB 'PROM. You can reuse the Atari RBI Baseball CHA.

Okay, I'll have this burned and run sometime this weekend. :) I'll probably do video this time, just because I don't want to get pictures out of sequence again. These tests are strictly targeting the daughterboard and custom ICs, so we wouldn't expect different results from the master vs. slave sides, correct?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179687)
Yeah, I can't imagine there would be any reason to care whether something is on the master or slave side. You should feel free to leave your janky 2C03 untouched in its socket and use the other side.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179696)
Alright, I have posted a non-published video of your test on Youtube. I hope to hear your response back on here! One or two of the tests would advance too quickly (like the advance button wasn't debounced), so I retried them and tried to push the button really quickly so that the results could be seen.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179705)
Ok, here's a summary of what I saw:

• RGB PPU sprite tests
→ (Of course, sprites work). Writes to $2003 appear to not cause OAM corruption. Bizarrely.
→ Followup question: Does this change from revision to revision of the 2C02 ? When did they break it? Maybe kevtris would be willing to test... Or is this an artifact of the 2A03's timing changing instead?

• RGB PPU memory readability
→ Neither palette memory nor OAM is readable.
→ I forgot to check whether the value read from $2004 is the normal "PPU's internal open bus" value, i.e. what you'd also read from any of the write-only registers.

• RGB PPU overscan
→ Overscan does appear to be the color of the backdrop. Like the 2C02, the top and bottom appear to have 0 and 2 scanlines respectively of backdrop color, so It's probably the same 284x242 picture that the 2C02 draws. Any more specific horizontal timing will require a 'scope.

• 108 banking verification
→ N108 banks 0-7 are mapped to the PRG2 socket, and are open-bus if that socket isn't populated.

• 108 0x8000 execution bug
→ I was unable to reproduce Naruko's bug. This might be because the 108 on the RBI daughterboard uses /A15 instead of /ROMSEL. I may have to pick up some random Tengen game from the local used game store to try to reproduce this one.

• 127 reader
→ A11 (as surmised) is ignored. Reads from addresses 0x5e00, 0x5801, 0x5901, 0x5a01, 0x5b01, 0x5c01, 0x5d01, and 0x5f01 appear to be open-bus.
→ Could you run this test again and play with both sticks? The UI should be:
Left (P1) stick: up/down change address by 0x10; left/right change address by 0x100
Right (P2) stick: up/down change address by 0x01
→ There is a minor bug such that certain addresses could accidentally leave the coin counter in the "driven" state, and getting hot. (These would be addresses 0x5e20 through 0x5e3f, and any others where the second-to-last digit is 2,3,6,7,a,b,e,f)

Those 384 bytes worth of data should be enough to figure out what the IC is doing inside. It feels like an LFSR, but... also, transcribing that for analysis is going to be a pain. (Oh well)

... Actually, now that we know the approximate shape of the 127's results, I should add a new test that will just scan for not-open bus locations and report any place it differs.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179712)
lidnariq wrote:
• 127 reader
→ Could you run this test again and play with both sticks?

I looked at the 127 reader again, and did a bit more thorough looking around. I swept the entire 0x5eXX range. The only page that had anything was the 0x5e01. However, while randomly paging through larger segments of memory, I found a mirrored section at 0x5601. Does that make sense or give you a clue about the structure of data in here?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179713)
Yeah, 0x5601 and 0x5E01 differ by exactly 0x800 .. which makes sense: CPU A11 isn't connected to anything, so the 127 can't distinguish between the two addresses.

So two tests I should add:
* scan for addresses, see if any other than 0x5E01 emits an output
* scan for addresses, see if any other than 0x5E00 restarts the pseudorandom number sequence.

I briefly entertained the idea that maybe the game could write something to 0x5E00 to get a difference sequence. However, if that were true, the sequences at 0x5e01 and 0x5601 should differ... and they don't.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179714)
Thought you might be able to do something with a binary version of the 127's output.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179715)
... Thank you so much. That's perfect. We know what it's doing now, too, because someone wrote an online implementation of the Berlekamp-Massey Algorithm that can determine what exact LFSR is being used.

The LFSR inside is apparently x²³ + x¹⁸ + 1
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179716)
lidnariq wrote:
... Thank you so much. That's perfect. We know what it's doing now, too, because someone wrote an online implementation of the Berlekamp-Massey Algorithm that can determine what exact LFSR is being used.

The LFSR inside is apparently x²³ + x¹⁸ + 1

Interesting! Well, does that conclude trying to identify 127's scope and purpose, or is there reason to think anything else is going on in there?
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179718)
You know, you're almost certainly right. There are probably just the two addresses, and everything else almost certainly does nothing at all.

Extra complexity wouldn't really serve any purpose but to increase costs, especially since the game never tests anything else.

That said ... here's a new version with the two new tests I described. Locations of not-zeroes are what's interesting.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179728)
lidnariq wrote:
Locations of not-zeroes are what's interesting.

Question about that... I noticed that whatever the MSB of the address was, is what the entire page would return (in flipped order).

e.g. If I flipped to address 0x5401, the entire page would be full of "45". If I flipped to 0x5101, the page would be full of "15". Should I go ahead and burn the test and run it, or did you want to make modifications based on what I just mentioned?

If you already noticed that, my apologies for restating the obvious. :)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179729)
Scratch that -- went ahead and burned and verified results. :-)
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179733)
All right. It's fully decoded, with the exception of A11, so the two registers are simply only at $5E00 and $5E01 and a mirror at $5600 and $5601. There's nothing else there.

I've written a silly implementation of the yielded LFSR but it doesn't match. Maybe the 127 is somehow folding multiple bits of state into each bit of output.

Certainly the bit right at the beginning where the bits disappear as:
Code:
FF 1111 1111
FD 1111 1101
F5 1111 0101
F4 1111 0100
B4 1011 0100
shows that the bits are at the very least shuffled.

I think no further programs need to be run on the Vs. System. At least, nothing comes to mind. Thank you very much for your help!
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#179735)
lidnariq wrote:
I think no further programs need to be run on the Vs. System. At least, nothing comes to mind. Thank you very much for your help!

Glad I could help! I'm kinda sad now that we're done! ;) Well, I guess I can turn my attention full-time to solving my NES-on-VS mirroring issues. May also try some homebrew on the NES and VS now, I read through the NESDoug tutorials that were linked from one of the forum posts, and it actually looks like the NES is really easy to develop low-level games on, so I'm excited about the prospect now.

Thanks again, everyone!
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#189666)
bump :mrgreen:

What's the problem with the .NES test file header? My emu detects "dirty header", and disabling it, I got mapper 206.
Re: NES version of Balloon Fight resets on a VS red tent, wh
by on (#189670)
All of my tests have valid NES2.0 headers.

Vs Atari R.B.I. Baseball is mapper 206.