Search results

Audio pulls from the RAM using a shared data path, though it's the pair of 74LS161 chips at UE15 and UF15. I'd have to do a bit of digging to understand quite how it gets from eight bits of data to an analog audio signal, though my current intuition is that it's using counters to generate a PWM...

Look for a pair of shift registers (74LS166 at UF13 and UF14 according to the schematic that I found). Eight pins on each chip are supposed to connect to different RAM data output lines. One of those connections is probably bad. It's clearly not the RAM chips themselves, as the system boots to...

I may also be interested in a board or two as well, given what happened last time I tried to use my "working" IIfx (spoilers: it wasn't anymore).

So far as I am aware, the Intuos is only providing the one device with handler 0x6A, but I don't have a mouse for it so perhaps that's required for it to mode-shift? Yes, the MouseMan ADB's "mouse" device returned that string, and I was running some version of System 7.x, which might explain...

This took a bit more doing than I had expected, apparently my "working" IIfx isn't anymore, so I had to dig out my Q800. MouseMan, Macintosh Version: Type: Mouse, original handler $01, original address $03, current handler $04. Supports handlers $01, $02, and $04. Does not support handler $03...

Just checked, and I have a few things. A Wacom Intuos GD-0405-A. A Logitech MouseMan(TM), ADB. "M/N: M-AC13-4MD". A Logitech MouseMan(TM), Macintosh Version. "M/N: M-AH32 P/N:840015-00". I also have a Wacom Digitizer "*UD-0608-A*", but I already see that in your list. The two MouseMan devices...

My own read on this scenario is that CurrentA5 is still valid in the interrupt context (see IM II-386, the Assembly-language note for SetUpA5). That said, I don't know how this would interact with MultiFinder or other multi-process environment.

Looks like you have a broken trace between C6 and the label for Q1.

C111, like C120, looks like a decoupling capacitor... which, as recently discussed elsewhere, is unlikely to cause a straight-up circuit failure. That said, a decoupling capacitor exploding is extremely suspect, so I'm going to hope that it's more a case of having been mechanically crushed. If...

I don't have a board to examine, but based on the photo you've shown I can see that it's a Philips part, in that particular in-line package that suggests a need for good thermal dissipation (thus, power handling capacity). It's in the speaker path, so probably an audio amp, and then there's the...

Looks like the backside is all "decoupling" capacitors, which are probably all the same type. Remove another one and measure it out-of-circuit to find its value, then use the same again? That said, a single missing decoupling capacitor isn't quite likely to cause a straight-up failure like this...

Sounds right. NTSC black level is 7.5 IRE, NTSC-J black level is 0.0 IRE. Hence why some people recommend setting a US TV brightness to 7.5 if using an old Japanese game console over composite or RF. Presumably some other display standards have a similar variation.

No, pins 9 and 18 are mutually-exclusive tri-state outputs. One of them will always be high-z if the other is driving, and vice versa. Either manipulate the FREQADJ signal or probe at pins 2 and 11 for the inputs. If 9 is showing a clock then 3, 5, and 7 should all show the same clock. If 18 is...

Okay, first off, it's very easy to determine that the horizontal timings are in units of four pixels. The first half of the third set of 8 bytes seems to be some sort of flags (the 24th byte takes on values of $30, $c0, $f0, $f3, and $f8), possibly coarse scaling of the pixel clock multiplier...

Congratulations!

There can be off-by-one issues all over the various timing register values due to latency issues between recognizing that the sync state machine needs to change state and actually changing the state (the vertical sync state machine needs to transition synchronously to scanline boundaries, so the...

Apparently, I can't leave this thread alone tonight. This is a BSR with a 32-bit offset, targeting $0000063c. Looking at the 1024x768@60 mode, I see an htotal value of $014f (335), times four to get pixel clocks is 1340. The vtotal is $328 (808), giving 1340 * 808 = 1082720 pixel-clocks per...

I'll go one further, as I think that I have the weirdness figured out: For all modes except the first 1024x768 mode, it's 8 pixels per clock of the horizontal timing machine. For that one other mode, it's 4 pixels to the clock. And the corresponding difference in the record is that fairly early...

The 0F near the beginning feels like some sort of clock scalar for the horizontal resolution (note the odd entry out on the 1024x768 modes and the corresponding horizontal timing parameters). The 000F002200CC00D7 is the horizontal timing parameters. I'm not quite sure what's going on here, but...

Easy fix. Clean it up, scrape any soldermask off the via, and run a bodge wire from the new capacitor to the via.