Strange memory write problems

[adrianhudson]

Hello, I wonder if somebody might help me.

I am making a simple 6502 SXB. I created the design and made it on breadboard. I learned a LOT about making small computer circuits on breadboard (it was quite painful).

I decided I wanted to make it up into a permanent form and I also decided that since the 6502 is a classic '70s machine I would make it in a classic manner and use wire wrap. I read as much as I could about using wire wrap and making these sorts of bench computers (thanks Garth, you are a lifesaver!).

I completed the thing and powered it up (slowly, part by part). I was somewhat flabbergasted to find that it worked pretty much first time.

Except it didn't, quite.

There is one problem I can't trace and it is to do with memory writes to certain addresses

I have a software debugger called NoICE. One of the many functions it has is the ability to display and alter memory. I used it to test the RAM is working correctly. It isn't.

Addresses 0003, 0007, 0013 and 0017 have "something strange" about them, also addresses 0203, 0207, 0213 and 0213 and then later, addresses 0403, 0407, 0413 and 0413 and so on through the RAM.
Always these 4 bytes in the EVEN 256 byte "pages". The odd numbered pages have no problems.

When I write (using NoICE) a value to these addresses the program reports that the data was not written properly (actually, sometimes it is but most of the time it isn't).

Firstly I replaced the memory chip, just to rule out a faulty chip. This made no difference.

I have checked every connection on the board (multiple times) both for continuity and shorts. I thought it must be something to do with an address line or some other chip being selected at the same time as the RAM chip on these addresses but I can't find anything. I thought that by analysing the bit patterns of the affected addresses I would be able to deduce which component might be guilty but I can't see a pattern that might cause this exact problem.

My memory map is:
0000 - 7EFF RAM
7F00 - 7FFF IO devices (2 x 6522, 2 x 6551)
8000 - FFFF ROM

I have attached my schematic. PLEASE don't judge it too harshly, I realise it's not the most beautiful thing. I made it for just my own use, not expecting to show it to anyone else.

Has anyone else had anything like this sort of issue? Does anyone have any hints for further fault finding? I have a simple 2 channel 'scope.

Edited to replace schematics showing glue logic as HC

Edit: For anyone trying to follow along but not wanting to read it all here is a link to a recap page: viewtopic.php?f=12&t=7371&start=60#p96499

[gfoot]

Nice design! What are you going to use two ACIAs for?

I wonder if it's due to the LS component (U8A) that's decoding your I/O range, with its output feeding into an HC component (U7B). HC officially requires a much higher threshold for "high" inputs than LS can provide. Sometimes it works anyway, but I think to be sure you should either use some form of HC component for U8, or use an HCT component for U7 instead of HC, so that it can accept LS inputs.

Also, what clock speed are you running at and have you tried a slower one?

[adrianhudson]

Hi gfoot and thanks for the reply.

I should have said that although the schematic shows different, all of the glue logic are HC - I just didn't have the symbols for HC and forgot to update the text. I will edit the main post to state that.

I am keeping things real simple and running at a lowly 1970's 1MHz.

As for what am I going to use the two 6522's for - dunno, I just decided I would like two

[gfoot]

Ah I see. Unfortunately the attachments don't seem to work any more so I can't take a second look.

Sometimes a missing power or ground connection on an IC can lead to it appearing to work for some input combinations but not others.

Ideally I think you'd use a logic analyser to see what's happening - maybe the RAM doesn't see a clean "write enable", maybe some of the glue logic is not working. You might be able to do some of that with the two channel scope as well, especially if you have an external trigger option so that you can use both channels for signals.

[adrianhudson]

gfoot wrote:

Ah I see. Unfortunately the attachments don't seem to work any more so I can't take a second look.

Working here. Perhaps a refresh of your browser might help.

Thanks for the thoughts... have had that problem before (forgotten power connection ~blush~) but all okay this time.

Regarding the clean write enable. Thats interesting... I will see if I can check it somehow. I can certainly scope it and look. Thanks.

[plasmo]

Feel like there is a floating/short-to-ground-or-Vcc/bridged problem of address A2. If you zero out all memory then write a value to one location; if you see the same value in other locations then you have a floating/bridging short somewhere.
Bill

[adrianhudson]

plasmo wrote:

Feel like there is a floating/short-to-ground-or-Vcc/bridged problem of address A2. If you zero out all memory then write a value to one location; if you see the same value in other locations then you have a floating/bridging short somewhere.
Bill

Thanks Bill. I will try that. I do have a program running on the machine at the moment, though, that runs a clock display with serial output and interrupt driven updates that runs perfectly as long as I avoid variables in the "strange" addresses. Will report back further tests and what I find with A2.

[floobydust]

Beyond the possible problem that Bill described, I'll add my $0.02 to the overall design:

1- I would add a 3.3K resistor to the DS1813 Reset chip. The internal resistor is a bit high in value.
2- I would add a DS1813 to the NMI line. Using just a momentary switch will likely result in some switch bounce, making any NMI routine a bit erratic.
3- The SO (set overflow) pin on the CPU should also have a pull-up resistor, 3.3K to +5V.
4- The 4148 diodes used in the IRQ lines for the 65C22 VIAs might be a problem due to voltage drop. Recommendation is to use schottky diodes instead.
5- 6551 ACIA... ancient design (sad but true) and the recently released W65C51 chips have a defect. You'd be much better off using a single SC28L92 or equivalent. Much faster, etc.
6- Are you really using a 6502 NMOS CPU?? W65C02 is highly recommended.

Beyond the above, if you're able to program an ATF22V10 PLD, you can replace all of the glue chips with a single PLD and have a much more flexible memory map.

[adrianhudson]

floobydust wrote:

Beyond the possible problem that Bill described, I'll add my $0.02 to the overall design:

1- I would add a 3.3K resistor to the DS1813 Reset chip. The internal resistor is a bit high in value.
2- I would add a DS1813 to the NMI line. Using just a momentary switch will likely result in some switch bounce, making any NMI routine a bit erratic.
3- The SO (set overflow) pin on the CPU should also have a pull-up resistor, 3.3K to +5V.
4- The 4148 diodes used in the IRQ lines for the 65C22 VIAs might be a problem due to voltage drop. Recommendation is to use schottky diodes instead.
5- 6551 ACIA... ancient design (sad but true) and the recently released W65C51 chips have a defect. You'd be much better off using a single SC28L92 or equivalent. Much faster, etc.
6- Are you really using a 6502 NMOS CPU?? W65C02 is highly recommended.

Beyond the above, if you're able to program an ATF22V10 PLD, you can replace all of the glue chips with a single PLD and have a much more flexible memory map.

Thanks for your reply and time in looking at my design floobydust:
Regarding 1, 2 3 and 4. Will do. Thank you.
Regarding 5. It's a retro design. I'll live with it.
Regarding 6. No. It's not that retro. It's a typo -it's a 65C02.

I'll look into these PLD thingies for future designs.

However, I don't think any of your comments will fix my memory problem. It's an odd problem. The whole thing runs perfectly as long as i don't try to use any of those addresses.

[adrianhudson]

plasmo wrote:

Feel like there is a floating/short-to-ground-or-Vcc/bridged problem of address A2. If you zero out all memory then write a value to one location; if you see the same value in other locations then you have a floating/bridging short somewhere. Bill

Hi Bill. I have checked all address lines once more for floating, shorts, bridged etc. No luck. All memory acts perfectly except for the addresses I mention in the first post. V strange.

[8BIT]

Hello Adrian,

It looks like U12A is used to gate the R/W and PHI0 signals to /WE. I think the rest of U12 is not used. In the bottom left, you show U13B,C,D as spare with the inputs not connected.

Is this really U12B,C,D? Are the inputs actually floating or are they connected to gnd or Vcc? if they are floating, you could be getting some unstable outputs on the A gate and your writes may be corrupted. I cannot explain why it only affects certain addresses, but /WE is only used by RAM so that is a good place to start since only RAM is being affected currently.

keep us informed of your troubleshooting.

Daryl

[floobydust]

Yes, my suggestions were not based on trying to isolate your odd memory problem, as Bill had some good suggestions to look for.

Daryl posted while I was typing, but I was also looking more closely at the schematic and the second 74HC00. As you have a wire-wrapped board, perhaps try an alternate circuit for your memory read and write lines. The circuit below will let you remove the second 74HC00 and get a clk2 qualified write signal. I've been using this circuit since the 80's without issue... even with newer 32KB SRAMs.

It should be an easy modification and worth a try. Also, make sure your power supply decoupling on the memory and logic chips are solid and that your power supply isn't showing any noise.

A picture of the board (both sides) might be helpful.... you never know.

[Dr Jefyll]

floobydust wrote:

A picture of the board (both sides) might be helpful.... you never know.

Yes, good idea.

adrianhudson wrote:

When I write (using NoICE) a value to these addresses the program reports that the data was not written properly (actually, sometimes it is but most of the time it isn't).

If this problem continues to baffle, and you end up getting bogged down, I suggest you try to verify the symptoms using some tool other than NoICE. Not that I have any particular reason to mistrust NoICE, but using a different troubleshooting tool (or using the same tool in a different way) can sometimes be revealing.

Here's an example. What if you were to write and execute a little program that copies a page of ROM (or some other known data) to an Even numbered RAM page -- ie, an afflicted page -- and then in turn copies it to an Odd numbered RAM page? IOW, let it be your program -- not NoICE -- that does the reading and writing of the Even numbered page.

-- Jeff

[adrianhudson]

8BIT wrote:

Hello Adrian,
It looks like U12A is used to gate the R/W and PHI0 signals to /WE. I think the rest of U12 is not used. In the bottom left, you show U13B,C,D as spare with the inputs not connected.

Is this really U12B,C,D? Are the inputs actually floating or are they connected to gnd or Vcc?
Daryl

Hello Daryl,
Yes the rest of this chip is unused - which irritates me no end. The unused inputs were floating (Newbie mistake) so, as per your suggestion I have set them all to +5V. It hasn't helped the problem but is more correct that way. I note floobydust below has suggested a way to get rid of this chip altogether which I will try when I understand completely what he means.

floobydust wrote:

... I was also looking more closely at the schematic and the second 74HC00. As you have a wire-wrapped board, perhaps try an alternate circuit for your memory read and write lines. The circuit below will let you remove the second 74HC00 and get a clk2 qualified write signal. I've been using this circuit since the 80's without issue... even with newer 32KB SRAMs.
-snip-
A picture of the board (both sides) might be helpful.... you never know.

I love this idea. I will modify the schematic with what I think you mean and post it here... then you can tell me what you really mean!

I will also do photos

adrianhudson wrote:

~snip~
I suggest you try to verify the symptoms using some tool other than NoICE.
~snip~
What if you were to write and execute a little program that copies a page of ROM (or some other known data) to an Even numbered RAM page -- ie, an afflicted page -- and then in turn copies it to an Odd numbered RAM page? IOW, let it be your program -- not NoICE -- that does the reading and writing of the Even numbered page.
-- Jeff

Jeff, thank you for your thoughts. Yes, a good idea. I'm not quite sure whether to do the hardware mods suggested by others or write this program first. Hmmm...

[adrianhudson]

floobydust,
I have made the changes to the read/write logic to eliminate the part used 74HC00 that I *think* you mean. Please could I ask you to scan your eye over the following before I start fiddling with wire wrap.

...the same thing as a pdf

newSelect.pdf

(224.38 KiB) Downloaded 167 times