The people who "have access to schematics or logic diagrams or Verilog/hdl" are the ones who reverse-engineered them, and most of them sell replacements and consider them proprietary.
If you think they should be getting "open-source love and preservation", go ahead and do the work and release your files.
You're not going to learn anything by copying someone else's homework.
FWIW I understand the desire to protect efforts in order to sell products and recoup on inital R&D, but I've only seen one online listing for any sort of aftermarket 05XX replacement, and it hasn't been in-stock for who knows how long.
But yes, I plan to put the analysis in. I understand it will take time and fiddling both with the game hardware and with trying to compare simultaneous in/out signals between the dev and reference chips, not to mention the polynomial gate "hacking" approach which I can only theorize is how others have matched up the PRNG-like data transforms with the LSFRs. When I have something I'll absolutely link to an open git repo.
EDIT: As part of my preliminary LFSR research, I've found this interesting and (seemingly) comprehensive theory/application document on the topic provided by none other than the folks at Texas Instruments themselves, figured I'd link to it here for any other interested eyes:
Texas Instruments on LSFR Theory and Application.
What the initial description is telling me is that I appear to have been on the right track regarding the XOR gate hacking methodology, but may potentially have to contend with testing for an XOR circuit that contains more than 2 input gates from the register. If test results between Dev and reference chip do not match after using a 2-line XOR polynomial gate across all potential permutations in the register, then we may have to contend with adding a third input line to the XOR gate in sequence, and repeating the cascade-shift from LSB across to MSB just as described for attempting to test inputs for the 2-input XOR test - so on and so forth for a 4+ input XOR gate for every respective test cycle in which all given XOR input permutations for given input size n have been exhausted.
Now, I doubt they're using 4+ inputs into the XOR gate, since that would mean half or more of the register's inputs would potentially be toggling (or affecting the toggle effect) of the Exclusive OR gate, likely leading to an unsatisfactory PRNG generator. I'm only making an educated guess when I say this, of course. I could be totally wrong, and haven't gotten far enough into the document to see if TI expresses concerns over practical input-count limits for a given-sized register/array of SRs. I'll obviously have to observe test behavior to know, ultimately.
The document also mentions loading an initial seed into the LFSR, and clarifies that if all-zeros are loaded into the LFSRs upon initialization, that randomization effects would not be observed. Now, I'm not sure what factor Namco's implementation plays in initializing this seed, at least for Galaga, if not universally (they only ever used this IC in two games anyway), but if we confirm that a 0-default LFSR init causes all-Low/linear outputs when provided with test data, then we could proceed to experiment with bit-level iteration/evaluation steps for initializing and verifying the seed/feedback effect across permutations. This would take some time, even for an 8-bit array, but clearly is in the realm of doability (it's been done before, after all, as we can see from others results).
The original idea in my head was that the randomization effects would be observed even without a preset seed, as when high values would be clocked into the register through the initial D input line, they would eventually shift their way into one or more of the XOR input lines, causing an erratic, variable change in the register value (the changed bit is seemingly usually towards the end of of the register bank, closer to the MSB, at least if Nintendo's CIC polynomial LFSR implementation is anything to go by).
But it could be the case, that the output may not be considered "erratic enough" for the game's implementation, so if that's the case then perhaps having an extra seed value initialized into the register on-start helps to improve the non-linearity of the perceived output, or perhaps even just to prevent some sort of jarring startup behavior on the starfield during the initialization of the playfield - still totally conjecture at this time.
I see additional resources claiming that some LFSRs use XNOR gates instead of XOR gates as their functional feedback implementation. Welp, there's yet another Truth Table variable to keep track of for iterative purposes
Here's the second reference I'm alluding to
I also found another reference from a university site - haven't verified all info but it appears it may even have linked access to a comparable polynomial simulation program to whichever one wuzl used in their analysis
Scratch the sim program part - that repo is dead as well.
But according to various sources, including AMD, tap points to appropriately allow for max-length LFSR iteration are contained in this doc's tables
And from that we get a suggested starting tap-points set of bits 16, 15, 13, and 4 BUT it's for an XNOR implementation, so not my first choice for logic-fit testing. It's totally possible that this may not be the right combination - apparently in these LFSRs, you can mirror the combinational effect by mirroring the position of the taps mathematically to the opposite end of the shift registers in/out data lines, for example. There's also a possibility of more than one non-mirrored max-length existing for this 16-bit dataset, but there's just no way to know without more testing or sim programs. What I have at least learned is that for a max-length LSFR tapset to be possible, it must be of an even number of taps.
Another University resource indicates some Verilog code to test an LFSR template with (basically just D-Flipflops in sequence with the extra combinational logic, so not hard to follow anyway). It also has what may be a viable 16-degree (16-bit) minimum polynomial equation for max-length iteration across all 65535 possible step-states
