UsagiElectric

There's a nice little ZIP file here that has a full suite of ROMs and the console ROMs in there are good. I dumped my 99/4 ROMs and tested the hex against those and sure enough, they were identical. https://www.retrostic.com/roms/mame/ti-99-4-home-computer-54278 Also attached my console ROMs here too for good measure! These are the ROMs as dumped on my homemade ROM reader. I had two TI-99/4 motherboards and both sets of console ROMs dumped identically and matched to the ROM files in the link above. As far as checksums go, here's what HxD calculates: High ROM CRC-16: CFD5 MD5: D4BEB51D6267270FC1E3917E076DFA55 Low ROM CRC-16: DA50 MD-5: 1BEC408D2D5CC964E66AB285BA4A7887 The High ROM looks to be the same as yours, but the Low ROM looks pretty dramatically different. I'd do a full data comparison between the two files to get an idea of what's going on. You could very well have a bad low-byte ROM. If you do, you can make an adapter from a modern EEPROM moderately easy with a little inventive wiring. I attached a picture of how to wire up a 28C64 EEPROM that should work, although it's best to double check. I wargamed the possibility of a bad ROM, but didn't ultimately end up needing this. Let me know if there's anything else i can check on the system to help! Cheers, David CR_C994_LOW.BIN CR_C994_HIGH.BIN

Thanks again everyone for all the help!

Oh awesome! Looking forward to seeing the setup soon! Interesting, I was always under the impression that the four or so out there were prototypes. Color me all the shades of jealous that you actually have one! My goal is to build a replica P-Code sidecar using a spare RS-232 box and a P-Code PEB card. But both the P-Code and Video Controller are just going to be all about playing the long game. We'll get there eventually!

Thank you! It's definitely a factory TI socket, both the 99/4 motherboards I've seen have the same sockets on the Console Roms, but it still could have come from me or a previous owner. Either way, it was an absolute bear to hunt down, but we got there in the end! Whoa, that's an insane solder bridge! I'm not sure I'd have been able to find that one, it definitely would have had me running circles for a long time. Oh yeah, going for the big TI train! Current loadout from left to right is TI Color Monitor, 99/4, Speech Syntehsizer, Thermal Printer, RS-232, Phone Modem, Memory Expansion, Disk Controller and Disk Drive. Would love to expand it with a 2nd Disk Drive and the Video Controller and P-Code sidecars someday. The Video Controller is rare but they did actually produce them, so I'm keeping an eye out for it. The P-Code sidecar was only a prototype, so I think I'll have to get a P-Code PEB card and modify it to go into a spare box to make a replica P-Code sidecar. The software is nothing fancy, just Multiplan and TI-Writer in the binders, and Personal Record Keeping, Tax/Investment Record Keeping, Terminal Emulator II and Mini Memory. And I think I have Extended Basic in a cartridge around here somewhere too. I have a weird obsession with productivity/office software, haha.

Thanks! Thanks! Definitely not that way from the factory, and very well could have been from me at some point in all my rework. The fact that it was under a TI socket though gives me a bit of pause. Maybe from a previous owner? Either way, problem solved! Oooh, interesting idea. I did check the oscillator frequency at the chip and its bang on though, so it might be a little deeper in the analog stuff.

Oh, and this was the cause of the failure! No clue how that piece of solder got there, it's up under the edge of an original TI socket in an area where I didn't do any rework, so could have been from me or could have been previous owner stuff. Either way, it's free and clear and alls good now!

Awesome, thanks! Ah, that makes sense! I was getting confused on order of things occurring here, but I'm following now! You get all the credit my man! Seriously, I don't think this thing would have come back to life without your help! That did the trick, keyboard works perfectly now, and isn't quite as terrible to use as before. It's a bit like typing on a teletype, but I think with some practice and retraining of the brain, you could get fairly quick at it. I manged to get it a little better, but there's still a ridiculous amount of noise/interference, and it makes it straining to look at, so something is definitely funky in the video circuitry, but that's a problem for future me.

Well, that's promising! Measuring the resistance between address pins came up with this: A6 to A7 -> 8M ohms A7 to A8 -> 22M ohms A6 to A8 -> 44 ohms A6 to A8 at 44 ohms is way too low, and would account for our cross talk on those lines. So I started tracing them out, and just under the edge of one of the original TI sockets for the console ROMs (an area I have done no rework on or around), there was a piece of solder jammed in there, creating a short between two vias. And those two vias went to A6 and A8. Break the solder bridge away, and boom, successful boot! Insane, but I absolutely would not have been able to find it without the help of the disassembly telling me what was misbehaving. Now, it's not all good news. It looks like hot garbage. I have to put the TV into Hi-Impedance mode instead of 75ohm, and I have to crank the brightness, contrast and the potentiometer on the motherboard to max to get a picture that is dim. There's also what looks like a massive amount of interference in the picture, I'm not sure where that's coming from. Could be some questionable passives in the video circuit, or something else entirely maybe? Also, the keyboard is a pile of trash. There's so much bounce on each keypress, I sometimes get six characters for one press. I need to figure out how to pop the keycaps off so I can clean the actual keyswitch inside or something. Like, it's real bad. Took me 2 minutes to type "PRINT "HELLORLD!". But, bad picture or not that is a functioning system! Thank you guys so much for your help in getting to this point! Cheers, David

I'm not necessarily a smart man, but I'm stubborn as hell, we'll get there!

Yeah, that was filmed when we were still about halfway down page 1 of this thread, haha. I'm not a huge fan of how that episode came together, it seems like I'm flailing about and just replacing things without thinking about the why, but there was actual logic behind the choices I made. Notably, it takes about an hour to sit down with a logic analyzer and determine if an IC is working correctly in circuit. It takes about 20 minutes to desolder, socket and replace that same IC, so from a time management perspective, if an IC was even remotely suspect, it was faster to just rip it out and replace it. Knowing what we know now about the disassembly, I think we're finally starting to hone in a bit on where a potential fault might be though, so hopefully the next episode comes together a lot better! So, I did actually check for a short between A8 and A6 (0080 and 0200... I think... I hope) and it didn't show up on the multimeter beep out, but maybe there is enough resistance to not kick off the beep test. I believe 0080, 0100 and 0200 would be A6, A7 and A8, so I'll go check all three of those at each SRAM, ROM and the CPU for low resistance or shorts. If nothing shows up there, I wonder if it could be the LS367 at the end of the line (U509). It had an internal short that only crops up when powered on, it could be causing interesting failures as well. Hopefully, some time spent with the multimeter today will help us narrow it down a bit! Cheers, David

Okay, so, found the problem with >0080, I had a bent pin on one of the SRAM chips. Easy fix, but did not fix the boot issue, just made it... different. Here's the new data, there are a few minor changes throughout that I'm still trying to understand. Lines with different data are noted by a "**". 0000 83E0 - Reset - read Workspace pointer 83FE 0000 - SRAM access, save status register (not sure if the data is valid) 83FC F57A - SRAM access, save program counter 83FA 74EE - SRAM access, save workspace pointer 0002 0012 - Reset vector, fetch program counter 0012 020D - LI R13,>9800, save address of GROM port 0014 9800 - fetch immediate data 9800 (seem to be missing the write to SRAM) 0016 0200 - LI R0,>0020, save starting GPL address 0018 0020 - fetch immediate data, should be 0020 (transcription error, screenshot shows it is correct) 001A 100C - JMP >0034 (0C is the offset in words) 0034 D11D - MOVB *R13,R4, dummy GROM read to reset address flip flop 83FA 9800 - SRAM read from R13 to get GROM port (9800) ** 9800 0000 - GROM read - (In this instance the random value was 0000) 83E8 08F4 - SRAM access to R4 (there should be both a read and a write - are we filtering writes? Maybe MEMEN didn't toggle.) 0036 C180 - MOV R0,R6, prepare to work on GPL address 83E0 0020 - SRAM read of R0, got 0020 83EC 08F0 - SRAM read of R6, again, we are missing the write 0038 1013 - JMP >0060 0060 DB46 - movb r6,@>0402(R13) - write the first byte of the address to the GROM 83EC 0020 - read R6, we get 0020 as expected 83FA 9800 - read R13, we get 9800 as expected 0062 0402 - read immedate data, we get 0402 as expected 9C02 0000 - probably read-before-write to 9C02 for grom address, but that shows the previous worked 0064 DB60 - movb @>83ed,@>0402(r13) - write the second byte from the assumed address of the R6 LSB 0066 83ED - read immediate data 83ED 83EC 0020 - read the value from 83EC (because we can't read 83ED as a byte address) 83FA 9800 - read R13, get expected 9800 0068 0402 - read immediate 0402 9C02 0000 - RBW of 9C02 for grom address 006A 5820 - szcb @>0047,@>837C - clear a (or some) bits in 837C, used by GPL as a status register 006C 0047 - read immediate data 0047 0046 D120 - read word at 0046 (cause we can't read the byte address 0047) 006E 837C - read immediate address 837C ** 817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?) 0070 0300 - LIMI >0002 (enable interrupts) 0072 0002 - read immediate data 0002 0074 0300 - LIMI >0000 (disable interrupts) 0076 0000 - read immediate data 0000 0078 D25D - movb *r13,R9 - read a GPL instruction byte into R9 83FA 9800 - get address from R13 (9800) 9800 4000 - read byte from GROM - >40 - this matches my GROM - BR 83F2 00F0 - RBW on R9 007A 1105 - jlt >0086 - starting instruction decode. >40 is not less than 0, so no branch 007C D109 - movb r9,R4 - prepare to work on the instruction byte 83F2 40F0 - read from R9 - got expected >40 (lsb unimportant, but matches the RBW above) ** 83E8 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4) 007E 09C4 - srl r4,12 - isolate the top nibble 83E8 40F4 - read R4 83E8 0004 - rbw on R4 (or maybe the actual write? it's the correct value) ** From here on out, it's quite different, but still looks like RESET 0000 83E0 0002 0012 0012 020D 83FE 0000 0004 83C0 83E0 0020 83FE 0000 0006 0A4C 83F8 01F0 83F8 1F00 0008 83C0 83E0 0020 83FE 0000 000A 0A12 83E4 01F1 83E4 03E2 The lines that are different are: ** 9800 0000 - GROM read >> I think this one reads random data, and in this case, the data was randomly 0000. This is of no real consequence. 006E 837C - read immediate address 837C ** 817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?) >> This one is interesting. An immediate read of 837C is returning 817C? But, execution after this seems to chug along just fine, so maybe this one is alright? 83F2 40F0 - read from R9 - got expected >40 (lsb unimportant, but matches the RBW above) ** 83E8 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4) >> This one was originally 83E8 4AF4, which didn't raise any red flags on the previous disassembly, but now it's 00F4, which is quite different. A change from 4A to 00 is big and indicative of more than one line... Then we get into what looks like reset and it's all chaos from there. I'm not sure if this answers questions or creates more questions, haha. Cheers, David

Oh man, this is amazing, thank you so much Tursi! The 0080 and 0200 lines (or 0280) are surprisingly sparse, which should make checking them relatively easily. Looking at the schematic, it seems that they just got to the ROMs, SRAM and some LS367 driver chips for the I/O port. It could be something as simple as a broken connection between the CPU and the SRAM (but not the ROM), or maybe one of the LS367s has an internal failure and is affecting the chip in someway. Other than that, there's nothing else really on those lines, and honestly, a broken trace between the CPU and SRAM but not the ROM actually makes the most sense given how that all the other ICs have been replaced. Tomorrow morning, I'll film a new intro and a bit to get us up to this point, and then I'll do some diagnosis on the bus connections and hopefully we can get this thing up and going! @Tursi just to double check, would it be alright to show your disassembly and mention all the work and help you've done on the video? Cheers, David

