Jump to content

stepleton

6502
  • Content count

    52
  • Joined

  • Last visited

2 Followers

Recent Profile Visitors

181 profile views
  1. As of about 3PM CDT this afternoon, there was a nice-looking LC III at Gateway Electronics in St. Louis, on the junk rack at the back of the store. https://photos.app.goo.gl/LkMFVoXK5Q8U5y6o2 Although I didn't turn it on, there were no capacitor or battery problems at first glance. The case looked pretty un-yellowed; there was hardly any dust, even. No monitor or peripherals, just the computer. A decent specimen, if not the most exciting machine. If you're interested and you live in St. Louis, and if someone else hasn't bought it, you could go and pick it up.
  2. stepleton

    Restoring a Lisa widget drive

    An update: I replaced U11 on my Widget controller board, and this has allowed the drive to operate again after about 20 years This result keeps me feeling doubtful that Pin 3 of the Widget power connector ever needs to be powered on a properly functioning drive. Given the two reports on this forum of people needing to power this pin in order to run their Widget, I'm starting to wonder whether U11 just has a tendency to break from time to time. --Tom
  3. stepleton

    Restoring a Lisa widget drive

    Opinion seems to be mixed about this. I too have a Widget that I'm trying to fix, and one of the mysteries involves this pin. I'm of the opinion that you shouldn't need to power it. Indeed, on my one widget that does work, you don't need to---it spins up just fine with nothing connected to that pin. If you look at this schematic, you can learn more about what Pin 3 does. It doesn't look to me (note: a computer programmer by trade, not a hardware engineer ) like it ought to be powered, but I think it makes sense that powering it would work around a potential problem. By my interpretation, Pin 3 is a power sense pin that's meant to be fed back to the power supply. In a working widget, resistor R1 should pull this line up to near +5V. This line is one input to the AND gate in U11, and assuming the other input is also high (which it should be for a drive that isn't plugged into anything, thanks to the pull-up resistor R6), then the AND gate output (called POK) should also be high. People more familiar with Widget than me say that POK has to be high in order for the drive's microcontroller to start up. The existence of R1 suggests that if Pin 3 can't reach +5V on its own (i.e. without external power as in CelGen's diagram), then something is wrong with the circuitry that generates the POK signal. But if that's the case, maybe supplying +5V there externally can "boost" the generation of POK. For instance, maybe U11 is going bad and is pulling the Pin 3 line low---if you look at the 74LS09 datasheet, the schematic for the AND gate inside U11 suggests that you would only need one diode inside to fail for that to happen. If you force pin 3 high with +5V from your PSU, then maybe you are unwittingly implementing a workaround to damage to U11. Anyway, I don't think you really want to power Pin 3, and I'm going to try to fix my own broken Widget without doing that. But I'm still learning about this circuit, and I'll probably know better in a few months. More on this particular mystery can be found on recent LisaList posts.
  4. stepleton

    Restoring a Lisa widget drive

    Here is some more information, but probably not enough for old Walt. I remembered a diagram of the graticule from somewhere, and here it is in Figure 1 of this patent: http://bitsavers.informatik.uni-stuttgart.de/pdf/apple/disk/widget/patents/4707754.pdf On Page 10 you can also find a description of the mechanism, under the heading "Optics Scale". (sorry @mactjaap, none of this is helping you fix this drive of yours, but I hope it's at least interesting )
  5. stepleton

    Restoring a Lisa widget drive

    I'm not sure this is so for the Widget. (as in, I'm literally not certain.) Widget (which uses voice-coil actuation, not a stepper) doesn't use magnetic sensing alone to servo the heads. For coarse positioning, it employs an optical mechanism that scans a glass graticule mounted within the drive. (Word is that this same graticule is responsible for a common Widget failure mode: the glue affixing the glass to the drive fails, and the part winds up going somewhere it isn't meant to be. I assume that in the worst case this includes a bit of glass bouncing all over the inside of the drive housing.) Once roughly positioned onto the track, only then does the drive trim the head location by a small centering offset, which it accomplishes via some kind of magnetic sensing of the track itself. It is possible to seek the heads without performing this fine correction---indeed, for low-level seeks, you have to order the correction on your own. Thus, you might imagine that you could format a completely degaussed platter by doing track-by-track coarse seeks and then formatting a track wherever the heads wind up. The fine offset adjustment should detect this placement and, after coarse seeks back to the track in the future, adjust the heads to the new location. Is this right? A true Widget expert I know (not an amateur like myself) seems to think this is so. I'm in no hurry to try for myself, though, because I also see text like this: (PDF page 137 here) and diagrams like this: (PDF page 8 here) and I wonder whether the Format_Track command is really capable of initialising a track with that "servo data" and that index wedge. I am sure the expert I mentioned is aware of this information, though. I guess we'll find out over time, and who knows, even if the drive really can't format itself in its "stock" configuration, maybe it'll be possible to make a gizmo that interfaces directly with the heads and actuators at the lowest level and formats tracks with everything they need. In the meantime, more information than you probably require for adjusting the optical servo mechanism can be found at the end of this document... unless you happen to be somebody called Walt Webber, who as the last page shows requires even more information.
  6. stepleton

    Announcing NeoWidEx

    I'm glad it's working now! I'm in the middle of assembling one of these: http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidEx.htm Should come in handy for jobs that NeoWidEx can't handle, like my old Widget that doesn't even get far enough along to spin up the motor. --Tom
  7. stepleton

    Howdy! So I have this old Lisa 2/5....

    Here is the forum post I must have paid attention to when I was making my pads: https://groups.google.com/d/msg/lisalist/ki86xMT7gww/-83CpKbf7rcJ Note the warning about Elmer's Glue. pH-neutral adhesive is probably important. If memory serves, I got the Mylar material from one of those emergency space blankets. You can use a party balloon too if you're feeling festive... --Tom
  8. stepleton

    Howdy! So I have this old Lisa 2/5....

    It looks like "conductive/capacitive" text was meant to be a link? Anyway, since the keyboard is a capacitative keyboard, I'm not sure you want a material that's conductive on its surface, since I don't think you want to short the pads? Although if you are talking about the conductive foam that they pack ICs in, it may not be conductive enough to matter. The easiest way will be just to try it---attach a bit of foam to the end of a pen and use it as a stylus on the bare PCB. I actually wound up using this sort of arrangement to type the 24-byte BLU bootstrap program into Service Mode a few years back For me, the hardest part wasn't finding materials and laminating them together. Instead, it was the tedious work of pounding out all of those darn little pads, and I think you have to deal with that no matter what kind of foam you use. Now, maybe my punch wasn't the best. I was using a mallet, too---an arbor press or something similar might have been a lot easier! (For what it's worth, I wound up using a sandwich of metallised mylar film with the nonconductive side out, some kind of HO model railroad trackbed I found recommended on a forum somewhere, and a polystyrene sheet from an art store, all bonded with 3M Super 77. Everything went together in minutes, and I left the sandwich under a heavy book for a day or two to cure. After that---quality time with the mallet and punch. I did two keyboards this way...) I'll give my usual warning about these keyboards---be very careful about the plastic clip on the caps-lock key. If you take it off, there's a chance that a tiny pin and spring in the locking mechanism will come flying out, and you will be lucky if you ever find those again. Good luck!
  9. stepleton

    Howdy! So I have this old Lisa 2/5....

    Consider also checking or even replacing the trimpots on the video board. They are known to go bad occasionally. It's interesting that the yoke coil has been unplugged. Obviously you've still got the 3A CPU ROMs, but what about the video state ROM that gilles mentioned? Since this controls some crucial display timing, I would be a little bit surprised if the screen-mod state ROM were still in place---how would it work without the yoke coil installed?---but I haven't really had any opportunity to experiment with a screen-modded Lisa and don't really know how all of these parts work together. There might be some marking on your video state ROM that would say one way or another. It's the chip on the CPU board at location C6. In this image, it has the part label 341-0229-A, which I assume is the original Apple part. I don't think it will help you fix your Lisa to investigate this, but it might be interesting on its own.
  10. stepleton

    Anyone have a DC42 image of Lisa COBOL

    Thanks for the citation! Here's a scanned PDF online: http://yesterbits.com/media/pubs/STMac/st.mac-1984-may-300dpi.pdf Reading it, I'm not too sure what's going on... But it looks like we can actually find out conclusively. Over in http://bitsavers.informatik.uni-stuttgart.de/bits/Apple/Lisa/macworks/, there are files with names like "MACWORKS SOURCES 1.IMAGE". A peek in there would let us know exactly what the tricks were. But that's a project for another evening
  11. stepleton

    Anyone have a DC42 image of Lisa COBOL

    And hey, at least I can now cite the "source" that led me to believe the wrong thing Here is a Wikipedia page that I swear I did not write: https://en.wikipedia.org/wiki/MacWorks_Plus
  12. stepleton

    Anyone have a DC42 image of Lisa COBOL

    Shows what I know. Got a link?
  13. stepleton

    Anyone have a DC42 image of Lisa COBOL

    Of course, the Lisa could not have emulated a Mac so easily... ...if it couldn't place a copy of the Mac ROM at the exact memory address where the software expected to find it. Luckily, it had an MMU to do the address translation A prior effort to present Lisa and Mac as happy and totally intentional siblings, really, was the marketing term "Lisa technology" (e.g. links below). Either that or it was a subtle hint that the most compelling bits of Lisa had a life---that is, any future at all---outside of the machine itself. http://www.storiesofapple.net/meet-the-apple-32-supermicros.html http://www.computerhistory.org/collections/catalog/102630893
  14. stepleton

    Anyone have a DC42 image of Lisa COBOL

    As soon as we get to see the source, we'll know for sure what's going on! I think it's pretty likely that there is some actual kind of fault recovery underway in some cases, like the stack---as in, the precautionary TST.W causes a real life page fault, the OS handles it, and then the program resumes. (Maybe this could be a kind of one-instruction malloc-me-maybe system call, I guess.) In many other cases, meanwhile, I expect it is the other way---there's no page fault per se, the OS is shuffling segments in and out of RAM on demand. The manual says things like "If the program calls a procedure in a segment not in memory, a segment swap-in request is initiated." It's not really shedding too much light on what's going on, but since a BSR will definitely affect your register state, I can't imagine that they're handling that with a page fault. Anyway... as far as the motive for all this goes, I guess even the source code can't explain that---we'll have to summon John Couch to the forum somehow! But if I had to guess, I would expect that in no small part it goes back to the minicomputer-alumni design culture I was talking about earlier: "Look, see, a serious business computer has an MMU and virtual addressing and paging (and at least a megabyte of RAM, and a modular no-tool-disassembly component design, and baroque infrastructure for software licensing, and COBOL, and...). We were hired away from serious business computer companies, and by golly we are going to make ourselves a serious business computer!" Perhaps if you have this mindset, it becomes easy to add on additional supporting justifications---like, who knows how complicated this GUI stuff is going to be, we'd better design the hardware defensively so we don't let the software folks down...
  15. stepleton

    Anyone have a DC42 image of Lisa COBOL

    I have to admit that I'm mostly taking it on faith that the Lisa is using demand paging (for pete's sake, what on earth could the thing be doing as you stare for seconds at a blank LisaWrite window with the ProFile blinking away furiously ). But the Operating System manual does describe it in section 4.6, starting on page 89 of this PDF. There's only a paragraph, basically. Folks may know this already, but if I understand correctly, while the Lisa engineers understood that the 68000 was not restartable in general, they determined that some instructions were restartable. For that reason, if your program intended to access an area of memory that you didn't know was already prepared for you, you had to try to provoke a page fault first by touching it with one of the "safe" instructions (TST.W was recommended specifically). Procedure calls in particular needed to do this to make sure that the stack would be big enough for the procedure's arguments and variables. If your program didn't test the ice before it tried to stand on it, then it deserved to fall into the lake, I guess. For more details, check out section 6.6.1 of the Workshop Users Guide, or page 110 of this PDF. In light of what other manufacturers were doing to get virtual memory on a 68000 system, having this combined hardware/software approach seems like an elegant kludge, if there is such a thing. (for those who don't click on the last link: let's just have two 68000s---one of them "goes first" and triggers a page fault, then the second one cleans up the mess and puts the first processor back on its feet. I assume without knowing that the second processor was ordinarily running the same program as the first, allowing it to know what the register contents were just prior to the page fault. Well, that's one way to do it.)
×