Jump to content


  • Content Count

  • Joined

  • Last visited


Recent Profile Visitors

472 profile views
  1. I'm nowhere near LA (in fact I'm in the UK), but if you find no other help, I back up Twiggy media for free, provided it is in decent condition (i.e. the oxide layer isn't starting to degrade) and my Lisa feels like it (dependability is not a Twiggy strong suit). This offer extends to everyone, and I would be very pleased if knowledge of this would spread far and wide. Let's save those disks! That said, you are likely to find help closer to home, I expect.
  2. I've just posted a reply to a 2017 thread about repair of a Lisa power supply but maybe I should have messages you firstly. Anyhow, you seem very knowledgeable about Lisas and so wondered if you could answer another question about internal drives. I have two Lisas; one came with a ProFile (sadly not working), and the other came with a widget drive. The latter Lisa does not work (PSU is faulty as per other post) so I wanted to test the widget drive in my other fully working Lisa as I have never had a hard drive so I could load the Lisa OS. I was surprised to see that the spare data and power connectors in the drive bay of my working Lisa are both different to the connections on the widget drive.

    Is there a way to fit the widget drive to the other Lisa?

  3. stepleton

    How interesting is the Lisa?

    I have a tough time relating to wanting to have a square-pixel XL, but it's a significant part of the Lisa story, and to each their own. If I found a machine that had been set up that way by a user in the days of Sun Remarketing, I'd probably have mixed feelings about reverting it to the original configuration, in the same way I'd be conflicted about adding the mod to a stock machine. Doing that would be the choice of the machine's owner, I guess, although I'd encourage them to save all the bits so that they can revert the mod if they want. Either way, for their trouble, this person would achieve the slowest System 7 computer ever made available to consumers. LisaEm is good, and Ray is working on making it better. For now, though, the Workshop compiler doesn't work on it (the compiler crashes and drops you into the debugger), and since making Lisa programs is my main interest in the machine, I have to use a real system at build time for now. Once or twice I've used LisaEm to write code in an emulated Workshop session, saved the source files to a .dc48 image, then loaded the files on the real Lisa with a Floppy Emu for compiling. I haven't tried IDLE much; I should give it a shot someday. For me, another one of the bizarre charms of the Lisa is its actual construction---being able to access most of the low-voltage components (not the speaker or the power button) with no tools is pretty neat, and of course overengineered and wholly unnecessary. Obviously an emulator can't let you experience this in a satisfying way yet. That said, the 32MHz speedup you get with LisaEm is useful, as the Lisa really is underpowered. I had an occasion where I had to make some really complicated LisaDraw drawings with lots of freehand lines, and before long, scrolling was taxing even the sped-up emulator. I don't think it would have been possible to finish the job on a real Lisa, so I was happy to save that for the very last bit, when it was time to print on the colour inkjet.
  4. stepleton

    How interesting is the Lisa?

    I like Lisas a lot. They're strange and fun to hack on---they have a lot of complexity, but virtually all of the parts are through-hole, and most ICs are off-the-shelf 74-series logic. You can understand the computer at a very detailed level if you choose to. Also, compared to its contemporaries, there's a whole lot of computer there for you to understand: a strange homemade MMU, a disk controller powered by its own 650x chip, a video system that can draw pixels from anywhere in RAM, a highly-engineered operating system with all kinds of workstation-like features, funky bespoke hard drives with a funky bespoke protocol, and more. (All the docs on Bitsavers really help you dive deep.) Seeing right into the guts of how all of these things work beats staring and some mysterious black VLSI square on a modern motherboard. There's not much you can understand about those without signing an NDA, and even then, what would be the point? (Counterargument: those folks who made the amazing Previous NeXT emulator have delved pretty deeply into that platform's mystery chips, so anything's possible, but you have to be much more talented than I am!) Anyway, you are largely making your own fun when you start working on Apple Lisa projects. There is just not really much software, so unless you want to build it yourself like some kind of weirdo, you're limited to a software library that was innovative in some ways for its time but is otherwise pretty dry today. If writing your own code floats your boat, though, then great! There's a whole lot that people haven't really done yet, so far as I know (insert tangent here about making new Office System apps with the ToolKit). So I don't agree with @Gorgonops: even if it weren't a technical milestone, it'd still be fun and interesting for the hacking pleasure. Everything is similar enough to the systems that "made it", but just different enough to be odd and interesting. But if you don't like spending an evening poring over ROM listings, for example, then yes, a Lisa is a bit of a museum piece (and a heavy one, too!).
  5. 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
  6. stepleton

    Profile Power Supply Blown Resistor

    Can you use the schematic to identify the value?
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. 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 )
  14. 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.
  15. 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