PDA

View Full Version : Eagle II Hardware problem



Ecaroh
November 14th, 2012, 04:21 PM
Do we have any Eagle II experts here, or Z-80 and CP/M generalists who might be able to help?

I started up my old Eagle II recently and it almost immediately produced a "RAM ERROR" screen. So it won't boot sufficiently to run any software tests.

DRAM consists of a bank of a eight 64k chips, all of which perform the same as to resistance from data-out pin to ground, none of which heat up to any extent; all are receiving the 5V supply and none look bad. (Both 12V supplies are working as well.)

Is there any cache? Any obvious possibilities I'm overlooking? I don't have any of the DRAM chip on hand to try piggybacking.

Buffer, the board is heavily populated with the 74LS244PC Octal Buffer/Line Driver. No obvious anomalies there that I've found. Not sure what else might be in play.

The BIOS (I think), the Z-80 and one other thing are in sockets. I removed all from the sockets and reinserted.

Perchance, is there a schematic? Or, last resort, does anyone want the machine in its current state?

Thanks hugely in advance.

Steve.

Chuck(G)
November 14th, 2012, 04:51 PM
AVL Eagles are pretty cool CP/M systems. I think they were used extensively in the audio-visual business to run things like slide projectors, so a schematic is not beyond the realm of possibility, but I've never seen one. You can play the "piggyback" game to locate your bad RAM chip however.

4116 DRAM chips aren't hard to come by.

Ecaroh
November 14th, 2012, 05:15 PM
Thanks! I guess if I were sure that a bad RAM chip is what I have, I'd go out and pick up a few (it uses 8264). Are you pretty sure?

The great thing about the two machines I had (have) was the native Spellbinder word processing. They sold a lot for that purpose, but I think with more pervasive distribution and marketing they could have sold 10X or 100X more.

Chuck(G)
November 14th, 2012, 05:30 PM
8264? The Fujitsu MB8264 64Kx1 16-pin DRAM? That should be easy--just about any 64K DRAM (e.g. 4164, 2164, etc.) should do the job. There are scads of equivalents. They do go bad--and it would be the cheapest troubleshooting task.

Ecaroh
November 14th, 2012, 06:16 PM
All noted and sounding reasonable. (Yep, the Fujitsu part you mentioned.) Thank you.

Ecaroh
November 19th, 2012, 05:30 PM
OK, it's fixed. I ordered a few pieces of NEC 4164 from a guy on eBay (kentelectronics) and they came today. I turned out only to need one.

It was funny. The Eagle had 7 of the Fujitsu chip and, down at one end, it had a Motorola 4164. I had turned up a few *possible* anomalies when going over that chip with the meter, so I went in again today before trying the piggyback. Things were more out-of-whack there than I'd thought.

On the Data Out pin, the other seven chips were each giving me a nearly identical 3.9 volts or so. The Motorola read 1.35. Voltages on the Data In pins seemed to vary by pair, but the apparent companion DRAM to this one read 2.47 volts, while the Motorola read high at 3.3 volts. No other chip was over about 1.5 volts on this pin.

So I bent the pins a little on one of the new NEC chips and got it onto the pins of the Motorola part. The machine booted! No "Ram Error." Unsoldered the Mot. and soldered on an NEC. All is well.

My C. Itoh daisywheel printer still works too!

Thanks again to Chuck.

Chuck(G)
November 19th, 2012, 05:57 PM
Congratulations--aren't you glad that you didn't get rid of it? :)

------------------------
Dirty little secret: US-made DRAM in the early days was pretty awful--the Japanese were far ahead of the US for quite some time. It got so bad that the US phonied up "dumping" trade sanctions on the Japanese--which precipitated a DRAM shortage because US manufacturers didn't have their yields up. In Silicon Valley, there were break-ins and at least one truck hijacking, all for DRAM.

Ecaroh
November 21st, 2012, 02:35 PM
Am I glad I didn't get rid of it? :) Well, I don't know. There's a display problem. Will attach two shots of a screen to show what it is. In these screens, lines start in the middle; that is, they start with the right half of a line, finish that half, and then go on to the start of the line. The problem also shows up as confusion about where to put the cursor in word processing. You'll move it accurately anywhere from two to 11 times, and then it'll go to the wrong place and continue on that basis until you eventually move to the end of a line, then it corrects itself. I'm thinking a faulty logic chip. But that's a wild guess, and there are a lot of logic chips. Piggybacking onto the other seven DRAM chips doesn't solve this.

