Daisy Chain Design Vote
Vote for your preferred Floppy Emu daisy chain design option! I’ve been working on this concept for several weeks, and wrote about it here, here, here, and here. I’ve now realized there are two different paths I could follow, with different feature sets and likely costs. For those who are potentially interested in the daisy chain adapter, I’d like to know which option you’d prefer.
Option 1 is what I’ve been discussing all along. It’s an intelligent adapter based on a microcontroller or CPLD, that allows for pretty much any valid combination of Floppy Emu mode and daisy chained drive types. It auto-detects the modes and types, so there’s nothing to configure. It has some LEDs to show the detected types or other debug info. And it also fixes some other minor problems with Floppy Emu daisy chaining like this one. I’m about 90% sure it will work, but there may be weird rare bugs. Retail price will likely be somewhere in the 30’s (very rough guess).
Option 2 is a “dumb” adapter, somewhat similar to the retired Universal Adapter for Floppy Emu Model A. It’s a fixed configuration of a few 7400-series logic chips. It supports the most useful combinations of Floppy Emu mode and daisy chained drive types, but does not support all combinations. Drive types are not auto-detected, and must be manually chosen with a switch. There are no status or debug LED’s. It doesn’t fix the other minor problems. I’m 100% sure it will work. Retail price will likely be somewhere in the 20’s (very rough guess).
| Option 1 | Option 2 | |
| Design | Smart | Dumb |
| Disk Type Detection | Automatic | Manual Switch |
| Configurations | Emu 3.5 with chained 3.5 Emu 3.5 with chained Smartport Emu 3.5 with chained 5.25 Emu Smartport with chained 5.25 Emu 5.25 with chained 5.25 |
Emu 3.5 with chained 3.5 Emu Smartport with chained 5.25 Emu 5.25 with chained 5.25 |
| Status LEDs | Yes | No |
| Minor Fixes | Yes | No |
| Development Time | Slower | Fast |
| Confidence | 90% | 100% |
| Cost | $30’s | $20’s |
For the sake of this discussion, Unidisk 3.5 emulation mode counts as Smartport. Note that neither option 1 nor 2 supports Emu Smartport with chained Smartport.
Option 1 is certainly the most flexible, and has the best cool factor. With a change of firmware, it could even do other cool disk-related things I haven’t dreamed of yet. And I’ve already sunk a lot of time into designing it.
But I can’t escape the feeling that I’ve lost sight of the core purpose and over-engineered a solution. There’s a lot to be said for a keeping-it-simple design, and that’s what option 2 is. Auto-detection is very nice, but is flipping a switch really so bad? Would anybody really miss the two disk configurations this option lacks? Option 2 could be built easily, but option 1 would have to be programmed and tested after assembly, adding time and cost.
What do you think? Despite how much time I’ve spent working towards option 1, I’m leaning towards option 2. Because it’s probably more important that this thing works rock-solid in the common use cases, and is as affordable as possible, than that it has every whiz-bang feature that only 1% of people will care about.
Read 20 comments and join the conversation20 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
OKay then. SMART and SOMEWHAT more expensive… Go for it. I hear you about #2.. but .. I like it when things just work, no switches. That’s just me. š
For only about 10 more dollars, go with #1!
A vote for #1 option. I do like the kiss solution of #2, however with the years progressing much faster than I would like, automatic things seem to work better for eyes, arthritic fingers etc. Good luck and keep the faith.
#1 seems like the “smarter” choice.
I’d prefer the smart one if you can make it work but I’d buy either.
I would want to keep my Floppy Emu sandwiched between a 3.5″ drive and a 5.25″ drive (on a GS) so the three configurations I need would be (A) 3.5, Emu 3.5, 5.25, (B) 3.5, Emu Smartport, 5.25, and (C) 3.5, Emu 5.25, 5.25
I could live without (A) because I can always just load an 800k image in Smartport mode and treat it like a Unidisk 3.5. (That wouldn’t work with the few weird programs that try to access the 3.5″ hardware directly, but most of those only work with drive 1 anyway, so it’s not likely to be an issue.)
Looks like the audience has spoken for option 1! Tim, the (B) setup has somewhat limited usefulness, because you can’t boot from a Smartport drive in that configuration, although you can boot from the 3.5 and then access volumes on the Smartport drive. That’s a result of how the IIGS works, and isn’t anything specific to Floppy Emu or this daisy-chain adapter.
Agreed. Option 1 nice to have, but Iād buy either as well.
Option 1 seems the way to go. More capabilities now and possibility to support more that don’t currently exist. That last thing is the most important because people keep dreaming up cool new stuff! Adding support for the next cool thing would hopefully only require a firmware update rather than a whole new card.
Even with a microcontroller-based design, it won’t be possible to do a firmware update (unless you have a special programming tool), because there’s no interface for loading new firmware. My musing on “potential new features” is more about ideas during the design phase, or for a 2nd-generation design.
It looks like Sparkfun sells an AVR programmer for $13.50, and other options are available on eBay for as little as $4.00. So availability of the “special programming tool” shouldn’t be much issue if there were ever some desire to update the firmware on an existing device in the field.
I’m echoing the crowd, but #1 makes sense to me. When I have some obscure need for it in 15 years and can’t remember exactly how it works (or what I’m hooking it to is called, or ???) I’ll appreciate automatic and won’t miss the $20 extra it cost me. Old gear and older people need whatever extra smarts we can get!
I’m joining the groundswell of votes for #1. I’ve got an extra $10 in my pocket and can always find use for more intelligence outside my head.
-> “Can always find use for more intelligence outside my head”
These are great words, even not limited to this event.
I don’t have any suitable computers I might use the device on, so I’ll abstain from voting – but to turn the question on its head, which option would be more fun to design and build?
eBay has USBISP AVR programmers for $1.50 (shipped). The driver is built in to macOS, so software like AVRDUDE and Arduino IDE just work.
Option 1!!!
Hi Steve,
What are the consequences of setting the switches incorrectly on #2?
I’m working on a microcontroller-based solution along the lines of option 1. For the drive type, if it’s set or detected incorrectly, one or more drives in the daisy chain might not work correctly. In the worst case, a drive could theoretically get damaged.
I don’t care which one, as long as it happens. I very badly want to pull out the regular disk controller from my IIe and chain things to my SmartPort controller, as well as chain off the IIc+ SmartPort. Please oh please oh please …
Option #1…
And to add to my uninformed curiosity, is it, in any way, possible to run two 3.5ās chained to two 5.25ās AND get the Floppy Emu in there someplace?
I guess if I had to ditch one of the 5.25ās that would be okay, but I don’t want to break a 3.5 out of my AE Conserver.