Okay, resampling on the rising edge changes things a lot! To the point where it's hard to connect to the previous data sniff, almost like there's more instructions happening here or maybe we're catching more? As for access to 9800, I checked sampling on phi2, and it looks like it hits 9800 for around 27 clock cycles, which seems to be right on the money. So, our READY line getting held should be alright. ADDR DATA FE00 0000 - Junk 0000 83E0 - Reset? 83FE 0000 - SRAM access, setting up workspace registers? 83FC F57A - SRAM access, setting up workspace registers? 83FA 74EE - SRAM access, setting up workspace registers? 0002 0012 - Reset vector, fetch program counter (should get 0012) 0012 020D - LI R13,>9800, first instruction 0014 9800 - ? 0016 0200 - ? 0018 0200 - ? 001A 100C - ? 0034 D11D - ? 83FA 9800 - SRAM access to R0 9800 4A00 83E8 08F4 0036 C180 83E0 0020 83EC 08F0 0038 1013 0060 DB46 83EC 0020 83FA 9800 0062 0402 9C02 0000 0064 DB60 0066 83ED 83EC 0020 83FA 9800 0068 0402 9C02 0000 006A 5820 006C 0047 0046 D120 006E 837C 837C 21F0 0070 0300 0072 0002 0074 0300 0076 0000 0078 D25D 83FA 9800 9800 4000 83F2 00F0 007A 1105 007C D109 83F2 40F0 83E8 4AF4 007E 09C4 83E8 40F4 83E8 0004 0200 83E0 0202 0012 0012 020D 83FE 0000 0204 83C0 83E0 0020 03FE 0000 0206 0A4C 83F8 01F0 93F8 1F00 0208 83C0 83E0 0020 83FE 0000

It's data sniff time! I got the Logic Analyzer hooked up and managed to have enough clips for the full data bus and full address bus. A15 is still tied to GND and we're triggering on the falling edge of MEMEN, but it looks like it's making sense. Here's the transcribed data updated with your notes from the previous disassembly. ADDR DATA FFFE FFFF - Junk 0000 0000 - Reset 0000 0000 - Reset 83FE F73A - SRAM access, setting up workspace registers? 83FA F73A - SRAM access, setting up workspace registers? 83FA 34EE - SRAM access, setting up workspace registers? 0002 34EE - Reset vector, fetch program counter (should get 0012) 0012 34EE - LI R13,>9800, first instruction 83FA 34EE - SRAM access to R13 0016 9800 - LI R0,>0020, store GROM start address of 9800 into R0 83E0 9800 - SRAM access to R0 001A 0018 - jmp >0034, jump to 0034 0034 0018 - MOVB *R13,R4, dummy read from GROM to get to known state 83FA 0018 - SRAM access to R13 9800 0020 - Read data from GROM (dummy) 83E8 5000 - SRAM acces to store to R4 0036 50F4 - mov r0,r6, prepare to load GROM address 83E0 00F4 - SRAM access, read value of R0 83EC 0020 - SRAM access, store data in R6 0038 0026 - jmp >0060, jump to 0060 0060 0026 - movb r6,@>0402(R13), entry point to GPL interpreter 83EC 08F0 - SRAM access, read value of R6 83FA 08F0 - SRAM access, read value of R13 0062 9800 - ROM access, read immediate value (0402) 9C02 0020 - GROM access, write GROM address 0064 0000 - movb @>83ed,@0402(r13), get the LSB of R6 0066 0000 - ROM read symbolic address (83ED) 83EC 0000 - SRAM access, read requested data - R6 83FA 0000 - SRAM access, read value of R13 0068 9800 - ROM read immediate value (0402) 9C02 2000 - GROM write GROM address 006A 2000 - szcb @>0047,@>837C, clear a bit in memory for GPL status 006C 0000 - ROM read symbolic address (0047) 0046 0000 - ROM read requested data 006E 0000 - ROM read symbolic address (837C) 937C 20D1 - SRAM access, update the RAM 0070 01F0 - 0072 01F0 0074 01F0 0076 01F0 0078 01F0 83FA 01F0 D800 21F0 83F2 4000 007A 40F0 007C 40F0 83F2 00F0 83E8 40F0 It looks to me like everything is humming along smoothly right up to 0064 0000. The data bus seems to really go off the rails from that point on. So, maybe that's indicative that the GROMs aren't successfully asserting the data bus? Maybe the buffer is dead or perhaps the GROM enable pins aren't hitting at the right time? GROM enable looks like it comes from the DBIN pin of the CPU through U602, an inverter (probably an LS04). GRMCLK comes directly from the VDP which is a known good IC, but I haven't confirmed the traces between the two are good yet. I'm not quite sure I understand how Q500, the NPN transistor on the pull down resistor network next to the GROMs, is supposed to work. But I suppose it could be having an issue causing GROM data to look broken? If it is indeed a problem of the GROMs not asserting data to the data bus, there isn't that much in that area that can be wrong, so it might help really narrow down the fault. Cheers, David

