Jump to content

Nezgar

+AtariAge Subscriber
  • Content Count

    3,202
  • Joined

  • Last visited

Everything posted by Nezgar

  1. First order of business.... Swap one end of the two resistors on R110/R111 to swap the base 64K U13-and extended 64K (U26-U33). The machine may then boot up OK if the extended RAM is OK (now being used as base RAM) Otherwise if you either buy a SysCheck 2.2 (which has a memory test OS ROM as one of the selectable OS's) or socket your OS ROM and temporarily replace it with Shoestring's memory tester, you can find out which base RAM chips are specifically at fault. Although the general recommendation with "Mt" brand chips is to replace them all - they are a very common failure point in XE's. Others will likely eventually fail even if you replace some individual bad ones...
  2. Hang on folks, I'm not convinced that @kbj's stepper is the problem yet. Process of elimination is pointing to the FDC socket or something related to it at this time. Here is the troubleshooting thread:
  3. Oh the feeling of hastily putting in an 2732 EPROM backwards in a 1050 and it actually makes a flash in the EPROM's glass window when you turn it on.... Couldn't be more painfully obvious that I toasted the EPROM!
  4. @kheller2 Yes, you missed that I tested that in post #30. The POST succeeds in my drive with stepper detached, as long as head is positioned at track 0. It also succeeds if the track 0 sensor is disconnected at J10, making it think the head is always at track 0. Awesome, thanks for digging out that list. Interesting - so, since we confirmed his drive ALWAYS does the 2 second on/off regardless of head position (even with J10 disconnected) it must be failing at the FDC test. This also corroborates my process of elimination that pointed at the WDC in post #53. Failing at the FDC check would also explain why the head never pulls back when not at track 0. Since @kbj has tested known good FDC chips in this drive, it would suggest a connection issue with the socket, or possibly bad solder point, trace or other nearby component.
  5. Sounds like symptoms of a machine that has been subjected to a commodore 64 power supply... Could be multiple IC's blown out from the overvolt+AC potentially subjected. I see your OS ROM is already socketed - pop it out and see if the voltage scenario improves. Then next desoldering & socketing the RAM. Then proceed to the other main IC's. Measure voltage after each is removed. If you measure +5V with the power ON, then you know whatever you removed last was the last short-circuited IC. (There could have been others, so test replacing things one at a time)
  6. I'm not in the market for one of these myself, but maybe others would be... Personally the CX40 is my most disliked joystick. I grew up on WICO. How much cheaper is a place like JLC? I recently put in a restock order into OSH park for some other PCB's, but it was easier to just click re-order than research and start from scratch a the time with a new fab.
  7. Some further testing with a 1050 here produced the following findings: powering up without a 6532 present results in continuous motor-on powering up without a 279x controller present results in the 2 second motor on/off pattern powering up without CPU or 6810 present = completely unresponsive So @kbj based on your current symptoms of "always 2 second on/off pattern," I would prioritize your efforts on the WDC controller socket first.
  8. We have eliminated the stepper from the equation, so I guess there still could be an issue there - but I have a drive apart here with J15 + J10 disconnected and it powers up with a happy 1 second motor spin that I'm referencing against. If your stepper is bad, we can't test it for now because we know now there's something else up with your motherboard logic that needs to be sorted out first. There's RAM in both the 6810 and 6532 that could be at fault. (or maybe some of the data/address line pins are not making good contact, causing them to appear bad) I'd have to review the 1050 source listing to get some more ideas of conditions that can cause it to go to that failure mode.
  9. Wow, so confirmed not stepper, confirmed not T0 sensor. Something else thats triggering the power on self-test failure conditions! 🧠 🤔 Since you indicated cleaning the 6532 improved the situation, maybe we still have a situation with bad IC contacts in sockets. The original sockets are only single wipe and prone to corrosion - maybe something to start planning replacing the sockets. You could temporarily place the IC's machine sockets, then stack those into the existing sockets to see if that improves things (maybe better conductivity etc)...
  10. I would hope there is no movement with J15 disconnected. That should be impossible. So does it ALWAYS do the 2sec on / off thing no matter where the head is positioned? (track 0 / elsewhere) If so, that points to a faulty track 0 sensor. (always registering NOT at track 0) To confirm: Disconnect J10. (The second-furthest back jumper block at the back left of the drive) This will trick it to think it's "always" at track 0. With that disconnected, see if the drive now powers up with motor on and spindown after 1 second instead of the 2sec on / off thing.
  11. I meant move the head to track 0 *before* switching on the drive.... In a good drive that should produce 1 second of disk rotating motor time, then off. Is your disk spinning motor even turning anymore? With the head not at track 0 when switched on, with J15 disconnected, expected behaviour is the disk spinning motor to loop 2s on / 2s off. Before you had it doing 2s on/2s off somehow?
  12. And what about if switched on while manually moved to track 0? And also how about both conditions with J15 disconnected?
  13. Are you sure your probes were making contact to the terminals? That's the only explanation I can see while also being "in spec" when plugged back into the motherboard... (well... other than the stepper being FUBARed of course heh) I had to stick my multimeter probes in from the top of the connector, where the wires lead out to the motor to make contact...
  14. Sorry I just want to clarify here - I measured the connectors on the plug of the wires that lead to the motor itself, while it was disconnected from the motherboard. Not measuring the pins on the motherboard PCB. If your measurements of of the motor directly are 30.4-31.76 as you wrote, then I think your stepper is OK, and we should continue to focus on the tests to confirm if the track 0 sensor is working... (powerup + spindown after 1 second when manually positioned at track 0, and powerup + 2s on/2s off motor cycling when manually positioned away from track 0) Also - does your stepper move freely if moved manually when the drive is powered off? How about while the drive motor is on?
  15. Please describe your measurements compared against mine below, which has a discrepancy? J15 pins are in this order: Yellow Brown Orange Black Red (+12V) Red (+12V) I measured the following: Individual coils: Red pin 6 to Yellow pin 1 - 32Ω Red pin 5 to Brown pin 2 - 32Ω Red pin 6 to Orange pin 3 - 32Ω Red pin 5 to Black pin 4 - 32Ω And combining coils: Yellow to Orange - 64Ω Brown to Black - 64Ω
  16. SIO competing with PBI speeds, whodathunk!
  17. If you type in 2, it will change to 3 if you watch carefully (the minimum order) Shipping is included/free. Even to Canada. (Yay for me!)
  18. I just tested in a 1050 with a stock Rev. L ROM with the stepper disconnected at J15. If the head is positioned at track 0, the drive will power up, spin for 1 second, then spin down. (Great!) If the head is positioned anywhere OTHER than track 0, the drive will fall into the POST failure 2s on/2s off loop. Please also test your drive with J15 disconnected, and powering up with the head manually positioned at track 0 and again with the head positioned elsewhere other than track 0 and report back with your findings. You may actually have a faulty track 0 sensor if you always get 2s on/2s off loop.
  19. I see 38.45 for minimum 3, or 12.82 each. or 76.90 for minimum medium run of 10 (7.69 each) Other pcb fabs may do it cheaper. These boards do have a large surface area.
  20. Also just stumbled across a replacement CX40 PCB design on OSH park for "low profile Alps tactile smd switches" https://oshpark.com/shared_projects/QQRnyHo5
  21. The clicks are at about 200ms intervals when I tapped it out in a tempo finder, so my guess is it's related to the wifi beacon frames transmitted from your AP, which are often in multiples of 100ms, plus a DTIM multiple of 2 as a common default. The DTIM interval allows low-power wifi radios to "sleep" and will "wake up" every 2 beacons for the "Delivery Traffic Indication Message" to see if any traffic is queud for the device.. The random other intermittent clicks may be from other traffic on your wifi network, or broadcasts. How far away is your AP from the Fujinet? Is the audio noise present on the audio-out of the atari, when not running through the monitor? If it is just the DTIM 'wakeup' of the FujiNet, the interference would be from the processor in the FujiNet itself...
  22. I guess it would make sense for a DOS loader, if it loads below that, and then is free for re-use once control is transferred...
  23. Maybe it would work if the file is placed on a SpartaDOS disk and then set with the "BOOT" command? From the SDCS documentation: The DOS loader on the first three sectors of each SpartaDOS 2.x formatted diskette, can load and run files in the same manner as a command file. Normally DOS is loaded, but actually anything could be loaded as long as it avoids the loader memory ($2E00-$3180). <snip> Example BOOT STAR.BIN When this diskette is booted, it will immediately try to load and run the file STAR.BIN. I've made "quick boot" disks for some utilities this way as long as they're single-segment loaders.. Some games, RAM testers, UAV colour/artifact test utility etc worked...
  24. The thing with the Archiver -- unlike most other "enhanced" drives -- is that it's extended commands were not available by default until a special "open code" was sent to the drive, or it was turned on with a special disk in the drive, so it was pretty immune to detection. The code was a 2-byte code unique to each drive, so it would take up to 65,536 attempts to even attempt brute forcing it by software. The happy for instance you had to explicitly set it to "unhappy" to disable the extended commands and track buffering. Regardless, always a good idea to write protect those disks hehe
×
×
  • Create New...