6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 01, 2024 11:33 am

All times are UTC




Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Jun 13, 2014 10:43 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
PaulF wrote:
The only real way to tell the end of memory from a memory fault is to check the address the test fails at. If it fails at an expected location (e.g. $2000 for an 8k RAM, $8000 for a 32k RAM) then this is likely to be the end of memory. If it fails at some random address, this is probably a fault. Of course, once you have a failure, you know how much memory is available to use - just don't use the address the test fails at or anything above it!

However, if the machine can accept varying amounts of RAM (e.g., using plug-in DIMMs like Garth's), how would you define "the expected location?" Assuming that all RAM is good, you expect that a full test (checkerboard, at least) will eventually "run off the road," causing a benign fault. However, the "end of the road" can't be written into the test procedure, since it's unknown. I think this is where a single bit address bus test would clearly differentiate between an "end of the road" fault and an actual defect.

This is something that I am mulling as I close in on bringing POC V2 to fruition. It will have 512KB in a single SRAM, so some means of verifying that all 512KB are there will be required. Yet I don't want to hard-code that specific size into the BIOS, since something may prompt me to add more RAM. Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it). How would a checkerboard test be done on those RAM ranges?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 14, 2014 10:42 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
Checkerboard is good to find bad memory implementations - bad bits, or bits which influence nearby bits. It works best if you know the internal layout of the memory. For example $AA might be $F0 internally.

I would guess that much more likely failures are stuck-at or short or open faults on address lines, chip selects, or data lines. Missing chips and broken decode logic are also possible. So it would be nice to be confident in finding - and perhaps distinguishing - those kinds of things, especially if it can be done quickly.

Examples of things to look out for:
- mirrored memory, so $1000 and $3000 are actually the same locations
- addressing or chip select trouble, so $2000 and $3000 both write to $3000

I think it's probably necessary to write sentinel values in other locations, then the test value, and then check both the sentinel values for not being changed and the test value for being correctly written. Also necessary to pre-write and pre-read something different from the test value beforehand. It might be enough to have just one sentinel location for each test location, carefully chosen, but I'm not sure of that. (It would surely be overkill - and very slow indeed - to have every other location as a sentinel location!) Perhaps enough to flip one of the address bits:
- test location $0001, sentinel location $0002
- test location $0002, sentinel location $0004
- test location $0004, sentinel location $0008
- test location $0008, sentinel location $0010
- test location $0010, sentinel location $0020
and so on. But, if two non-adjacent address bits are shorted, will that be found? If we have a memory size which is not a power of two, such as 24k, will it be tested correctly? I suspect not.

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 15, 2014 5:02 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
BigEd wrote:
Checkerboard is good to find bad memory implementations - bad bits, or bits which influence nearby bits. It works best if you know the internal layout of the memory. For example $AA might be $F0 internally.

I would guess that much more likely failures are stuck-at or short or open faults on address lines, chip selects, or data lines. Missing chips and broken decode logic are also possible. So it would be nice to be confident in finding - and perhaps distinguishing - those kinds of things, especially if it can be done quickly.

Examples of things to look out for:
- mirrored memory, so $1000 and $3000 are actually the same locations
- addressing or chip select trouble, so $2000 and $3000 both write to $3000

I think it's probably necessary to write sentinel values in other locations, then the test value, and then check both the sentinel values for not being changed and the test value for being correctly written. Also necessary to pre-write and pre-read something different from the test value beforehand. It might be enough to have just one sentinel location for each test location, carefully chosen, but I'm not sure of that. (It would surely be overkill - and very slow indeed - to have every other location as a sentinel location!) Perhaps enough to flip one of the address bits:
- test location $0001, sentinel location $0002
- test location $0002, sentinel location $0004
- test location $0004, sentinel location $0008
- test location $0008, sentinel location $0010
- test location $0010, sentinel location $0020
and so on. But, if two non-adjacent address bits are shorted, will that be found? If we have a memory size which is not a power of two, such as 24k, will it be tested correctly? I suspect not.

Cheers
Ed

Another approach is to write the page number into all locations of a page and then read them back. If you write into page $14 (with the value $14) but get back $04, then you know that A12 is acting up.

The most extensive test I ever saw did a page write as I described above, followed by a "quadruple" checkboard ($AA, $55, $A5, $5A), followed by a bit rotation on each cell. Slow but thorough.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 21, 2014 7:51 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 408
Location: Minnesota
Quote:
Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it).


