Jump to content
IGNORED

Noisy video problem, plus...


Recommended Posts

Hey guys... I've been working to repair my TI setup... mainly I was focused on getting the disk controller to work. I was thinking that the issue was with the disk controller itself, but now I've turned my attention to the console itself. I've experienced a number of strange behaviors, and just recently as of yesterday received a FinalGROM99 to aid in debugging.

 

Before receiving the cart, I was kinda focused on the disk controller like I said.... When attempting to do any disk access the system hangs. Before I had the cartridge I was testing this with TI BASIC, Disk Manager 2, and Personal Report Generator, just to see if I could attempt to read/write to the disk. The disk drive activity LED wouldn't light and motor wouldn't spin but apparently enough of the DSR could be accessed so that the system knew about the DSKx devices, and the disk controller activity LED would light when attempting to access. Using the Final GROM cart with Mini Memory, I started probing around the CRU write addresses to see if I could manually get the drive activity light and motor to turn on, and I can with it...however the CRU addresses I'm using seem like they are off (but that could be a result of my unfamiliarity with the 9900). I would expect that writing a '1' to address >1101 would turn on the motor, but instead a write to >1102 does. I'm testing using an oscilloscope. Basically everything works on subsequent even numbered addresses:

 

>1100 - Activity LED/card select

>1101 - nada

>1102 - KACLK - Motor ON strobe

>1103 - nada

>1104 - HLT

>1105 - zilch

>1106 - DSEL1

>1107 - you guessed it

>1108 - DSEL2

>1109 - ""

>110A - DSEL3

>110B - SIDSEL

 

These clearly wiggle with writing '1's and '0's, so the latch at U23 is good and doing it's job. I'm a little confused why the addressing is working out like this based on a read of the schematic. I would think that these should all have no gaps from 1100-1107. But, I know CRU addresses are effectively shifted by 1 on the address bus, so maybe this is how things work in the Mini Memory program? Dunno. Likewise if the DSEL1 and KACLK are both set, the disk activity light comes on and the motor comes on, so that circuitry works too. Before getting the Final GROM, I suspected that ROM access to the second ROM wasn't working, since the system would read the DSR linked list seemingly correctly, but hang on access (some of those routines are in the upper bank), just a working theory. But... with the FinalGROM inserted, the DSR access is completely jacked up. The system doesn't know anything about the controller, and inspecting memory in the DSR space from >4000->5FFF shows a bunch of garbage in it. So, the DSR linked list at the beginning isn't read right, TI BASIC et al doesn't know about DSK, and errors out without trying, no disk controller activity LED at all when attempting 'OLD DSK1.TEST" for example. The disk activity light at powerup doesn't flash nearly as long as it does with the Final GROM removed from the system.

 

Tests to my expansion RAM in the PEB all seems to work fine with a diagnostic program (the CorComp one) and random reads/writes in the expansion memory spaces via Mini Memory. (above tests were performed without the RAM expansion or anything else in the PEB except the Disk Controller), so I think the flex cable interface is good. I also checked power supplies in the PEB and they are good.

 

Now, onto the console itself.. With just the console and no PEB, I have noticed that video is a little flakey, but not flakey from the standpoint of bad ram. IF the display is really white (as in starting out a game of Hunt the Wumpus), the screen gets a bit squirrely and noisy... like the video amplifiers power supplies are noisy or sagging. Alpiner will play with no speech synthesizer, when music is playing some of the sound must be bleeding into the video as the video gets a bunch of wavy lines in it while sound is playing. The game won't play with the speech synthesizer installed past the game selection screen. As soon as the climber appears, it craps out. An actual Parsec cartridge will play with speech.

So, That lead me to inspect the power rails on the console. I think those are good... a little bit of periodic noise 50mV p-p. So now I'm leaning toward caps on the main board. 

 

Any one experience issues like this?

 

 

Edited by Geoff Oltmans
Link to comment
Share on other sites

14 hours ago, Geoff Oltmans said:

I would expect that writing a '1' to address >1101 would turn on the motor, but instead a write to >1102 does. I'm testing using an oscilloscope. Basically everything works on subsequent even numbered addresses:

The disk controller responding only to even-numbered CRU writes is normal behavior. As for why DSR access breaks with the FinalGROM, I'm not sure.

 

While it's possible that the electrolytic caps in the video amp went bad, chances are they're not the issue at play here. Couldn't hurt to change them, but the caps on the motherboard have proven to be rock-solid compared to many other devices of the time, and you'd be hard-pressed to find reports of them failing.

 

The audio coupling into the video signal almost sounds like a grounding issue. Happen to be able to take a photo of the inside of the DIN plug on the video cable?

 

 

Link to comment
Share on other sites

2 hours ago, AwkwardPotato said:

The audio coupling into the video signal almost sounds like a grounding issue. Happen to be able to take a photo of the inside of the DIN plug on the video cable?

Yeah, if pin 6 isn't connected well, the video may end up using the audio as a virtual ground.  That would cause signal issues.

Link to comment
Share on other sites

The TI system does not have odd CRU addresses; this is an architectural feature. However, bits are numbered in 1-steps. So the rule is

 

CRUAddress = CRUBase + 2*bitnumber

 

The reason is that the CPU cannot set odd addresses at all; there is no 2^0 address line (A15). It is, remember, a pure 16-bit architecture. The A15 line is actually created on the main board by the databus multiplexer.

Link to comment
Share on other sites

10 hours ago, ChildOfCv said:

Yeah, if pin 6 isn't connected well, the video may end up using the audio as a virtual ground.  That would cause signal issues.

I’ll have to check continuity on the pins, but this cable has a molded on end.

 

i do have the issue too remember where Alpiner doesn’t work with a speech synthesizer but does without. 

Link to comment
Share on other sites

9 hours ago, mizapf said:

The TI system does not have odd CRU addresses; this is an architectural feature. However, bits are numbered in 1-steps. So the rule is

 

CRUAddress = CRUBase + 2*bitnumber

 

The reason is that the CPU cannot set odd addresses at all; there is no 2^0 address line (A15). It is, remember, a pure 16-bit architecture. The A15 line is actually created on the main board by the databus multiplexer.

I suspected that might be the case. It seemed unlikely that it would be able to decode the base address correctly but then munge it up in such a way.

 

i presume that others are able to use the finalgrom with disk controllers…

Link to comment
Share on other sites

2 hours ago, Geoff Oltmans said:

I’ll have to check continuity on the pins, but this cable has a molded on end.

 

i do have the issue too remember where Alpiner doesn’t work with a speech synthesizer but does without. 

Molded cables are notorious for breaking the wire right at the connection to the pin :(

 

The other common problem is that the receptacle's connection to the PCB breaks after a bunch of plugging and unplugging.

Link to comment
Share on other sites

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..

Link to comment
Share on other sites

1 hour ago, Geoff Oltmans said:

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..

Sounds like the job of U504...

 

TI 994/A Console And Peripheral Expansion System Technical Data(link)

:ponder:

  • Like 1
Link to comment
Share on other sites

2 hours ago, Geoff Oltmans said:

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.

U504, pre-decodes the chip-select signal, that goes out from the I/O, port, on line 28, enabling the ROM, that is mapped into the >4000 - >5FFF, address range. U504, also pre-decodes the chip-select signal, that goes out to the GROM, port, on line 34, enabling the ROM, that is mapped into the >6000 - 7FFF, address-block, in cartridges. U504, also enables/disables the system ROM, at >0000 - >2000. Timing issues, or noise, applied to U504, might cause  the contents of these ROMS, or other device's signals, to inter-plex. While too much drain on U504's outputs, or too little drive on one of its inputs, might cause FAN-OUT issues.:ponder:

Edited by HOME AUTOMATION
  • Like 1
Link to comment
Share on other sites

5 hours ago, HOME AUTOMATION said:

U504, pre-decodes the chip-select signal, that goes out from the I/O, port, on line 28, enabling the ROM, that is mapped into the >4000 - >5FFF, address range. U504, also pre-decodes the chip-select signal, that goes out to the GROM, port, on line 34, enabling the ROM, that is mapped into the >6000 - 7FFF, address-block, in cartridges. U504, also enables/disables the system ROM, at >0000 - >2000. Timing issues, or noise, applied to U504, might cause  the contents of these ROMS, or other device's signals, to inter-plex. While too much drain on U504's outputs, or too little drive on one of its inputs, might cause FAN-OUT issues.:ponder:

 

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.

 

Edited by Geoff Oltmans
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, Geoff Oltmans said:

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.

Yes, an astute observation indeed.:-D

 

Have you heard the one about...

 

TMS9900 :: TMS9909 Floppy Disk Controller Preliminary Data Manual Dec82

 

...or are you using this...

 

TI Circuit Diagrams and Schematics.


Looks like U10(PAL), is doing the decoding.
I found U28(1771).:cool:

  • Like 1
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Edited by Geoff Oltmans
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...