Hans23

You could try inserting a machined socket into the TMS9918A socket and put the F18A into that. Machined sockets have slightly thicker pins and are often longer than the pins of the F18A, so that might help.

You need a FinalGROM99 to emulate cartridges. TIPI can load programs from the network into RAM, but it does not emulate GROMs or other cartridges.

I'm looking at the datasheet and it seems that the minimum Vdd/Vref voltage is 2.7V. Does that not mean that I can't really turn the reference voltage down to my output level of 1.7V?

What is missing in Arduino, Raspberry Pi, Agon Light, MicroMite and the many other systems that exist today? How are these not "actual home computers"? I think that the options for tinkering with computers today are huge, and there are many different fields in which simple systems can be built from cheap, readily available components by individuals to have a bit of fun. How much mass are you looking for that the Raspberry Pi family does not have?

After a having done a couple of TI-99 repairs, I'm back to figuring out how to get sound working with HDMI on the TI-99/4A. So far, I have determined that the only version of the tn-vdp that successfully embeds sound from the MCP3202 is tn_vdp_v2_v9958 - It does not seem to be register compatible with the 9918, though, so the console starts but does not display anything. The (negative) startup beep is audible, but at a very low level. The signal that I'm injecting into the ADC looks like this: I'm taking the audio signal after it has been filtered: The high frequency noise is not audible on my TV even with the volume maxed out. I believe that the filtering is a good thing, but I'm not sure why the signal is barely audible in the HDMI output. The peak-to-peak level is at 1.7V. If I understand the MCP3202 data sheet correctly, the input range and the supply voltage are the same - 3.3V volts in our case. Would that not mean that a 1.7V signal should be pretty loud, as it is at ~50% of the input range of the ADC? I'm going to try and backport the audio code to the F18A based version of the tn-vdp, but I would really appreciate some help on the analog side of things as I don't really know what to do next there. Thanks! Hans

Here's the picture of the repaired PCB, back to life: Red - Dead component replaced Yellow - Chip desoldered, found to be OK

OK, so after I replaced the '245 in the bus multiplexer which did not make good contact to the socket that I had installed, the black screen became a blue screen - I also saw the beep on the oscilloscope, telling me that the ROM initialized the sound chip. The DRAMs were my next suspect, and I desoldered the one that got hotter than the others. It tested bad, and I replaced it with a good one which changed the screen to be black with a blue border and some structure that resembled the startup screen. No other chip got hotter than the others, so I decided to desolder all DRAMs and test them. This was not a pretty operation due to the large ground planes and I'm not all that proud of my work, but it was necessary as all DRAM chips test bad. I'm going to pause here to breathe some air, but I'm kind of hopeful that this console will be back operating eventually. The dead CPU, 9904 and DRAMs lead me to believe in a power supply failure to have been the cause, but the dead VDP crystal does not fit that theory too well. Anyway, thank you all for helping and rubber ducking, I would not have made it so far without you!

I swapped out the VDP crystal and now the clock comes up and I reliably get a black screen. Back to square one in fault finding, I guess

It was indeed the GROMs that locked up the machine, and I think that the reason for that is that the GROM clock is wonky - If I understand things correctly, it is generated by the TMS 9918 and should always be present on the clock input pin of the GROMs. I did not see it, though, so I started poking around in the VDP area and found that once I probe one of the clock output pins of the VDP with the scope, the clock starts ticking, video output sync is generated and the CPU executes instructions. Black screen, still but some progress at least. I've exchanged the socket and tried a known good VDP, so I now believe the problem is somewhere around the passives and the crystal that create the VDP clock. I'm a bit puzzled, however, that probing with my 10x oscilloscope probe makes the clock generator work, but I don't know much about electronics.

That makes sense, thanks for cross checking. I've put in a set of known good GROMs and the behavior is the same. If I start the machine without the GROMs installed, though, it does not hang, so it seems that the CRU interface is involved in the fault.

I may be missing something here: It looks as if the D input of the flipflop (pin 2) is connected to another two gate inputs and nothing is driving this network? Me not reading the schematic correctly or error in the schematic?

This is the part of the schematic in question:

As I mentioned, both the ROMs and the RAMs are good, I've verified them to work in another console. I have looked at the READY signal now and as I suspected, it is stuck low when the machine freezes. Unfortunately, it is generated by a whole bunch of combinatorial logic and flip-flops, making it really difficult for me to pinpoint exactly where things go wrong. I might end up having to desolder and test all of the chips involved

I've also successfully replaced 4A console ROMs with 2764 EPROMS on two sockets with the required rewiring applied. I'm not sure how you'd replace the 6810 RAMs with EPROMs though.

I've removed everything but the ROMs and the RAMs from the data bus to see whether the machine gets any further in the reset initialization process, but it does not. It seems to me that this only leaves the READY signal as being incorrectly combined, but maybe I'm missing something?