• Please review our updated Terms and Rules here

Model I display problem - stumps even me! - help??

T

TRS-Ian

Veteran Member
Joined
Sep 10, 2011
Messages
1,036
Location
Melbourne, Australia
Trying to fix a "spelling errors" problem on a Model I, usually you just replace a bad 2102 ... or 2 or 3....

I have a system open on my workbench trying to get a consistent @9@9 display, but every 8 columns the characters differ. I'll post a picture tonight.

So far I have removed all 6 2102s, only the graphic one is left in place. I've tried a different character generator. I've changed Z28, a 74LS174, which connects to pin 12 of each of the 2102s.

This one has me confused. Any thoughts?

Ian.
 
TRS-Ian said:
Trying to fix a "spelling errors" problem on a Model I, usually you just replace a bad 2102 ... or 2 or 3....

I have a system open on my workbench trying to get a consistent @9@9 display, but every 8 columns the characters differ. I'll post a picture tonight.

So far I have removed all 6 2102s, only the graphic one is left in place. I've tried a different character generator. I've changed Z28, a 74LS174, which connects to pin 12 of each of the 2102s.

This one has me confused. Any thoughts?

Ian.
Click to expand...

Ian,
Remote troubleshooting is a challenge even IF you know what you are doing.... So here goes...

Not sure what you have available... But here is what I would do.
Find out which side of the horse we have the issue with...

Step 1 - Is it Video Memory?
I would start by poking in to the Video memory area 3C00H to 3FFFH ASCII displayable values and read them back to verify the memory is intact. Say 30-95 or 20H-5FH to see if we have bits that are changed. ( higher if we have the lower case mod ), But you said '9@9' changes if I understand correctly so this range should surface.

Step 2 - Memory OK - Must be Video Chain not reading memory correctly OR missing bits during the read OR Address wrong memory location during the read.
If the Memory is unchanged then we are looking at possible address decoding error during the Video chain divider Ram Access Mux Z64,Z49,Z31. But we need to know what Bits are missing or Held high to force the "spelling errors".

While I don't remember very well now some 30 years later, I got into a pickle with my LNW80's during a speed up mods I was doing resulting in video displaying wrong chars in certain rows. That had to do with late wait signals not allowing the data to settle long enough so the chain divider could catch the correct bits. Your post made me go and look up my mods and review the issues..... While not the same exact issue ... but in the ball park somewhere!!! :lol:

Good Luck...
 
Ok so a known good set of 4116 rams are fitted and the system runs normally. A tape based memory test program (H&E computronics MEM/CMD) loads and runs with no error.

Currently all 6 2012s have been desoldered and are not installed. Roms are removed as well.

What should be on the screen should be all the same character or alternating characters, but I currently get 8 columns alternating.

something like: ////////????????////////????????////////????????////////????????

Anyway, I'll have a look at Z64, 49 and 31 tonight

Cheers,

Ian.
 
TRS-Ian,
Since you have a repeat at every 8 Columns, Check Address Line A3 (2 ^ 3 = 8). You can also check the Tri-State Buffer for A3 (Z22 for proper operation.)

It could also be a bad data line. The most common cause of a stuck data line is a bad memory chip, the inputs of which are tied directly to the data lines.
Removing all memory chips, and checking the pattern will identify whether the problem is RAM or some other chip.

Larry
 
TRS-Ian said:
Ok so a known good set of 4116 rams are fitted and the system runs normally. A tape based memory test program (H&E computronics MEM/CMD) loads and runs with no error.

Currently all 6 2012s have been desoldered and are not installed. Roms are removed as well.

What should be on the screen should be all the same character or alternating characters, but I currently get 8 columns alternating.

something like: ////////????????////////????????////////????????////////????????

Anyway, I'll have a look at Z64, 49 and 31 tonight

Cheers,

Ian.
Click to expand...


Ian,
With no Video Memory the pattern could be anything and may even look like that, but most likely the screen should be filled with random changing characters I would think. It's what ever the data lines floated to when the Video display logic Selected the missing memory.
I would put the Video memory back in and roms, run the memory test on the video rams.
Again, if it passes then look down stream. If it fails then look for the bad bits. Could have a stuck data line or bad buffer...

