SuperMac Spectrum 24/V Display Problems

MacOSMonkey

Well-known member
Weird. Lots of information!

A couple of issues:
1. The board has a default gamma table that is going to affect what you see on screen (but not the values in RAM). The default for all of these boards is usually the Apple Standard RGB Monitor Gamma. See Cards & Drivers. It derives from early trinitron monitors. If you want to change it, open the Monitors cdev and hold down the option key (you should see a smiley for the boot screen) -- then, double-click on the gray monitor region for the card. Then, choose "Uncorrected Gamma". You should also see any other gammas that the board (or system) has to offer. This topic is peripheral to the actual problem, but if you disable gamma correction, you should see pixel values on screen (via the board's DAC) that represent the uncorrected phosphor beam response. Gamma correction attempts to simulate a linear response -- or when using products like SuperMatch, helps to mimic certain lighting environments (D50, D55, 9500K, etc.) and harmonize the appearance of print color vs. screen/light/transmitted color (after calculating the phosphor response for a specific display).

2. After writing all 0's are you seeing the same values appear repeatedly, or do you see random results?

For example, if the first pixel is: 0x00008086 after writing all 0's and you then write 0x00224466 and see 0x00a2c4e6 (but also where you sometimes see an $80 is green and blue components -- but never red), you may be seeing stuck pixels that are OR'd into the response:

in : b0000 0000 0010 0010 0100 0100 0110 0110 (0x00224466)
out: b0000 0000 1010 0010 1100 0100 1110 0110 (0x00a2c4e6)
0's: b0000 0000 P000 0000 1000 0000 1000 0110 (0x00008086)
diff: b0000 0000 N000 0000 X000 0000 X000 0UU0
P = present in some of the corrupted 0 writes (green and blue, maybe it happens in red also and is just random), X = bit present in 0 write at the same address, U = Undetectable since the bit pattern is the same as the 0 corruption pattern

Some tests you could do here might be:
1. to continuously write 0's at a fixed location and read back the data to see if the bad pattern is always the same.
-- this test helps to confirm if the problem is random or fixed.
2. to check to see if you always see a certain failure, like x00008086 instead of 0x00000000 at the base address as in #1, then write 0x00007f79 and see if you consistently read back 0x0000ffff.
-- this test helps to confirm whether or not the problem is input data-dependent. If you read back 0x0000ffff, then you know the problem is likely data independent. If the bad bits change depending on source data, then that's another clue.

And to try to stay out of the rabbit hole -- just to make sure I understand what you have said -- have you checked that the RAM holds the correct data by looking at the RGB components on the scope directly at the VRAM device...and then looking at what is being read back on the scope at the VRAM device on a read? You can't filter the SMT02 out on the write, but you can filter it out for the read - it's just an initiator -- and you can immediately capture the read data (and verify that the transfer waveform is correct).

Some examples:
- If you see bad write data going into the VRAM device, then you know that there is a problem in the data path
- If the input data and wave form are correct and you read back corrupted data with a correct waveform, then the device may be bad
- If you saw bad data going in and you read the same bad data at the device coming out, then you know device reads are probably OK
- If you read back the same corrupted data at the device and across Nubus, then you know that Nubus reads are OK, etc.
- If you read back good data at the device and good data went in, then you know that the VRAM R/W is OK and that the read back across Nubus has a problem somewhere.

Try to bracket as much as possible to save time and pin down the problem.

I see that you verified the address lines. After you have definitely confirmed the data/data lines at the VRAM device, then, as you say, you should look at the same data on the write and read cycles on Nubus. See Cards and Drivers for the expected waveforms. There could be a timing or data bus issue. But, phenotypically, because you are seeing columns of bad data on the screen, it implies that there is a data write/translation problem (as you have already confirmed by the current read-back tests).

Hope this helps.
 

jmacz

Well-known member
Many things to try here.. I did check the reads and writes coming immediately in and out of the vram. It’s not always what I wanted but what went in is what’s coming out. But I need to conduct more testing to be sure. Thanks!
 

jmacz

Well-known member
I've got multiple issues on the board.

I found and fixed 3 issues last night but it did not solve the main problem with artifacts. While debugging the main problem, I bumped the card near the SMT/SQD chips and happened to notice a glitch. I then started tapping the card on that side of the board and was able to reproduce the glitch. The issue could either be internal to the PCB or an external connection, but just in case, I went through all 204 pins on the SMT and the 204 pins on the SQD, nudging each pin side to side to see if it was loose. I found 2 such pins on the SMT and 1 on the SQD. After fixing those, the bump glitching on that side of the board was fixed, but again, it did not solve my main issue.

I then decided to tap to see if anything else was loose on the board. I found another ... the SDQ3 on U19 VRAM (pin 26) is getting a glitch signal whenever I tap the board near it. This is the same chip location I was having earlier in this thread. I know it's not the chip as I swapped chips and the issue stayed with the VRAM location (not the chip). But there's clearly a partially touching connection in this area but after poking around, I don't see anything on the surface that could be causing it. Still looking further but it's possible there's a partial break here inside the PCB. But this is only on the SDQ3 which I believe is the output to the BSR/DAC and it's only on this one chip whereas my main problem is with many other chips.

Checking the writes/reads on the VRAM is kinda painful and I'm open to ideas on how to more easily do it. The writes are easy. I just have my logic analyzer trigger on the WE going low (write signal) and since that only goes live when I initiate a write to memory, I can easily jump to the signal output for that write.

But for reads, the card is constantly issuing read requests, there's a flood of them, so I am trying to figure out how best to trigger my probe so that I can focus on the read that I want. My logic analyzer software doesn't provide an expression based trigger otherwise I could trigger on the right addresses + the read signal + the right RAS/CAS combination, but alas I can only trigger on a single channel only. So I have to end up going through hundreds of reads to find the one I want which is very inefficient.
 

MacOSMonkey

Well-known member
Good job finding the solder fractures. You should probably flux and reflow SQD01 and SMT02. Tapping only helps if the pin has intermittent contact. It could be a full open break/separation. However, the fact that you saw those 3 fractures means that others are likely. They could be anywhere. Also, there could be via fractures or corrosion (as I mentioned in a much earlier post somewhere). If you find a via fracture, you will have to do a very careful drill and fill with silver epoxy to reconnect to the (internal) trace. External trace breaks are much easier. It's either drill and fill or a cut and jump with rework wire. If you don't feel confident with drill and fill, there are local assembly shops that could do it. PM me about it, if needed. But, I realize that you are Rework Wire King. :D

For triggering, you can try the following: disable interrupts and do a back-to-back read then write and trigger on _WE. Then, look at the buffer immediately ahead of the trigger. Or, do it in order as write/read -- the scope should capture it as a post-trigger buffer and it should be there - either way -- doesn't matter. If you write the code in assembly, you will have back-to-back 68K instructions, so it won't matter what other OS update reads are happening (assuming there are no intervening interrupts). You will be explicitly triggering on _WE to catch a pre- or post-read. It also helps to be able to see/compare the write and read data as adjacent events.
 

jmacz

Well-known member
Good job finding the solder fractures. You should probably flux and reflow SQD01 and SMT02.

Yeah, I had flux'd and reflow all the pins on the SQD01/SMT02 months back but obviously didn't do a good enough job. Will need to go through and do it again. I'm watching the pins under a scope and they are liquifying so not sure how these were missed last time.

For triggering, you can try the following: disable interrupts and do a back-to-back read then write and trigger on _WE. Then, look at the buffer immediately ahead of the trigger. Or, do it in order as write/read -- the scope should capture it as a post-trigger buffer and it should be there - either way -- doesn't matter. If you write the code in assembly, you will have back-to-back 68K instructions, so it won't matter what other OS update reads are happening (assuming there are no intervening interrupts).

I might be missing something but I don't think that helps. I've tried disabling interrupts but that only halts the OS. But the card itself has lots of stuff going on on its own -- it has its own SAM clock to send the output of the VRAM to the BSRs and to the DAC for the display, it has to refresh the DRAM all the time to persist the values so the reality is that even with the OS paused, there's a ton of activity to each of those VRAM chips which means even consecutive instructions are no longer consecutive at the VRAM chip level.

I did make a little more progress today.

I figured out the U19 tap glitch issue - but it didn't solve my overall problem.
I attached probes in groups (since I don't have enough channels) to the U19 pins and was able to find the one that had a fluctuating signal when tapping. It was the A2 memory address line. This one's totally on me I think... I had removed this chip before so I didn't do a good enough job putting it back on. The solder joint looked good but clearly it was not 100%.

But I don't understand why A2 was causing me a problem with this chip. The symptom was that when I tap the chip, the column of pixels this chip is responsible for flickered. I had my logic analyzer set to trigger on a WE (write enable) signal. But NONE came. For a flicker to happen, either the memory is being temporarily written to OR it's the outbound signal to the DAC. But this A2 pin has nothing to do with the outbound signal to the DAC (nor did the outbound signal to the DAC -- the SDQ pins -- glitch at all). The A2 pin would impact only a read/write to memory from the OS but again, there was no WE signal. My logic analyzer never triggered on the WE. So I don't get why an issue with the A2 pin would cause a tap glitch. But with the A2 pin fixed, the tapping issue is gone. Huh?? There is another path to writing to the chip, it's a SAM to DRAM write but I triggered on the signals that would cause this write to happen and nothing on those signals were seen either. I'm lost on this one.

Time consuming but got more data on the U19 SDQ-3 output. I'm debugging in B&W now. The columns of pixels generated from U19 SDQ-3 is stuck sometimes in black, sometimes in white across the screen. Watching the DAC, the BSR, and the SDQ-3 output, it's clearly showing the pixel is set to black. I then drop into the debugger and am reading/writing values to that those pixels. The screen always show what is in the VRAM. Logic analyzer shows read requests are answered with what is showing on the screen but my debugger output for that read shows the opposite. When I do a write from the debugger, that write value doesn't show up properly going to the VRAM in my logic analyzer.

The values going to/from the VRAM go to the SQD chip, not the SMT. I double checked this. So something is there... the SQD/SMT pins are too tiny for me to latch onto with my probes. Will have to use the nearby vias for this purpose and see if I can identify why I'm getting the wrong values for this particular U19 chip from SQD.
 

jmacz

Well-known member
Been watching more of the operations:
  • Probe on the host side of Nubus
  • Probe on the card side of Nubus
  • Probe after the operations go through the bus transceivers (before SMT02-S)
The transactions for all three of the above are the same. What I see:
  • On reads from MacsBug, for all three I see the faulty "stuck" value on the wire.
  • On writes from MacsBug, for all three I see the proper value I asked to be written on the wire.
This seems to rule out Nubus and the bus transceivers. The bus transceivers have their data lines hardwired directly to the SMT02S. Looking at the path:

Code:
HOST<->NUBUS<->CARD<->BUS TRANSCEIVER<->SMT02S<->SQD01<->VRAM

Things look fine on the host, the nubus, the card side of nubus, the traces between bus transceiver and SMT02S. Also confirmed it's got the wrong writes but the correct reads between SQD and VRAM. So that leaves the fault in one or more of:
  • Pins on SMT02S connected to bus transceiver traces.
  • Inside the SMT02S.
  • Pins on SMT02S connected to the SQD01 traces.
  • Traces between SMT02S and SQD01.
  • Pins on SQD01 connected to SMT02S traces.
  • Inside the SQD01.
  • Pins on SQD01 connected to VRAM traces.
  • Traces between SQD01 and VRAM.
Unfortunately not much above to have my probes latch onto.
 

jmacz

Well-known member
Reflowed all pins on the SMT02S and SQD01 and didn't improve the situation. I looked into 204 pin clips but they seem to be a few hundreds of dollars which puts them out of reach.

Given I'm seeing the proper writes and improper reads up to SMT02S (from nubus bus transceivers) and that I'm seeing improper writes and the proper reads (well proper "improper" reads) up to the SQD (from the VRAM), the issue looks like the SMT02S or the SQD01 or the connections in between. I need to rule out the connections between the two chips first and hope the issue is there given those chips are irreplaceable (without a donor board which defeats the purpose). This will take some time as I need to finish tracing between those chips (already traced 36 of them) and then get ready to solder wires onto the vias next to each pin in order to allow probing on those signals.

I've got some other things going on so will have to unfortunately put this down again and get back to it in a month.
 

MacOSMonkey

Well-known member
Just saw all of these messages. Sounds like progress. Sorry - I was forgetting about RAM refresh activity. I think that's a function of the video config. So, you could try using it as a secondary monitor and set a low-speed config like NTSC by using SuperVideo -- it should end up running at 14.31818Mhz. Also, disconnect any cable sense connectors on video out - it might override a PRAM setting - not sure. You don't need to connect it to a display -- it's more about seeing if you can catch the read. There might also be a 12Mhz NTSC mode IIRC - slightly slower. The fastest would be 23" 1280x1024, but I don't think it was in the original ROM - max was 21" 1152x870 -- but maybe added later with 3.0+. I would have to look at a newer ROM.

In terms of soldering, when there is debris or poor contact, looks can be deceiving. For example, solder can well up on top of a pin and look good, but the pin may still not be connected to the pad. Or, there can be solder on top of debris that is preventing contact/wetting. Verify that you see solder on the pin and the pad and not just on top of the pin. It can be a subtle issue. The other important contact issue if the board has sustained physical damage is pad adhesion. Check carefully to make sure that the pads haven't lifted/fracture at the joint. It can be difficult to tell, depending on the routing.

In terms of debug wires, I'm not sure of the pin spacing .050? .025? Not sure of the spacing -- would have to measure. But...instead of soldering individual wires, you could look for J-bend, single-row pin headers. If you find the right ones, you could wire an entire side (or 8 or 16 -- whatever your pod supports), but you just have to be careful with them because of the risk of torquing the pads. If there are consistent rows of vias, you could scrape and attach to them (including possibly on the back side of the board -- depends). Just a suggestion.

I sometimes used to make debug jigs out of bare FR4 -- maybe a bit exotic...but there might be a custom solution that would save time in the end. YMMV.

Did you figure out if it's always the same bits? Also, does the clock look OK when transferring data to/from VRAM?
 

jmacz

Well-known member
So, you could try using it as a secondary monitor and set a low-speed config like NTSC by using SuperVideo

Yup, I've been using a second monitor. But even the slowest option is still too fast. I can sometimes catch the read but then picking it out of all the data is a pain. I wish there was a search function built into the tool where I can give it an expression (when this signal falls AND this signal is high AND ... etc. etc) that would be SO useful but this software is bare bones. I might have to consider exporting this data and writing my own visualization tool, but that would be yet another project.

But...instead of soldering individual wires, you could look for J-bend, single-row pin headers.

Yeah, been considering exactly this... I didn't measure the spacing but it's very tight.. 51 pins per side, 204 pins total on a chip that's about 1" square.

Did you figure out if it's always the same bits? Also, does the clock look OK when transferring data to/from VRAM?

In black and white (which is what I'm currently focused on to reduce the problem for now), it's currently always the same VRAM which means same column and yes same bit. It seems to be stuck high (black) but on occasion is stuck low (white). Regardless of whether it's stuck high or low, I see 0x4 coming back to the debugger when I read those 4 bits when it should be 0x0 (when it's low). I see this "bad" value on the nubus, the nubus bus transceivers, coming from the SMT. When I try to change it, I see the write value that I requested on the nubus, the nubus bus transceivers, and heading to the SMT, but I see that bit corrupted when it comes out of SQD headed to the VRAM.

Clock looks ok... this includes the serial data io clock, the nubus clock, and the ras signal which drives the other signals. The two crystals on the board also look ok.
 

jmacz

Well-known member
Unfortunately, I'm going to throw in the towel on this one after 9 months of messing with it on and off.

Host <-> Nubus <-> Card Nubus Slot <-> Card Bus Transceivers <-> SMT02S

Spent some time analyzing the nubus signals both on the host side and card side of the bus transceivers on the card. Limited to 16 probes on my logic analyzer, I needed 4-5 of them to monitor the main nubus signals which only allowed me to analyze 8 of the address/data lines at a time. I played with setting bytes/words/longs on multiple addresses corresponding to the pixel buffer, and every time I see the correct address and correct data (write contents) on the card side of the bus transceivers. This part of the path looks clean. All connections are near zero resistance.

SQD01 <-> VRAM

I watched the signals here as well and the reads match what I see on screen. Writes on one pin (DQ3) are missing to VRAM Chip U19 when setting individual pixels. But the right value seems to show up when an image blit is happening. So this suggests the connections here between the SQD01 and VRAM are fine. Individually testing the connections from all the VRAM pins to the SQD and SMT chips are all good with near zero resistance.

I watched the row and column address signals to/from the VRAM chips and that all looks correct as well.

VRAM <-> BSR03 <-> RAMDAC <-> SCREEN

I watched the signals from the VRAM chips to the BSR03 and RAMDAC. These all look correct and the what I see on screen matches what I see in the VRAM. Seems like everything is good here as well.

SMT02S <-> SQD01

There are 37 connections between these two chips. I traced each one and also looked for shorts across most of the top side and bottom side of the board. Also compared these against a working Spectrum 24 IV (which is not exactly the same but close enough). All the connections are good, I see no shorts, all are near zero resistance. Nothing looks out of place here.

I could tap vias on the bottom side of the board to analyze each of these 37 pins but it's going to be a tedious task and not clear how difficult it will be to make sense of the signals as these connections are proprietary. I could look for magic bits I send via reads/writes, but I'm some what demotivated to go down this path right now as it would be extremely time consuming. Given blits seem to be ok but individual pixel reads/writes are not, my guess at this point is one of these two chips (or both) has a fault. I also don't feel like swapping the SQD or SMT off my working boards as I don't want to risk breaking the working boards just to satisfy my curiosity.

Rest of the Board

The rest of the board had some issues but I've repaired everything that was problematic. All resistors check out on/off board. All capacitors check out. The resistor packs check out. The clocks check out.

Going to leave this board as a parts board for now and if I ever run across a cheap dead board, will try at that point swapping chips around to finally get an answer on this one. But at this point, it looks like one of the proprietary chips is dead.
 

Taniwha

Member
(I designed SQuiD ... and did the high level architecting of the other SM accelerators)

There are 32 data bits between SMT and SQuiD, some arbitration (probably 2-3 bits) - I can't remember how ras/cas/addresses are shared.

In 24-bit mode only 24 of those 32 data bits are used (most accelerated things don't use those bits at all) - 1-8 bit modes only use one bank of the DRAM (red I think) and use all 32 data bits.

It does sound like you have a bad pin on a ram chip, or a single bad bit on the nubus->smt->sqd path

I'm on an extended trip to the US at the moment, when I get home I'm going to finish an architectural write up of how SQuiD based boards work which will hopefully help some people in the future

- Paul
 

jmacz

Well-known member
Wow, that would be totally helpful!

Ok, I counted 37 connections between SMT and SQD so that's close. I guess I wasn't too off. And yup, I saw that 1-bit mode was using the red VRAM bank only so it's good hearing that validated as well.

My issue occurs at all bit depths but I was working on 1-bit first as that's easiest (at least I thought so). I ruled out the VRAM because probing those pins (of the VRAM chip U19 in the red bank that seems to be outputting one of the bad values) seemed to show proper activity. I also swapped two of the VRAM chips and that didn't change anything, the issue stayed with the location, not the chip.

As far as I can tell, something seems to be happening between the SMT and the SQD. Nubus to SMT seems ok. And SMT to VRAM seems ok.

Not sure if you remember everything from three decades back :) but if you remembered which pins were part of the 32bit data flow between the two chips and/or what the semantics were on how the two chips communicated, that would be immensely helpful :) I also have a crude partial schematic I drew up that needs to be validated but I don't want to be a burden to you.

Thanks for your post. Awesome to see you SuperMac folks out there!! (y)
 

Attachments

  • S24V.pdf
    1.3 MB · Views: 5

lobust

Well-known member
(I designed SQuiD ... and did the high level architecting of the other SM accelerators)

There are 32 data bits between SMT and SQuiD, some arbitration (probably 2-3 bits) - I can't remember how ras/cas/addresses are shared.

In 24-bit mode only 24 of those 32 data bits are used (most accelerated things don't use those bits at all) - 1-8 bit modes only use one bank of the DRAM (red I think) and use all 32 data bits.

It does sound like you have a bad pin on a ram chip, or a single bad bit on the nubus->smt->sqd path

I'm on an extended trip to the US at the moment, when I get home I'm going to finish an architectural write up of how SQuiD based boards work which will hopefully help some people in the future

- Paul

Awesome!

I'm looking forward to reading this already!

Ditto that!
 

Taniwha

Member
So SQuiD's main job is as an accelerator but it's also part of the datapath when you access from nubus in 8-bit mode copies those 32 data bits to/from the red bank, in 24-bit mode it reads/writes 32-bits to/from each bank and does a 4:1 mux to make 24 bits from/to nubus - some of those 37 bits will be a direction, an 8/24 mode and a mux, there's probably a bit that selects SQuiD's internal registers. I think I have the docs for SQuiD at home, I'll look it up when I get back at the end of the month
 
Last edited:

jmacz

Well-known member
So SQuiD's main job is as an accelerator but it's also part of the datapath when you access from nubus in 8-bit mode copies those 32 data bits to/from the red bank, in 24-bit mode it reads/writes 32-bits to/from each bank and does a 4:1 mux to make 24 bits from/to nubus - some of those 37 bits will be a direction, an 8/24 mode and a mux, there's probably a bit that selects SQuiD's internal registers. I think I have the docs for SQuiD at home, I'll look when I get back at the end of the month

Awesome, thanks!!!
 
Top