Hello all,
I have just recently inherited an Apple II+ Plus from my late godfather. I got it working with little trouble, but then the power supply blew up. I bought a replacement for it from ReativeMicro and just installed it. Since installation I seem to be having trouble with getting the Apple II to read disks. Now when turning on the Apple II, it flashes the screen with random characters for a split second and then just stays at the Apple II screen with the drive spinning, I can get it to boot to BASIC by pressing CTRL+RESET.
I have a feeling it is either a problem with the Apple II board itself or the Disk II interface card. I have tried to swap between the two disk units I have and whatever I have connected to the Disk 1 slot is what is endlessly spinning.
Any help is greatly appreciated!!
Someone will be along soon with more info, but, when a II Plus has a disk interface card installed, it will boot to the Apple II header and await a valid disk. Lots of things could potentially be an issue there, but namely, if the disk is the wrong type it can just spin like that. CTRL+RESET to get to BASIC is also normal with a disk card inserted.
If you want, you could try loading a cassette program from your smartphone using an audio cable hooked to the tape in on the Apple II Plus, to otherwise test the system.
What disk do you have in the drive? Do you know that it is good?
Unfortunatly I know these disks worked fine because I was testing them out before the original power supply blew. Could you link me more instructions to hook up my phone to the tape line in on my Apple II? I would be potentially interested in doing this if I could run a diagnostics on it. This is my first go at anything from this era, as this computer is signifigantly older than I am.
That's pretty neat you are interested in this stuff then. The Apple II was my 1st school computer.
Anyway the very short version is to connect an aux cord and turn the volume up pretty loud, and then issue the LOAD command to basic right after starting the "tape." This site has far more detailed instructions as well as a library of software in audio format.
https://asciiexpress.net/diskserver/readme.html
I hope you are able to get sorted!
I am an electrical test engineer by day so as my dad says "I live and breathe this stuff"
An update on the Apple II: I removed the disk interface card and it booted as normal, I used that website you provided to try to load some of the games that could be fit in RAM to see if they would work and it appears to work! Unfortunately I also discovered the S and D keys do not work unless pressed harder than I would like. Sounds like I will have to find a way to repair the keyboard and the disk interface card?
You can try a little Deonit on the keys, but you may need to replace the keyswitch. Depending on which version of the ][+ keyboard you have that usually isn't too bad. You can find keyswitches on eBay sometimes. There are several different versions.
Since your keys work sometimes, but take extra force, then a little contact cleaner should do the trick. I like "Deoxit D5", but people use lots of things. Spray, rapid press the key a few hundred times (like it is the the fire button on Galaga), repeat. Do this a few times a day or two apart and your keyboard problem is likely to be solved. You will find lots of keyswitch tips on this site if that does not fix it.
It's very very easy to accidentally connect the disk drive connector one-pin off...
If you do so, it blows the analog board on the disk drive and turns it into an automatic disk-erasing device.
You will then have to repair the drive and then reformat all the disks you tried to use. They will be ruined (well, track 0 anyway).
rittwage is correct... it almost always blows the 74LS125 on the Disk ][ Analog Board. It can occasionally blow one of the other chips but rarely. If you have an Apple II with a Disk ][ drive, it is a good idea to keep a couple extra 74LS125 in your parts bin just in case.
Another Update on the Apple II:
Got the new Disk interface card and installed it into Slot 6, unfortunately same issue, the disk makes a little noise and then spins endlessly with no "Boot Cursor", I also installed a new 74LS125 on the Disk II analog board with no difference either. I did see what I think is an error message on boot once, attaching for reference:
5AE6788A-B6C0-49E0-82AE-C12B73206074.jpeg
This is also the random characters that flash when turning on, dont know what this is:
414BC36F-A43F-42BA-A899-371377EB95B3.jpeg
Any other suggestions?
Do you see the same video corruption without any cards istalled? If so, it looks like it might be bad RAM in the lowest bank, otherwise, your problem is related to the disk subsystem. That RAM bank is responsible for the text video screen, among some other important system things. In order to boot properly, the Apple ][ Plus needs good RAM only in the first row closest to the keyboard. My guess it might not actually be bad, but all the inserting and removing of disk controller cards flexed the motherboard and caused poor connections betweem the RAM socket connections and the RAM chip legs. I would start by pulling all the first bank of RAM, looking for corrosion (often has black legs) or bad sockets. I'd spray some Deoxit DL5 or other contact cleaner on the socket and reinsert the RAM chips. Often, just removing and reinserting the RAM chips will solve this problem, even without any contact cleaner. You can also swap RAM from another bank into the lowest bank or try to identify individual RAM chips. Often a bad RAM chip will be noticably hotter to the touch than good RAM. You can search this site for more info on ][ plus RAM problems and solutions, or ask here for more ideas.
Sorry to revive and old thread but I think I have made some progress on this finally.
I managed to do a RAM test and this is what it came back with. Would these memory addresses having a fault not let the computer boot?
At first I would only get the error with 0BFF-00 (FF), but then it started showing other addresses.
IMG_0652.mov
Unfortunately your video is not playable on any of my devices. Could you try clicking the video in your comment above and confirm if are you able to play it?
I was recently studying the Disk II ROMs, and noticed there's an amazing amount of data hidden in that first photo in your comment from 2022.
Admittedly, the photo isn't the problem you're currently investigating...but it's still interesting!
If you cross-reference the Autostart ROM and Disk II boot ROM against the photo, it suggests that your motherboard has a faulty 74LS138 sending an unreliable IO SELECT to slot 6. (H12 or F12) Other causes are possible, like a bad P5 PROM, but we've encountered bad 74LS138 decoders on the forum before...and one user had two of them fail in the same machine!
Anyhow, your photo implies a timeline of events that led to the crash, suggesting the behavior of IO SELECT or the P5 PROM was intermittent/unreliable:
Autostart crash evidence.png
Sorry, this doesn't exactly help with the RAM problem...if there is one. But it's worth considering whether there's a bad LS138 decoder because it would cause data-bus conflicts, which might be (mis)interpreted as a RAM problem.
The Apple motherboard has 74LS138 chips at H2, H12, and F12. They should be 100% interchangeable (if they're working properly) so I suggest swapping those three chips around to verify that the computer behaves the same no matter which chip is in which socket.
If swapping any of those chips causes a noticable change in behavior, one of them is undoubtedly faulty.
Thank you for taking the time to write all of this up for me. I have an IC puller on the way and will be testing out the 74LS138 chips. I also went ahead and uploaded the memory test on YouTube. Hopefully you'll be able to see that there: Video of Memory Test
I am honestly hoping its the 74LS chips because I hadn't thought of that before.
Ok, so an update (and a good one!) I swapped the 74LS138 chips and have something significantly more repeatable. Now when I start up the Apple II with a disk in it, a couple seconds go by and I get an error similar to the one that originally appeared back in 2022... But this time it's consistently appearing.
I also swapped around some memory and now BASIC seems much more reliable.
Here are some examples of the error. It all seems to be centered around COXX memory addresses. The addresses change without me switching any chips or disks.
IMG_0670.jpeg
IMG_0674.jpeg
IMG_0671.jpeg
IMG_0672.jpeg
Even better, when I run an audio file to the cassette port, this happens now:
IMG_0669.jpeg
That's definitely progress!
The latest batch of errors fall into a simpler pattern, hopefully just a single problem. The test video and the crashes both agree that socket E3 contains a faulty RAM chip...or a missing RAM chip.
So, why did disks seem to crash at $C0XX? Probably because the memory region from $8000 to $BFFF was affected by the faulty RAM chip in such a way that it corrupted any code loaded in that memory. Any calls to code in that range wouldn't work and wouldn't return, so the program counter would just keep advancing until it got beyond the bad RAM addresses, started reading from motherboard IO addresses at $C0XX, and got a 00 byte which the processor interpreted as "break".
Is there a RAM chip in socket E3? Do you have any spare 16K RAM chips?
That was the issue!! It works now!! Thank you so much for your help
I suggest running this BASIC-based memory test as a final measure.
It's not fast, but it's really effective at finding RAM issues missed by pattern-fill tests like the original //e diagnostics, Locksmith, and Sather's monitor command-line test.
What's your issue with Sather's monitor mem test? That's been my go-to for a long time and has not yet let me down. I admit, I use this too much and can enter it on a any keyboard wihout caps (which most of mine are)!
A surprising limitation of all those tests, including Sather's, is that they can't detect any address-related problems at all. In fact, Sather's test only requires each RAM socket to reproduce the last single bit that was written into it. It writes all-1-bits, then verifies all-1-bits. It writes all-0-bits, then verifies all-0-bits. Sather's test would even pass reliably if a RAM chip internally shorted pins 4, 5, 6, 7, 10, 11, 12, and 13 to ground.
Luckily, real-world RAM chips don't cunningly hide their faults like that!
But in the real world, you can get a RAM chip with one bent address pin that isn't connecting to the socket. Such a problem does pass Sather's test because the chip is perfectly capable of storing all-0-bits and all-1-bits, it's just not storing all of them in distinctly-correct addresses. Likewise, a faulty LS153 or LS139 on an Apple motherboard will cause memory corruption that won't be detected by Sather's test.
The computer being discussed already had one faulty TTL, so it warranted a memory test that can detect addressing problems or faulty support TTLs.