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