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. The Plus Too core is "open source". If you need a specific license, let me know. FYI the core was integrated into the MIST FPGA computer in 2015, and also received some significant bug fixes and additions from Till Harbaum, like a model of the SCSI chip. https://github.com/mist-devel/mist-board/wiki
  2. Replying to a 4-year-old thread for documentation purposes, in case somebody else has the same problem in the future. For the IIGS to communicate with a A9M0106 Apple 3.5" Drive, or any compatible "dumb" 3.5 inch floppy drive, the disk I/O signals HDSEL and EN35 must both be working. Both of these signals come from the VGC chip, not the IWM chip like the other disk signals do. And neither of these signals is used for communication with 5.25 inch drives or Smartport/Unidisk drives. So if your IIGS suddenly won't work with 3.5 inch drives, but works fine with other drives, you probably have a ba
  3. Glad to hear it's working again. I'm still suspicious of your power supply (analog board).
  4. 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.
  5. 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.
  6. 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
  7. 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 rando
  8. 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 its
  9. 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-b
  10. 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 a
  11. 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
  12. 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.
  13. 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 paralle
  14. 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.
  15. 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. A
  • Create New...