nesdev.com
http://forums.nesdev.com/

NES version of Balloon Fight resets on a VS red tent, why?
http://forums.nesdev.com/viewtopic.php?f=2&t=14792
Page 3 of 4

Author:  lidnariq [ Tue Sep 13, 2016 8:09 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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?

Author:  Myask [ Tue Sep 13, 2016 10:30 pm ]
Post subject:  Red Tent Research

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.

Author:  lupin3rd [ Wed Sep 14, 2016 1:10 pm ]
Post subject:  Re: Red Tent Research

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.

Author:  Myask [ Wed Sep 14, 2016 1:39 pm ]
Post subject:  Re: REd Tent Research

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.

Author:  lidnariq [ Wed Sep 14, 2016 1:43 pm ]
Post subject:  Re: Red Tent Research

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

Author:  lidnariq [ Sat Sep 17, 2016 1:34 am ]
Post subject:  Re: Red Tent Research

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.

Attachments:
ARBIBB_tests_2016_09_16.7z [12.54 KiB]
Downloaded 51 times

Author:  lupin3rd [ Sat Sep 17, 2016 4:55 am ]
Post subject:  Re: Red Tent Research

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?

Author:  lidnariq [ Sat Sep 17, 2016 12:32 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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.

Author:  lupin3rd [ Sat Sep 17, 2016 3:57 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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.

Author:  lidnariq [ Sat Sep 17, 2016 7:49 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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.

Author:  lupin3rd [ Sat Sep 17, 2016 11:01 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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?

Author:  lidnariq [ Sat Sep 17, 2016 11:14 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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.

Author:  lupin3rd [ Sat Sep 17, 2016 11:41 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

Thought you might be able to do something with a binary version of the 127's output.

Author:  lidnariq [ Sat Sep 17, 2016 11:54 pm ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

... 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

Author:  lupin3rd [ Sun Sep 18, 2016 12:03 am ]
Post subject:  Re: NES version of Balloon Fight resets on a VS red tent, wh

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?

Page 3 of 4 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/