Hello everyone, just found this forum.
I have 2 Apple computers , Apple IIe, and Apple II plus(16kb), in Apple IIe (I/O controller 655-0101-B) and in Apple II plus (Disk II interface card 650-x104-)
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.
So what is possible problem may be ?
Thank you
P.S. In Apple II plus not working 2 key in keyboard "O" and "J" how to fix it too?
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
...
No need to unplug it. Simply holding down both Apple buttons while turning on the machine has the same effect.
Thank you for the answers,
I do not think it is a broken controller )
Today I will try a memory test.
It would be great if someone sent the link for eprom with the test I can flash it to the chip.
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.
CALL-151" and press RETURN.C0E9 C0ED I C0EA N C0E3 I C0E8 C0E2 N" and press RETURN00thenFFthen7Fas 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.