Just my 2 Cents.
 
Last edited:
TRS-Ian,
It appears you have two different problems.

In the first row you have repeating characters of @) & P9 in groups of 8.
For the @):
@ = 40H 0100 0000 ) = 29H 0010 1001 but you are really needing:
@ = 40H 0100 0000 9 = 39H 0011 1001 so Bit 4 is the problem bit (Stuck LOW) in this group.

For the P9:
P = 50H 0101 0000 9 = 39H 0011 1001 but you are really needing:
@ = 40H 0100 0000 9 = 39H 0011 1001 so Bit 4 is the problem bit (Stuck High) in this group



Then, there are 608 characters repeating, until the display changes. The 608 breaks down to one "512" + one "64" + one "32"
which are actually address lines Bit 5, Bit 6, and Bit 9. So, I'd check the Address Lines A5, A6, & A9.

Probably the easiest way to check all the Address lines is to make a NOP Generator from a Z80 CPU. Take a known good
Z80 CPU, bend out all the Pins for D0 thru D7 and strap them to the NOP Instruction (00) (Z80 Pins 7, 8, 9, 10, 12, 13, 14, 15
to GND). This will allow you to insert the Z80 back into the socket (with no connected Data LInes) and verify all the address
lines over the complete motherboard. You can check all the Buffers, and anything connected to the Address lines to see that
no Address line is stuck LOW or HIGH. That will just leave the Data lines for your testing with an ICE (In Circuit Emulator)


Larry
 
Last edited:
TRS-Ian,
Don't forget that the Keyboard is also connected across the A0 - A7 & D0 - D7 Matrix along with the associated tri-state IC's
Z1 & Z2 (74LS05) for A0 - A7 and buffers Z23 & Z24 (74LS368) for D0 - D7.

When you power up the computer and tap enter a couple of times does it respond correctly to ?MEM

Larry
Larry
 
TRS-Ian,
I stumbled across this posting by Tim Mann:

https://groups.google.com/forum/#!search/logic$20pulser/comp.sys.tandy/94drnxXXq8g/I3YFE0r1TYIJ


> I've just remembered, one of the tests in the techref is to pull the
> ROMs and see what happens - you should get a screenful of @9s that
> flicker as the CPU tries to access the ROMs....that's exactly what I
> get so the CPU MUST be running at that point.

It helps to know that. Here's why you get @9s. With the ROMs removed,
the CPU reads all 1's (that is, hex FFH) whenever it reads from the area
the ROMs are supposed to be in, because an open connection tends to
float to a 1 with this type of logic. Hex FFH is the RST 38H
instruction. So when the processor is turned on and fetches an
instruction from 0000, it gets a RST 38H (FFH). This makes it push 0001 on
the stack and jump to address 0038. At that address it reads another
FFH, so it pushes 0039 on the stack and jumps to 0038 again. Now it's in
an infinite loop. As the loop continues, the stack grows and grows,
going backward through memory. When it reaches the frame buffer between
3C00 and 3FFF, you can see it on the screen. It looks like a string of
@9's because the TRS-80 displays a 00 byte as an @ character, and 39 is
an ASCII 9.

OK. So the fact that you get @9's means that the CPU is working. The
data bus appears to be working correctly too, as if a data line were
stuck at 0 the CPU wouldn't be reading FF's, and if it were stuck at 1
the CPU couldn't be writing both @'s and 9's.

There could still be a problem with the address bus or the ROMs. Note
that a problem with the ROMs might not be in the ROM chips themselves
but in the sockets or circuits on the motherboard that connect them to
the rest of the system. But trying a different set of ROMs does seem
like a good idea.

This test of removing just the ROMS, would also point to some stuck Data Lines
that would give you the something different from the @9 characters.

I'm curious if you have made any progress.

Larry
 
Last edited:
You must log in or register to reply here.
Back
Top