Jump to content


  • Content Count

  • Joined

  • Last visited

About bigmessowires

Profile Information

  • Location
    San Francisco Bay Area, CA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Glad to hear it's working again. I'm still suspicious of your power supply (analog board).
  2. Last comment: I once accidentally rigged up a Floppy EMU connector (without +12 and -12) to a real floppy drive. The behavior was similar to what you described. The drive made a pathetic clunk when first powered on, but otherwise refused to spin.
  3. Hmm, actually I may be wrong about the PWM signal - if that's broken, it could explain why the Floppy Emu works but the real drive doesn't. But if you're seeing a nice-looking periodic signal there, it's probably fine.
  4. JDW asked me to take a look at this thread. If the motherboard boots from the Floppy Emu but not from a real floppy drive, the first place I'd look is the Mac's power supply. Specifically the +12V and -12V supplies. Floppy Emu doesn't use these, but a real floppy drive needs them to spin the disk. If you have another compatible power supply, try swapping it in and see what happens. I think it's mainly the +12V supply that matters, and offhand I don't remember how the -12V supply is used. I know you measured the +12 and -12 pins and they look OK, but those were no-load voltages. The floppy drive motor probably draws a current of something like 1 amp. If the power supply can't handle that anymore, the voltage will drop as soon as there's a substantial load, and the drive won't spin. Problems with the PWM (SPEED) signal should not prevent the drive from spinning, but you would get drive I/O errors. Floppy Emu ignores the PWM signal. Swapping the internal and external drives sounds like a good next step. The only difference between the internal and external floppy connectors should be the /ENABLE pin. To confirm, you can use a multimeter in beep mode to check continuity between all the other corresponding pins on the two connectors. I think there's also some type of passive filter (the Bourns filter) on the external floppy connector, but not the internal one. I'm confused by the evidence here, but IMHO it should be OK to try the "broken" 400K drives with another 512K motherboard to help isolate the problem. If you don't want to risk another 512K board, you could also use a Mac Plus motherboard, which is much more common and easier to find.
  5. bigmessowires

    Mac IIci PSU recap advice

    Here's the conclusion of my Mac IIsi story. I replaced all the electrolytic capacitors in the IIsi's power supply, except for the two big ones (they looked fine and I didn't want to mess with them). The good news is that the PSU no longer smells like stinky fish. The bad news is that I still have the same problems with with PFW that I saw with the ATX power supply. So the PSU recap project was ultimately no help, other than to eliminate the fish smell. Even with the recapped PSU, the computer would either turn off immediately after turning on, or turn off at some random time 30+ seconds after turning on, or turn on and stay on but refuse to turn off. Bolle is probably right that the problem lies with the 68HC05, but I'm tired of screwing around with this machine. So for the PFW signal I added a 5.1K ohm external pulldown, as well as a diode in series with a 1K ohm pullup connected to +5V. With this it seems to reliably turn on, stay on, and turn off from soft power. Obviously it's not a great long-term solution, since something is wrong with the logic board and may get worse in time. The extra parts were stuck into pins in the PDS slot, so I've also lost the ability to use the PDS slot for anything else. And the sound no longer works - it's very quiet and sounds scratchy. Hard to believe this logic board was recapped just a few years ago and was working fine as recently as last year. But then... I thought everything was OK with this work-around, but as I was typing the above paragraphs, I noticed that the hard drive sometimes randomly spins down for a brief moment and the computer freezes, even though the mouse still moves. I'm not sure, but I think the system fan also slows down when this happens. It happened several times in a row while booting from another disk, right at the moment when it tried to mount the main SCSI disk. I'm not sure if it's a problem with the disk, or the logic board and PFW, or the power supply I just recapped, but I'm out of patience and not going to work on this any more. Let us all take a moment of silence for this poor sad IIsi.
  6. The challenge with SDRAM is that typical SDRAM controller logic presents a transaction interface, and doesn't have any fixed or guaranteed address-to-data timing. It's a black box with variable timing depending on what other memory transaction are in progress. That's no good for a streaming framebuffer where you need to be constantly reading out pixel data at some fixed rate, while also interleaving reads and writes from the CPU. To accomplish that, you may need to jettison the canned or wizard-created SDRAM controller and write your own from scratch, which is a decent-sized project all by itself. This was my downfall in my attempts to build a DIY graphics card, years ago. In contrast, doing it with SRAM is trivial. Some FPGA dev boards do have SRAM, such as the Altera DE1 that I used to build Plus Too. But SDRAM is certainly fine too if you can solve the interface challenges easily enough.
  7. If you haven't seen it, here's a great discussion of how a basic NuBus video card works: http://dec8.info/Apple/How_the_Macintosh_II_Nubus_Works_Byte88.pdf If you can get your hands on the "NuBus Monitor" software they describe, it would be a very helpful debugging tool. I was thinking that another advantage of using a CLUT is that it requires less RAM. Up to 800 x 600 x 8-bit will fit into 512KB, while anything in true color requires more than 1 MB RAM. That may not seem important, but I think it could be. The SRAM chips that I've seen top out at 512KB, so you could build a CLUT-based card using SRAM instead of SDRAM, making the memory interface much simpler. I know SDRAM interfaces are a "solved problem" and there are wizards and things to build them for you, but it always hurts my head just thinking about it. In contrast, an SRAM interface would be dirt simple to build and understand and verify that it's correct. Here's an updated version of my earlier code, modified to assume the framebuffer is in external SRAM instead of internal FPGA memory. The CLUT is small and can stay in internal FPGA memory. Hopefully it's clear: // SRAM interface reg [18:0] address; wire [7:0] data; // internal state reg [23:0] clut [0:255]; reg [18:0] pixelCount; // output stream to video converter reg [23:0] output; always @posedge clk begin // get a byte from the framebuffer in SRAM // the pixel count is the SRAM address address = pixelCount; // do a CLUT lookup for the framebuffer byte that was // fetched on the previous clock cycle output = clut[data]; if (pixelCount == 307199) pixelCount = 0; else pixelCount += 1; end´╗┐ Additional minor advantages of the smaller memory requirement are fewer address bits to decode (so fewer I/O pins needed), and the ability to fit the whole address space of the card into the 1 MB slot space of the Mac's 24-bit memory map.
  8. Dlv, I like this idea, and let me know if I can do anything to help. I'm not really worried about NuBus, but I only mentioned using an MCU because I think it could be much simpler than using an FPGA, assuming it's fast enough to work at all. At least in my experience, it's much easier to use a microcontroller than an FPGA. The development experience for an FPGA is more challenging, the tools are complex and confusing, it's difficult to wrap your head around what the Verilog or VHDL is doing, and the simplest operations seem to require 10x more effort and have 100x more bugs. But an FPGA would certainly give you the most flexibility and speed, and as Gorgonops mentioned the MCU might not be fast enough to meet tight timing requirements anyway. You'd have to look at where the critical paths are in a bus transaction, that can't be covered with wait states or something, and determine if the MCU could keep up. An FPGA with integrated ARM would be neat, if you have a plan for the ARM. There are also simple open source soft-core CPUs that you can implement in the FPGA logic, if your FPGA has enough resources. Supporting only true color sounds reasonable if you want to keep things as simple as possible. I think adding a CLUT is only a very small increase in complexity, though. Verilog pseudocode for a 640x480 frame buffer with 307200 pixels: True color: reg [23:0] frameBuffer[0:307199]; reg [18:0] pixelAddr; reg [23:0] output; always @posedge clk begin output = frameBuffer[pixelAddr]; if (pixelAddr == 307199) pixelAddr = 0; else pixelAddr = pixelAddr + 1; end Indexed color: reg [7:0] frameBuffer[0:307199]; reg [23:0] clut[0:255]; reg [18:0] pixelAddr; reg [23:0] output; always @posedge clk begin output = clut[frameBuffer[pixelAddr]]; if (pixelAddr == 307199) pixelAddr = 0; else pixelAddr = pixelAddr + 1; end
  9. Some questions from the uninitiated - what is the basic theory of operation for an unaccelerated NuBus video card? Does the Macintosh ROM already have routines that do pixel-by-pixel line and polygon and text drawing, and it just writes those pixels into a frame buffer whose address is mapped to the NuBus card's address space? NuBus is different from a processor direct slot or hardware mapped directly into memory space, so I guess there must be more to it than that. Once you have a frame buffer in memory on the card, outputting a VGA signal from that is pretty easy and there are a million examples. I don't know anything about HDMI, but I'm guessing that's also a solved problem and it's not anything Mac specific. So basically the challenge is to build a card that sits on the NuBus and speaks NuBus protocol and that presents a region of memory to the CPU to be used as a frame buffer? What kind of device driver software is needed? Is it certain that an FPGA is needed here at all, or could a fast enough microcontroller do the job? I see that NuBus is only 10MHz while inexpensive microcontollers can run at 120MHz+, so it might be possible to handle bus traffic in software. Bbraun did this for his Macintosh SE video card, which is some flavor of STM32 microcontroller connected to the SE PDS, no FPGA needed.
  10. Cool idea, I'll be following this project! I'm a firm believer that you need to crawl before you can walk before you can run. I like the idea of targeting the simplest design possible first, just to get SOMETHING working, even if it's slow or limited. You can always make improvements later. If the initial goals are too lofty, it's easy to get bogged down in complexity, get discouraged, and give up without anything to show for it. At least that's what happens with half my projects.
  11. bigmessowires

    Mac IIci PSU recap advice

    Thanks for the suggestion! The desolder and resolder is something you're doing pretty routinely on your boards to fix power-up problems? I probably won't try that on this IIsi board, because I'm running out of patience with it and I'd be afraid of accidentally making things worse rather than better, but it's a good idea to keep in reserve if I need it. I was able to test my idea of replacing R115 without actually modifying the board, by connecting a diode and 1K resistor between +5V and PFW on the PDS slot. That doesn't actually replace R115, but it puts another resistor in parallel with it, lowering the overall resistance. Though it's not the "right" solution, it works fine with my FET-based soft power circuit and ATX PSU. We'll see what happens with the original PSU once it's recapped.
  12. bigmessowires

    CUDA, EGRET, HC6805 Hacking

    Thanks for the commented disassembly! Is that the whole thing, or just a part? I didn't see anything in there for how CUDA monitors the power button and asserts or de-asserts /PFW to turn on/off the power supply.
  13. bigmessowires

    Mac IIci PSU recap advice

    Probably the 68HC05 wasn't intended to draw more than microamps when the Mac is off, so the series resistors don't really matter. I think I understand the 12V part now - it's basically a simple 5V regulator. So once the PSU turns on and the +12V supply is live, the 68HC05 can draw as much current as it wants (up to about 13 mA by my math). I've poked and prodded this thing 100 different ways, and my conclusion is that something not shown is pulling PFW towards the wrong values. When it should be about 4.4V (pulled up by D3 and R115), I instead see lower numbers like 1.4V or 2.7V. And when it should be 0 after a shutdown, I see it growing up after the shutdown, from 0 to around 1.0V. Two possible explanations: 1. Weakly conductive goo on the logic board has created a weak short-circuit between PFW and some other trace. 2. The 68HC05 output pin for PFW is damaged: when it should be Hi-Z it's actually weakly driving some value about 1 to 2 volts. I'm planning to recap the original PSU from this IIsi, and just hope that everything works. If it doesn't, I'll try replacing R115 with a smaller value resistor like 1K. That should pull up harder against whatever is pulling PFW down during startup. If that still doesn't work, I'll just jumper PFW to 5V standby so the Mac will turn on whenever it's plugged in, and to hell with soft power.
  14. bigmessowires

    Mac IIci PSU recap advice

    Ahh, some logic board schematics are in this collection here: The relevant part for the Mac IIsi startup circuitry is on the page with the ADB stuff: I I see D3 and R115 that Doug mentioned, at the lower-left. But I also see some crazy stuff... the 68HC05 doesn't appear to be powered by 5V standby power as I thought (pin 10 on the PSU connector). The schematic shows a supply symbol that's a triangle with three lines inside subdividing it. And it looks like that funny triangle supply is derived either from the battery, the 5V standby (labeled "power monitor line" here), or from the 12V supply. The 12V supply path at upper-left is the weirdest part. 12V goes through the parallel resistors R172 and R173, then through a couple of diodes to the funny triangle supply and the main 5V supply. I don't understand what's happening there. No matter which path powers the funny triangle supply, it has a resistor in series, if I'm reading this correctly. Why would you ever put a resistor in series with your supply? That would mean the 68HC05 could only draw a tiny amount of current.
  15. bigmessowires

    Mac IIci PSU recap advice

    Thanks, that's good to know, even if it's a little discouraging. And Doug, I was able to verify everything you mentioned: the traces connecting R115 and D3 to the rest of the system are OK, and D3 checks out fine with my multimeter's diode test mode. With the BJT inverter, the 3.3K resistor R115 will be in series with the 10K resistor on the transistor base. Combined with the diode drops from D3 and from the transistor, my math says it should be 3.45V at the point between the two resistors where I was measuring. That's higher than the 2.7V I saw, but not wildly off. But I did some earlier tests with a FET, where there should have been virtually zero current flowing through R115, so the measured voltage should have been 4.4V after the diode drop. I didn't save those graphs, but the actual voltage I measured was around 1.8 to 2.5V. Maybe I should repeat that test. The big question is why /PFW shows that odd behavior after the 50ms low pulse, where it decays down to nearly zero, but then slowly increases again. There must be more RC components in this circuit somewhere that are effecting its behavior.