Eagle II Hardware problem

[Ecaroh]

Leeb, I'm confused about which pin and chip you want me to measure voltage on. I have the pinouts for these and I can go to the right place. A5 on the VDAC, the socketed chip, is Pin 9 and it connects to Pin 15 on the SRAM, Data In/Out 6 (where the first one is #1, so yes, what you're counting as Data In/Out 5).

Just tell me again what to measure.


Re this: >> How many times can you overwrite before the input buffer fills and a new A:> comes up? <<

--the 128th character results in a new prompt. So you keep overwriting until then. The prompt itself, which I don't input, the A>, is included as two characters.

Same as what you said earlier.

On this: >> or perhaps a 244 for the A5 line is defective... IMO. <<

--you mean A5 on the VDAC?

thx,
Steve

 

[leeb]

Leeb, I'm confused about which pin and chip you want me to measure voltage on. I have the pinouts for these and I can go to the right place. A5 on the VDAC, the socketed chip, is Pin 9 and it connects to Pin 15 on the SRAM, Data In/Out 6 (where the first one is #1, so yes, what you're counting as Data In/Out 5).

That should not be true... ADDRESS line 5 should be going to pin 3 on the RAM. Please check continuity between V-9 and R-3... and NOT R-15.
Just tell me again what to measure.


Re this: >> How many times can you overwrite before the input buffer fills and a new A:> comes up? <<

--the 128th character results in a new prompt. So you keep overwriting until then. The prompt itself, which I don't input, the A>, is included as two characters.

Same as what you said earlier.

On this: >> or perhaps a 244 for the A5 line is defective... IMO. <<

--you mean A5 on the VDAC? Yes... check to see if it ever goes HIGH (or something close). IF SO, then check again at pin 3 of the RAM for the same value. While you're at it... take a good look at the traces between ALL the address lines... just 'because'.

thx,
Steve

Im sorry... Ive confused myself some without access to a schematic and popping datasheets up & down all the time...

How this is supposed to work is:
The lower address lines of the RAM (xxx 0000 0000) are connected to the 'row' address lines of the VDAC (A0-A7). The 3 remaining (A8-A10) on the RAM connect to the R0,R1 and R2 lines of the DAC as 'column' lines.
If starting at position zero in the screen,
The DAC addresses X0 Y0 as (000 0000 0000) to the RAM which give back the DATA for the character ('space' in this case) of (0010 0000). This value corresponds with the ADDRESS of the FIRST LINE of the CHARACTER BIT PATTERN in the character generator... in most every case this is (0000 0000), for spacing above/below each 'character'.

The BIT LINE 0 of the character is output to the screen as 8 bits... a '1' turning on that pixel. Once that line is done,
the DAC increments the CHARACTER ROW value (001 0000 0000) and that data is retrieved (in this case, the value does not change). This repeats until the CHARACTER ROW value reaches (111 0000 0000) at which time CRow resets and the column location is incremented (000 0000 0001).

This is supposed to continue until the ROW (X) count = (80 -1) or (1000 1111) AS DEFINED BY the value set in the INTERNAL DAC REGISTER at which time the COLUMN (Y) count is incremented and the X is reset to 0.

In the 'standard screen mode' this does not seem to happen, as we have noticed that the character location will loop back to the beginning until a CR/LF causes a change. For whatever reason it is NOT incrementing past 32 (0-31) to continue across the screen X locations. This could be caused by the DAC register not receiving the full 8-bit data that it should have (0100 1111 instead of 0001 1111), OR THE DAC REGISTER IS NOW DEFECTIVE and cannot ACCEPT the full 8-bit data.

It could also be caused by the area of memory that stores the initialization data being defective... CP/M would not necessarily notice this issue.

The WP program is a unique case as it APPEARS to do direct-2-memory access, although it is not confirmed... the pixel display is not restricted to the 1st 32 bytes of the 'screen page'.

I suggest finding a decent memory test program and allowing it to run on UPPER memory areas (above 32k). Im willing to bet you're going to find more bad memory.
:D

 

[Ecaroh]

Hi Leeb, Thank you. I will absorb this and look at the underside of the board for those traces, but meanwhile, as to the connections for A0-7 on the VDAC, I can confirm again that they all connect to Data In/Out pins on the SRAM; namely pins 9-11 and 13-17, i.e. DQ 1-8. And VDAC A5, which is Pin 9, connects to Pin 15 on the SRAM, and produces the same voltage -- usually 4.04 or so as mentioned. VDAC A5 does not connect to SRAM pin 3.

I'm posting a table with the VDAC address pin connections, and also the pinouts for both chips, for reference.

 

[leeb]

Okay... this sux...

It looks like the VTAC (not VDAC) is responsible for the chr/line and only 3 bits (0-7) select which qty of chars is on the screen...
000 = 20
001 = 32
101 - 80
(There are others, but I intentionally left them out.)

SO?
It looks like BIT 3 of the data INPUT to the VTAC REGISTER is not getting set, so it is using the 32 chr/line configuration in regard to cursor and video control.
As suspected before, the VDAC is happily churning away, outputting the character generator bits across the entire screen based upon the bytes it gets from the SRAM.
That is why the WP prg can fill the screen with characters... it is going directly to RAM to put them there. (or so I still think!)

Try reading voltage on DB2 (pin 23) of the VTAC during power-up and see if it EVER goes HIGH... If it does the problem MUST lie in the VTAC...

