Re: MOS 8500 CPU for C64C

Here you are,
I have no idea what other versions I had. I have the bad habit to
sometimes still code by hand then write a loader
in basic. Once disassembled it should be clear the mechanism for
testing the gate charge fading time. I probably have many other
programs for running a loop and saving to a disk file at regular
intervals, but it's hard to recover the useless things of exactly 3
years ago.
Frank

On Wed, Aug 30, 2023 at 8:00 PM <silverdr_at_srebrnysen.com> wrote:
>
>
>
> > On 30 Aug 2023, at 17:37, Francesco Messineo <francesco.messineo_at_gmail.com> wrote:
> >
> >>>>>>>>> I know the 8500 CPU for the cost reduced C64C is rare would anyone here
> >>>>>>>>> have any extras I could get?
> >>>>>>>>
> >>>>>>>> You can also use a 6510 from an older C64, they are compatible.
> >>>>>>> Just the HMOS(II) vs NMOS apply to those two, right?
> >>>>>>
> >>>>>> Yes, the only difference is the process. I have seen 250425 boards with 8500 CPUs.
> >>>>>
> >>>>> Yeah, /me too. And I know they're functinally the same but as we know CSG did various things with the numbering like marking the HMOS CIAs with NMOS number. Although doing it the other way around (like putting 8500 on a 6510) would make even less sense I guess ;-)
> >>>>
> >>>> FWIW, 8500 vs 6510 can be detected in software by checking how many
> >>>> cycles it takes for the unconnected port bits to decay from 1 to 0
> >>>> level when the DDR is switched from output to input.
> >>>> I made a test ASM for proof of concept years ago. The decay time is
> >>>> also temperature dependent, but the 8500 is some (binary) order of
> >>>> magnitude slower due to probably much better gate insulation and lower
> >>>> die temperature (gate leakage depends on temperature).
> >>>
> >>> I remember a thread about that a few years ago and the outcome there was that it's not reliable, the best 6510 are better than the worst 8500. So you can only output a probability.
> >>
> >> Do I understand correctly that the results _partially_ overlap? Something like:
> >>
> >> |=======6510=======|
> >>               |======8500=====|
> >>
> >> If yes, then it would be possible to properly "binarily" determine the variant on both sides of the overlapping range? Of course sample size might be an issue for reliable derivation of the boundaries for each variant
> >
> > the overlapping is more or less as you pictured. However, in my
> > limited sample (I have 4 x 6510 and 2 x 8500) the results are widely
> > far away. It's been some time, but afair, someone else had
> > inconsistent results, I should really go and check the old thread.
> > Ideally the test should run on a wide sample of CPUs and record on a
> > database both the results and manufacturing plant + date code of the
> > CPU. With the "remarked" CPUs from China, things might get complicated
> > though. All the parts I tested were acquired in the "old days" here.
>
> I /think/ the "Chinese NOS" procedure affects chiefly the 6502, which they can source from order(s) of magnitude more devices/appliances. Therefore I'd expect this factor not to be that important in the C64 context. But it would really be interesting to run this on a large sample size. Do you have the code you used back then? Even if you don't have that can't be complicated
>
> --
> SD!