So, now that you mention the Gary chip on a rev 3 board (this is great info you%&$#?@!%&$#?@!%&$#?@!8217;re providing BLTCON0) I knew I had to take a second look at it %&$#?@!%&$#?@!%&$#?@!8216;cause when replacing the MOS CIAs I noticed that the Gary chip was the only one (besides the CPU) that was not a MOS chip and I wondered if it had been replaced by someone. It%&$#?@!%&$#?@!%&$#?@!8217;s labeled CBM 5719 / TC17G008AP-0025 / Japan 8713EAI. So, is this the Toshiba made chip?
It sure is
Would you happen to have a part # for the MOS Gary chip?
The part number is still 5719. But the marking on the corrected chip is either MOS or CSG (they're the same thing, Commodore bought out MOS and later renamed it to Commodore Semiconductor Group. Earlier Amigas have chips with a MOS stamp, later ones the same chips with a CSG stamp).
So, basically, if it doesn't have the TC marking, it's a corrected Gary :-)
But other than this IC, yes, I want to keep this board as original as possible (gloating purposes, ya know?).
Yup.
Attached is the fix, just in case you decide to keep the original TC Gary and modify the board (it's actually just a transistor, not really a huge modification per se).
I had two 512KB expansions and one wouldn%&$#?@!%&$#?@!%&$#?@!8217;t work with the rev 3 board. I stashed a keyboard and that expansion board and can%&$#?@!%&$#?@!%&$#?@!8217;t find them anywhere!
Oh, and how did I know about the 16 IC%&$#?@!%&$#?@!%&$#?@!8217;s? Cause Jens said so%&$#?@!%&$#?@!%&$#?@!8230;. LOL
https://icomp.de/shop-icomp/en/produkt-details/product/A512.html#filter=*
Actually the schematics say so, Jens just replicated the A501 rev6C circuitry, this info also exists IIRC in some Commodore tech-info document from back in the day.
I wrote something about this on Amibay a few months ago - a few rev6A boards missed the newer Agnus so they couldn't properly refresh their very onboard RAM :-) so an equivalent "refresh fix" had to be implemented onboard.
What is not said is why this refresh bug exists at all.
See the 16-chips are 256Kx1 each, and the 4-chips are 256Kx4 each, so since the number of rows (which determines the refresh cycles required) is the same in both cases (256K = 262144 = 2^18, so 9 address lines alternatively used as rows/columns provide the necessary 2^9 rows times 2^9 columns = 2^18 locations each chip provides) there is no obvious reason for a problem to exist.
The secret (and cause of the problem) is that esoterically the 256Kx1 chips are actually x4 chips, so the highest address line is not used in the traditional row/column sense but as a 2-bit (muxed, 1 bit during row selection time and another 1 bit during column selection time) selector/decoder for one of the 4 bits in the x4 group. So one less line for the actual row signals that way and the Agnus needs only an 8-bit counter.
But on the 256Kx4 chips all 9 address lines act as row selectors, and so the older 8370/71 Agnus (which was only aware of the 256Kx1 chips), only having an 8-bit refresh counter, cannot fully enumerate all memory locations leading to the refresh inefficiency when used (without a workaround) in conjunction with 256Kx4 chips.