Yes, famous last words!

 

[Ecaroh]

Try reading voltage on DB2 (pin 23) of the VTAC during power-up and see if it EVER goes HIGH... If it does the problem MUST lie in the VTAC...

Yes, famous last words!

On power-up, Pin 23 of the VTAC hops up as high as 2.58 volts. With either Ultracalc or CP/M in the floppy drive, that pin settles at 2.42 volts on the first (and following) screens. With no disc, and the display reading Floppy disc not ready, press F to boot (etc.), then it settles at 1.66 volts.

I notice that Pin 16 of the VTAC is "Cursor video."

BTW, on the matter of the Address Inputs of the SRAM (A0-7), they all connect with output pins in a bank of four Data Selectors/Multiplexers SN74S157.

So what about those voltages on VTAC Pin 23? Is that "high"?

thx,
Steve

 

[Ecaroh]

PS - Question. The two SRAM chips secured as possible replacements for the one in question here, between VTAC and VDAC, arrived today. By now no one is optimistic that this part is the problem, but do you guys think I run any risks if I piggyback one of these onto the chip on the board? (I don't mind much if one of the new chips gets wrecked.)

many thanks,
Steve

 

[Chuck(G)]

You're probably not going to wreck anything by piggybacking.

The problem is with the voltage levels is that we don't know that those are DC levels; in fact, they're probably AC and your DMM is just integrating the signal to provide an average reading.

One of those inexpensive logic probes can go a long way toward pointing our problems, as it differentiates a static level from a pulse train.

 

[leeb]

On power-up, Pin 23 of the VTAC hops up as high as 2.58 volts. With either Ultracalc or CP/M in the floppy drive, that pin settles at 2.42 volts on the first (and following) screens. With no disc, and the display reading Floppy disc not ready, press F to boot (etc.), then it settles at 1.66 volts.

I notice that Pin 16 of the VTAC is "Cursor video."

BTW, on the matter of the Address Inputs of the SRAM (A0-7), they all connect with output pins in a bank of four Data Selectors/Multiplexers SN74S157.

So what about those voltages on VTAC Pin 23? Is that "high"?

thx,
Steve

As ChuckG said... we cant really tell because it does not last long enough.... it may be time to beg/borrow/steal an o-scope...

The data pin, on the other hand, had so many 'high points' that it was able to hold higher than this one.

 

[Ecaroh]

Thanks for those answers. Logic probe sounds like a good idea here. However, if the news turns out to be that the VTAC is faulty, that's going to be the end of the road. Forty pins. The VDAC, OTOH, can be cheaper and is in a socket. And then there are those various associated buffers and selectors.

Leeb, on this:

It looks like the VTAC (not VDAC) is responsible for the chr/line and only 3 bits (0-7) select which qty of chars is on the screen...
000 = 20
001 = 32
101 - 80
(There are others, but I intentionally left them out.)

SO?
It looks like BIT 3 of the data INPUT to the VTAC REGISTER is not getting set, so it is using the 32 chr/line configuration in regard to cursor and video control.

Yes! The cursor problem in WP is also the 32-character thing. When you reach character 33, the cursor hops back to the start of the line; while the display indicating which character in the line you have reached (28, 43, 67 or whatever) continues to be accurate as to where you've in fact directed the cursor. So that's interesting. It confirms that there is a single problem.

On the matter of Bit 3 of the data input to the VTAC, do you know which pin this would occur at?

thanks again,
Steve

 

[Ecaroh]

I wrote:

On the matter of Bit 3 of the data input to the VTAC, do you know which pin this would occur at?

OK, I found this section of the datasheet and I see that this is why you called out Pin 23, DB2, of the VTAC.

Steve.

 

[leeb]

Please DO NOT FORGET to consider failure of buffers and such when looking at the issue on that line. Perhaps that particular pin/bit does not adversely affect other registers.

Also... as far as replacement is concerned...
IF one can be found, it should be relatively easy to replace it by snipping pins until you get rid of the old one. It would be a MUCH EASIER effort to remove the cut pins one-by-one... and they could be replaced with a socket or socket-pins...

IF it comes down to that!
:D

 

[Ecaroh]

Thanks for the encouragement, Leeb. :D I would definitely snip the pins if removing that chip. Eyelets and traces on both sides of the board make it a little vulnerable, is all. Socket is a terrific idea.

But what about this: Pin 23 of the VTAC, in fact pins 21-25 (DB 0-4) all connect to the adjoining 40-pin NEC Floppy Disc Controller. DB pins on that chip. Check out the photo with Post 27. You can see the traces coming off of VTAC pins 21-25 and going up to the floppy controller. What do you figure that is all about?

thx,
Steve

 

[leeb]

Merely common data lines ... but I think I see your point. If they are both on the same side of a 'buffer' then it is unlikely that could be an issue as we know that input/output from the FDC is behaving properly.

Certainly sounds like it is time to dig out the 'chip-snippers'

 

[Ecaroh]

Thanks. Yes, AFAIK the FDC is working OK. Both drives read and write, and do it accurately.

VTAC pins 21-23 and probably others connect also to a 244 (buffer/line driver/receiver) that is not far away, I have learned.

Reaching for the chip-snippers: we'll see. I can buy the part for $25 or so.... Too bad the 244 is, probably, not the problem.

 

[leeb]

The best of luck! :D