I don't know if the specifics of your machine would make it useful, but on the good 'ol C64 the character ROM and the I/O block both "overlaid" the same RAM addresses. In the default memory map the 6510 "saw" the I/O block but the VIC-II "saw" the character ROM.

If so inclined, it was possible to manipulate the memory map so the 6510 "saw" the character ROM instead of the I/O block. Then you could copy the character ROM to the RAM "underneath" it, relying on the write-through-ROM-to-RAM behavior. Once there you could make the 6510 "see" the RAM, which would let you alter some of the character patterns (if you were going to alter them all, there'd be no point in copying the default character set). Set the VIC-II to "see" that RAM as well, and you have a custom character set without giving up any normally available RAM space. You'd have to be careful with interrupts while the I/O block was unavailable, but it was still pretty straightforward.

Used that in a couple of games.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 21, 2014 8:42 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
teamtempest wrote:
Quote:
Also to be considered, the glue logic will (eventually) allow writes to ROM to bleed through to RAM, as well as allow I/O hardware to be mapped out and replaced with RAM (for what reason I don't know, but I will try it).

I don't know if the specifics of your machine would make it useful, but on the good 'ol C64 the character ROM and the I/O block both "overlaid" the same RAM addresses. In the default memory map the 6510 "saw" the I/O block but the VIC-II "saw" the character ROM.

If so inclined, it was possible to manipulate the memory map so the 6510 "saw" the character ROM instead of the I/O block. Then you could copy the character ROM to the RAM "underneath" it, relying on the write-through-ROM-to-RAM behavior. Once there you could make the 6510 "see" the RAM, which would let you alter some of the character patterns (if you were going to alter them all, there'd be no point in copying the default character set). Set the VIC-II to "see" that RAM as well, and you have a custom character set without giving up any normally available RAM space. You'd have to be careful with interrupts while the I/O block was unavailable, but it was still pretty straightforward.

Used that in a couple of games.

The RAM bleed feature of the C-64 was not fully appreciated when the machine first came out. However, it wasn't long before people were taking advantage of it. Back when I had a C-64 attached to a Lt. Kernal hard drive, I used the 8KB of RAM under the BASIC interpreter ROM as a set of disk block buffers. Reads from disk required no special action, due to the bleed-through feature. A write to disk required that the BASIC ROM be mapped out to expose the block buffers.

POC V2's I/O will be the only thing in the I/O block, other than the RAM underneath.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 25, 2014 5:49 am 
Offline
User avatar

Joined: Sun Dec 29, 2002 8:56 pm
Posts: 460
Location: Canada
I've used checkboard testing in the past. I don't usually do a memory test unless I suspect bad memory already.
I find the memory test actually tests my patience so I usually skip it.

I do a doubled up checkerboard test, writing $AAAA5555 to all memory locations first, then reading it back later to ensure that bus capacitance isn't holding the memory value. Then I switch the pattern around to $5555AAAA and repeat the test.

I usually do a checksum on ROMS. I spit out the checksum value in a running system and compare it to what my tools generated to make sure they're the same.

To determine the amount of memory, write a magic number to the last suspected word of memory in each in block. For example if going in 64k increments write to $FFFC-$FFFF. Then readback the number and see if it's valid. Increment by a whole block size to test the next block.

_________________
http://www.finitron.ca


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: