Question about disk interface card on apple IIe (not working)

This fallacy happens not only to FLYNC, but also to others who try to revive old Apple II computers.

Still, FLYNC has made an exellent example on how to deal with the problem towards a diagnosis:

- both floppy disk controller cards work in the Apple II plus

- none of the two work in the Apple IIe

Now, based on these facts, the fallacy is to blame the floppy disk controller cards and not the Apple IIe.

My money is on the Apple IIe having a bad RAM (or, worse, a bad MMU), and this does not allow DOS3.3 to be loaded.

The same infamous problem is often seen with the Apple IIc, too, where it typically leads to a "check disk drive" error. And then the desperate user starts to take the Apple IIc apart and mess with the disk drive, damaging it, or blowing up the IWM chip in the process. The sad remains, often with the disk drive latch missing, are then sold on Ebay as "for parts only".

What happens with a bad RAM is this: the firmware in ROM does not really need much functional RAM to start up, and then it looks for the bootstrap PROM of the disk controller card (which we know works). It jumps to this PROM which starts the disk motor and steps the head to track zero, and then reads the first boot sectors which are not regular files, and stores them in RAM. And then jumps into this just loaded code which is supposed to load the rest of the DOS. Which fails miserably if the RAM has wonky / bad bits in any memory location needed for this process.

Part of the problem is, with only 256 bytes of code space in the bootstrap PROM, it was impossible to add checks that what is written into RAM is really there, before jumping right into it.

How to solve the problem ?

You need a RAM test that does not need a floppy disk. If you are lucky, you could load a RAM test via the cassette interface - but I don't know of any such  audio file being readily available.

And then there is the possibility that bad RAM will thwart this attempt, too.

So a better way is to use a RAM test in EPROM, and this RAM test should be written such that it does not need any RAM by itself, to keep it alive. Some stupid RAM tests use subroutines . . . please tell us, Mr. Genius Coder, how this subroutine can ever return to its caller if the stack ($100-$1FF) does not work properly due to a bad RAM ?

OK, now assuming the RAM test code is sound, and would work even with totally bad RAM, the next problem is if the RAM is good enough to allow display of an error message - the Apple II screen buffer also is in RAM, and a bad RAM chip can obscure the message in bad ways.

All these problems have plagued Apple II users since the beginning, and so there were diagnostic cards which had their own hardware to display information about the type and location of any bad IC found. These cards are long gone. They were popular when the Apple II was in its heydays.

The best course of action may be to plug in a suitable EPROM with a RAM test, and hope it can tell you which RAM chip is bad. This is not hopeless, if the screen buffer RAM works well enough, and the bad bits are elsewhere.

- Uncle Bernie

Apple //e has a built-in memory test, just unplug the keyboard cable from the motherboard to run it. Or use Dead Test.

https://github.com/misterblack1/appleII_deadtest

Macintosh_nik wrote:

Apple //e has a built-in memory test, just unplug the keyboard cable from the motherboard to run it.

...

No need to unplug it. Simply holding down both Apple buttons while turning on the machine has the same effect.

FLYNC wrote:

Both cards work in Apple II Plus and easily load DOS 3.3. But in Apple IIe, both cards have the same issue: they start reading the disk but never stop or load DOS.

That could be a symptom of a bad 74LS154, at position C10 on the motherboard.  The LS154 line decoder is supposed to decode IO addresses and activate the one specific device at a time.  When LS154 and LS138 line decoders fail, they sometimes activate multiple devices simultaneously, causing conflicts.

A quick-and-dirty test: turn on the computer, press CTRL+RESET to get to a BASIC prompt, wait for the disk drive to stop spinning, then type "PRINT PEEK(-16375)" and press RETURN.  This just reads motherboard IO via address $C009, which should print the ASCII code of the last keypress (the RETURN key).  On a normally-functioning Apple II, it should just print 13 and return to a BASIC prompt and nothing else should happen.  If the disk drive switches on or if the computer stops responding, then the LS154 at C10 is undoubtedly faulty.

PEEK-16375.png

A more rigorous test is to use these Monitor commands to probe the Disk II controller.

1. Make sure the Disk II controller is installed in slot 6, a disk drive is attached to Drive 1, and the disk drive is empty.  (Remove any diskettes.)
2. At a BASIC prompt, type "CALL-151" and press RETURN.
3. At the monitor prompt, type "C0E9 C0ED I C0EA N C0E3 I C0E8 C0E2 N" and press RETURN
4. It should print several lines of numbers as shown below.  If motherboard and controller are bot working correctly then the three lines printed in inverse text should print exactly the three numbers  00  then  FF  then  7F  as shown below.  In a normally functioning Apple II, it should print all three of those numbers exactly.  (It would be especially suspicious if any of them printed 0D, which could occur if a faulty LS154 is causing a conflict between slot IO and motherboard IO.)

DiskII three echo bytes.png

You may try these commands on your functional Apple II to compare the results from a working system.

NB: That last test works only with the Disk II controller and a 20-pin disk drive.  It probably won't work with an Apple IO Controller or 19-pin UniDisk or DuoDisk drive.

FLYNC wrote:

I did the test with Disk II interface card in slot 6

 

and recive 13

Those results are all good.  The Disk II controller results confirmed that the controller is receiving DEV signals from the motherboard, and the echoed 00-FF-7F bytes confirm that the controller can transmit all bit values in all positions.  The IO Controller result merely confirms that the controller is receiving DEV signals, but doesn't test much more than that.

It looks increasingly likely that Uncle Bernie's first hunch was right, especially upon seeing your photos of MT-branded RAM chips.  MT memory is notoriously unreliable.  (Sigh.)

If you're located in North America, you can buy replacement 64K DRAM chips from retro suppliers like Jameco, Arcade Components, or Unicorn Electronics. 

Or you could install 256K DRAM chips (eg: 41256) if you just happen to have some already.  The Apple //e motherboard can safely use 256K chips, but the extra address pin is ignored so they will only give you 64K of usable memory.