Apple ii plus boots to Apple ii screen but won’t load disks

This sort of symptom is often caused by bad memory in the 2nd and 3rd banks of RAM.  Other things that can cause it is bad logic that controls memory access.  I've seen cases where memory addresses weren't right so things will get garbled.  If you can get some kind of RAM test to run it can help diagnose these kinds of errrors.  Another thing that will sometimes give a clue is to hit reset to get to BASIC instead of trying to boot a disk.  Then do some hires graphics commands...

HGR

HCOLOR=7

HPLOT 0,0 TO 279,0

HPLOT 0,0 TO 279,160

HPLOT 0,0 TO 0,160

HPLOT 0,160 TO 279,0

HPLOT 0,160 TO 279,160

If you see glitches in the hires screen, especially if those glitches change the more commands you execute...  Then suspect memory ot the logic that controls it.

You've twice described screen contents as "garbage".  Share some pictures of those results.  That garbage is directly connected to the problem, so it undoubtedly contains information about the problem.

To illustrate, here are two sample screen caps.  These are just mock-ups I've thrown together, but they're both based on real-world failures...and they illustrate the wealth of information that can be extracted from a picture:

• Sample on left depicts an Apple II that had a bent address pin on the RAM chip at C5.  BASIC worked okay, but stripes of $ characters appeared if you tried to boot a disk.  The arrangement of the corruption in horizontal stripes pointed toward an addressing issue.  The $ characters narrowed the problem to the RAM chip that stored data bit 2 for the first 16K of RAM, which pointed to the chip at C5 but didn't pinpoint which specific pin was bent.
• Sample on right depicts an Apple II that had a bad LS153 at E12, so that address bit A9 was shorted to ground.  Consequently, the part of the ProDOS boot loader that should have been mapped to $2400-$27FF had overwritten screen memory $0400-$07FF.

Boot error with bad A9.png

Try sharing pictures of what "garbage" you got when you try to boot disks, and another picture of what "garbage" appears after typing the HGR command.  If they aren't exactly the same, then the differences could be very informative!

Ooo...that'll take some work to interpret.  A few (unhelpful?) first thoughts...

• Both pictures show an unusual bullet-like ● character near the bottom of the screen, which I don't recognize from the Apple II character set (unless the computer is a J-Plus).   Is this computer using an upgraded character-generator?  (eg: Videx lowercase ROM)
• The first 25 bytes of HGR screen (top left) are nonzero bytes that differ from the rest of the screen contents.  Perhaps it's not a coincidence that when the HGR command attempts to clear the screen it the uses byte 26 in the zero-page (hex address $001A) as a pointer to the screen memory.  Speculation: let's suppose there's an address-generation conflict between those two memory regions, which might cause it to destroy its zero-page pointer at $001A when it tried to clear byte $201A in HGR memory.
• On the text screen, most of the corrupt characters appear in columns that are a multiple of 8.  There are three bad chars in column 8, one bad character each in column 16 and column 24 and column 32, and four bad characters in column 40.  Patterns like that are common with address generation issues, but I don't yet have any guesses what it might mean.

If it was me, my next action would be to use the Monitor to test whether there's some sort of address conflict between HGR memory and the zero page.  Go to the monitor and try these commands to fill 32-bytes of the zero-page memory with all-0-bits and to fill 32-bytes of HGR memory with all-1-bits.  Then use the commands  0000.001F 2000.201f  to display and verify the contents of those memory areas.  If there are any address generation problems then it's likely some of the 0-bits have been clobbered with 1-bits.

Monitor cmds at 0 and 2000.png

Note: Be careful to stay in the address range $0000 through $001F in the zero page memory.  The Monitor uses memory locations $0020 through $004F

In the meantime, I spotted the first meaningful pattern in the screen corruption: most corrupted characters occur in screen memory locations whose binary address has all-1-bits in the lower 3 bits of each address byte.  In other words, the corrupt addresses have six 1-bits in specific positions: xxxxx111xxxxx111