Alright, back in the saddle again! FarmerPotato, I think you may be right in that something around the GROMs isn't quite right. I did check the VSS pin on the GROMs that is pulled to -0.7V by the diode, and they're actually right on -0.7V, so hopefully that's good to go. The 245 might also be another thing to look into. I actually tried the piggy back method on the 245, thinking that if it were weak, a piggybacked chip might jump start it enough, but no luck. Dan this is awesome work, thank you! I think once we get a bit more information on what the address and data bus is doing, we can start closely comparing to this boot process and find discrepancies. Oh yeah, the trick is finding that single logic gate! The old 99/4 here is giving us a proper run-around! She's doing immensely better today, even starting to put weight on the leg again. She'll be right as rain in a few weeks thankfully!

Hey all! Just a heads up, I got delayed a bit because our idiot of a cat stepped on a rattlesnake and got bit twice in the leg. Been a fun two days, but she's back home now and recovering! Planning on getting out tomorrow morning to grab a Logic Analyzer shot of the data bus and address bus. Thanks again for all the help y'all! Cheers, David

“It's not CRU. You haven't even touched CRU yet.” > Yeah, that's what I was thinking, and it doesn't appear to be wrecking the bus from catastrophic failure either, so I think we can safely eliminate that. “Reading from the data port guarantees to reset the address flipflop.” > Ah, that makes sense! “So software-wise -- assuming we aren't getting garbage on the data bus -- things are humming along nicely.” > I think the next step is definitely going to be for me to hunt down enough clips to sniff the address bus and the data bus simultaneously. Once I get caught up on video editing (or get sick of it), I’ll jog back out to the garage and give that a shot and see if that gives us a bit more insight. “It should be A0, A1 and A2 that come into the first LS138, but I'd start simpler and just look at the output bit. Should be pin 11 (Y4) for the >8xxx range.” > You’re right, I got my numbers mixed up, I’ve been staring at this thing too long, haha. I did probe the output pins of U505, the second LS138, and the 8xxx lines (14, 13, 12) never get hit. Which means either it’s a bad address coming in, or something never triggers the correct enables at the right timing. “So... if I understand - we have not really proven that the GROM circuits are working 100% - are we getting valid data back from the GROMs?” > I have two copies of 99/4 GROMs and I’ve tried both in the board and both react the same way. I also tried both in the working 4A, knowing they wouldn’t work, but hoping to see something different. And both get the machine as far as a cyan screen, so I’m guessing that up to that point the GROMs are indeed good. Now, we could still have a fault in some of the circuitry around the GROMs, or the GROMs themselves could be bad and the 4A was just able to push them a little further. “Assuming GROM is working, verifying SBE and the sound chip selection (pin 6 of the 9919 at U511) is the next step.” > I’ve actually confirmed this one, but not at the sound chip, rather at the LS138. Pin 6 of U511 is connected to pin 14 of U505 (the second LS138), and that pin never toggles. So, we aren’t getting that far. “But I'm really wondering about U506, knowing that NAND gates dying is not uncommon on other machines.” > I’m starting to get to the shotgun approach, lol. It’s actually faster for me to just desolder and socket an IC than it is to try and diagnose whether that IC is good, marginal or bad. (I can desolder, socket and replace an IC in about 20 minutes). So, I replaced U506 and U508 for good measure, but no change. And speaking of the shotgun approach, we’re rapidly getting to a point where there aren’t any ICs involved in the boot process I haven’t swapped or replaced. I attached some pictures of the schematics with the ICs I’ve swapped highlighted on it. U607 and U613 are involved in the generation of A15, which is toggling, but maybe not quite right? U603, U606 and U612 are all NAND gates and could potentially have gone awry. U614, U615 and U616 are the 16-bit to 8-bit conversion ICs, but that really feels like the wrong place to look since all the boot process is pure 16-bit life. And… that’s about it? Except for passives maybe. We could have a bad decoupling cap somewhere that’s causing a chip to be unstable, but that seems like it’d be even harder to track down. I’ll jog back out and get a shot of the address bus and data bus (if I can find enough clips), and maybe that’ll give us a bit of insight into what the data bus is doing, or maybe it’ll highlight a chip that’s misbehaving which might point us in the right direction for hunting down a bad passive. I feel like we’re so, so close to a working system! Thanks again! Cheers, David

