PART 12 - TROUBLESOME UPGRADES
From Phase 1 of this saga you will be aware that another part of this exercise was to use, where possible, all new parts. Up till now I had been using an ARMSID, replacement ROMs, PLAnkton and a MOS 8701 replacement all through initial testing. With this combination of replacements there was one troublesome issue that cropped up now and again but we will touch on that a little later. As my initial build kit included all the logic ICs and RAM, I had been using new-old-stock 41464 RAM ICs but with a stable build, now was the time to test the SRAM replacement I had bought.
This was a very quick, and pretty definitive test. It didn't work. On switch-on the screen was peppered with random characters and no cursor. We couldn't proceed any further in that state so the original RAM chips were re-inserted and everything returned back to normal.
The problem here is that I wasn't sure if the SRAM replacement was faulty, or if it was failing because it was conflicting with something else on the board. I had assumed the former, and had resigned the replacement SRAM to scrap when I watched YouTuber Jan Beta's video of his experiences doing virtually the same thing, with the same board. A link to his video.
In that video, Jan experienced exactly the same "weird character" glitch as I experienced, except in his case the SRAM was conflicting with his prototype VICII Kawari. When he put his regular VIC chip back (a 6569-R3 - the same as mine) everything returned to normal. This obviously doesn't translate exactly to my experience but it did get me wondering.
Jan was using Eslapion's "SaRuMan" SRAM replacement. I had a different variation of SRAM. Jan also had a different 8701 replacement, the "TOLB" (The Other Little Board), also by Eslapion. If we assume the different SRAMs work the same way (a naïve assumption I'm afraid) then all other things being equal, the only difference between Jan's set up and my own was the 8701 replacement. Jan said at the start of the video that he had to remove his initial 8701 replacement as it was causing a strange issue with Sprite collisions. As it happens, I had been experiencing odd behaviour in Sprite collisions too.
In 2021 I was messing around with Assembly Language and managed to write a slightly crap, but functional game which my son and I have been thoroughly enjoying trying to beat each other's speed run times. In the game I use sprite-to-sprite collisions to trigger further actions (yes I know it's not good code but for pity's sake, I'm a beginner!). Anyway, on my breadbin this runs perfectly, but in the new build the sprites visibly overlap somewhat without any action being triggered as though somehow, something is misaligned. I wondered then if the 8701 replacement was the cause of the fault here?
Luckily I had a new-old-stock 8701 I could drop in and experiment with.
Installing the original 8701 chip did indeed cure the sprite collision problem: that immediately behaved as one would expect.
I then added the SRAM replacement. The "weird character" problem was gone! Only to be replaced with an equally bad, if not worse problem of constantly resetting, or probably more accurately, constantly "restoring" the computer, which on boot sat at a flickering ready prompt - no "64K RAM SYSTEM 38911 BASIC BYTES FREE" message - no, just a flickering, unresponsive screen with "Ready" in the top left corner, as pictured below. The exact same screen you get when hitting "run/stop" and "restore", but flickering and clearly stuck in a loop. Without an Oscilloscope I have no clear idea what's going wrong.
Putting the 41464 chips back in brought everything back to normal. So yeah, another wrong theory.
I put some time into reading some fairly heated forum posts about SRAM replacements and it's clear some designs just aren't compatible with the 250466. I think it's obvious I have bought one of them: cue some colorful language which I will spare you here.
Further digging brought me a comprehensive answer. In a forum post here, in reference to the SRAM replacement design my problematic one is based on, Eslapion states:
"He used a 12ns high speed cache SRAM IC which is very sensitive to the slow transition signal of old 8 bit computers and this causes write errors. This makes this design unreliable. The fix is to use a slower 45ns/55ns IC which uses less power and correctly takes slower signals. This problem is more prevalent on the 250466 because it uses legacy 74LS technology to manage the multiplexed address bus. The 469 uses the large 64 pin PLA which uses HMOS/CMOS technology and has sharper transitions"
Bugger. So there we have it - a sensible explanation for the very clear problems I encountered. None of this was obvious and another case of Caveat Emptor. I simply bought an allegedly compatible product, which was (and still is - so watch out!) sold as being compatible with the 250466, based on aesthetics and put no more thought into it than that. Oops. So, yeah, back into the scrap pile it goes.
I will pick up a SaRuMan in the near future and test with that but I'm pretty confident this is the answer. As for the 8701 replacement it seems a fair bet that Eslapion's "TOLB" will work too so I'll add that to the "to buy" list.
PART 13 - IS "ALL NEW" ACTUALLY POSSIBLE?
So far, this doesn't look good for my "all new" philosophy: incompatible SRAM and a glitchy 8701 replacement. I now understand the issue with the SRAM. However, there are a number of other things we must try in order to understand exactly where incompatibilities with the 8701 replacement lie: is it glitching because it is simply not 100% compatible, or are other replacement parts (the ARMSID, PLAnkton or something else) having a reaction and it's that particular combination that's causing the glitch?
My gut feeling (and this is something I can eventually test) is that the 8701 replacement is glitching because of the Voltage Regulator replacement I'm using. The 8701 is fed, via the inductor at L1, from the CAN +5 volt line which comes directly from the 5v regulator at VR2 which, as stated in Phase 1, I replaced with a Recom R-78B5.0-1.5. If so then something about the design of the 8701 replacement reacts to that 5v input differently than the original chip which works perfectly. At any rate, it's a theory.
This causes me to raise a hitherto unanswered question: as more and more replacement chip projects start to see the light of day are the developers creating these with other replacements in mind? Are full tests being undertaken with every conceivable combination of every replacement already available on every variant of every new and old PCB in both NTSC and PAL flavours? I think the answer to this is, and always will be, unsurprisingly, no.
Given that there are several variants of an 8701 replacement, and half a dozen replacement SIDs, at least that many replacement PLAs and who knows how many replacement PCBs all of which work in slightly different ways, it's a distinct possibility that an "all new" C64, is not actually possible. At the bleeding edge of 80s technology, we will have to act as beta testers and, it's clear already that things aren't completely satisfactory. (Edit from the future: ok, I was wrong. All new is possible, but it's not cheap!)
In order to fully test future incompatibility questions, I would have to test all possible combinations of replacement parts against each other, and against original chips as a baseline. I don't have a spare suite of original chips to conduct that and I'm not that keen on messing about with my perfectly functioning new build just in case I royally screw up. However...
Brace yourself for a lightbulb moment.
I do have a recently discarded and completely broken PCB with shoddy sockets that, if brought back to working order, could serve as the ideal test bed for precisely these kind of experiments.
I had, literally, thrown that broken PCB away. It was sitting in a bag, outside in the garbage where I had rashly dumped it in disgust after extracting the last few parts I needed for the new build. We have fortnightly garbage collections round these parts and it had not yet been collected.
Suffice to say, it's not in the garbage any more. I'm going to bodge it back to working order and it's going to have a working life as a test bed for all future experiments. This, I think, is a fitting future and a satisfactory outcome, albeit one where ill fitting chips will always be an issue. So, the to do list for the broken board is:
- Fix it
- Replace salvaged components
- Populate with ICs and replacements for test
PART 14 - THE NEW BUILD
As for the new build, as I write it's been running perfectly for 8 weeks or so now. I added to my already scandalous expenditure by getting an S-video to HDMI converter (a cheap one from Amazon) and together with a nice long HDMI cable and a C64 s-video cable this has improved the video substantially from the horrors of composite. It's a long way from perfect - nothing is perfectly crisp, jail-bars are pretty bad, fast moving sprites smear but as I said in Phase 1 it's good enough.
I'm actually very impressed with this cheap HDMI converter. It's simple to setup - there are two button on the output side (not pictured): one of these switches between composite and s-video input; the other cycles through HDMI output resolutions and holding that button down for a moment cycles between 4:3 and widescreen aspect ratios which is very handy indeed.
Strangely, it is fixed to a 60Hz output but in practise I see no ill effects from feeding in 50Hz from the Commodore.
PART 15 - PICTURE QUALITY
To give you some idea of what I'm talking about regarding picture quality, I've taken pictures of the screen output with all 16 colors. This will demonstrate the sort of degradation I'm talking about. This is output via S-video to HDMI using the converter above to a 2010 Samsung LE32C450E1W LCD TV and photographed with a DSLR. The colour reproduction here is hit and miss because I didn't bother to white balance, but it's the jailbars I want to highlight. You can click any of the pictures for a larger view:
PART 16 - SUMMING UP
First let's update the running cost total with new expenditure from the purchase of the HDMI Converter which was £34.99 ($42.36 USD or €39.91) from Amazon UK. This brings total costs so far to:
£757.69, $1028.06, €908.14
With luck, a fair wind and yes, more money to throw at it, maybe the next 12 months will see a brand new keyboard, a 6569-R5 (and I do wonder if that will make the slightest difference to jail-bars and sharpness - I'm not hopeful), a SaRuMan SRAM replacement and a TOLB 8701 replacement, but that aside, for the moment, I fully intend to simply enjoy the computer I've built.
Now, how about a nice game of chess?
 |
| (There is nothing nice about how much I suck at this game!) |
In the next article I source some of the IC replacements I mentioned above and talk about these at (excruciating?) length.
