Currently looking at a //e mobo that doesn't want to boot from a disk. I've tried both Disk II and DuoDisk controllers and drives (both work on "good" //e) so I think there's a mobo problem and just started digging into that. But I've got no knowledge of how the mobo factors into the boot process (other than expecting it easily could)
I pulled and verified the CD and EF ROMs are fine. I can't comment on RAM because I haven't been able to get anything to load. The asciiexpress.net loader I thought could load app to RAM and run, but the "non-format" version appears to be loading the disk writer which does crash so I'm expecting that's because of some disk error. I checked the signals on the drive controller and what I've noticed is the head calibration sequencing of O0, O1, O2, O3 is happening and after the period of that sequence O0 does go high and it looks like there's data being read from the disk. AFAIK the sequencing of pulsing the stepper for calibration is a ROM function and ROMs verified. So where should I look next?
I think the SAMS book IDs 4 suspect but I didn't start probing the board drive board volatages, the ICs would be my firs suspects. I think two are the bi-directional data muxes and don't have an easy to check those. I did start wiring up an arduino so I can write some tests for the ICs. I've done this testing manually after plugging in my TJBoldt ProDOS cards backwards and frying a 74245 but that's a story for another day.... I think it's best to automate logic tests if I'm needing to do that again.
I've attached the logic capture, please note O3 is correct, the lead had just come loose and that's why it's flat it was working correctly.
As I understand you also have Terrance Boldt’s ProDOS card that boots fine? In order to test the RAM, why don’t you write the Apple ][ RAM Test Utility v.1.4 to it?
Take a look here to be able to test the RAM without any disk nor software.
Thanks, yes that is correct, and this is one of the projects I'm currently researching. I've never created the binary for the eeprom and it's on my list to do today.
I did try to use asciiexpress.net to transfer the file using the cassette port but that failed. I had been told in the past there's a way to just transfer the program to ram but I don't think that's correct. AE.net appears to need the disk writer loaded to write a disk. Unless I'm missing something the folks in the FB A2Enthusiast group were wrong on that...
Thanks, it ran withtout printing an error but did break back to the monitor prompt after what I'm guessing was a single pass and I did include the space after 34:14 but that didn't run forever. I may try again later (I so miss being able to up-arrow to trace back through command history!)
RAM Result sm.PNG
What version of the card do you have? (It's written on the botton right.)
So I ran the RAM test a few more times and once (and only once) I got an error at C00-00 (FF) which means the verify expected to match FF but got 00 if memory serves. So a write may have been missed. Ok but strange.
I then entered and ran the test two more times (each time adding the space after the text locatoin address (34:14) and in those runs the test exits to the monitor with the screen still white so the 265:00 N 266<265.BFFEM didn't appear to run. Interesting... I learned writting machine code (hex value not instruction labels) but I've also written hex values for decades so I write my 0 as 00 when entering hex values... that's just how I learned. It occured to me maybe the monitor interpreter isn't able to decode 00 correctly?!?! I tried again, this time entering a decimal 0 and not the hex 00 for the second write to 265, 265:0 and that runs without breaking. Wow, proof it's been too long! Now I'm trying to recall how I'd enter a break in the monitor, I'll now need to investigage what happens if you use 00 instead of 0 when adding a break instruction.
All that to say, I think the memory is fine. if not... it's timing, heat or power thing. The supply is good as it's been reworked and this EE used caps that actually match the originals correctly, not ones from a kit. I have total confidence the supply has nice stable output. So still looking at the ICs on the board as the most likely suspect...
It's the latest 1.4 card and I just updated one of skate323k137's utility images to include the RAM test and as expected the RAM (including 80 col's 64K) checks out good. I'm making progress. =)
I grabbed an Arduino and wired up a breadboard to test the 7400 logic chips, I wrote tests for most of what I think I'll need (04, 05, 08, 32, 74, 86, 153,) I'm thinking it may be worthwile to just start pulling logic from the motherboard to see if something is bad.
Looking at the SAMS book I'll check the CPU but given the ProDOS card works... I'm not sure it's the CPU. The other thing that's bothering me is that book is written to troubleshoot the drive and since the Disk II and DuoDisk which aren't working in this computer work fine in another I think it's safe to assume it's not the drives or their controllers... where to look on the motherboard is what I need to figure out. I'll put a scope on the voltages in the morning becase I'm thinking either something has shorted to ground or pulling one of the voltages low even though I'm pretty sure I checked those already...
Is theres a similar book to the SAMS disk book where values for component pins are listed? That could help.
Was it this motherboard to which you plugged the ProDOS card backwards or was it another one? And if it was this one, did you test whether it can boot from a disk prior to that, or was it only after?
Absolutely. Usually 0 and 00 are the same but not in that particular case. You have to type the instructions exactly as they appear in my message. The extra 0 will break the test because of the length :-)
Great question! But no that was my //e and this is someone else //e that I'm trying to help them with. If memory serves what I thought happened with the reversed card was 12V is put on the 5V line which should/could kill any IC with a path to ground but I didn't look at chip circuits to find how current would flow. I suspect that -5 and -12V on the address lines was also not great but I walked away thinking the damage would be only to the card. That could be totally wrong, but AFAIK everything still worked when the card was removed. On the card, everthing checked out except for a single 245 (card in/out) which was replaced, I added sockets for all chips and a label to indicate which side faces the keyboard!
This system under test, I've only seen boot from the prodos card and the games function the same as my unenhanced //e.
LOL that is a funny behavior! I acutally just read the instructions you posted and after understanding the code went to the computer and worte it myself. I've spent years in the monitor and understand what's happening. I think it's a brilliantly simple piece of code! I also tried to modify and test the exteneded 64K but eventually gave up understanding it's more usefult to understand how to modify the prodos card binary.I'm now curious what happens if trying to clear to any value <16 using a leading zero nibble. Will it clear to 0 then treat the lower nibble as an instruction? I don't remeber. If so, most values should just modify A... although if run enough 08 may eventually corrupt something and I don't remember with undefined values do on the 02. Curiousity may get the best of this cat....
I grabbed the scope to check voltages and here's what I'm seeing:
I think 5V is >4.5V should be good.
There's a slight dip on 12V at the controller during stays above 11.4V and I expect that's just the driver motor spinning up.
I think I can also rule out power...
You've tried different slots I presume?
Correct, problem presented on S6, I've been doing testing on S5 and also tried with the ProDOS card in S6 to test directly with prodos.
Have you tried not booting from the floppy, but just trying to access it from ProDOS? For example you could format a ProDOS diskette using your good Apple IIe and copy some files to it. Then on the Apple IIe under test put the ProDOS card in slot 6 and the Disk ][ Controller in slot 5. As soon as the ProDOS card boots, hit 5 and see if you can see the files on the diskette. You could also load CopyIIPlus from the ProDOS card, select DISK MAP, choose Slot 5 Drive 1 and see what happens. Finally, you could also attempt to format the diskette from CopyIIPlus.
Thanks, yes and I'm surprised I forgot to mention that!
You and I share a similar approach to troubleshooting! Here's what I had done... and basically what you said, s5 5.25 disk II, S6 Prodos card
Booted, launched CII+ 8.4
Init a blank disk DOS, verify, zero errors
Init disk to ProDos, asked if I wasnted to erase volume with data, said yes, provided volume name and it formatted, verified. Zero Errors
Verify - Drive Speed: 299.6-299.9 which just basically verified the strobe check done previously.
1) when the drive calibrates the head my video flaked out a bit, but the connector (I belive is busted so without fixing first I think this can be explained as loose connection) I may hit the center pin with solder to eliminate that... or maybe not.
2) As found with my IIe the drive is fine, so there's got to be something in the boot sequence that isn't happening. (e.g. track read not getting detected so head doesn't move to next track.) AFAIK the drive and controller are doing exactly what they should. The RAM still looks solid, the CPU also seems to be behaving correctly (Games and CopyII+ working).
3) I did not have the scope on the power lines when doing this testing, I may hook back to confirm the drive calibration isn't pulling something too low. The logic on Read/Write data line did look correct although I was using the Analog Discovery Waveform and not the Salaea Logic which I find is easier to scrub through the signals.
It may be time to investigate how the ROM detects a track is read, it really seems like that's not working. CopyII+ doesn't have a problem but I suspect that's manually reading sectors and then moving to the next track. It's been decades since I looked at the beneith book, but it may be time to dust it off and see if it's got suggestions. I didn't check the video ROM but expect there's nothing in there which would be affecting the boot sequence. Is that a bad assumption?
So I've recently been troubleshooting some other disk thing and and a WTF momement where things just started working (was a duodisk thing on different computer) and then things just started working.After finding the Beneath book on archive and reading the boot stages I decided to see if anything was loading to $800 with Dos 3.3.... drive still in slot 5 with Prodos card in 6 and told the prodos app to book 5,1 and guess what happened... It booted just fine! I'm totally floored but need to eat dinner so I'll likely dig into this later tonight. Frustrating for sure!
Update #2, almost couldn't wait until finished eating dinner to take another look. This time, I went back to the computer inspector disk and booted with the drive controller in slot 5, it starts to load but after the graphic comes up the screen goes black. Moved to S6 and found the same behavior. So this is no fun... I may go back to the basics... pull every IC, clean the pins and reinstall. This will not be fun but should rule out another suspect.
Hmm, I am not sure. On my Apple IIe only the +12V dips while it's booting from floppy, the +5V stays solid: https://youtu.be/3YKKY5gfDac
The yellow channel is connected to pin 19 of the second disk connector on the disk controller (+12V rail) and the blue is on pin 11 (+5V rail).
Thanks that's interesting, my 12V shows something similar. I think the .5 drop on 5V is close to what would be acceptable. I'm sure about the supply so I may have to start probing the board looking for where it's dropping but honestly I've stared at the schematic for hours trying to find a good suspect or three but without something like the values provided in the SAMS book I'll be probing blind cuz I doubt anything will be super obvious.How do you like your Rygol scope? I've been thinking about the MSO1104 for the addition of the logic.
I really like it. I bought it almost 10 years ago because it was the 70MHz version that could be hacked and unlocked to 200 MHz, which I did, but I kept it because it turned out to be an a pretty good oscilloscope. The fan is a little loud though.
On topic: also consider RF interference as being the cause. Last year I lost a couple of good hours trying to figure what kind of Voodoo magic was causing a perfectly working floppy drive in another machine not to boot. It turned out to be simply being too close to my unshielded Sony CRT TV: https://www.applefritter.com/comment/99080#comment-99080
Yeah, I think the early unshielded computer speakers caused more problems but affecting the display rather than the other way around. It's interesting that you said this too because the problem //e is one of the early ones with the braided mesh on the lid/case back but, I don't totally remember what the problem was that was fixed with the braid but suspect it was a ][/ ][+ problem that was fixed in the //e design and after being vetted by the early //e owners that shielding got pulled. My first //e was one of the first rev-B boards and I hated that case (mostly cuz of the lid clips).
I don't think this is noise but can ues "clean" AC and thow this inside a cage... but I think I'll check give the mobo caps a quick check first to make sure they're filtering correctly.