Thank you so much again for all the disassembly! Ok, let me see if I can follow along with what's happening here: Hit reset vector Setup working registers in SRAM Get GROM base address and start address Dummy read from GROM (why do a dummy read?) Jump to entry point of GPL interpreter Do some other magic stuff to finish loading GPL interpreter Once the GPL interpreter is loaded, we can start reading from the GROMs and executing the instructions in them. And the first instructions that get run out of the GROM are: Clear sound bytes Load speech write Set sound generators (which would shut the chip up) But, since the chip isn't shutting up and it's making a wonderful screech noise, we're losing the plot somewhere before the "set sound generators" instructions. I've actually confirmed this by checking A3, A4 and A5 as well as the chip enables coming into the LS138 that decodes that into 8400 for writing to those sound generators on the sound chip. The address never hits, and it never gets written. But, if we've successfully loaded the GPL interpreter and are into the GROM, there's not a whole lot that could go wrong. "Clear sound bytes" is writing to the SRAM, which we know is working (partially because we made it this far and partially because I've confirmed the SRAM chips are good in a working 4A) "Load speech write" is... I don't actually know what this is? Is it related to the CRU? I ask because it's at an address that the CRU could respond to I believe (based on what the address pins the CRU has as inputs) If it is CRU related, could a bad CRU be causing our downfall here? It's the one chip I haven't touched yet on the machine, and it would be a hilariously twisted fate if the last big chip that I decided to skip is the one that's borked. Having said that, I'm not entirely sure it is CRU related because the CRU seems to primarily look at the keyboard and cassette port. Speech seems to be a 9919 sound chip thing? And if the sound chip is bad, shouldn't removing it alleviate the problem and allow the system to boot? (Which I've tried to no avail.) If it is looking like the CRU could be responsible, I'll desolder that bad boy and replace it with a salved piece from a 4A in a heartbeat though! Thanks again for all the help! Cheers, David

