Jump to content

bigmessowires

68000
  • Content Count

    1283
  • 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. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. bigmessowires

    Mac IIci PSU recap advice

    Ooh thanks, I'll check it! If you found IIsi schematics online somewhere, could you share a link?
  13. bigmessowires

    Mac IIci PSU recap advice

    I tried replacing my soft power mod with your circuit exactly: an NPN BJT with 1K pullup and 10K base resistor. The startup from soft power works reliably, but it won't turn off. Here's what I observe on the /PFW signal from the logic board, when I try to shut down: The /PFW signal starts at roughly 2.7V (I don't know why this strange value). Then it goes to 0V for 50 milliseconds, but I think this pulse may be too brief to fully shutdown the ATX supply. After the 50 ms pulse, the voltage jumps up to 1.3V, slowly decays to 0.1V, slowly grows to about 2.9V, then jumps back up to 2.7V. Then I tried adding an additional 10K pulldown resistor for the input signal, and this seems to work. The shape of the /PFW waveform is the same as before, but the overall voltage levels are slightly lower due to the pulldown. This prevents the voltage from creeping back up to the point where the transistor turns back on after shutdown, so it turns off and stays off: So I guess that's success. But I still don't understand why the BJT behaves differently from the FET, or why the voltage creeps up again after shutdown, or why the voltage is a weird value like 2.7V instead of a valid logic value. But assuming this is normal behavior (?), the good news is my IIsi logic board is OK and it's the PSU that I need to address. So I can either recap it and hope that fixes everything, or replace it with a micro ATX supply inside the case, or use it with a standard ATX supply outside the case like I'm doing now.
  14. bigmessowires

    Mac IIci PSU recap advice

    Yes, the IIci works reliably now after adding my patch wire, using the ATX PSU and soft power mod. I spent a long time with the IIsi logic board and a scope, but I couldn't figure out exactly what's wrong with that board and why it turns itself off. However, I'm suspicious that the "soft power mod" doesn't work correctly with the IIsi. What I found was that the IIsi power button is wired directly to the 68HC05 microcontroller on the logic board. Pushing the button grounds an input pin. Then another 68HC05 output pin is wired directly to the /PFW pin on the PSU connector. There are probably other capacitors and components in parallel with these, but I'm certain of these two connections. The 68HC05 is powered from 5V standby power, so it's always on. When the power key or power button is pushed, I observed that /PFW goes high for about 700ms. And when a shutdown is requested through software or the power button is pushed a 2nd time, I observed that /PFW goes low for about 50ms. That all seems good. But when the IIsi is steady-state on, it looks like /PFW just floats, or is somehow driven to an intermediate value around 1-2 volts. That's bad, and it screws up my soft power mod, which is basically just your single-transistor inverter from another thread: The only difference is that I used a MOSFET instead of a BJT, so there's no resistor on the base. I tried it with and without a pulldown resistor for the base (or the gate in the case of MOSFET). If you look at the IIci startup circuit schematic, the symptom I'm seeing could be perfectly explained if diode D6 were missing. That diode holds /PFW high once the main 5V supply is on, even after the startup pulse generated by UE13 is over. But on my IIsi there doesn't seem to be any equivalent to D6, or it's broken, or maybe it's actually located inside the IIsi power supply instead of on the logic board. I tried adding my own external diode to serve the same purpose. It sort of worked: the IIsi would turn on from soft power, and stay on, but when I tried to turn it off, it would turn back on again after a half second. The observed voltage for /PFW also didn't make sense for what I thought I understood about the circuit. It was too low, as if the 68HC05 or something else were actively pulling it low, but only weakly. I gave up at that point, and concluded I just don't understand how this is supposed to work. So in the end, I'm still not sure if my original problem was in the IIsi logic board, or in the IIsi power supply and further compounded by a flaw in my soft power mod with the ATX power supply.
  15. bigmessowires

    Mac IIci PSU recap advice

    Confirmed that R112 was the problem with the IIci. After manually adding and removing a replacement resistor, the IIci would work for a few more on/off cycles, but would eventually stop working again. Confirmed that the trace between R112 and UB13 pin 1 was bad, and patched it with a jumper wire. All seems OK now, but I'll keep testing. I have to decide whether to keep the original PSU, which was likely fine after all, or spend more time mucking with the ATX replacement. Now for part two, the IIsi that's exhibiting the same symptom of turning off immediately after turning on. From a quick glance at the logic board, the IIsi uses a different startup circuit than the IIci, and I couldn't readily identify which parts are involved in startup. I haven't found any IIsi startup schematics either, so I'm not sure where to begin troubleshooting this one. It was recapped a few years ago, but dripping goo from the PSU may have eaten away traces on the logic board. I tried cleaning everything with alcohol, but it didn't change the behavior. I'll welcome any suggestions on where to start with troubleshooting the IIsi startup.
×