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.
600D Colour RAM. Help!!!! SOLVED!
-
- Posts: 129
- Joined: Sun Feb 03, 2019 10:31 pm
Re: 600D Colour RAM. Help!!!!
Last edited by waltermixxx on Thu May 09, 2019 2:01 pm, edited 5 times in total.
Turning into quite an OSI Junkie (HTFDTH?) Superboard II REV B-40K, 9600b, HC-05 Bluetooth, Superboard II Rev D, C4P rebuild- 502, 542c, 540B.
-
- Posts: 325
- Joined: Mon Oct 06, 2008 1:54 pm
- Location: Markham, Ontario, Canada
- Contact:
Re: 600D Colour RAM. Help!!!!
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).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
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
C4P working, C1P working. 600D Replica working, C4P+D&N floppy not working. 505 board, 610 board, Mittendorf board, TOSIE hacker board need testing, PicoDOS disk untested.
-
- Site Admin
- Posts: 717
- Joined: Tue Sep 09, 2008 5:24 am
Re: 600D Colour RAM. Help!!!!
Steve, out of curiosity, what is the speed of your RAM, and what clock speed for the 6502?
-
- Posts: 356
- Joined: Wed Mar 16, 2011 1:49 am
- Location: New Zealand
Re: 600D Colour RAM. Help!!!!
Steve,any trouble with the lower 4 bits? Is it just the changing upper 4 that is the concern? (Ill try this out tonite...)
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:HexDOS,FDD Emulator
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:HexDOS,FDD Emulator
-
- Posts: 129
- Joined: Sun Feb 03, 2019 10:31 pm
Re: 600D Colour RAM. Help!!!!
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
and here is a video on youtube better describing the issue.
https://www.youtube.com/watch?v=KOv5elmu5Ms
Turning into quite an OSI Junkie (HTFDTH?) Superboard II REV B-40K, 9600b, HC-05 Bluetooth, Superboard II Rev D, C4P rebuild- 502, 542c, 540B.
-
- Posts: 325
- Joined: Mon Oct 06, 2008 1:54 pm
- Location: Markham, Ontario, Canada
- Contact:
Re: 600D Colour RAM. Help!!!!
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
C4P working, C1P working. 600D Replica working, C4P+D&N floppy not working. 505 board, 610 board, Mittendorf board, TOSIE hacker board need testing, PicoDOS disk untested.
-
- Posts: 325
- Joined: Mon Oct 06, 2008 1:54 pm
- Location: Markham, Ontario, Canada
- Contact:
Re: 600D Colour RAM. Help!!!!
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
C4P working, C1P working. 600D Replica working, C4P+D&N floppy not working. 505 board, 610 board, Mittendorf board, TOSIE hacker board need testing, PicoDOS disk untested.
-
- Posts: 356
- Joined: Wed Mar 16, 2011 1:49 am
- Location: New Zealand
Re: 600D Colour RAM. Help!!!!
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
Address decoding ??? I wonder if the memory test program might give a clue?
Address decoding ??? I wonder if the memory test program might give a clue?
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:HexDOS,FDD Emulator
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:HexDOS,FDD Emulator
-
- Posts: 11
- Joined: Wed Oct 11, 2017 7:01 am
Re: 600D Colour RAM. Help!!!!
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
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
-
- Posts: 129
- Joined: Sun Feb 03, 2019 10:31 pm
Re: 600D Colour RAM. Help!!!!
fixed, thank you for pointing that out.
Turning into quite an OSI Junkie (HTFDTH?) Superboard II REV B-40K, 9600b, HC-05 Bluetooth, Superboard II Rev D, C4P rebuild- 502, 542c, 540B.