Okay, sounds like we're frighteningly close to a booting system! Thanks for the links and the help! I made some changes like you suggested and grabbed another Logic Analyzer shot. A15 is now just connected to ground, so will always be 0. The Logic Analyzer is using the falling edge of MEMEN as the clock for latching in the address. I attached a photo, but here's the first few addresses I got. (I think the FFFE, 0000, 0000 is just some junk it caught. The second time I ran it I got the exact same collection of addresses only without those three at the beginning, but I kept them listed just in case.) FFFE 0000 0000 83FE 83FA 83FA 0002 0012 83FA 0016 83E0 001A 0034 83FA 9800 83E8 0036 83E0 83EC 0038 0060 83EC 83FA 0062 9C02 0064 0066 83EC 83FA 0068 9C02 006A 006C 0046 006E 837C 0070 0072 0076 0079 83FA DE00 83F2 007A 007C 83F2 83E8 83E8 0200 0202 0012 83FE 0204 83E0 03FE 0206 03F8 83F8 0208 83E0 83FE 020A 83E4 83E4 020C 83F4 We see the 9800 again of it trying to get to the GROMs. Then we see a bunch of 83xx, notably 83FA, but these should be something in the SRAM, right? There's a couple of 83Ex hits as well, which should specifically be the CPU registers in the SRAM, right? I do find it interesting that we can see a clear count up from 0002, 0012, 0016, 001A ~ 0206, 208, 020A, 020C. I feel like the problem is there in that code somewhere, I'm just not quite smart enough to find it yet. I got a lot of reading and absorbing of information to do! Thank you again for all the help! Cheers, David

