AwkwardPotato

Worth noting that an RC circuit like this will distort the input signal from the QI mainboard, being that the RC acts as a low-pass filter. With the high-frequency edges of the digital signal filtered out, the rise and fall times will be far longer, with which third-party cartridges' tolerance is anyone's best guess.

The 1979 99/4 actually has this IC populated, unlike the 4A and QI. Bypassing it causes the black screen + cacophony fault, even if the original 9918 is swapped for a 9918A. I assume they had issues with tolerances on early units and something about the 4A's board layout solved them without the need for the LS04.

Cart port dongle, or cleaner yet, a new cartridge port riser board with option to use either an RC network or LS04. Could potentially kill two birds with one stone, one being the QI fix and the other being a replacement for worn-out cartridge ports. Edit: And if such a thing were made through the SMT assembly services offered by practically all cheap board houses, it could be a no-solder drop-in fix.

Another possible solution: using a 74LS04, and putting either 2 or 4 inverters in series between GS# line from the QI TAL and GS# line of the cartridge port. Delay time per inverter would be consistent between different TI units so long as wires are kept short, eliminating RC component tolerances as a potential issue, and it might be possible to mount the LS04 on the back of the cartridge slot riser.

Worth noting that the black screen & cacophony symptoms can be caused by the failure of almost anything, so it's a good idea to check the SRAM/ROM especially, and also the 'LS373/244/245 multiplexer setup and VDP if you haven't already, before going to the trouble of replacing the CPU. Edit: And to answer the original question, his troubleshooting methods are great, but frustrating at the same time, given how many years' worth of documentation are on AtariAge and elsewhere. You should be fine working without an oscilloscope.

If you're getting 4V on VCC on the 9900, that suggests there was some error when you measured voltages before that, since the 9900's VCC is connected directly to the 5V rail. What method did you use to probe voltages on the power supply/motherboard? There shouldn't be a significant difference between the VCC of the 9900 and the VCC of the RAMs. 4.7V to 5.2V is an acceptable range for the 5V output from the power supply. Anything lower than 4.7V may start causing instability.

On the GROM select difference: I'm not convinced it has any effect on the QI's operation. Unlike in the 4A, GS# isn't activated in the QI when both DBIN and A5 are low. I'm not sure, though, if there's ever a time when both DBIN and A5 are low in the 4A. A5 being low would mean the GROM read ports at >98xx are being accessed, which implies that DBIN should be high. If any of the more GROM-knowledgeable people want to confirm that, it would be much appreciated : - ) That being said, if the TAL really is to blame here, I think it's most likely related to the WE# and/or A15.CRUOUT lines.

AFAIK, the old-style keyboard strip slot and the "Solid State Software" badge being on a plastic insert date this one to very early 1983 at the latest, based on the consoles I've seen. Since that was well before the introduction of the beige units, the board probably was swapped by the user, like @wierd_w said.

Correction: the cart port's RESET line actually doubles as an input to the TAL, so scratch that. However, as I understand it, the TAL does generate GS# (GROM select), A15.CRUOUT and WE# differently than the 4A did. For instance, in both the 4A and QI, the conditions for GS# going low include: MEMEN, A0, A3 and A4 being high A1, A2 and A15 being low The last condition that must be met for GS# to go low differs between the 4A and QI. In the 4A, A5 and DBIN are NAND'd together: If the above conditions are satisfied, GS# will go low as long as A5 and DBIN aren't both high. In the QI, however, A5 and DBIN are XOR'd rather than NAND'd. In other words, the QI's GS# will only go low if A5 is high while DBIN is low, or vice-versa. I'm not certain whether this difference has any impact on the operation of the machine. In addition, the wait state generator in the TAL, which is involved in producing the A15.CRUOUT and WE# signals, is wired slightly differently than in the 4A. Still trying to understand the ways in which that might affect things...

Backing up slightly -- it's been suggested before that the FinalGROM/QI incompatibility was partly due to the missing CRU signals on the cartridge port. However looking at Ralph's schematics, it turns out that the FinalGROM doesn't make use of the CRU lines. Worth noting that the QI TAL not only generates GS#, ROMG#, A15 and WE#, but also the RESET line for the cartridge port. In the 4A, this signal is generated by the TIM9904 clock IC. Perhaps differences in the RESET timing are enough to break compatibility with the FinalGROM?

Assuming that the logic equations in the QI's TAL for GS#, ROMG#, A15 and WE# are identical to those in the standard 4A, you ought to be able to run one jumper wire from pin 4 on the cart slot to pin 11 of U28 (a chip right next to the 9900), and another wire from pin 6 on the cart slot to pin 4 of the 9901. I don't have a QI board to test this on; no guarantees that it'll work, don't hold me responsible for damage to you or your TI ?

