Help needed for Apple IIe PAL

Don't blame the IOU merely because it's generating that ugly display.  These same symptoms could occur if there's an intermittent fault in any of the four following components, but the IOU would generate exactly that screen because it's merely reproducing what was erroneously written into the screen memory.

1. 74LS244 in socket C1 (blue highlight, affects low address bits and mux'd address bits)
2. 74LS244 in socket C2 (orange highlight, affects high address bits and mux'd address bits)
3. 74LS125 in socket C12 (red highlight, affects write-to-memory signal)
4. MMU in socket C4 (green, address mux)

The 74LS244 is a fairly common component, so you might be able to borrow one from another peripheral.  It's also been a common component to fail in the last few years, so it's a plausible suspect.

(Also be sure to remove any peripherals, especially from the AUX slot.  Many of these signals are shared with the slots, so a faulty peripheral could cause interference.)

NB: all socket locations are for 50Hz European Apple //e

IIe (euro) CPU to DRAM interface.png

Could you do the following tests after you turn on the machine and hear a beep:

1. Blindly type PR#3, hit Return and take a picture.

2. After that type GR, hit Return and take another picture.

3. Make a video of what you see when you hold both the Open Apple and Close Apple button down while turning on the machine.

If you have a modern Pico-based VGA or HDMI card, try it to see if what you see on the screen looks different.

I agree with S.Elliott; the IOU is probably not the problem. Since we see part of the "Apple" logo on top, I'd think the two LS244s are good. If not, the computer wouldn't be able to fetch instructions and wouldn't even display the "àpple". Personally, I'd search around the Video ROM and maybe the LS374 that generate the VID0-7 signals. Remove them, clean with DeoxIT and put them back. See if it changes something.

I'm very curious what the self test look like (the point 3 in CVT's post).

Please also tell us what you see when you flip the character set / language switch. Do the "à" becomes "@"?

Also do you see something blink like a cursor using the wrong character? What happens when you type?

lazaj30 wrote:

However, I noticed that the original 6502 heats up quickly. When I replace it with a 6502 taken from an Apple IIc, it stays cool.

The//c uses a CMOS 65C02 so it would be expected to run much cooler.

As for the screen display , it's defineitely weird that the HOME function which clears the screen by writing $A0 to each screen location ends up displaying the inverted @ signs instead. While there are lots of faults that could explain this, when it displays the APPLE ][ title, the space between E and ] is also written as $A0. Yet that displays correctly as a blank space. While highly unlikely, a BAD F8 ROM could cause this; swapping it out with one from another machine, an Apple Language Card, or a fleXrom could rule that out.

jeffmazur wrote:

As for the screen display , it's defineitely weird that the HOME function which clears the screen by writing $A0 to each screen location ends up displaying the inverted @ signs instead. While there are lots of faults that could explain this, when it displays the APPLE ][ title, the space between E and ] is also written as $A0. Yet that displays correctly as a blank space. While highly unlikely, a BAD F8 ROM could cause this; swapping it out with one from another machine, an Apple Language Card, or a fleXrom could rule that out.

No, it's not at all weird that the HOME function didn't clear the screen -- it just shows a difference in how a slot-based video card behaves under the same basic situation:

• The OP picture showed how built-in video behaves when the screen memory isn't initialized -- at power-up the motherboard DRAM contains patterns of 0 bits and 1 bits, roughly a 50/50 ratio.  Each manufacturer's DRAM exhibits distinctive patterns -- the arrangement in the OP picture matches Texas Instruments TMS4164.
• The new picture shows how slot-based video card behaves when the screen memory isn't initialized -- at power-up the pico initialized its own memory with zeroes, which maps to inverse "@" signs until overwritten.

The "Apple ][" text appeared correctly because the ROM stores those 8 characters directly in screen memory at $040F through $0406.  But the HOME function is more vulnerable to failure because it writes indirectly via "STA (BASL),Y" instructions that require zero-page memory to perfectly store and recall numerous bytes like WNDTOP, CH, CV, WNDBTM, WNDLEFT, WNDWIDTH, BASL, and BASH.

The test results effectively rule out motherboard RAM, character generator, and IOU.  It could still be any of the components listed in comment #2, but I acknowledge frozen signal's skepticism about the LS244s because most of those address bits must have been working in order to display the title -- at least some of the time.  If it's not a bad LS244 then it's most likely to be a bad MMU.

Kudos to CVT for suggesting that test with the Pico-based video card.

S.Elliott wrote:

But the HOME function is more vulnerable to failure because it writes indirectly via "STA (BASL),Y" instructions that require zero-page memory to perfectly store and recall numerous bytes like WNDTOP, CH, CV, WNDBTM, WNDLEFT, WNDWIDTH, BASL, and BASH.

 That's true. But If the machine beeps there's a good chance that zero page RAM is working. A good dead test memory checker (e.g. ROMX, Adrian Black's DEADTEST, or fleXrom) could be used to verify that.

Another thought: Perhaps a power supply issue causes the machine to crash after the speaker is toggled during the "beep."

S.Elliott wrote:

...

The test results effectively rule out motherboard RAM, character generator, and IOU.  It could still be any of the components listed in comment #2, but I acknowledge frozen signal's skepticism about the LS244s because most of those address bits must have been working in order to display the title -- at least some of the time.  If it's not a bad LS244 then it's most likely to be a bad MMU.

Kudos to CVT for suggesting that test with the Pico-based video card.

 

Thank you, but I am not sure why you are completely ruling out the IOU. Take a look at this: even with the IOU chip completely removed and sitting on top of the PSU, after the Vince Briel VGA card initially shows all inverse @ (all zeros), pressing <Ctrl><Reset> a few times injects the Apple II logo and sometimes it even shows a flashing Basic cursor:

NoIOU.JPG

CVT wrote:

Thank you, but I am not sure why you are completely ruling out the IOU. Take a look at this: even with the IOU chip completely removed and sitting on top of the PSU, after the Vince Briel VGA card initially shows all inverse @ (all zeros), pressing <Ctrl><Reset> a few times injects the Apple II logo and sometimes it even shows a flashing Basic cursor

When you removed your IOU the computer did not replicate the odd behavior of showing "Apple ][" over a non-cleared text screen.  Perhaps we're drawing different interpretations or making different assumptions?  Let's try to keep it on-topic and make it useful for lasaj30, since the purpose of the thread is to troubleshoot his issue.

Importantly, perhaps, I neglected to state this assumption: when  lasaj30's  Apple //e shows the "Apple ][" title over a cluttered background, I assumed that the motherboard's composite video shows the title over stripes of random-looking characters as pictured below left, and I assumed the Pico video card shows the title over a screen filled completely with inverse @ signs as pictured below right.  And I assumed (perhaps wrongly) that the motherboard video and Pico video are showing these slightly different-looking screens at the same time.

Composite video (from motherboard DRAM) lazaj30 motherboard video.png

Pico video (from bus snooping) lasaj30 Pico video.png

Oopsie, sorry I made an assumption without stating it...and without asking  lasaj30 to verify it.

To lasaj30, when your //e shows any part of the "Apple" title, does the motherboard's composite video show a different background from the Pico video card's output?

APPLEII subroutine.png

For reference, here's the ROM subroutine that writes the title onto the text screen.  Its first instruction is "JSR HOME" but the faulty //e certainly did not clear its screen to blank spaces.  I guessed that the HOME subroutine returned without actually initializing screen memory, but jeffmazur raised other possibilities.

lazaj30 wrote:

Even though I tested all the RAM ICs with the RCT Pro (using the March test), I’m going to install the https://github.com/misterblack1/appleII_deadtest ROM. There might be a problem with the RAM traces, even though I’ve already checked for continuity.

In your latest photo, DRAM writes were not reliable when address bit A4 was 0.

Unreliable address bit A4.png

Some guesses at what could cause that:

• If there's a broken connection for address bit A4 between socket C1 (pin 3) and socket C4 (pin 37).  Since an open connection is often interpreted as a 1, then the bit could be  unreliable for transmitting addresses where address bit A4=0.
• The MMU in socket C4 might be faulty, and thus unreliable for multiplexing DRAM addresses where A4=0.  This would not impair ROM operation, just RAM, because bit A4 is not involved in the MMU's selection of ROM addresses.  (The MMU only uses bits A12~A15 to select ROM addresses, and the rest of the address bits are passed to the ROM without passing through the MMU.)

[EDIT: If it's the MMU, you might find a modern substitute...like the one at this page from frozen_signal's design.]

[EDIT2: I just noticed that address $040F is one of the unreliable addresses where A4=0, and it's the first character of the "Apple ][" title which was corrupted in your first photo.  This further pinpoints the problem as address bit A4, but doesn't determine whether it's the MMU or a broken wire on the motherboard.]

lazaj30 wrote:

Connection between C1 pin 3 and C4 pin 37 is good, so I need to test if MMU is ok.I will ask a friend with a working computer to lend me a MMU ic. I will go back when tested.

 

If the issue is not in the MMU and considering the problem started while the computer was just off for some time, you should consider the possibility that of a bad socket connection. 

lazaj30 wrote:

New problem, keyboard reset key now doesn't do anything. This computer drive me crazy.

For information, I'm not a noob repairing a computer, I am a freelance engineer  in electronics and embedded software development. I teach PCB design (IPC-certified) at an engineering school.

I asked the developer of the deadtest what the error ZP/SP ERR 1111110 corresponds to. Here is t

I had similar problems with the last AIIe (PAL) I have repaired.

It turned out that there were poor contacts with the original ROM pins in the sockets. 

The original ROM pin's were very oxydized (gray color) .  It's most probably  tin oxide which is a very poor electrical contact.

Programming a new set and cleaning the socket did solve the problem of not being able to type blindly.

After thoroughly cleaning the original ROM pins, these ROM's were found again OK.

Curiously, the faulty ROM's were readable by a PROM programmer in a ZIF socket, but the contact was not good in the mainboard tulip socket.

Yves

CVT wrote:

lazaj30 wrote:

Connection between C1 pin 3 and C4 pin 37 is good, so I need to test if MMU is ok.I will ask a friend with a working computer to lend me a MMU ic. I will go back when tested.

 

 

If the issue is not in the MMU and considering the problem started while the computer w

The sockets that Apple used were not the best, so failure of one or even just significant oxidization of the contacts or pins on the chips is a possibility.  Cleaning may help but may not fix it if the socket is bad enough.