Page 2 of 5

Re: 600D Colour RAM. Help!!!!

Posted: Wed May 08, 2019 3:28 pm
by waltermixxx
agreed, I have made the changes and corrected the recent typo:

10 C=15:Z=0

20 FOR X=54272 TO 55295

30 POKE X,C

40 NEXT X

50 FOR X=54272 TO 55295

60 B=PEEK(X)

65 REM PRINT B

70 IF (B AND 15) <> 15 THEN Z=Z+1

80 NEXT X

90 PRINT “NUMBER OF BAD WRITES TO RAM IS”;:PRINT Z

100 END

you could add the line 65 PRINT B to see the value of B.

could someone please run this on their rev d?
you can copy and paste into a text file and send to your 600 :)

We are curious to see other peoples results, both replica 600 REV D and original :)

Cheers.

Re: 600D Colour RAM. Help!!!!

Posted: Wed May 08, 2019 4:08 pm
by Steve Gray
froso wrote: Wed May 08, 2019 1:04 pm Hi, from the schema of the 600 d, you will see the upper 4 bits of color memoty doesn't exist. So writting or reading then is useless. When you read then you read garbage. You should modify the program:

60 if B AND 15 <> 15 THEN Z=Z+1

when you write c= 15, you are writting 00001111, and when you do the test, you are compairing with 255 (11111111). As there isn't upper nibble, you read xxxx1111, so its a matter of lucky if you get 11111111. You should discard the upper bits (xxxx1111 AND 00001111 = 00001111) before do the check.

best regards
In fact, in my experience when you try to read memory that does not exist you will get the upper byte of the address rather than random data. This was the case when I ran my tests. I can't say I've had any experience with reading memory with half the bits not connected until now when I ran the test on my machine. Over 95% of the time I saw $D as the upper 4 bits (colour ram is at $D0 to $D3).

Still, you are correct that masking out the upper bits is a good idea. I mentioned in an earlier post of mine, that I did mask those bits and that still indicated that writing/reading to colour ram was not working. It made no difference to the overall goal of testing the ram and determining if there is a design flaw with colour ram or simply that both Walter and my machines are somehow defective.

Steve

Re: 600D Colour RAM. Help!!!!

Posted: Wed May 08, 2019 9:00 pm
by dave
Steve, out of curiosity, what is the speed of your RAM, and what clock speed for the 6502?

Re: 600D Colour RAM. Help!!!!

Posted: Wed May 08, 2019 9:56 pm
by MK14HAK
Steve,any trouble with the lower 4 bits? Is it just the changing upper 4 that is the concern? (Ill try this out tonite...)

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 1:04 am
by waltermixxx
I edited the program, it wont work unless you put brackets around the (b and 15).

and here is a video on youtube better describing the issue.

https://www.youtube.com/watch?v=KOv5elmu5Ms

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 2:48 am
by Steve Gray
dave wrote: Wed May 08, 2019 9:00 pm Steve, out of curiosity, what is the speed of your RAM, and what clock speed for the 6502?
The CPU is standard ~1MHz. The RAM's I'm not sure... they are 2114LC-1 (would that be 100ns?). I have tried swapping around the ram from main memory and no change.

Steve

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 2:56 am
by Steve Gray
MK14HAK wrote: Wed May 08, 2019 9:56 pm Steve,any trouble with the lower 4 bits? Is it just the changing upper 4 that is the concern? (Ill try this out tonite...)
The problem has always been about the lower bits. The upper bits don't exist and we can mask out the value returned. As I mentioned before, if I poke a single address in colour ram with any value I can see random bytes in colour ram changing. This seems to be an address issue, which could be because of one or more of the following:

1) a design flaw of the original
2) a design flaw of the clone board
3) some type of timing issue,
4) defective/flaky chip
5) bad karma

We can eliminate (1) or (2) if we can find someone else that can verify a working system. Problems (3) and (4) can possibly be eliminated by swapping chips. I have tried swapping the colour RAM and some other component without any change in the results. Number (5) we have no control over ;-)

Steve

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 9:44 am
by MK14HAK
No problem here folks. Original RevD always reads $D400-D7FF top nibble as $D. Low nibble is whatever you poke it. RUN multiple times same result. (Z=0 on completion) Only no colour :mrgreen:

Address decoding ??? I wonder if the memory test program might give a clue?

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 1:37 pm
by froso
Hi,
90 PRINT “NUMBER OF BAD WRITES TO RAM IS”;:PRINT X
should be
90 PRINT “NUMBER OF BAD WRITES TO RAM IS”;:PRINT Z

Yes I know, is a typing mistake, but if you do a copy-paste, you have to change this

And, A long time ago, I read that some cpu mirror the address bus into the data bus, during the fetch process. I don't remember if the 6502 do this or not, but it could be a clue to explain why the four upper data bits show $dx. But I can't remember now if this cpu do or don't do this (and if mostek 6502 do and hitachi 6502 don't).

greetings

Re: 600D Colour RAM. Help!!!!

Posted: Thu May 09, 2019 1:54 pm
by waltermixxx
fixed, thank you for pointing that out. :)