NeXTcommunity

Everything => Hardware => Topic started by: KennyPowers on Sep 24, 2025, 06:55 PM

Title: NeXTDimension VRAM error
Post by: KennyPowers on Sep 24, 2025, 06:55 PM
I have a NeXTDimension board that's showing the following VRAM error:

VRAM test 2 failed at 0x2e800000; bad bits 0x00000001Screenshot_20250923-161927.png

The board's onboard LED also flashes 3 times when powered on, which I believe means a VRAM error.

Does anyone know how to translate that error to a specific VRAM chip?  The ND board has 32 on-edge KM424C257Z-8 VRAM chips, totaling 4MB.
Title: Re: NeXTDimension VRAM error
Post by: ZombiePhysicist on Sep 25, 2025, 01:27 PM
I could be wrong, but didn't the ND board need a minimum of 8MB to work?
Title: Re: NeXTDimension VRAM error
Post by: jeffburg on Sep 25, 2025, 02:12 PM
Thats a good point actually, was this known to be working before? Then you would at least know its a hardware failure rather than a configuration failure.
Title: Re: NeXTDimension VRAM error
Post by: andreas_g on Sep 25, 2025, 02:19 PM
The NeXTdimension board had 4 MB of VRAM and up to 64 MB of RAM. The amount of VRAM was not configurable. I'll check if I can find out some more things. But I think it might be hard to find out which chip or whatelse is broken just from this error message.
Title: Re: NeXTDimension VRAM error
Post by: andreas_g on Sep 25, 2025, 05:11 PM
I just had a closer look but unfortunately I cannot link the error message to a certain hardware failure. I think it means that one or all VRAM modules are bad. But it also might be something else.

Out of interest I tested how much RAM is necessary to run an ND board. It works with a minimum of 4 MB RAM (not to confuse with the 4 MB of VRAM on the board).
Title: Re: NeXTDimension VRAM error
Post by: KennyPowers on Sep 28, 2025, 01:18 AM
I'm told this board was working a month or so ago, and its configuration wasn't changed.  It has 64MB of RAM installed, and that's reflected in the boot log pictured in my first post.  I actually have *some* replacement VRAM chips, as well as enough sockets for all 32 of them.  However, I'd rather not blindly desolder and socket all 32 chips, especially if more than one of them are bad.  Also, it could be a bad chip or broken trace elsewhere.  The two caps near the VRAM circled in red here were leaking before I replaced them, so it's possible they damaged something.

PXL_20250924_000401562.jpg

I did find some schematics for the ND board, but they're a little rough to read:

https://www.dropbox.com/scl/fi/2fwrv75i0dstqmo04j8z2/NeXTDimension_schematics.zip?rlkey=dyy4rksu4l9xygt6v4eep2dnj&st=a5qwazqi&dl=0

Quote from: andreas_g on Sep 25, 2025, 05:11 PMI just had a closer look but unfortunately I cannot link the error message to a certain hardware failure. I think it means that one or all VRAM modules are bad. But it also might be something else.

Out of interest I tested how much RAM is necessary to run an ND board. It works with a minimum of 4 MB RAM (not to confuse with the 4 MB of VRAM on the board).

The "bad bits 0x00000001" part of the error makes me think that it's saying that the first bit of the 32bit word at address 0x2e800000 is stuck.  I think the 4-bit-wide VRAM chips are probably arranged in 4 banks of 8 chips that handle 32bits each.  So, if I could identify the 4 banks and which chip is "first" ("first" chip handles the lowest 4 bits?) in each bank, then I'd at least have narrowed it down to 4 chips from 32.  I LOVE that there are no reference markings printed on the ND board...
Title: Re: NeXTDimension VRAM error
Post by: andreas_g on Sep 28, 2025, 07:12 AM
It is interesting that the first VRAM test passes. By printing the memory access during the VRAM test using Previous I can obtain the test values.

Test 1 fills the memory with 0xaaaaaa0aaaaaaa0a doing 64-bit writes and reads them back doing 32-bit reads. This results in this pattern:
2e800000: aaaaaa0a
2e800004: aaaaaa0a
2e800008: aaaaaa0a
2e80000c: aaaaaa0a
2e800010: aaaaaa0a
2e800014: aaaaaa0a
2e800018: aaaaaa0a
2e80001c: aaaaaa0a
...

Test 2 fills the memory with growing values starting with 0x00000001 doing 32-bit writes, adding 0x00000101 with every iteration and masking the result with 0xffffff0f and then reads it back using 32-bit reads. This results in this pattern:
2e800000: 00000001
2e800004: 00000102
2e800008: 00000203
2e80000c: 00000304
2e800010: 00000405
2e800014: 00000506
2e800018: 00000607
2e80001c: 00000708
2e800020: 00000809
2e800024: 0000090a
2e800028: 00000a0b
2e80002c: 00000b0c
2e800030: 00000c0d
2e800034: 00000d0e
2e800038: 00000e0f
2e80003c: 00000f00
2e800040: 00001001
2e800044: 00001102
2e800048: 00001203
2e80004c: 00001304
...