This is awesome information, thank you so much! I hooked the Logic Analyzer up this morning (just to the Address bus for the moment) and tried to get a shot at startup. I had to add in some qualifiers for single shot because it only stores 1024 traces and it was getting all 0000 during reset. Also, it was seeing some minor activity for like 5 clock cycles before seeing 0000 again for more than 1000 clock cycles. So, in these shots, it ignores any address that is 0000. But, the Addresses just don't make any sense to me. It's entirely possible that I've got something setup wrong on the LA (A15 as the LSB and A0 as the MSB, 0V is 0, 5V is 1), but it seems like the adresses bus doesn't really share anything with what we should be seeing? To avoid posting 1,000 pictures (since I don't have a HPIB interface) here's the first few address changes: FEFF 0001 83FF 93FD 83FB 0003 0013 0015 83FB 0017 0019 83E1 001B 0035 83FB 9801 9800 9801 83E9 0037 83E1 83ED 0039 I can kind of see some logic in there with the 0001, 0003, 0013, 0015, 0017, 0019 count up showing up intermittently. And 9800 showed up for a *lot* of clock cycles. So that might be the machine trying to store it into scratchpad RAM? I didn't get the data bus in on this one just yet because I have to go scrounging for enough clips. But, if it's looking like the address bus is making some sort of sense and we can maybe figuring out where we're losing the plot, I'll go on a treasure hunt to see if I can find enough clips to get the full 16-bit data bus as well. Cheers, David

Thanks for all the ideas all! Okay, a bit of an update. I have a good working 4A, so in an effort to end up with no good working machines, I took it apart and socketed the CPU and one of the SRAMs on it so I could test chips. Thankfully, I didn't bork it and I was able to test some chips. For the 4A, here's the current status. Confirmed good: CPU, VDP, SRAMs, DRAMs Should be good, but not sure how to test: GROM, SOUND, ROMs I tested GROM 1 in the 4A, and of course it didn't boot, but it did initialize the VDP and get to a blue screen, which is further along than the same GROM in the 4 gets, so I'm fairly certain the GROM is alright. I have three different copies of 99/4 ROMs, two are pulls from original 4 motherboards (ROMs are socketed on the 4, so easy to pull), and one is a 28C64 on an adapter. Between the three copies, I would have expected one to work, but perhaps that's not the case? I suppose I could have two bad original ROMs and my adapter isn't correct, but triple failures is... uncommon. That leaves just the CRU or some other logic fault. I checked the inputs to the LS138 that should be selecting VDP CSR and CSW, and the correct combination of 3-bit address and chip select pins just never happens, but none of the pins are stuck. I don't think a bad CRU can prevent a boot unless it shorts one of the A10 to A14 address pins to high or low, but those addresses aren't stuck as confirmed by the logic analyzer. Which would leave either a logic selection fault or a bad trace on the motherboard somewhere. It was a literal barn find, so that's not completely out of the question, but I'm not sure how to start hunting for that. I keep thinking tracing the VDP CSR and CSW backwards is a good idea, but that just dead ends me in the LS138 combo, which has activity coming into it, but the activity doesn't make sense. The activity coming into the LS138 combo is from A0 ~ A5, A15, MEMIN, and DBIN. All except A15 come from the CPU which is tested good. A15 comes from... somewhere, the schematic isn't super clear on this one. Perhaps it has a typo or something because it looks like it comes from a junction of inputs, which can't be correct. I may throw in the towel on this one for a bit and let the subconscious chew on it. I've been burning the candle at both ends trying to get this one solved and it's just whipping my butt, haha. Cheers, David

This is the one I've been following actually. I keep ending up at a dead end with the manual telling me to replace the LS138, but replacing it didn't change anything. I'll keep plugging away at it!

Thanks for the links! I hadn't seen John Guion's guide before, I'll start with, maybe I'll have a bit better luck with that troubleshooting procedure!

Hi All, I've been working on a TI-99/4 and it's giving me the proper run-around (picture attached of system in question). It's a dead system, black screen and sound chip screaming. In my initial round of testing, I found two bad transistors in the video circuit (weird, but they definitely weren't amplifying) and a bad DRAM (all have now been replaced with 4164s modified). There is effectively no change in the failure mode. There is data on the data bus, addresses on the address bus, none of the data or address lines look to be stuck low or high, all four clocks look good, voltages are not perfect but close (4.9V, -5.2V, 11.4V). I have a spare 99/4 parts donor (it's a rusty nightmare, so no guarantee the parts are good) and a spare 99/4A parts donor (it was also a non-booting machine though), so I've been swapping chips from those machines to test stuff out. So far, I've confirmed the following: - Swapped CPU for two different CPUs, all three behave the same (all three came from non-working systems though...) - DRAM is good, though I think the failure happens before we even get that far (VDP never receives CSW or CSR) - Swapped VDP for three different ones, all four behave the same (generates a video signal, but there's not data in it) - Swapped console ROMs (both) for two different ones, all three pairs behave the same (one pair is from parts donor, the other pair are 28C64s in adapters) - Swapped the GROMs (all) for the spare ones from the parts donor, same behavior - Replaced the 74LS138s on the right edge of the board, no change (this was at the behest of the manual) I'm starting to run low on things it could be. I've tried to follow the TI-99 new technician manual troubleshooting procedure, but it's not getting me there. I'm down to thinking it's either the SRAM chips or the the 16-bit to 8-bit conversion chips (LS245, LS373, LS244). I would kind of expect one line to be stuck high or low if it were the SRAM chips, though I suppose they could fail high impedance? Also thinking that maybe the board is just really picky on voltages? The 4.9V is well within spec, but the 11.4V is right on the bitter edge for the TMS9900. It could still be CPU as well, all three of the CPUs I have tried came out of non-working systems, but I feel like they shouldn't all fail in the exact same way. It could also still be the GROMs, but I'm not sure how to test those in such a way that it rules them out. Of interesting note, if there's a cartridge in the slot, it stays in reset for about a full second longer than if there isn't one. Not sure if that's indicative of anything. If y'all have any other ideas, I'm all ears!