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

27 posts / 0 new
Last post
Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Apple ii plus boots to Apple ii screen but won’t load disks

Hello group,

I have an Apple ii plus that boots to an Apple II screen and cursor but when I try to load and disks I get garbage on the screen. It will execute a small basic program I type in fine. I know one of the 6 ROMs is bad so I’m booting it off a ROM card and I tested the romcard on another system and the ROMs on the card are all good. I pulled all the logic chips cleaned and tested each one and they were all good.  There was corrosion on several pins on the LS32 socket and one of the pins (the ground) was so weak it broke. I removed the socket cleaned everything and installed a new socket and IC. All traces show good continuity from the IC leg when installed to the other end of the trace. Still won’t read disks. I’ve checked all the ram and they are good. I swapped the processor, no change. I’ve moved the romcard and the disk controller card to different slots and no change. 

Any suggestions or ideas?

Thanks

Randy

Offline
Last seen: 2 months 1 day ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
This sort of symptom is often

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.

 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Thanks for replying. I’ll run

Thanks for replying. I’ll run those commands today and post my results. 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
I ran those commands on a

I ran those commands on a functioning system first just to see what I should be looking at as I’ve never used them before. On the system with issues, it didn’t even like the “HGR”. Garbage, then locked up.  Which logic should I be looking at. I tested them all on a minipro but that doesn’t guarantee anything. The I know the ram are good and I even moved complete banks around several times. Hopefully this is getting narrowed down.

Thanks again for the help

 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Get some pictures!

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.

 

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!

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Here are 2 pictures. The one

Here are 2 pictures. The one consuming most of the screen is when I enter "HGR", the second is when I PR#6 a system  master disk.

 

 

 

 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Hmm. Working on ideas...

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.

 

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

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Thanks for your help. I’ll

Thanks for your help. I’ll try those monitor commands this evening when I get home and I’ll post a picture of my results.  Also, I’m not using any type of special character generator.  Nothing special just your everyday ii plus. 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
And the first pattern emerges...wait, what??

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)

 

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?

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
And the results are in...

And the results are in...

 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
I didn’t answer 2 of your
Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
I didn’t answer 2 of your
Offline
Last seen: 2 months 1 day ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
Zero page looks ok, but memry

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.

 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Ahh...interesting.  In your

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

 

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.

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Best-guess for now: a bad 74LS08 at H1

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.

Offline
Last seen: 2 months 1 day ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
It will be good news if it is

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.

 

 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Please forgive a few frivolous observations...

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.

 

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!

Offline
Last seen: 2 months 1 day ago
Joined: Jul 5 2018 - 09:44
Posts: 2587
The HGR trick dates back 40

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.

 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
I did some testing last night

I did some testing last night. I retested all the RAM . As I did before, I removed them all and repopulated another system wih them and the system boots fine.  I booted a diagnostics disk with and without the romcard in and all RAM pass. I tested the romcard as well. All still good. Ran the HGR test  and no issues. I put everything back in the cranky system, AND removed all the ROMs off the motherboard as was suggested.  It boots to an Apple II screen and prompt like before, now when I PR#6, the drive just spins,  nothing but the Apple II on the screen, and now when I type HGR it gives me a "syntax error". Also worth mentioning,  With the romcard in S4 and the controller card in S6 (tried S7 aslso, different controller cards and drives) I get a spinning drive. I put a voltage testing card in S2 and boot, now the screen fills completely with random characters mostly inverted. (notice I refrained from the word "junk"). I take the voltage card out (doesn't matter what type of card I use) and it will still show the random characters until I remove the disk controller card and reinstall it. Then it goes back to just spinning the drive on boot. I carefully looked under high magnification inside all the card readers and they're clean of debris and I don't see any damage. The only thing I haven't done yet is swap the ROMs I removed from the motherboard onto the working system.

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Oh ho! Could it be another batch of failing LS138's?

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.

 

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's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
So sorry!
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.

 

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Better solution, use the ROM Card to test those LS138 chips

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.

 

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.

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Thanks for all those tests.

Thanks for all those tests. Ill keep those on file for future use.  I did have the roms back on the motherboard. I forgot I put them back on last night basically so they didnt get lost or damaged. But the romcard was active during testing. I believe I ran all the tests. I noticed occasionally when I install a drive controller in S6, the computer doesnt recognice it. Boots like the card isnt in. I remove it and re-install it, then it works. Everything looked clean.  but I went though what you gave me and here's the results. I also noticed when I entered C400L with the romcard in for the test for that slot showed up empty. Maybe I used that command after I used the one to turn the romcard off. One of the pics shows the S4. (i've got to put something over that green led, it's misleading)

 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Today I swapped out the LS08

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.

S.Elliott's picture
Offline
Last seen: 12 hours 3 min ago
Joined: Jun 23 2022 - 16:26
Posts: 240
Apologies for all my errors...
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.

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
Much continued testing last

Much continued testing last night and I’m embarrassed to say there’s a problem with the rom card. Not the EPROMs on it but the card itself. I tested this card on another system and I know it was good. I thought something was odd when it wouldn’t boot off the rom card when the motherboard ROMs were out. I tried a different rom card and it booted with no ROMs. I populated the working rom card with the EPROMs from the rom card I was using and it still boots fine. So it was the card itself. I even swapped the 5 logic chips off the good card, still bad. Running the diagnostic disk with the working card and testing the ram and the rom shows all good. I greatly appreciate all you’ve done for me and all those commands you shows me won’t go to waste. I’ve written them all down in a ledger for future use. But I assure you that card was tested in another system, it must have failed at some point during this testing. 

Offline
Last seen: 1 month 4 weeks ago
Joined: Apr 23 2022 - 18:41
Posts: 103
It appears the fault with the

It appears the fault with the romcard is the switch. Choppy readings on the pins with the switch activating the card. (Up position). Ohm readings fluctuate between 29 and as high as 104. I removed it from the board and I’m going to replace it. 

Log in or register to post comments