Check on the VDP's thermal paste. The old paste is likely dried out and the VDP is more likely to fail if it starts overheating. Recapping isn't a bad idea -- it may not be entirely necessary for the motherboard, but there have been a couple more reports lately of flakey/marginal power supplies. Also, take out the TI's cartridge slot. The end of it that cartridges plug into has a plastic cover with felt lining: take that cover off, throw it away, and then clean the contacts on the cartridge slot. The felt lining gets full of oil and dirt and causes bad contact between the cartridge and the slot, causing the symptoms you describe.

If yours is actually labelled TMS9919 (which is actually pretty rare in 4As) it needs to be replaced with either an SN94624(A) or SN76494(A). Other chips like the SN76489 would need a higher clock rate than is found on a board that originally came with a 9919.

...and as far as I was able to tell, the parallel 4Mbit parts are listed as "Obsolete, Not Recommended for New Designs" on virtually all major electronics distributors, whereas the Spartan is still active and in stock. There's no question about whether such a thing will work; an EEPROM approach straight-up will not work in the 4A.

I'm pretty sure he's not misunderstanding -- replacing one FPGA with a litany of EEPROMs is impractical at best. Most FPGAs remain on the market for quite a long time, and the task of reworking a board to use a different one would be far easier than designing this hypothetical, comically large EEPROM-based board. Parallel EEPROMs themselves are going out of style; Mouser only shows 13 different parts in stock in your suggested size. More importantly, EEPROMs are a poor substitute for programmable logic at the speed of the 9918A/F18A. The access time of 120ns for the part you linked (which is typical for EEPROMs of that size) means it'll take 120ns for the output data to be valid after an address change; by extension, a chain of 4 EEPROMs cascaded would need 480ns for the output to be valid, at which point you're almost certainly violating the timing requirements of the 4A.

Unplug the power board from the motherboard. On the motherboard's power connector, measure the resistance between each of the power rails (+5V, +12V, -5V) and ground. Chances are at least one rail is shorted if it's causing the power board to buzz. Also, 11.7V is totally fine for the 12V rail.

Small dabs of hot glue; if the glue needs to be removed, isopropyl alcohol will detach the drop of glue from the board without damaging the board or leaving any residue at all.

You have to do a full transaction with each sensor to properly implement SPI. Sensors will not report data back to the AVR on their own; the AVR is responsible for clocking the data out of the sensors. The time it would take to query a single sensor is so small that parallelization is impractical.

Implementing SPI does not have to be this complex. No 512-pin breakouts or latches or buffers are needed -- the sensors/displays/etc will not compete for control of the SPI bus, since the AVR will only ever read/write to one device at a time. Theoretically, to implement this you'd connect the 3 SPI lines (SCK, MOSI, and MISO) from the UberGROM's AVR to each SPI device in parallel. Each device does NOT need its own SCK/MISO/MOSI. An individual Chip Select for each device can either come straight from the AVR, or from a demux if you run out of I/O. If I'm not mistaken, the UberGROM could use the READY line on the cartridge port to slow the TI down for slow SPI accesses. With this method, you would need a total of 7 wires coming out of the cartridge for 4 SPI devices. If you wanted even fewer wires than that, you could use I2C instead of SPI, allowing access to up to 128 devices with only 2 wires.

About the RPi Pico -- it's not in the same league as any of the other members of the Pi family, so using it for TIPI is likely out of the question. The core they're using on it is identical, for the most part, to the one found on higher-end Arduinos. What makes it interesting though is the programmable I/O, which has already been demoed driving HDMI displays.

Yes. That component (it's an inductor, btw) actually looks totally normal. Even though the video works fine, it's worth reflowing the joints on the motherboard's video connector to rule out a bad solder joint as your sound problem. It's common for a cold joint to appear fine, when in reality it isn't.

The highlighted component wouldn't affect the sound; it's part of the video circuitry. If you have a multimeter, plug in your video cable, and see if there's a connection between the center pin of the cable's audio jack and the video connector pins on the bottom of the motherboard. If there isn't, resolder the video connector pins.

Rich hasn't done anything wrong, please get over yourself. These back-and-forths do way more to trash threads than RXB plugs.

The PCB would be the relatively easy part; the hard part is coming up with new mounting hardware to install the PCB in the case (modern switches are lower profile so the whole board has to be raised up) and finding keycaps that look appropriate in the TI.

Thanks, that makes more sense. I never knew the 99/4 could come with a 9928/29, everything I recall reading online suggested to me that they only came with 9918s.