Here's a list of corrupted characters whose memory address fit that pattern.  I've inserted a tick between the high-byte and low-byte of the address to emphasize that the high-byte and low-bye both end with three 1-bits.  Most of the bad chars affect different data-bits, and usually affect more than one data-bit at a time, so it is not likely to be caused by a bad RAM chip.

  $0707   00000111`00000111   @

 $0727   00000111`00100111   ^

 $0797   00000111`10010111   !

 $079F   00000111`10011111   "

 $07A7   00000111`10100111   @

 $074F   00000111`01001111   #

 $07AF   00000111`10101111   '

 $07B7   00000111`10110111   Q

 $07D7   00000111`11010111   A

 $07F7   00000111`11110111   C

There are two additional corrupt characters that don't fit the pattern above, but let's ignore those for the time being.  They could be caused by a secondary side-effect that may resolve itself when the principal failure is fixed.  (eg: cascading failure)

Apple corrupt char addresses.png

To help idenfity all the addresses, I overlaid your HGR photo on top of the text-mode photo to use the pixel stripes as guide lines.  Then I realized that the "unusual bullet-like ● character" in my previous comment was just a reflection from something that's casting a green glow on the monitor bezel.  (There's probably a bright-green LED somewhere nearby.)

This points toward the circuits that translate 16-bit addresses into multiplexed row/column addresses for the DRAM.  But those circuits vary depending on your motherboard revision and choice of memory-select blocks (if your motherboard uses them).  If your motherboard has socketed memory-select blocks, clean their pins like you did with all the socketed ICs and make sure all three blocks are exactly the same type.

What was the memory configuration when you ran those tests?  Do you know which motherboard revision you've got?

Zero page looks ok, but memry addressing in the HGR area not so much.  If you're sure the memory is OK, and it sounds like you've tested it somehow, then it has to be something that's controlling memory.

