Memory Test Problem

[Hutch]

I've been restoring a SP9000/8032 and have had a few problems with it so far, bad video RAM, bad Kernal ROM, but I got those fixed and the system started up normally.
I ran David Roberts PETTESTE2K (v4) from Bitfixer's ROMulator and it passed 13 cycles of the DRAM test with no failures. So I figured I was good.
Thanks for that program David, I appreciate it and it's been quite helpful.

Then I tried loading programs from disk and ran into problems that made me dig a little deeper.
Using Tynemouth's RAM/ROM board and replacing the RAM allowed everything to work normally. I narrowed it down to only the upper 16K bank. With the on-board RAM, it won't load anything from disk, but it's fine if I replace that 16K with the Tynemouth board.
So I re-ran PETTESTE2K and it still passes with no error, so I wrote my own basic program to test the upper 16K and figured it what was happening.

It seems the DRAM test is passing because it writes the same value to all of RAM at the same time.
But in this case, it looks like one bit (chip) is responding to all addresses. That is, if I write to any address, it changes that bit for ALL addresses, or it just outputs the same bit always, regardless of the address
See attached photo. It looks like a bad bit 5 in the upper 16K so UA8 I think.
I wanted to let David know about this failure mode just FYI. I know it's not meant to be a fully comprehensive test, I just thought this was an interesting failure mode.

If you're curious about the restore process so far, I'm doing a video series on YouTube here

 

[Nivag Swerdna]

Interesting.

PETTESTER uses a four pass approach... write and check 0s, write and check 1s (i.e. MSCAN), then checkerboard (0, 1) and finally a March C test.

Curious

The March C test should detect both AND and OR Address faults (AF).

 

[Nivag Swerdna]

One thing that the March C test could not detect would be temporal defects... e.g. that bit having an inability to hold its value across time (and in the case of this DRAM across refresh cycles)

It might be worth poking it and then watching it to see if it holds its value over time (both 1 and 0)

 

[Hutch]

No change over time. I wanted to test if writes to any memory would affect the bit, so I filled 16380 thru 16389 with 255, and manually poked bytes into 16380 thru 16383 to see if anything changed in the upper bank.
It didn't. But as you can see, the first poke into the upper bank changed all of them and poking 32 (bit 5) back to 1, changed them all back to 1
Bad chip for sure, easy fix, it's just odd that the PETTESTE2K DRAM test passes all 32K

 

[daver2]

My PETTESTER ROM announces the amount of RAM it 'thinks' it has found to test as the very first thing.

Does this align with the amount of RAM that is physically fitted?

It may be that the PETTESTER has detected 16KB - and is fully testing that - when you actually have 32K fitted?

Worth double-checking that the PETTESTER actually says 32K on the top line...

The type of fault you postulate should be detected by the MARCH-C memory test (unless there is something that is time dependent). There could also be a refresh logic issue - or a data bit RAM fault with a refresh issue.

>>> Thanks for that program David, I appreciate it and it's been quite helpful.

No problem. Just working on Version 5 - trying to cram more tests into the available space...

One of the issues with V4 is that the 'simple' checks of page 0 and 1 of the first bank of RAM was a bit too simplistic. This could cause the subsequent tests to misbehave. I was away on a business trip over the last few days, so whilst sat in the hotel - I worked on a better page 0 and 1 RAM test algorithm (well, borrowed it from someone else and tweaked it for my use)!

Dave

 

[Hutch]

Yes, I made sure it said 32K. You can see the pass count in the attached photo and no errors detected.
Odd thing for sure.
Testing in basic, I can't say how long it takes to change, but you can see from the photos above that the bit stays at 1 or 0, whichever one was written last, so it's not decaying for lack of a refresh.

*Also note that I really only tested the lower part of the high bank manually like this. It's possible the bit works normally if some of the higher address lines are toggled.
I'll have to check that later.

 

[daver2]

Let me think about that one...

I have just come back from a business trip in Lancaster - so a wind-swept drive down the M6 and M5 has tired me out...

Dave

 

[Hutch]

I used the monitor to fill 4000-7FFF with 00
Then I changed 4100 to FF and looked at memory.
It changed bit 5 for a range of addresses in a pattern of every 64 bytes.
Possibly only address bit 6 is being ignored.
The pattern was the same all the way up to 6FFF but from 7000-7FFF is totally unaffected. Everything up there remained 00

 

[daver2]

Yes, if you have an address fault that could cause the effect you are observing - but I still would have thought that the MARCH-C memory test would have detected that. The MARCH-C memory test works in 'bits' by 'scanning' and 'flipping' a bit at a time either upwards or downwards in memory.

For example, if memory was all $00 and it was testing for a '0' bit going 'upwards' and it found a '1' this would fail the test. If it found a '0' it would 'flip' the bit to a '1'. If flipping this bit caused other bits to be flipped higher up in the address range - this should be detected when the test reached those bits.

