Geoff Oltmans

Neoprogrammer. Looks like I'm going to have to hook up an external oscillator up to the avr to recover it.

Well, I managed to brick mine even worse with the programmer. I think I accidentally set the debugwire fuse bit. I'm borrowing our AVR JTAG ICE from work to reset it.

I followed the directions in one of the prions posts: do the update.pld and then subsequently the update.avr files in the root of the SD card. The pld image seemed to work fine, but not the avr update. I’ve got the programmer now, so I’ll try that next.

I am now a member of the bricked FG99 club. lol Just placed an order for a programmer so I can unbrick it again. I tried a variety of different SD cards, the PLD updated fine, but the .avr was no bueno. Quick flashing LED, mostly on while trying to update the .avr.

Thanks... I measured these yesterday and it appears that Vbe swings from 0-0.7ishV which should be okay, Collector is 0 and clamped to approx 5V. It is a bit messy looking though, not very square, about 200ns.

It’s definitely a non-QI board

Looking at the schematic, I'm kinda wondering if, like the Vss thing mentioned already, if the problem could be related to the circuitry connected to the resistor network connected to the data bus outputs of the GROMs and GROM port. I don't know what the AC characteristics are of these GROMs. (is there a datasheet for the GROMs?) GROMs must have some sort of open drain drivers in them I guess. I haven't poked around there yet.

Yeah I don’t see the address bus as a problem either since most of the accesses to from shouldn’t involve it at all. It feels like an electrical issue rather than a pure logic issue… too slow a state transitions between Voh/ol, but you might be onto something with the wait state generator. I suppose I could check for that with the scope.

Oh yeah, I've checked all the power supplies early on and even bench tested with an old PC supply instead of the TI one, no difference there either.

Just measured Vss at the GROMs in the console and by my multimeter it reads -0.705 so I think I'm good there. I replaced a few components in the console now too.... I replaced the two 74LS138s responsible for address decoding (U504 and U505) and the bus drivers at U614 and U615. I don't have 74LS244s at the moment so I can't replace that component at U616. I have reflowed the GROM sockets, the GROM port connector, I've tried a different VDP since I have a few of those on hand and it's socketed already. It seemed at first that removing the TI BASIC GROMs helped, but later test that didn't make any difference. So far replacing U504 fixed my PEB DSR access in the >4000-4fff range on the FDC. Before that I was getting garbage in that address space. Everything else hasn't really helped matters. To summarize, where I'm at currently: Standalone the console seems to work A-OK. Any loading on the expansion bus connector (PEB or Speech) will make a couple of games not work perfectly (Parsec and Alpiner). DSR access >5000-5fff no bueno on the FDC. Memory expansion in PEB tests out fine, so I think that eliminates address bus issues since >2000-4000 and >A000-FFFF should wiggle all the Address lines appropriately. Data bus likewise seems to work okay to the PEB Memory card as reads/writes are all okay. CRU write access to FDC appears to be okay, all signals from the latch outputs are good (card select, motor strobe, drive selects, etc). I haven't completely checked CRU read from this access space, but I did see that the DS1*Strobe input does read a '1' when the motor strobe is on, so I presume that should all be okay.

Thanks for the link to the Vss info... I was unaware of that. I'll have to check that out. Yeah, I've thoroughly cleaned both the console GROM port connector and the L connector and edge. I have also reflowed the solder joints to the GROM card edge on the console PCB. I haven't done my check on the PIO port of the RS232 interface card yet.

Nope, it’s a black and silver.

Update: The Speech Synthesizer was a bit of a red herring. There's definitely issues with this Alpiner game while it's plugged in. But, turns out that there's also a problem with the game when the PEB interface is plugged in as well!

Nevermind, just ran it in Classic99 and I think that's sufficient.

Does anyone have a video of what this test should look like on a good unit for the checkerboard test and the test with address test?

Not sure I'd use tantalums since they are not supposed to be good with ripple.

Well, maybe spoke too soon... maybe a loading issue on the data bus instead. I came back after a couple hours and tried again and while things are better than they were, it's still a bit flakey.

A little update... since the Speech synthesizer seemed involved in the Alpiner issue, seemed to work okay with no Speech module I replaced the other 74LS138 that is responsible for GROM and Speech synth memory address decoding. No dice there. I noticed that Parsec mostly worked except for the blocking around the in game text. Looking at the size of those carts, I noticed that Parsec uses 24K of GROM where Alpiner uses 32K. Seemed like a good hint. So, thinking I had a similar problem to the DSR ROM access getting clobbered on the GROM bus I tried pulling GROM 1 and GROM 2 out of the sockets, and voila, Alpiner works flawlessly. The pins were a bit tarnished so I pulled them all out and gave them a cleaning. Now, Alpiner "mostly" works... a little flakey at times. So, I'm tempted to replace the GROM DIP sockets on the motherboard since it's kinda hard to clean tarnish out of those. But, I think that may be my smoking gun.

For the >5000 access, I'm tempted to use the PIO port on the RS232 card to see if I have a general problem with this address space or if it's unique to the disk controller. I should be able to write known data to the parallel port and check that I can at least write to 5000. I guess that doesn't necessarily help me for reads though.

So, I replaced U504, and that seems to have fixed access to the DSR memory space from >4000-4FFF while using the FinalGROM99. Peeking memory on the disk controller in the >5000-5FFF range is returning nothing but 0's. This is kinda the result I was expecting to see when I first got the FinalGROM cart but didn't have a way to prove it 'til now. So, on to figuring out why the upper bank of ROM doesn't show up... Back to using my Alpiner test... things are no better or worse than before changing out U504. I guess this is still some progress though!

I think U504's output is only used for sidecar expansions when decoding for >4000-5ffff... because if you look at the flex cable interface, it doesn't go anywhere there. But it is certainly possible that it is letting the GROM port onto the bus, yeah. I've got some spares of those so I may shotgun that.

Disk controller.

I thought that might be the case but it doesn’t appear that it is used with the PEB. i get similar results to the disk controller with the rs232 card in the dsr area.

lol, well i dunno what this video cable was for, but clearly it is not for the TI. Video is on the correct pins, but the cable audio ground is on the audio pin and then the audio signal is on pin 5. This cable came with the TI setup I acquired so I assumed all was kosher with it. I guess it makes sense why the audio had to be turned way up to hear anything. Anyways, I fashioned up a correct cable and now my video isn't flakey anymore. So there's at least one little victory, heh. Still having issues with Alpiner with the Speech synth attached. I've also noticed that there are some issues with Parsec with the speech synth attached... the text around the in-game messages "Alien craft advancing..." etc show a blocked out background at the bottom of the text, rather than the ground being flat all the way across the screen underneath the text if that makes sense. Sometimes it does, sometimes it doesn't. Back to the DSR... I have probed on the DSR memory addresses and it seems like something (FinalGROM?) is loading the bus in the >4000-5fff memory range. I get different results there using mini memory via FinalGROM if the disk controller is manually enabled vs not. For instance, at >4000 I get 'AA' regardless (makes some sense since if two different DSRs are driving the bus they would have the same contents in this address), but everything past that up until >4010 is all zeroed out. Once I get to >4010, I get 40 12 42 08 ... with the controller enabled, and without I get 60 5a 62 ca ... Hmm..

True. I’ll check and see.