Ahh...interesting.  In your picture, the text-screen memory corruption happened again at screen addresses $074F and $0727 and $0717.  Once again, all those addresses have the bit pattern xxxxx111`xxxxx111.

And then...surprise!

I recognize those bytes...two instances of 4C, separated by 3 bytes...those are ROM entry points for Applesoft BASIC.

Here's a screen capture.  Notice that the bytes in the ROM at $E000.E015 are exactly the same as your bytes at $2000.2015

Applesoft entry point bytes.png

Assuming your ROM card is working properly, it appears the motherboard is inappropriately activating its own ROM chips at RAM addresses...thereby causing data bus conflicts.

As a simple test, pull all the ROMs from the motherboard and leave those sockets empty.  That will prevent them from conflicting on the data bus, and might get the system functioning.  Keep the ROMs safe -- they're probably good chips.  The fault is probably at F12 or H1.  H1 is the TTL that activates motherboard ROMs in general, and F12 is the chip that chooses which ROM to activate.

Upon tracing through the schematic, my best-guess is that you've got a faulty 74LS08 at motherboard location H1 that's inappropriately activating the motherboard ROMs.  H1 is also involved in multiplexing DRAM row/colum addresses, so it might be causing some of the other symptoms too.

Location H1 is easy to reach, it's right near the power connector, so try swapping in another 74LS08 if you've got a spare.

It will be good news if it is a 74LS08, those are readily available and cheap.  I see them in packs of 20 for about $10 with free prime shipping on Amazon...  Although in this case if the OP doesn't have a stockpile of common 74LS*** chips for testing purposes one of the assortment packs that includes like 2 each of 10 different chips for $10 or even the larger multi-packs might not be a terrible idea.

The following comment doesn't alter my previous suggestions -- I still suggest pulling the six motherboard ROMs or replacing H1.

So this comment is just a tangent.  (ie: if it's not interesting, just skip/ignore it)

The schematic reveals exactly how the ROM at $E000 might have gotten copied into DRAM at $2000.  If pin 3 of H1 is activated erroneously, it will activate motherboard ROM outputs during access to DRAM at addresses $1000 to $3FFF.  And during access to addresses $5000 to $7FFF.  And during access to addresses $8000 to $BFFF.  But DRAM at $0000 to $0FFF will work normally, so the computer will be able to start because the first 4KB of memory is fine.  Zero page, stack, and text screen memory will work.

But here's the fun surprise: if the CPU attempts to write a byte into any of the faulty regions, the motherboard will instead copy a byte of ROM into DRAM at that address.  Why?  ROMs don't have a write cycle, so the erroneously-activated ROM will locate a byte based on bits A0-A10 of the memory address and assert that byte onto the shared data bus.  Meanwhile, the DRAM will read the contents of the shared data bus and store it into memory...effectively transferring a byte directly from ROM into RAM.

The video scanner is not capable of activating the ROM, so it wouldn't be affected by such a fault.  It just reads the DRAM and generates pixels.

If that's what was happening in mochatea396's computer, the HGR command would have started copying ROM into RAM when it tried to clear the screen...until it crashed.  Mochatea396's first photo suggests the HGR command crashed after writing some small number of bytes after $2000.  Mochatea396's last photo suggests it crashed specifically after the monitor tried to print memory at $2016.

Using those assumptions, just as an exercise, I tried to replicate the conditions in mochatea396's HGR photo.  I re-created the background pattern by simulating the 128x128 pattern of 0's and 1's that arise in a typical 4116 DRAM before it's been written to.  And I guessed that the DRAM at C3 has been replaced with a different brand than the others in row C because that would cause the thin-vertical stripes seen in mochatea396's first photo.  Finally, I copied the bytes at $E000 to $E016 into DRAM at $2000 to $2016.  The resulting pixels were strikingly similar to mochatea396's first photo.

Here's a comparison, with mochatea396's photo at top and my replica at bottom.

Apple fault replica.png

This tangent doesn't advance our troubleshooting, but it suggests we're following the right path.

PS: Kudos to softwarejanitor for suggesting that HGR test in the first place!

The HGR trick dates back 40 years to when I used to do a lot of repair work on Apple machines.  It is convenient because it doesn't require any software to be loaded and it gived you a quick visual set of symptoms.

Hmm, I smell a possible trend.  Some of those symptoms resemble the faulty LS138 (H12) in tony359's machine last month, which caused bus conflicts with ROMs on expansion cards.  He later discovered another faulty LS138 (H2) in the same machine, which caused bus conflicts with IO ports on expansion cards.

In comment 14, above,  I had listed H1 and F12 as possible suspects.  For what it's worth, F12 is another LS138.

So tony359 found two bad LS138's in one computer.  Could it be possible that you've got three bad LS138's in one computer?

I can devise some basic tests...

To check the LS138 at H12 (IO SELECT):

Remove all cards except the ROM card in slot 4 and Disk II controller in slot 6.

• Turn on the computer and go to the Monitor.  (RESET to get a BASIC prompt, then CALL-151 to enter the Monitor.)
• In the Monitor, use the command C600L to list the ROM in slot 6 -- the bootstrap ROM of the disk controller.  It should produce a listing like the one shown in this picture, with the instructions listed down the right side.  If the listing doesn't match, then H12 might be faulty.
• Next try listing ROMs from the empty slots.  C100L to list slot 1, C200L to list slot 2, etc.  It should just list random-ish bytes, and the instructions should not match the Disk Controller listing in the aforementioned picture.  If the controller firmware shows up at addresses for other slots than 6, then H12 is faulty.

To check the LS138 at H2 (DEV SELECT):

Same setup as before (ROM card in S4 and controller in S6), go to the Monitor.

• In the monitor, use the command C0C0 to test DEVSEL for slot 4 by switching-off the ROM card.  This command should cause the Monitor to print just "C0C0-" and then freeze.  If it prints a 2-digit byte and continues to accept commands, then H2 is probably faulty.
• Use RESET to re-activate the ROM card and CALL-151 to enter the Monitor again.
• In the monitor, use the long command C089 C099 C0A9 C0B9 C0C9 C0D9 C0F9 to strobe DEVSEL for every slot except slot 6.  (Note: that command should not contain C0E9!)  It should print 7 lines of random-ish bytes and return to the Monitor's * command prompt.  If the disk drive turns on, then H2 is faulty.

To check the LS138 at F12 (ROM SELECT):

Remove the disk controller, just leave the ROM card installed.

• This is a more limited test because the motherboard ROMs have been removed, but F12 also activates on-board IO via pin 15 so we can do a rudimentary test:
• In the monitor, fill the first 32 (hex $20) bytes of RAM will a pattern of FF and 00 bytes as shown below.  Then use the command 0000.001F to print them out and verify that it was preserved as shown.  If the first two lines of FF bytes were replaced with 0D bytes then F12 is faulty.

Apple F12 partial test.png

If the LS138 at F12 is faulty, then my previous guess about H1 was probably wrong -- H1 is probably okay after all.

Especially if there are also faults in the LS138's at H2 and/or H12.  It would be weird to have multiple LS138's fail at the same time, but these three chips could indeed cause all the symptoms you've described!

S.Elliott wrote:

Hmm, I smell a possible trend.  Some of those symptoms resemble the faulty LS138 (H12) in tony359's machine last month, which caused bus conflicts with ROMs on expansion cards.  He later discovered another faulty LS138 (H2) in

Forgive me, I screwed up the IO addresses that affect the ROM card -- I had the card's wiring backward in my head.  (Unintuitively, the ROM card's control port uses a logic-bit where "1=off")

Skip the DEV SELECT tests or use these instructions instead...

To check the LS138 at H2 (DEV SELECT):

Same setup as before (ROM card in S4 and controller in S6), go to the Monitor.

• In the monitor, use the command C0C1 to test DEVSEL for slot 4 by switching-off the ROM card.  This command should cause the Monitor to print just "C0C1-" and then freeze.  If it prints a 2-digit byte and continues to accept commands, then H2 is probably faulty.
• Use RESET to re-activate the ROM card and CALL-151 to enter the Monitor again.
• In the monitor, use the long command C089 C099 C0A9 C0B9 C0D9 C0F9 to strobe DEVSEL for every slot except slot 4 and slot 6.  (Note: that command should not contain C0C9 or C0E9!)  It should print 6 lines of random-ish bytes and return to the Monitor's * command prompt.  If the disk drive turns on, then H2 is faulty.

Maybe it's better to disregard the tests I suggested in the previous two commands, and just use this simpler test below...

As listed in comment 20, your computer has three LS138 chips that could be the cause of your problems, located at positions H2, H12, and F12 on the motherboard.

Since the Apple ROM Card also uses an LS138, it makes sense to use the Apple ROM Card to test those three suspected chips from the broken computer.

• As a dry-run, install the Apple ROM Card in a known-good computer with the ROM card's switch set to enable the ROMs by default.  Verify that the computer can boot a disk, then go to the monitor and try the commands pictured to view the contents of each ROM as shown.
• One-by-one, replace the 74LS138 on the ROM card with one of the 74LS138 chips from the broken computer and repeat the test above.  Do this once each for the chips at H2, H12, and F12.

Apple ROM card 74LS138 tests.png

This method is more likely to pinpoint a faulty LS138 if any of them are bad because you can use a known-good ROM Card in a known-good computer.  For each test the only variable is which 74LS138 you have installed in the Apple ROM Card.

mochatea396 wrote:

Today I swapped out the LS08 at H1  and  still produces thick horizontal  lines  when entering HGR. I replaced the LS138s at both H2 and H12.  The C0C0 command still produces bytes and lets me type. When I enter C400L shouldn’t I see the ROMs on the card listed?  It’s showing nothing like all the other slots that are unpopulated.

Regarding the C0C0 command...

Oopsie, no...that was the mistake I tried to explain in comment 21 -- I got the ROM card's wiring backward in my head.  When you access the ROM card's soft-switch, it uses the low bit of the address to mean 0=enabled, 1=disabled.

For an Apple ROM Card in slot 4, that means the commands to enable or disable are as follows:

C0C0 = enable ROM card  (also  C0C2, C0C4, C0C6, C0C8, C0CA, C0CC, C0CE)

C0C1 = disable ROM card  (also C0C3, C0C5, C0C7, C0C9, C0CB, C0CD, C0CF)

My test instructions assumed your motherboard didn't have any ROMs installed.  If your motherboard has the same ROMs installed as those in the Apple ROM Card, and if the motherboard ROMs are working properly, then there wouldn't be be any visible effect from enabling or disabling the ROM card.

Regarding the C400L command...

No, you can't list any slot firmware for the Apple ROM Card.  Its sole function is to substitute its ROMs in place of the motherboard ROMs, not to function as a peripheral.