Jump to content


  • Content Count

  • Joined

  • Last visited


Recent Profile Visitors

290 profile views
  1. stepleton

    Another DIY ProFile emulator

    @Gorgonops This would be an easy option for the BeagleBone Black, which has a lot more of the PRU lines connected to its expansion headers. For the PocketBeagle, you could definitely swing it, but it'd be tighter. (You get 14 lines that can run in either direction, six that can be inputs only, and two that can be outputs only---presumably we would allocate some of those six input-only lines to getting input from the data lines, though several other schemes are possible. These lines may not all go to the same PRUs, though---in fact, they don't---so that could be an important hassle.) Other than the line-to-PRU riddle, I guess the main disadvantage at that point is the complexity of the adapter cape; the part count and of course routing it all---more lines mean another level translator of some kind (though for inputs only a voltage divider might be OK). I also wanted the cape to be pretty general, and tying the bus input and output lines together moves toward specialising the cape to hard drive emulation. As it is, the cape commits pretty strongly the other direction---it includes this pattern of pads for surface-mount jumpers that will hopefully allow people to customise it to their needs in certain ways (installing pull-ups, termination, etc.). (All that said, I am considering whether I could ditch the pads and make a task-specific version of the cape that's only two layers instead of four, which would be a significant cost savings for the PCB.) The solution you describe with the 74LSwhatever, meanwhile, is exactly what happens inside the real ProFile
  2. stepleton

    Profile Power Supply Blown Resistor

    Can you use the schematic to identify the value?
  3. stepleton

    Another DIY ProFile emulator

    Thanks! The Apple parallel port protocol is pretty demanding---as Dr. Patrick Schäfer notes in his IDEfile writeup (side note: the emulator would simply not have been possible in the time I had available without all of his hard work and shared info), it's the Apple that "sets the pace" for clocking data to or from the drive, which it can do at rates up to 1MHz. Luckily the PocketBeagle's two PRUs (the real-time I/O coprocessors---little 32-bit RISC CPUs, in fact---built into the TI Sitara line of embedded SoCs) are the secret that makes it all possible. The ProFile emulator has code that runs on the bare metal of both PRUs: one handles moving bytes between the data bus and a dedicated memory region; the other handles the handshake signals and talking to the high level code that runs on the ARM under Linux (which can be as slow as it wants---in fact, it's just a python script!). The PRUs are 95% fantastic. If you know the direction that signal pins will always be, you can toggle them on and off (or listen for level changes) at 200 MHz! More than enough for the parallel port protocol. PRUs are not pipelined and don't really have proper interrupts (you poll), so they are quite predictable. As long as an instruction doesn't need to touch anything outside of the PRU except instruction RAM (so, if you can keep to registers basically---and the signal pins are register-mapped), an instruction takes 5ns, every single time. So latency is something you can know and plan around, and it's small anyway. The missing 5% catch: a PRU can't change the direction of the pins, so you can't use super-fast PRU I/O for bidirectional lines (like the eight data lines on our parallel port). This is a shame. The workaround for me is to have the "data pump" PRU send orders to the "ordinary" Raspberry Pi-like GPIO modules that are also built into the AM335x---which can switch their direction as the PRU dictates. This too seems plenty fast enough for ProFile emulation, but since the PRU is talking to these modules over one of the more general data buses inside the SoC, you could imagine a nightmare scenario where some Linux program goes nutty and uses up all the bus bandwidth by hammering the RAM (I guess by doing it in a way that defeats the ARM's cache?). In this hypothetical, things need to get so bad that the PRU can't cut in and access the GPIO modules in a timely way, and it misses a beat. I don't think this scenario is particularly likely, though, especially since a PocketBeagle pretending to be a ProFile is probably not doing much else. The PRUs are still in control of all the parallel port I/O, and even though they have to share that internal bus, they'll never get interrupted like the ARM does to attend to some Linux housekeeping task. They only have the one job you give them, and unless they have business talking to the ARM (e.g. to tell it to read or write from the disk image), they don't ever wait around to do it.
  4. stepleton

    Another DIY ProFile emulator

    @olePigeon I don't know much about the Apple floppy connector, but glancing online at pinouts, it seems pretty different! The floppy drives seem to use a serial bus (one wire for data in each direction) with 19 pins, while ProFile uses a parallel bus (eight bidirectional lines for data) with 25 pins in total. So a gizmo that does it all may be hard to swing! On the other hand, the strategy of using a single-board computer like PocketBeagle powering a floppy emulator seems quite possible to me. The Floppy Emu does a great job, though, and is dependable and a good value in my book!
  5. Hi folks, As part of a project to see about using cheap single-board computers like BeagleBone Black, Raspberry Pi, and PocketBeagle to substitute for various old computer peripherals and components, I made a palm-sized ProFile hard drive emulator. I put all of the plans and software online and into the public domain, so you can make one of your own if you are OK at surface-mount soldering and want a nice little hobby electronics project. The interesting thing isn't so much the ProFile emulator as the fact that it was pretty easy to make a hardware problem into a software problem, once the issue of converting the single-board computer's 3.3V logic into old-school 5V logic was solved. I did that via a small "cape" circuit board that plugs into a PocketBeagle. The Beagle series of boards in particular have these nifty I/O coprocessors called PRUs that make high-performance bitbanging pretty easy, and I think there are plenty of retrocomputing projects that could take advantage of it. There's a silly video, but the most important links go to the GitHub, of course. For the 3.3V <-> 5V cape: http://github.com/stepleton/cameo And for the ProFile emulator: http://github.com/stepleton/cameo/tree/master/aphid I put a slightly longer post on LisaList as well, but the docs at GitHub have a lot more detail.
  6. 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.
  7. 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
  8. 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.
  9. 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 )
  10. 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.
  11. 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
  12. 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
  13. 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!
  14. 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.
  15. 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