Another DIY ProFile emulator

[stepleton]

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.

 

[olePigeon]

This is really cool.  I love seeing these projects.

Would be cool for a FloppyEmu v2 with ProFile support.  Not sure how you'd do that since they used different connectors.  Or did they?

 

[ben68]

Would one of you smart guys build a Raspberry Pi Hat that connects to a Macintosh wiring harness?

 

[stepleton]

@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!

 

[Gorgonops]

Profile interface cards for Apple II-family machines are pretty rare birds (as are functional Lisas and Apple ///s) so I don't really see much market for combining a Floppy emulator with Profile functionality; the FloppyEMU already supports SmartPort and HD20 emulation to do mass storage over the floppy interface, which covers Mac and Apple IIgs/IIc/IIe-with-the-right-card users. I suppose you could recreate and sell duplicates of the Apple II Profile card to expand the user base a bit, but considering how relatively simple it is to build mass-storage-on-a-card devices that fit in an Apple II slot I'm not sure the value proposition is really there.
 

On the other hand, the strategy of using a single-board computer like PocketBeagle powering a floppy emulator seems quite possible to me.

I'm curious, how latency-sensitive is it on the PocketBeagle side to handle the 8-bit parallel communication with the Profile port with Linux as the host OS? (Just scanning the docs it looks like the Beagle has something of an I/O offloading engine to help things along?) The barrier people run into trying to use devices like the Raspberry Pi for tasks like floppy emulation is that without some external glue Linux simply isn't responsive enough to reliably track the serial bitstream with a floppy controller via GPIO bit-banging.
 

Anyway, great job! It's particularly nice that the YouTube video demonstrates the device on a Lisa 1.

 

[stepleton]

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.

 

[Gorgonops]

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...

Hrm. Just ignorantly spitballing, could you get around this problem by using separate input and output pins, IE, define two separate 8-bit groups on the PRU (one for input, the other for output) and alternately use them to drive or listen on the common bus lines based on the state of the PR/-W signal? (Note I'm saying this with no idea if there are enough PRU pins to do the job.) Offhand I don't really see an issue with doing this as long as you don't drive the output line at the same time the host is. (If you were really worried I suppose you could put an 74LS...244, 245, whichever, in front of the output with its OE enable line tied to the PR/-W appropriately.)

 

[stepleton]

@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 :lisa: