It is currently Thu Oct 19, 2017 8:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Tue Sep 13, 2016 8:09 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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?


Top
 Profile  
 
 Post subject: Red Tent Research
PostPosted: Tue Sep 13, 2016 10:30 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
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.


Top
 Profile  
 
 Post subject: Re: Red Tent Research
PostPosted: Wed Sep 14, 2016 1:10 pm 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
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.

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Last edited by lupin3rd on Thu Sep 15, 2016 6:44 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: REd Tent Research
PostPosted: Wed Sep 14, 2016 1:39 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
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.


Last edited by Myask on Wed Sep 14, 2016 1:46 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Red Tent Research
PostPosted: Wed Sep 14, 2016 1:43 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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


Top
 Profile  
 
 Post subject: Re: Red Tent Research
PostPosted: Sat Sep 17, 2016 1:34 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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 48 times
Top
 Profile  
 
 Post subject: Re: Red Tent Research
PostPosted: Sat Sep 17, 2016 4:55 am 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
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?

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 12:32 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 3:57 pm 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
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.

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 7:49 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 11:01 pm 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
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?

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 11:14 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 11:41 pm 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
Thought you might be able to do something with a binary version of the 127's output.

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Top
 Profile  
 
PostPosted: Sat Sep 17, 2016 11:54 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
... 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


Top
 Profile  
 
PostPosted: Sun Sep 18, 2016 12:03 am 
Offline
User avatar

Joined: Tue Sep 06, 2016 4:34 pm
Posts: 38
Location: Evansville, IN
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?

_________________
Thanks!
Chris

"Can I keep his head for a souvenir?" -Max


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group