Conversely, on the next (downwards) pass, any '0' bit detected should be reported as a fault before flipping the '1' to a '0'.

It is just possible that some addressing faults may result in the test passing rather than failing? I will have to go back to the functional definition for the MARCH-C memory test to ascertain that.

It does seem to be related to either a particular address or data bit (or a combination of both).

If the issue is an address line, then the problem should manifest itself 'backwards' shouldn't it?

So, can you write $FF into addresses $4000 through $7FFF and then write $00 into address $4100 and see what we get in the same address range.

I have observed an 'interesting' thing with the RAS and CAS buffers. The address lines for the RAS buffer are from BA6 ... BA0; but for the CAS buffer are from BA12 .. BA17 and then BA13.

I am still not sure why the address range from $7xxx are unaffected by the issue though.

Dave

 

[Hutch]

The end result and demo of the RAM testing @~02:19

 

[dave_m]

I enjoyed the video. How did you get the SuperPET file images onto a real floppy?
-dave_m

 

[Hutch]

I enjoyed the video. How did you get the SuperPET file images onto a real floppy?
-dave_m

I used ZoomFloppy connected to the 4040 drive. Formatted and then wrote the D64 using opencbm.
I got some 170K compatible disk images from Mike Naberezny's page. They've also been cracked so they don't require the 6702 to run.
He also has a 170K OS/9 disk image.
I'm still looking for an 8050 or an 8250 maybe.

 

[daver2]

Thanks for a nice video.

It is interesting that the MARCH test doesn’t detect your fault though. So far it has pretty much nailed faulty RAM on other people’s machines. I wonder if omitting the address test before running the MARCH test (I have added this to version 5 that I am working on) is the issue?

I also see you have used my ‘de 6702’ images from Mike’s site. That was an interesting project reverse engineering that pesky chip! You will also find my “Hello Dave” program in all of the Waterloo Languages on that disk too. Have you tried using APL yet?!

It is an interesting thing about the option ROM sockets that you mentioned. I didn’t think of the /NOROM issue with any option ROMs. That’s something new I have learnt today.

Nice job...

Dave

 

[Hutch]

Dave,
I have not tried using APL yet, though it does load from disk. Rumor has it, using APL is a lot like drilling teeth without anesthetic.
Yeah, I got a lot of help from Mike via discord, as well as a couple of spare key-caps and a spare Kernal ROM from him.
I appreciate the 'de 6702' images, though maybe I should at least try the protected versions to see if my 6702 actually works or not.

I don't have the manuals so I didn't (still don't yet) know how to get a disk directory or load programs from within the languages.
I still have a lot to learn.

If you update the Pettester, and if I can figure out how to update the roms in the Romulator, I still have the faulty 4116 so I can put it back in the socket to try testing it again.
I have some 2532s I think I can drop in the Kernal socket also.

 

[daver2]

>>> Rumor has it, using APL is a lot like drilling teeth without anesthetic.

He he... It all depends on what you are trying to do.

It will test out your character generator though!

>>> I don't have the manuals so I didn't (still don't yet) know how to get a disk directory or load programs from within the languages.

If you read my write-up on removing the 6702 from the Waterloo languages (also on Mike’s website) - this is explained.

My ‘default’ configuration for my PETTESTER is to replace the EDIT ROM. So, if you can burn a ROM for the EDIT socket, you should be good to go.

Dave

 

[Hutch]

Dave, I just read through your PDF linked from Mike's web site. It is helpful, thanks.

I take it there's no way to get a directory listing from the Waterloo ROM menu,
But once a language is loaded, you can use the command di
I'm still learning...

 

[daver2]

>>> I take it there's no way to get a directory listing from the Waterloo ROM menu.

Not that I am aware of. I do have a disassembly of the 6809 ROM code somewhere so I could look for you... It is online somewhere anyhow.

There is an APL implementation of Startrek if you want to try it... It is written in Romulan...

Dave

 

[dave_m]

I used ZoomFloppy connected to the 4040 drive. Formatted and then wrote the D64 using opencbm.

That is good news. A few years ago when I tried with Zoomfloppy, disk image copy did not work with openCBM and the 4040 drive. It only worked with the 8050. The best that I could do was to copy files using the CBMXfer software from Steve Gray. Spiro must have fixed openCBM for the 4040 although I wished he had mentioned it on the Zoomfloppy users forum.

One thing to note with the SuperPET as you probably know, EPROMs on the PET mainboard will not work in the 6809 mode as grounding the 'NO ROM' signal will not float the EPROM output lines. Although as you showed, they apparently made a circuit mod to get EPROMs to work in the two expansion sockets.

 

[Hutch]

Well, it didn't work at first. After messing with it to try to get it to work, someone suggested using the --transfer=original option and that did the trick.