leeb
November 22nd, 2012, 03:15 PM
I dont believe you could TRULY say it isnt the (remaing) RAMs until the old ones are disabled... and it DOES sound like a stuck bit to me...

Does it ONLY do it with the WP or EVERYTHING?

Ecaroh
November 23rd, 2012, 09:31 AM
Appreciate the reply. I'm sure you're right about disabling the other RAMs. Maybe with a scope I could find one that has problems. (Don't have a scope.)

The screen in my thumbnails is from the spreadsheet program. In WP, what I get is the cursor becoming confused about where it should be. Also sometimes a lingering flash as of the cursor, in addition to the actual cursor location.

I did a test from inside CP/M. CP/M was also giving me the busted up, transposed display lines as in the thumbnails. With CP/M, I input the instruction to use a different I/O for the CRT. But the problem remained exactly the same. To me, that suggested that the RAMs weren't the problem.... Anyone agree with that?

Thanks.

Chuck(G)
November 23rd, 2012, 09:54 AM
A 'scope would tell you a bunch--there's also the possibility that the monitor has an issue and the video generation itself is okay. Do you know what your box uses as a CRT controller?

Ecaroh
November 23rd, 2012, 03:33 PM
there's also the possibility that the monitor has an issue and the video generation itself is okay. Do you know what your box uses as a CRT controller?

Thanks for that. About all I can tell you is that, on the board next to the CRT, with its power supply, there's an SN7406N, which is a "Hex inverter buffer/driver with open-collector high-voltage outputs."

The ribbon cable from the main board to the CRT assembly, most of it, comes off one of those 74LS244PC Octal Buffer/Line Drivers.

Steve.

Chuck(G)
November 23rd, 2012, 04:22 PM
Any LSI used in video generation, say a MC6845?

Ecaroh
November 23rd, 2012, 04:58 PM
Aha, didn't find that one, but did find these two big guys that may be germane:

CRT5037
CRT8002A

Both inscribed SMC.

thx,
Steve

leeb
November 23rd, 2012, 06:21 PM
Appreciate the reply. I'm sure you're right about disabling the other RAMs. Maybe with a scope I could find one that has problems. (Don't have a scope.)

The screen in my thumbnails is from the spreadsheet program. In WP, what I get is the cursor becoming confused about where it should be. Also sometimes a lingering flash as of the cursor, in addition to the actual cursor location.

I did a test from inside CP/M. CP/M was also giving me the busted up, transposed display lines as in the thumbnails. With CP/M, I input the instruction to use a different I/O for the CRT. But the problem remained exactly the same. To me, that suggested that the RAMs weren't the problem.... Anyone agree with that?

Thanks.

By 'Different I/O for the CRT' you mean you sent the I/O to the serial port and used an external terminal/computer to interface to it?
On my Model 4p, the X and Y coordinates are kept in RAM... so if they are not inc/decrementing properly, the format could/would get hosed... I BELIEVE it also controls the output to SIO as well, but cannot confirm that, particularly on your machine.

Of course, the fact that CP/M loads/runs at all suggests at least MOST of the RAM is okay...
???

Chuck(G)
November 23rd, 2012, 06:30 PM
Well, you've got the standard SMC VDAC+VTAC (the 5037 is the VTAC) chipset. Do you also have a small bipolar PROM (e.g. Harris HM-7602) nearby? The bipolar PROM could be used for auto-initializing the CRT controller and sometimes those can go bad.

Ecaroh
November 23rd, 2012, 10:43 PM
Do you also have a small bipolar PROM (e.g. Harris HM-7602) nearby? The bipolar PROM could be used for auto-initializing the CRT controller and sometimes those can go bad.

Interesting. Haven't found one of those, but I did find a 16k SRAM right between the two SMC parts, with quite a few traces connecting to the 8002 (see photo). Also a PLL. I'll look into the SRAM further tomorrow.

thanks,
Steve

Ecaroh
November 24th, 2012, 11:38 AM
By 'Different I/O for the CRT' you mean you sent the I/O to the serial port and used an external terminal/computer to interface to it?



No, it wasn't sent to a different port. I believe the I/O that I changed with CP/M tools is at the chip level and has to do with what parts of memory and/or the MPU are used to send data to the various ports. I'll dig out the manual a little later and describe better.

Ecaroh
November 24th, 2012, 03:52 PM
I think the SRAM described and photographed in Post 17 may be causing the display problem. The datasheet touts this as a pin-for-pin substitute for a certain EPROM (to refer to Chuck's question in Post 16). It's a 2kx8 part.

On this chip, which unfortunately has 24 pins, eight are designated input/output. With the machine running, one of the eight (which connects to the VDAC) emits 4.04 volts. The other seven emit .12-.20 volts. The 4.04 volts is not generated by the VDAC, because it occurs even when that part is off the board. (It's in a socket and can be removed.)

Steve.

leeb
November 24th, 2012, 09:10 PM
Pull that chip and see if the SOCKET is showing the 4.04 without it in place.

DUH... you already said that.
You may need to trace it back to a 74LS244/245 buffer that might be hosed on that pin...

:D

EDIT:

the M58725p is in a socket? :eek:
Doesnt look like it!

Ecaroh
November 24th, 2012, 10:33 PM
The 58725, which is the SRAM, is not in a socket. The VDAC is in a socket. I think the only thing the SRAM pin showing the 4.04 volts connects to is the VDAC. And the SRAM pin shows the 4.04 volts even when the VDAC is out of the socket. So it seems as if the abnormal 4.04 volts may be generated from within the SRAM, via an internal short or something like that. Yes?

leeb
November 25th, 2012, 10:03 AM
WHICH pin is that?
... not that I dont believe you, but if it is 8-11 or 13-16 then it MAY or MAY NOT be abnormal depending on what value that byte has in it... 20H would be a 'blank' in the screen, so bit 5 would be high... I think that would be pin 10... ?

Try to fill the screen with 'B' (42h I think) and then see if bit pin 10 and pin 15 are high and nothing else... (pin 24 being VCC, of course)

Ecaroh
November 25th, 2012, 11:21 AM
WHICH pin is that?
... not that I dont believe you, but if it is 8-11 or 13-16 then it MAY or MAY NOT be abnormal depending on what value that byte has in it... 20H would be a 'blank' in the screen, so bit 5 would be high... I think that would be pin 10... ?

Try to fill the screen with 'B' (42h I think) and then see if bit pin 10 and pin 15 are high and nothing else... (pin 24 being VCC, of course)

The pin with 4.04 volts is #15. Questions: When you say a blank in the screen -- do you mean an empty screen? Also, I'm not sure how to input "20H" and "42H."

But I'll experiment with getting different displays and then measuring those various pins (9-11 and 13-17).

Thanks!

leeb
November 26th, 2012, 02:49 PM
An 'empty' screen is filled with <SPACE> = 20h (0010 0000)... which, if EMPTY, would be nothing but 20h and pin 15 would appear HIGH (to some extent) all the time....
The fact that it is NOT 5v is due to the short times that the voltage changes between CHR 20h and 'nothing'...

IF I recall, 40h is the '@' symbol... try filling the screen (as possible) by pressing alot of those and see if pin 15 goes low for a significant period of time (or some voltage < 4).
(As a comparison, pin 16 should show some value ABOVE zero...)

If 15 DOES drop the voltage and 16 comes UP, it is fairly safe to assume that pin 15 is not stuck high...

Is it possible that the copy of CP/M you have has been configured (parly or fully) to run as 40 column?

Ecaroh
November 26th, 2012, 07:10 PM
I don't think the CP/M copy is the issue. I get the problem booting from a variety of discs. One that's CP/M and Basic. Others that are the WP (and CP/M) and the one with the spreadsheet (and CP/M) shown in my earlier screenshot.

However -- I don't know how you knew this, but filling the screen with an '@' does drop pin 15 from 4.04 volts down to 1.23, and raises pin 16 up to 2.86.

In various testing, there were a few other things that would drop pin 15 down to 2 volts and less, but it never went to the .07 or so that the other pins give when nothing is happening.

A near-empty screen, and pin 15 is 4.04 volts. A full screen of text, and it's 4.04 volts (and pin 16 is .07). If I fill the screen with periods, and then "Select" them, i.e. the whole screen lights up except for the numerous 2-pixel periods, pin 15 is 4.04 volts. There are times when it's more like 4.06 or 4.08. ("Selecting" the screen full of '@' signs doesn't change the voltage on pin 15, i.e. it remains 1.23.)

It does seem odd that nothing that I've found, at least, will get any pin other than 15 (and of course the supply) to go over 3 volts.

But I'm now much less optimistic about this SRAM being the problem. (bummer face here) I have a couple pieces of replacement chip coming in, they were cheap. We'll see. But without further confirmation, I won't be desoldering the SRAM, and its 24 pins.

leeb
November 26th, 2012, 08:04 PM
Something else to try...

Start with PRINTABLE characters... '1' to whatever...
then the letters from 'A' to 'Z'...
Then the small letters 'a' to 'z'...

See if any of them come up looking funny or do weird things.

Im pretty sure the socketed chip is your character generator ('character set')...
Which leads me to believe your video controller is 'fritzed'.. (likely the 40pin 'upper' chip in your pic).

EDIT: OR PERHAPS the CLOCK INPUT to the VC is not running at full speed... ??

I believe the main reason you cannot get any other pin above 3v is because you actually cannot fill the ENTIRE 80x25 screen with the 'alternate' character.
space = 20h = 0010 0000 = pin 15
'@' = 40h = 0100 0000 = pin 16
'A' = 41h = 0100 0001 = pin 16 and pin 8
(see how I knew now?) :p

:(

Ecaroh
November 27th, 2012, 12:18 PM
Something else to try...

Start with PRINTABLE characters... '1' to whatever...
then the letters from 'A' to 'Z'...
Then the small letters 'a' to 'z'...

See if any of them come up looking funny or do weird things.

:(

None looked or did anything weird.


Im pretty sure the socketed chip is your character generator ('character set')...
Which leads me to believe your video controller is 'fritzed'.. (likely the 40pin 'upper' chip in your pic).

EDIT: OR PERHAPS the CLOCK INPUT to the VC is not running at full speed... ??

I believe the main reason you cannot get any other pin above 3v is because you actually cannot fill the ENTIRE 80x25 screen with the 'alternate' character.
space = 20h = 0010 0000 = pin 15
'@' = 40h = 0100 0000 = pin 16
'A' = 41h = 0100 0001 = pin 16 and pin 8
(see how I knew now?) :p

:(

The socketed chip is the VDAC, or CRT Video Display Attributes Controller and Video Generator. So yeah, I think it generates characters, maybe among other things.

The 40-pin CRT5037 is the VTAC or Video Timer and Controller, so your hunch there is right too.

I don't know what the clock consists of in this box. There are two crystals in various places and a PLL. The PLL connects up with a nearby pot. Both are marked in my attached photo.

Two things to point out. If Pin 15 on my SRAM is "space," and the chip is working right, why do I get 4.04 or slightly more volts on that pin whether I have a blank screen, or a screen full of text, or an everything-selected screen full of periods (screen all lit up)? No need to answer in detail, but does that make sense?

Second. With CP/M and the spreadsheet, the display problem is the lines-cut-in-half-and-jumbled problem. That doesn't happen in Word Processing. In word processing, it's mostly to do with cursor display. I will describe:

At some point the cursor will start flashing somewhere other than where the rest of the machine thinks the cursor is. Say 20 spaces over, in a void. If you watch, that spot will flash after a while with only half the pixels lit up, and another flashing just like that will start where the cursor is supposed to be. Then, the wrong-spot-cursor will disappear, and the right one will fully light.

I start to wonder if these are two different problems. But why the disparity between behavior across different programs?

Many thanks,
Steve.

leeb
November 27th, 2012, 02:41 PM
None looked or did anything weird.



The socketed chip is the VDAC, or CRT Video Display Attributes Controller and Video Generator. So yeah, I think it generates characters, maybe among other things.

The 40-pin CRT5037 is the VTAC or Video Timer and Controller, so your hunch there is right too.

I don't know what the clock consists of in this box. There are two crystals in various places and a PLL. The PLL connects up with a nearby pot. Both are marked in my attached photo.

Two things to point out. If Pin 15 on my SRAM is "space," and the chip is working right, why do I get 4.04 or slightly more volts on that pin whether I have a blank screen, or a screen full of text, or an everything-selected screen full of periods (screen all lit up)? No need to answer in detail, but does that make sense?

Second. With CP/M and the spreadsheet, the display problem is the lines-cut-in-half-and-jumbled problem. That doesn't happen in Word Processing. In word processing, it's mostly to do with cursor display. I will describe:

At some point the cursor will start flashing somewhere other than where the rest of the machine thinks the cursor is. Say 20 spaces over, in a void. If you watch, that spot will flash after a while with only half the pixels lit up, and another flashing just like that will start where the cursor is supposed to be. Then, the wrong-spot-cursor will disappear, and the right one will fully light.

I start to wonder if these are two different problems. But why the disparity between behavior across different programs?

Many thanks,
Steve.

1) 'space' is not the ONLY 'character' that uses pin 15 (the '2' of 20h, or 0010 0000 )
ANY and EVERY 'character' from
20h - 2Fh....(0010 0000 - 0010 1111)
30 - 3Fh......(0011 0000 - 0011 1111) - '0' thru '9'
60 - 7Fh......(0110 0000 - 0111 1111) - includes lower-case letters
A0h - BFh....(1010 0000 - 1011 1111) \ usually includes 'inverted'
E0h - FFh....(1110 0000 - 1111 1111) / characters

2) This is the main reason I believe your video controller (whichever one OR both) is the cause...
It looks to me like the TEXT in the WP is being handled in a 'bit-mapped' fashion and the 'hardware' cursor is not 'addressing' properly.
When in WP, can you type all the way to the actual end of the screen (Y) or does it 'wrap' around somewhere strange too (N)?
If (Y) I believe the WP is putting the characters DIRECTLY into video memory and not allowing the video controller to do it... (many machines do it this way)...

At some point the cursor placement 'counter' is being thrown off which is where you see the 'wayward ghost' of the cursor.

It MIGHT be an addressing issue between the controller and the memory... are any of the chips in the 2nd pic 244s or 245s?

I DO NOT believe you have an ACTUAL video-memory issue.

EDIT: ** CONFIRM that pins 25 and 26 on the socketed chip are 5v (or something close).... They are supposed to be HIGH for 'alphanumeric mode'.
It seems likely that THIS CHIP is your 'problem child', but is it the chip or the connections to it? Ah... the $$$ question! :D

Ecaroh
November 27th, 2012, 03:49 PM
Thanks for the explanation in Item 1, Leeb.

The question in Item 2: The WP will display text all the way to the right edge of the screen, provided the word breaks allow for it. It breaks to a new line at the right-most possible word space, and that function works fine. (In WP.)

As for "244 or 245" chips: as mentioned, I have 74LS244PC chips all over the board; the Octal Buffer Line Driver. None of them show up in that last photo I posted, but I'm now posting a shot of the full board, and all of the LS244s are marked with red arrows (there are 13). To situate you, I've also marked the VTAC and VDAC we've been talking about. You'll see that several of the LS244 are at least nearby. IIRC, at least one shows traces to the VTAC and/or VDAC.

Last, I checked voltage on pins 25 and 25 of the VDAC, and both produce 4.89 volts; so, yes.

Connections to that socket -- I can at least test all the immediate traces, I believe.

thanks for all this,
Steve

Chuck(G)
November 27th, 2012, 03:56 PM
If I may offer a suggestion, I don't think it's clear if the CPU or the monitor itself is at fault. If you turn up the brightness all the way (and the contrast down) to get a raster onscreen, does it cover the entire screen?

Ecaroh
November 27th, 2012, 04:24 PM
Delighted to have any suggestions, Chuck. No, I'm not clear on the health of the monitor either.

At the moment, contrast is hard to get at, but I took some photos in Word Processing that may (or not) answer the question. These are screens full of periods. In the second one, the periods are "selected", a step you can take in order to make text print bold-face, underlined, etc. The few gaps that show up are spaces there happen to be between some of the periods. The screen does fill all the way up.

Chuck(G)
November 27th, 2012, 04:45 PM
So, what I'm seeing is a "staggered" display that's progressively off about one character for each text line? Or is the stagger intentional?

Ecaroh
November 27th, 2012, 05:08 PM
The stagger is just part of what was input, and how I did the cut and paste. Sorry. Those gaps could just as easily not be there. That display is basically fine. The problem in WP is the phantom cursor, the misplaced cursor.

Chuck(G)
November 27th, 2012, 05:27 PM
Is the problem only in WP? i.e., does it occur in other packages?

You're using Spellbinder, right?

leeb
November 27th, 2012, 05:58 PM
The stagger is just part of what was input, and how I did the cut and paste. Sorry. Those gaps could just as easily not be there. That display is basically fine. The problem in WP is the phantom cursor, the misplaced cursor.

... and I guess that the square off the right side of the periods is the 'phantom' cursor, or the 'actual' one?

Try this in CP/M A> prompt:

try a ^Z <ctrl-Z> to see if the screen clears. if SO, (or however you can get it to erase) do it.
THEN do a line of periods or '*' or something that will show where it is starting the line(s) and where 128 characters (the max a command line will accept) ends...

*** IF THE LINE WRAPS change to a different character!

It still sounds to ME like the software is not setting up the display properly, but until we can figure out a HARDWARE problem at least we are (hopefully) making headway!


EDIT:
Okay. What I can see (In your 1st images) is
The lines are being STARTED 3 characters (counting from 0) RIGHT (0000 0011) of where they should be.
At the 32 (31) byte point (0001 1111) they are being LOOPED BACK to 0 (0000 0000) until, as in the 1st line, a CR/LF resets it.
This problem is not in the video memory, otherwise the characters THEMSELVES would be wrong, but not necessarily in the wrong places...

Only the cursor in the WP prog is affected as it seems that the WP does direct video-memory insertions. That, or only the addressing for the cursor is affected in this case.

When you entered the periods... did they start at the VERY FIRST spot, or elsewhere? (suggesting an addressing issue)
How much memory is it supposed to have? How much does it TELL YOU it has? (if it does)

*** Take a look at A5 on the socketed chip to see if it shows any voltage > 0... I think it is never going HIGH. The address lines 0-7 should provide for 0-79 characters/line... (0000 0000 - 1000 1111) and it does not seem to get past 0-31 (0001 1111)...

Ecaroh
November 27th, 2012, 07:42 PM
... and I guess that the square off the right side of the periods is the 'phantom' cursor, or the 'actual' one?

Try this in CP/M A> prompt:

try a ^Z <ctrl-Z> to see if the screen clears. if SO, (or however you can get it to erase) do it.
THEN do a line of periods or '*' or something that will show where it is starting the line(s) and where 128 characters (the max a command line will accept) ends...

*** IF THE LINE WRAPS change to a different character!

It still sounds to ME like the software is not setting up the display properly, but until we can figure out a HARDWARE problem at least we are (hopefully) making headway!


EDIT:
Okay. What I can see (In your 1st images) is
The lines are being STARTED 3 characters (counting from 0) RIGHT (0000 0011) of where they should be.
At the 32 (31) byte point (0001 1111) they are being LOOPED BACK to 0 (0000 0000) until, as in the 1st line, a CR/LF resets it.
This problem is not in the video memory, otherwise the characters THEMSELVES would be wrong, but not necessarily in the wrong places...

Only the cursor in the WP prog is affected as it seems that the WP does direct video-memory insertions. That, or only the addressing for the cursor is affected in this case.

When you entered the periods... did they start at the VERY FIRST spot, or elsewhere? (suggesting an addressing issue)
How much memory is it supposed to have? How much does it TELL YOU it has? (if it does)

*** Take a look at A5 on the socketed chip to see if it shows any voltage > 0... I think it is never going HIGH. The address lines 0-7 should provide for 0-79 characters/line... (0000 0000 - 1000 1111) and it does not seem to get past 0-31 (0001 1111)...

A5 connects to Pin 15 in the SRAM (the one we've been talking about), and it shows whatever voltage that pin is generating. I.e., mostly 4.04 volts or so. (So yes, it *is* going high.)

Re: the 31 characters, yes that's exactly what happens if you enter text in either CP/M or the spreadsheet. After you input 31 characters, the cursor hops back to the start of the line and you being overwriting what's there.

Also, in CP/M, occasionally the prompt (A>) will be in the wrong place -- it will occur 32 spaces in from the left.

About the periods I inputted -- they will start where you want them to. Once the cursor gets confused, you may have a little trouble getting text to occur where you want it to....

I'm not sure what your memory question is. The system DRAM is 64K bytes. I don't know of a way to get the system itself to tell me how much memory it can find. Maybe there's a command in CP/M?

Steve.

Ecaroh
November 27th, 2012, 07:44 PM
Is the problem only in WP? i.e., does it occur in other packages?

You're using Spellbinder, right?

Yes on Spellbinder. There are different problems in SB than there are in Ultracalc and when I boot the CP/M disc. See Post 27, on page 3, for descriptions, and also Post 8, on page 1, for a screen with the display problem in Ultracalc.

Chuck(G)
November 27th, 2012, 08:04 PM
So, is 32 the magic number here? When you say "occasionally the prompt (A>) will be in the wrong place -- it will occur 32 spaces in from the left"--is this a consistently repeatable situation? Does it occur only on some lines but not on others? Does it always occur on the same line?

leeb
November 28th, 2012, 12:11 AM
A5 connects to Pin 15 in the SRAM (the one we've been talking about), and it shows whatever voltage that pin is generating. I.e., mostly 4.04 volts or so. (So yes, it *is* going high.)

Re: the 31 characters, yes that's exactly what happens if you enter text in either CP/M or the spreadsheet. After you input 31 characters, the cursor hops back to the start of the line and you being overwriting what's there.

Also, in CP/M, occasionally the prompt (A>) will be in the wrong place -- it will occur 32 spaces in from the left.

About the periods I inputted -- they will start where you want them to. Once the cursor gets confused, you may have a little trouble getting text to occur where you want it to....

I'm not sure what your memory question is. The system DRAM is 64K bytes. I don't know of a way to get the system itself to tell me how much memory it can find. Maybe there's a command in CP/M?

Steve.

No... pin 15 on the RAM is a DATA line, specifically D5 (D0-D7)... IIRC, the ADDRESS lines are pin 1-pin 8, 19,22 and 23...
Pin 1 = A7... pin 8 = A0. So A5 would be pin 3 on the RAM, tho you could continuity check to ensure the pins are the same for the VDAC, where I meant for you to check. :rolleyes: Sry. :p

Okay, 64k... good.

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

Either there is an addressing issue into/out of the VTAC/VDAC or perhaps a 244 for the A5 line is defective... IMO.
:D

Ecaroh
November 28th, 2012, 08:46 AM
So, is 32 the magic number here? When you say "occasionally the prompt (A>) will be in the wrong place -- it will occur 32 spaces in from the left"--is this a consistently repeatable situation? Does it occur only on some lines but not on others? Does it always occur on the same line?

This is the behavior when running CP/M itself. 32 is magic in that this (i.e. 31) is the maximum number of characters it will display in a line, and in that the prompt sometimes occurs as noted -- 32 spaces in.

What I find is that in the 17th line of the first screen, the cursor shows up on that 33rd space. After that, it happens once per screen. As you hit "returns," once the first indented prompt goes off the screen up top, you get a new one at bottom, and the pattern repeats.

In the spreadsheet, Ultracalc, things are less predictable. But I don't know that app at all.

Ecaroh
November 28th, 2012, 09:07 AM
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
November 28th, 2012, 02:32 PM
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'. :p

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
November 28th, 2012, 03:06 PM
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
November 28th, 2012, 05:09 PM
Okay... this sux... :p

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! :p

Ecaroh
November 28th, 2012, 07:08 PM
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! :p

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
November 28th, 2012, 07:28 PM
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)
November 28th, 2012, 07:44 PM
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
November 28th, 2012, 11:12 PM
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
November 29th, 2012, 12:22 PM
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
November 29th, 2012, 01:33 PM
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
November 29th, 2012, 02:03 PM
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! :eek:
:D

Ecaroh
November 29th, 2012, 07:16 PM
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
November 30th, 2012, 09:50 AM
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' :p

Ecaroh
November 30th, 2012, 12:41 PM
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
November 30th, 2012, 03:10 PM
The best of luck! :D