Test 3 fills the memory with 0x5555550055555500 doing 64-bit writes and reads them back doing 32-bit reads. This results in this pattern:
2e800000: 55555500
2e800004: 55555500
2e800008: 55555500
2e80000c: 55555500
2e800010: 55555500
2e800014: 55555500
2e800018: 55555500
2e80001c: 55555500
...


You can read and write memory with 32-bit reads and writes from ROM Monitor using the 'e' command:

'e 2e800000' reads and prints the value that is stored at address 0x2e800000 followed by a question mark. Typing '.' will stop. Typing some value will write that value to the address and print the value of the next address (0x2e800004). So for example you can do this:
NeXT>e 2e800000
2e800000: 55555500? ffffffff
2e800004: 55555500? .
NeXT>e 2e800000
2e800000: ffffffff? .
Title: Re: NeXTDimension VRAM error
Post by: KennyPowers on Nov 07, 2025, 10:05 PM
I finally got back around to looking at this board.  Since the error noted a bad bit in the low-order byte at the first address in the framebuffer (0x2e800000), and the low-order byte is the "tag" byte in the ND's pixel layout (the upper 3 bytes store RGB color information), I was able to use the schematic linked above to identify the 8 VRAM chips that store the tag bytes across the framebuffer's address space:

(https://i.imgur.com/ZWhE9jT.jpeg)

However, I'm no longer thinking that I simply have a bad VRAM chip.  I viewed the contents of VRAM using the method @andreas_g described.  My board is passing the first test that fills the VRAM with 0xaaaaaa0a.  It then immediately fails the second test, so the contents of VRAM *should* be this:

2e800000: 00000001
2e800004: 00000102
2e800008: 00000203
2e80000c: 00000304
2e800010: 00000405
2e800014: 00000506
2e800018: 00000607
2e80001c: 00000708
2e800020: 00000809
2e800024: 0000090a
2e800028: 00000a0b
2e80002c: 00000b0c
2e800030: 00000c0d
2e800034: 00000d0e
2e800038: 00000e0f
2e80003c: 00000f00
2e800040: 00001001
2e800044: 00001102
2e800048: 00001203
2e80004c: 00001304

but when I read that same memory range at the NeXT> prompt, I get this:

2e800000: 00000000
2e800004: aaaa0102
2e800008: 00000203
2e80000c: 00000304
2e800010: 00000001
2e800014: 00000506
2e800018: 00000605
2e80001c: 00000708
2e800020: 00000001
2e800024: 0000090a
2e800028: 00000a09
2e80002c: 00000b0c
2e800030: 00000809
2e800034: 00000d0e
2e800038: 00000809
2e80003c: 00000f00
2e800040: 00000001
2e800044: 00001102
2e800048: 00001001
2e80004c: 00001304
(Here's a photo of even more of the address space (https://imgur.com/TYytZiE))

It looks like there's some kind of aliasing going on, though I'm having trouble nailing down the pattern.  16-byte boundaries (every 0x10) are always wrong, though those aren't the only errors.  It does look like some of the addresses at 16-byte boundaries are reporting the value that was supposed to be written to the previous 16-byte boundary.  For example 0x2e800010 has 0x2e800000's intended value, and 0x2e800030 has ox2e800020's intended value, but that pattern doesn't always hold.  Aliasing due to a bad address line(s) or something similar would explain why the first test that writes the same 32-bit word everywhere passes, though maybe it's also significant that the value the first test writes everywhere (0xaaaaaa0a) only ever sets even bits?

I also get the following strange behavior when writing 32-bit values into the VRAM:

(https://i.imgur.com/AWZVfKe.jpeg)

Does anyone see a pattern or have any suggestions?  Should I start trying to beep out address lines to the VRAMs?
Title: Re: NeXTDimension VRAM error
Post by: andreas_g on Nov 08, 2025, 01:03 PM
Looks very strange. I can't see a pattern either. Maybe some hardware experts are around who have an idea what might cause this kind of errors.
Title: Re: NeXTDimension VRAM error
Post by: KennyPowers on Nov 19, 2025, 10:57 PM
I've noticed that reordering and/or swapping out some of the SIMMs actually changes what I see in the VRAM's memory range after the second VRAM test fails.  There are still always errors, and the first 8 bytes always read the same, but this is with the same 8 SIMMs installed as in my previous post, just in a different order:

IMG_20251119_173742.jpg

Yes, I've tried numerous combinations of only 4 SIMMs, thinking that one or two of them may be bad, without success.  These 8 SIMMs that came installed on the board are the only compatible SIMMs I currently have, but I'm going to order some to eliminate that variable.  Question...do I want EDO or FPM SIMMs for an ND board?

https://www.ebay.com/itm/155458853451?_skw=72+8mb+edo&itmmeta=01KAEH1ZW8SZ81HXPZ58K4KN70&hash=item243211da4b:g:nCMAAOSwDoFkFLpO

or

https://www.ebay.com/itm/155306516452?_skw=72+pin+8mb+fpm&itmmeta=01KAER5E2NMSH809FCD0PG9BFD&hash=item2428fd5fe4:g:1s8AAOSw98hhCvWu