Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

253 profile views
  1. nyef

    Macintosh II Restoration

    The Mac-II era startup circuit is weird. There's no standing voltage from the PSU, but if you supply +5v (apparently +3.6v is enough?) to one of the pins it powers up. If you then ground that pin, it powers down. The reason why the II has two batteries when one is sufficient to hold the PRAM state and clock is that the second brings the overall voltage up to about 7.2v, and then there's a drop over a couple of diodes to get about 7v. That's enough to charge a fairly chunky capacitor plus run a flip-flop attached to the power button (and ADB lines) to detect a power-up request. If there's not enough oomph in the batteries or if something else is wrong with the circuit, then it won't power up... But if you have an external supply you can supply the startup current to the PSU anyway. Video of jump-starting a Mac II Detailed explanation of the power control circuit
  2. nyef

    Macintosh II Restoration

    Three or four AAA batteries in a holder plus some wire might also do the trick (you'll be at 4.5v or 6v, I don't know how close you need to get to 5v here). Or if you have another machine that uses 5v (say, a PC?) you could bridge the grounds and then tap the 5v from that for a second. Or wire up a 9v to a 7805, or strip one end from a USB cable, or... Anyway, a 5v supply is easy to come by these days.
  3. nyef

    Macintosh II Restoration

    Having my own II-series startup issues (IIfx in my case), I have to ask... have you tried "jumpstarting" the PSU with a separate +5v supply? That's step one, and should tell you if you need to focus on the PSU or the mainboard.
  4. I'm still reading through the sfcircuits article, but one thing that leaps out at me is the complete lack of version numbers for the software examined, or a date for the article itself. This immediately limits its utility because there's no way to tell where it may be out-of-date. On my end, my budget for PCB design software is measured in time, not money: I'm not going to pay for PCB software, but I might consider writing my own if necessary. And given the licensing on Eagle 8, I'm starting with KiCad, as the "least worst" option (of, well, two evaluated). KiCad is... quirky. It definitely feels like open-source software, and clearly wasn't written in English to begin with. The tutorial documentation for version 4.0.x is a decent starting point, but the instructions for how to deal with routing aren't great (I had better luck after watching the video introducing the "push/shove" routing). I still haven't managed to get a "full" autorouter to work, but I'm not convinced that that's a huge loss. Some features are only available if you're using OpenGL or Cairo for rendering, which is a bit WTF. And then there's the rather quick responds to dragging beyond the edge of the canvas (although that might be due to running the entire system in VirtualBox). Overall, after a couple of days of poking about and trying things, I think that better could be done, but that there are limits to how much better can be done in the context of KiCad. It is, however, usable, and I plan to keep using it at least in the short term.
  5. nyef

    Recapping gone wrong

    The first couple of times I recapped something, I used radial caps to replace SMD. It works, more or less, but tends to be ugly. In one case, I simply couldn't find compatible SMD caps, so had to use radials, and then had trouble getting the case closed. I very quickly got tired of buying "capacitor kits" for specific hardware, especially since sometimes they aren't quite right, and moved up to simply stocking a goodly range of capacitor values in common packages. With a little bit of practice, SMD, at least of this vintage, tends to be fairly easy to work with, as long as I can get my iron to the terminals (not always guaranteed with the way some boards are laid out). I've never actually tried solder paste. I know that it supposedly works well with hot air, but does it also work well with an iron? If so, I can absolutely see that simplifying things, simply because you have fewer things to either keep steady or move carefully at the same time.
  6. nyef

    Recapping gone wrong

    Looking at the picture you provided, they both have surface-level traces (easy to expose with a fibreglass pen or craft knife and solder a patch wire to), and both lead to VIAs (typically already exposed, and easy to solder a patch wire to). Or if you're careful, you could even just leave one of the component legs for those radials you're using a bit long and use that instead of a patch wire. Overall, this very much looks rescueable without reference to a circuit diagram or trying to do a pad repair.
  7. For powering up without PRAM batteries, google for "jumpstarting a macintosh ii". Long story short, touch 5v between a specific pin on the power supply connector and ground, and it should wake up. For dealing with the battery leakage... I had best not proffer advice at this time. I still haven't gotten my own IIfx PRAM/capacitor issues completely sorted yet. As far as the case badge goes, putting an IIfx mainboard in an II or IIx case was a sanctioned upgrade path at the time. And for the loose RAM modules, IIfx RAM uses 64 pin modules, and are installed in banks of four. AFAIK, only two other pieces of hardware used RAM modules like this. If they physically fit, they're probably compatible.
  8. nyef

    How does a Mac know which one it is?

    If the VIAs are surface-mount, it might be as simple as lifting a pin and tying it to the 5v supply. If they're socketed DIP, pull it, bend the pin out, put it back in, and solder a bodge wire to 5v. If they're soldered-in DIP, cut the pin and solder a wire to 5v. Or, in all cases, if the pin goes to a trace, cut the trace, then solder the to 5v. Unless the pin is negative-logic, in which case tie it to ground. In all cases, it's a fairly reversible patch, though it may be obvious after the fact that you've done something even if you reverse it. Fairly easy thing to test, provided that pulling the mainboard is easy (and, while it's been a long time since I've had an SE/30, I seem to recall that it is easy).
  9. nyef

    IIfx 16MB SIMMs -- Thanks Doug!

    It'd be nice if 16Mx4 did work, even if such chips still aren't available via Mouser. And https://68kmla.org/forums/index.php?/topic/21519-finally-a-iifx/?p=221669 mentions a prototype involving paired 16Mx4s, a pair of FET bus switches (identified as SN74CBT3244 or similar), and a "five-pin gate" (probably an SN74xx1G series two-input of some sort)... But that they're finicky. Given the theory that the use of fewer chips is causing ringing on the address lines due to reduced load from the chips themselves, I was wondering if a set of fairly stiff pull-downs might help, but this is definitely beyond where I'd trust my intuition. Hrm... 1Mx16 is available. That can be run as 2Mx8, since it has separate "upper" and "lower" CAS pins. Still 8 chips, plus glue, but if it can be made to work then sourcing components becomes straightforward.
  10. nyef

    How does a Mac know which one it is?

    But you can pick out an SE/30 by its video card declaration ROM: That won't change when using a 32-bit clean ROM, and might remain even when there's a second video card in the expansion slot. A lot can probably be determined simply by which address ranges trigger bus faults (thus, don't have associated hardware). Just off the top of my head, I'd expect that to easily distinguish a 128k/512k from a Plus (the SCSI controller). Picking out the Plus from the SE can probably be done by relying on the SE's tighter address decoding (though that's not guaranteed, given the expansion slot). Picking off a SWIM vs. IWM should be straightforward (there's a mode switch, which won't kick over on an IWM). A number of machines may have "built-in NuBus cards", such as the SE/30 video system, that are specific to that model. If I were trying to devise my own function for this, I'd start with a breakdown of hardware (including embedded NuBus ROMs) per machine type, including address mappings, and go from there. If I were trying to figure out what System 7 (or whatever) uses, I'd either be looking to find and disassemble the actual routine that does the detection, trying various changes from "stock" hardware in an emulator to see what the effects are, or both.