Zeroplus LAP-C 322000 Logic Analyzer Review
Who needs a logic analyzer? You do! If you enjoy working with electronics, a good logic analyzer is an indispensable tool. It lets you examine exactly what’s happening with your data signals, so you can troubleshoot problems quickly or reverse-engineer unknown protocols. Developing digital electronics without a logic analyzer is like navigating without a map.
In decades past, logic analyzers were bulky and expensive purpose-built machines from companies like Hewlett Packard. There’s still a place for such high-end equipment, but today most engineers can get everything they need from a small USB device that costs just a few hundred dollars. Saleae is one of the better-known names here, but it’s a crowded market with many worthy competitors. Which one is right for you?
Hello Zeroplus
Today I’ll take a look at an example of the Zeroplus “Logic Cube” series. Zeroplus is based in Taiwan, and their logic analyzer products have a good reputation among Taiwanese IT companies, but are less well known in the West. Full disclosure: Zeroplus sent me a demo unit for the purpose of this review. What you’ll read below are my own unfiltered opinions of the hardware’s strengths and weaknesses.
The members of this product family are buffered logic analyzers, with a few megabits of high speed on-board memory for storing the captured sample data. This is the more traditional approach to designing a logic analyzer, and it provides some advantages versus the on-the-fly USB streaming approach used by Saleae and other similar low-cost logic analyzers. Buffered LAs aren’t reliant on the PC’s USB bandwidth, so they can capture many channels at high sample rates without fear of saturating the USB link and losing data. The tradeoff is that buffered LAs have finite storage space, so the maximum amount of data that can be captured is limited. Data compression helps, but once the on-board memory is full, signal acquisition stops. In contrast, streaming LAs support “infinite” capture sizes limited only by the PC’s available RAM and disk space, but have limited bandwidth.
The Zeroplus logic analyzers in this Logic Cube series are commonly called “LAP-C” for the common prefix in all of their model numbers, and you’ll find the most pertinent resources on the web by searching for this term. LAP-C models are sold in seven different versions, differing mainly in the number of channels and amount of on-board memory. For this review, I tested the top of the line LAP-C 322000, with a retail price of $1699 in the United States. Here are the specs:
Logic Analyzer: Zeroplus LAP-C 322000
Number of Channels: 32
Sample Memory: 64 Mbits (2 Mbits per channel)
Max Sample Rate: 200 MHz
Vinput of Testing Channels: -30V to +30V DC
Retail Price: USD $1699
In comparison, the mid-range members of the LAP-C family pare back the number of channels and memory size in exchange for lower prices. For example, LAP-C 16064 is 16 channels / 1 Mbit / 100 MHz for $249, and LAP-C 16128 is 16 channels / 4 Mbits / 200 MHz for $399.
Unboxing and Hardware
While the front of the box has English text, the technical bullet points on the back are primarily in Chinese. This probably doesn’t matter much, since very few people will ever be browsing store shelves when shopping for a logic analyzer, but it shows that Zeroplus’ marketing team has additional translation work to do if they hope to attract more Western customers.
The 34-page instruction manual inside the box is also Chinese, but a well-written English-language manual can be downloaded here.
The logic analyzer unit and its accessories all fit inside a hardshell zippered case that’s included. While it’s a small thing, this is a very nice touch, and it makes it easy to pack up your project when you’re finished debugging hardware. The pulse width trigger module included with the LAP-C 322000 model is the only accessory that doesn’t go in the hardshell case.
The LAP-C 322000 package includes:
- logic analyzer main unit
- USB cable
- 32 flying lead wires
- 36 IC test hooks
- printed manual (Chinese)
- installation software CD
- hardshell case
- pulse width trigger module
- hookup wires for trigger module
The pulse width trigger module is made from brushed aluminum. When connected to the main unit, this module upgrades the logic analyzer with a new feature: the ability to trigger on a high or low pulse whose duration is outside a user-selected range. This may be useful when working on PWM applications like dimmable lighting.
The main logic analyzer unit is made from an attractive gloss white plastic. The external interface is minimal: a button to start immediate captures, and status lights for Run, Read, and Trigger. The external connector is two rows of standard 0.1 inch male headers. In addition to the 32 data channel connections and ground pins, there’s also an external clock input, and a few special I/O pins for connecting the pulse width trigger module or a second LAP-C unit.
The LAP-C does not offer any analog measurement capability. While serious analog work demands an oscilloscope, some newer logic analyzers are starting to add low-bandwidth analog capability too. This can be useful for verifying that signal voltage levels are in a valid range, or that power supplies are behaving as expected. Analog measurement is a nice extra feature, but its absence here isn’t a deal-breaker.
Software
The LAP-C software is Windows-only. That’s not a big limitation, since any halfway-serious engineer will have access to a Windows machine even if it’s not their main system, but Macintosh and Linux software versions would have been nice. Windows 7, 8, and 10 compatibility is advertised. I used software V3.13.05 with Windows 7. You can download the software and try it out in demo mode, even if you don’t have the LAP-C hardware. The English-language software translations are generally well done and easy to understand.
The graphical interface appears geared towards advanced users, with a very large number of tools, measurements, and options visible directly on the main screen. This is great for power users, but may be overwhelming for newbies, or to anyone accustomed to the minimal interface of Saleae’s software. I found it a bit daunting at first, but after 30 minutes of experimenting and checking the manual, I had mastered the basics.
Some aspects of the UI would benefit from more polish. When viewing large data ranges, panning and zooming the waveform can be glitchy, with a laggy response to mouse input and different portions of the waveform scrolling a fraction of a second after others. Compared to the smooth pan and zoom of competing logic analyzer software, or to tools like Google Maps, that’s a little disappointing. Other minor graphical glitches and goofs sometimes appear, like waveforms that aren’t a uniform height or scale values that are the wrong units. The intervals of the ruler are also oddly chosen, with tickmarks at 0.409374912 seconds followed by 1.91042 seconds and then 3.411465 seconds, instead of divisions at even intervals using powers of 10. None of this prevents you from analyzing captured sample data, but it can be confusing and distracting.
A data capture can be started immediately by pressing a button in the software, or by pressing the physical button on the logic analyzer unit. Captures can also be triggered by a level or edge condition on a single channel, or by more complex functions like a specific value on a parallel bus, or a protocol-level event like an I2C NACK.
There are an impressive number of powerful features embedded in the LAP-C software. Repetitive run triggers the logic analyzer over and over, so you can look for one instance that’s different from the others. Noise filter ignores pulses with a duration below the threshold you specify. Data can be captured with an asynchronous internal clock, or synchronously using an external clock connection. Captured data can be searched in several different ways to find a region of interest. Waveforms and data can be imported and exported for additional examination with other tools. There are many more advanced analysis features that I didn’t have time to explore deeply. Some of these may only be valuable in specific circumstances, like the memory analyzer for examining address/data information, but they’re great when they provide the special capabilities you need.
One small but curious shortcoming: in the software’s list of choices for the sampling rate, it skips directly from 1 MHz to 10 MHz with no intermediate options. Most of my electronics projects operate a speeds faster than 1 MHz but slower than 10 MHz, so the missing sample rate options are a bigger issue for me than they might be for others.
Capturing and viewing sets of raw waveforms is great, and is the core of logic analyzer usage. But to really get the most out of the tool, you’ll want to use the software’s protocol analyzers to provide a high-level representation of the data. A protocol analyzer is a software module that converts raw waveforms into decoded data packets. For example, if the software offers an I2C protocol analyzer, then you can view the captured sample data as a series of device addresses, data bytes, and ACKs, instead of counting raw transitions of the SCK and SCL signals while you thumb through an I2C reference guide. The LAP-C software offers over 100 protocol analyzers, including I2C, SPI, serial (RS-232C/422/485), JTAG, PS/2, USB, 1-WIRE, CAN, IRDA, 3-WIRE, and many more. Some of these used to be extra cost options, but since 2016 all the protocol analyzers are available free. Here’s a typical protocol analyzer example from Zeroplus:
How Much Sample Memory Do You Need?
When purchasing a buffered logic analyzer, you need to predict in advance how much sample memory you’re likely to need. Underestimating is bad: if there’s not enough sample memory, you won’t be able to capture as many channels for as long a duration as needed for your debugging work. But overestimating is bad too: it means you’ll pay hundreds of dollars extra for additional sample memory you don’t need. So how can you decide how much memory is enough?
This is a difficult question to answer, because it depends heavily on the type of electronics work that you do. You might work primarily with low speed serial signals, or you might need to analyze a wide parallel bus running at high speeds. Your data might be highly compressible with the LAP-C’s compression algorithm, or it might not. This leads to a frustrating “it depends” answer that satisfies no one.
For my own hobby electronics work over the past few years, I typically need to analyze systems with 5 to 10 signals running at speeds between 1 MHz and 10 MHz. My normal work pattern with a streaming logic analyzer is to manually start the capture, and record a few seconds of data, then examine it afterwards to zoom in on the interesting parts. Using a buffered logic analyzer, without the benefit of compression, this would require a worst case of 10 signals times 10 MHz times 10 seconds, or 1000 Mbits total. My simple experiments with LAP-C compression found that it provided about a 10x improvement for my data, so that reduces the memory requirement to 100 Mbits – close enough to the LAP-C 322000’s 64 Mbits. So with the top of the line LAP-C model, I could probably support my existing work pattern, but anything with less memory would be insufficient.
To really get the benefit of the LAP-C hardware, I would need to stop using 10 second long captures, and instead set up triggers to capture only the few hundred milliseconds or microseconds I’m really interested in. That would require some extra time for setup, but would greatly reduce the amount of memory needed.
Other Thoughts
Zeroplus’ web site lists two official US distributors, and one appears to only stock the entry level LAP-C 16032, leaving a single source for most LAP-C models in the US. With a bit of Google searching, you can also find third-party LAP-C sellers from Asia who will ship directly to the US. Direct sales from the Zeroplus web site would be a welcome addition, but are not currently an option.
Is the Zeroplus LAP-C series right for you? It depends on what you plan to do with it. For the casual electronics hobbyists who are typical readers of this blog, the $1699 price tag of the LAP-C 322000 may be more than they’re willing to spend, but they probably don’t need all the features of the LAP-C 322000 either. Zeroplus offers three LAP-C models with slightly lower specs all priced below $400, which are probably a better fit for part-time garage hackers. I expect that most hobbyists will be fine stepping down from 32 to 16 channels, although stepping down from 64 Mbits of memory to 4 Mbits or 1 Mbit may be a concern.
With 4 Mbits and 16 channels, at a 10 MHz sample rate and using compression, you’ll get a capture window of a couple hundred milliseconds. That’s small enough so that manual triggering is unrealistic. Instead, you’ll need to plan ahead of time to decide what your goal is with this capture, and how you can construct a trigger to capture exactly the region you need to examine. For power users working with high speed systems and large numbers of channels, this will already be familiar. They’re more likely to know specifically what they’re looking for, and to see complex trigger setup as a normal and expected part of debugging. They’re also more likely to benefit from some of the LAP-C’s advanced features and hardware options like external clock input, pulse width triggering, and detailed software analysis. The breadth and depth of the LAP-C software’s various tools and analyzers is impressive, and will surely be a boon for hardcore electronics engineers. Beginners and others with more basic needs may be better off with an 8-channel streaming logic analyzer with a simple and friendly software interface.
What about the general merits of buffered vs streaming logic analyzer designs? For situations where there’s enough USB bandwidth to stream the sample data on the fly, I believe that approach provides a better user experience. There’s no need to worry about trading off sample rate for sample depth, or worrying whether the capture window will be large enough to contain all the events of interest. But for more demanding situations with large numbers of channels and high sample rates, streaming just doesn’t work. 32 channels at 200 Mhz sampling rate is 6.4 Gbits/sec, which is more than USB 3.0’s total maximum theoretical bandwidth and far more than its real-world bandwidth. So depending on the application, both streaming and buffered designs have their place.
My ideal logic analyzer would be one that operates in streaming mode where sufficient USB bandwidth is available, and falls back to buffered operation when streaming won’t work. That would probably be needlessly complex and expensive, but I can dream!
Read 3 comments and join the conversationFloppy Emu and the Apple Pippin
Remember the Pippin, Apple’s ill-fated attempt to enter the video game market? The hardware was effectively a modified Macintosh, running a customized version of System 7.5. The Pippin lacks any standard floppy disk connector (internal or external), but it does have a proprietary PCI-based docking connector for expansion. 20 years after its release, Pierre Dandumont has developed an adapter for the Pippin’s docking connector, making it possible to attach a Floppy Emu disk emulator. And it works!
During the Pippin’s lifetime, Apple and Bandai sold a floppy adapter for the console, and many games can use it. Pierre describes the official accessories on his blog here (French language). These accessories are very rare. Working with a colleague, Pierre made a copy of the PCB inside the official adapter, which is now available on OSH Park.
Pierre has also been busy with other floppy hacking exploits. He successfully added a Floppy Emu to a first generation Bondi Blue iMac, which famously lacks a floppy connector – it was the first Macintosh without a floppy. Apple included an unpopulated connector footprint on the motherboard, so with a little bit of soldering and the proper ROM, the iMac can have a floppy drive where it never did before.
Here’s the explanation from Pierre:
But on my blog, the Journal du Lapin (mostly in French, sorry), I like to show hacks, or curiosities. I had sent some of my tests to Steve and he offered to publish here.
The Pippin
For those who do not know the console of Apple and Bandai, it is a game console released in 1996, and very few copies were sold (about 40 000). Apple offered an optional floppy drive, which was to be placed under the console. It contains a simple PCB with a standard 20-pin connector. With a friend, we designed an adapter and then I plugged the Floppy Emu on the console. Some games allow you to save data on a floppy disk rather than on the internal flash memory (128 Kb). For example, it is possible to save images from a Dragon Ball Z game.
The iMac Bondi Blue
More amazing, the iMac. The first iMac (Bondi Blue, in 1998) did not officially have floppy drive, but Apple had left the traces of a connector on the motherboard. Obviously, the drive had been planned until a rather late date in the development of the iMac.
So I opened my iMac, soldered a 20-pin connector and connected the Floppy Emu. With the appropriate version of Mac OS, it works perfectly and it is possible to use the floppy drive with an iMac. In practice, it works with Mac OS 8.1 (the original system) and Mac OS 8.5, but not with Mac OS 8.6 or Mac OS 9 (and of course Mac OS X). Apple has actually blocked the floppy drive directly into the ROM from version 1.2. The iMac is the first Mac with a NewWorld architecture, that is, it uses a “ROM” that is loaded from the hard drive, while the previous Macintosh used a real ROM, that can not be easily updated. Since Mac OS 8.6 was delivered with a 1.4 ROM version, the floppy drive does not work with this version of the OS.
In both cases, the Floppy Emu perfectly replaces a conventional floppy disk drive and greatly simplifies testing. Thank you Steve for your work.
Great stuff!
Read 3 comments and join the conversationCustom Key Mappings for ADB-USB Wombat
Here’s an exciting new feature for the ADB-USB Wombat input adapter: custom key mappings.
With firmware version 0.3.0 or later, you can replace the built-in mappings between USB and ADB scan codes, and create your own customized key mapping tables. Change which keys behave as Command and Option, reassign the function keys to new purposes, select a different key to behave as ADB power/wake-up, and design other custom key mappings. Go crazy!
The code framework to support custom mappings has been in place for a while, and it’s little more than a lookup table of USB to ADB scan code equivalents, and a complementary table of ADB to USB equivalents. There are two separate tables, instead of a single bidirectional table, because there’s not always a one-to-one mapping between USB and ADB scan codes (in mathematical terms it’s not a bijection). Use a custom lookup table, and you’ll get custom key assignments.
The harder part was designing a user-friendly interface for viewing and editing the tables. It would be awkward and error-prone to expect people to manually fill in a few hundred numbers in a hex editor. After considering various cross-platform frameworks like Qt, I decided to implement the keymap editor as a web page. All of the logic is implemented in Javascript, so you can see how it works by viewing the page source. I’m not the world’s greatest UI designer, so if you’re a web UI specialist and want to contribute some interface improvements, they would be very welcome.
Because the control, shift, and capslock keys are used to access the Wombat’s help commands, those keys shouldn’t be remapped. A few other mapping details are called out in the editor for ISO keyboards and certain ADB keyboards.
Installing the custom key mappings to your Wombat board is very similar to installing new firmware. Copy a file to a USB flash drive, put the flash drive in the Wombat’s USB port, and hold the board’s power key button while it powers on. Complete instructions are on the keymap editor page. If you accidentally mess up the key mappings so badly that you can’t recover, the keymap editor can also be used to download and reinstall the default keymap.
Be the first to comment!Accepting Bitcoin for BMOW Hardware
I’m searching for a couple of guinea pigs who are interested in buying a BMOW Floppy Emu disk emulator or other BMOW hardware, and paying with Bitcoins. As an incentive, I’m offering a temporary 5% discount for anybody who pays via Bitcoin. This is an experiment into digital currency, spurred by a recent customer inquiry into Bitcoin sales, and I’m interested to see where it leads. There’s not yet an automated payment option for Bitcoin in the BMOW store, so if you’re interested in making a Bitcoin-funded purchase please use the contact link at the upper-right corner of the page. Coincidentally Bitcoin just reached an all-time high today, so your coins will have some extra spending power in the BMOW product catalogue.
Be the first to comment!Unidisk Firmware Update for Floppy Emu
I’ve updated the BMOW Floppy Emu disk emulator firmware, adding new Unidisk and Smartport features for the Apple II family. After some quality hacking time with a Unidisk 3.5 drive and a logic analyzer, the hardware secrets were finally revealed! Thanks to Roger Shimada for providing the Unidisk to make this possible. Here’s a rundown of what’s new:
Unidisk 3.5 Emulation – The Floppy Emu can now emulate an 800K Unidisk 3.5 drive. Because the Unidisk uses the Smartport communication protocol, this new mode is very similar to the existing Smartport hard disk mode, with a few key changes. Unidisk 3.5 mode disk images are always 800K. They can be selected from a menu and ejected when needed, just like the other floppy emulation modes.
Apple IIc owners will probably get the most benefit from Unidisk 3.5 mode, because it’s the only 800K drive type supported by that machine. Apple IIe owners with a Liron disk controller may find it useful too, as well as anyone with an Apple IIe PDS card for the Macintosh LC. Unidisk 3.5 mode also works on the Apple IIgs, but the existing 3.5 inch floppy mode for the IIgs offers the same functionality with faster i/o speed.
Unidisk 3.5 Daisy Chaining – The new firmware also enables a Floppy Emu to be daisy-chained behind a real Unidisk 3.5, when the Emu is in Smartport or Unidisk 3.5 emulation modes. Unfortunately, to gain the benefit of this change, an external hardware modification is also required. If you have an urgent need for Unidisk daisy chaining, see the cable-hacking suggestion in the comments of the linked post.
Unidisk/Smartport Cold Boot Speedup – The Floppy Emu initialization delay from power-on to ready has been dramatically improved for Unidisk 3.5 and Smartport emulation modes. This makes it possible to cold-boot an Apple IIe directly from an Emu attached to a Liron card. Previously it required a warm start or PR#7 command to reinitialize the Smartport once the Emu was ready, but that’s no longer necessary. This change may also help cold booting from Smartport on the Apple IIc+, which was hit-or-miss with the old firmware. I don’t have a IIc+, so please let me know how it fares with yours.
Get the Firmware
Firmware 0.1X contains all three new features described above. The Unidisk 3.5 emulation required major code changes which may have impacted other features, so if there’s a problem I’ve also included firmware 0.1V as an alternative and fallback. 0.1V contains only the daisy chaining and cold boot speedup features.
Floppy Emu Model A – apple-II-0.1X-F20
Floppy Emu Model B – apple-II-0.1X-F21-modelB
Try version 0.1V if you have trouble with 0.1X
Floppy Emu Model A – apple-II-0.1V-F20
Floppy Emu Model B – apple-II-0.1V-F21-modelB
Unidisk 3.5 Daisy Chain, Sad Trombone
The Unidisk 3.5 is an 800K floppy drive for Apple II computers, using the Smartport protocol to communicate with the Apple II. The BMOW Floppy Emu disk emulator is also capable of emulating a Smartport disk, so in theory it should be possible to plug the Emu into the Unidisk’s daisy chain port, and use them both together. Unfortunately it doesn’t work, for reasons that weren’t clear until recently. The good news is I now understand what’s going on, but the bad news is it’s probably impossible to make it work without hardware modifications.
Smartport is a bus-based protocol. Each disk is assigned a unique address at startup, and it should only respond to commands for that address. The original Floppy Emu firmware for Smartport was intelligent enough to do that, but it contained some implicit assumptions that were wrong in a daisy chain situation with multiple Smartport drives present. Fixing those was the first task. For example, it would ACK the receipt of any Smartport command, even if it didn’t actually respond to it because it was for the Unidisk. It would also enable its output on the READ and HANDSHAKE lines whenever any Smartport drive was enabled, interfering with the Unidisk.
Address Assignment
After resolving those problems, daisy chaining still didn’t work. The logic analyzer showed that the Floppy Emu was never even assigned a Smartport address. Here’s the telltale trace:
The first set of squiggles there on WRDATA (channel 08) is the computer assigning address 1 to the Unidisk with an init command. The following squiggles on RDDATA (channel 07) are the Unidisk’s reply, which is “OK, and there are no more Smartport devices after me”. The next command on WRDATA is a request to read sector 0 from the Unidisk, so Floppy Emu was completely ignored.
Determining what those squiggles mean is a tedious process. I have to zoom in until I can see each positive and negative transition of WRDATA. Every 4 microseconds there will either be a transition (a logical 1 bit) or there won’t be any transition (a logical 0 bit). I have to write down the bit sequences, frame them properly into bytes, and then consult the Smartport spec to make sense of it all. Maybe someday I’ll write an automated tool to do all this, which would make the debugging process dramatically faster. For now I’m happy simply to graph all the signals, because there was a time when I didn’t have even that much.
So why doesn’t the Floppy Emu get assigned a Smartport address? If I were designing the Smartport protocol, I would probably have it send as many init commands as necessary to give addresses to all the drives. Just keep sending init commands, incrementing the address each time, until all drives have received an address and no more init responses are received. But Apple chose a different solution, where each Smartport device is expected to know definitively whether or not there are more Smartport devices behind it in the daisy chain.
Input Becomes Output
Apple used a sneaky trick to accomplish this. On the DB-19 connector, pin 16 is normally an input to the disk called HDSEL, which is used to control non-Unidisk 3.5 inch drives. But on the Unidisk 3.5 (and presumably other Smartport devices) pin 16 of the male connector is tied internally to ground. On the Unidisk’s daisy chain output connector, pin 16 has a 2Kohm pull-up resistor to 5V. Internal logic senses whether pin 16 on the daisy chain connector is low (another Unidisk or Smartport device is daisy chained, and its internal ground connection pulled pin 16 low) or high (no Smartport device).
Turning a disk input into a direct ground connection is dangerous. It means that if the computer tries to drive a high value on HDSEL, and a Unidisk 3.5 is connected, it will create a power to ground short and likely fry the disk controller. This will happen for certain if a Unidisk 3.5 is connected to a Macintosh. The Apple IIc and the Liron disk controller don’t connect anything to HDSEL, so they’re safe. The Apple IIgs does make use of HDSEL, but its schematics reveal a 470 ohm inline resistor to protect against a power to ground short. I’m not sure about other disk controllers like the Apple 5.25 controller or the Duo Disk controller. The Disk II controller has an incompatible 20-pin connector, but if you used the Floppy Emu’s adapter cable to connect a Unidisk 3.5 to a Disk II controller, it would directly connect +5V to ground. Ouch!
This kind of I/O switcheroo seems like a very bad idea to me. Ideally, you could plug any kind of 19-pin Apple drive connector into any kind of 19-pin controller, and the worst that would happen is it wouldn’t work. But Apple created a situation where you can actually destroy your equipment by doing this. It’s not the first time, either. Pin 4 was similarly repurposed, from a ground connection on Unidisk 5.25 and Unidisk 3.5, to a drive input signal on the Apple 3.5 drive. And pin 10 is a drive input for Macintosh and Lisa, but an output for Apple II drives.
An Unintended Voltage Divider
The Floppy Emu’s CPLD can be reconfigured to treat pin 16 as an output when in Smartport mode, with an output value of zero, to simulate a ground connection. Setting aside the potential for damage this presents to a Macintosh connection, it should get the Unidisk to recognize there’s another Smartport device on its daisy chain connector. Unfortunately it doesn’t work. Ironically it’s the CPLD protection resistors that were added in Floppy Emu Model B that cause the problem, by creating an unintentional voltage divider with the Unidisk’s pull-up resistor on pin 16.
All of the Model B’s CPLD inputs have a 1K series resistor to help protect against voltage spikes and static. This is fine when the inputs are actually inputs:
The CPLD input buffer draws only a few microamps of current. From V = IR, we can calculate that the voltage drop across the resistor will be a few microamps times 1K, or a few millivolts total. If the computer drives a 5V input signal, the CPLD will see something like 4.99 volts, which is fine.
Things are quite different when the input becomes an output, and that output has a relatively strong pull-up resistor:
Now there’s a path through the two resistors, from 5V to ground. From the voltage divider rule, we can calculate that the voltage at the point between the two resistors will be 1.66 volts. (I measured it at 1.55 volts experimentally.) That’s far too high to be recognized as a logical zero value; 0.8 volts is the maximum valid zero voltage for 5V TTL logic. So the Unidisk doesn’t think there’s a Smartport device on its daisy chain connector, and the Floppy Emu never gets a Smartport address.
I was able to get daisy chaining working by adding a small value resistor between HDSEL and ground, external to the Floppy Emu. But that’s not much help to anybody, and it also prevents the Floppy Emu from working correctly in 3.5 inch disk emulation mode.
Solution?
So what’s the answer here? I’m afraid there probably isn’t one, and Unidisk 3.5 daisy chaining just won’t work, wah-wah and sad trombone. But maybe a reader will have a clever suggestion.
Changing the Floppy Emu’s protection resistors to something less than 1K could help. My math says a resistor of 381 ohms or less would put the pin 16 voltage at a valid logical zero for 5V TTL. By combining an old Floppy Emu Model A (no resistors) with some manually-wired external resistors, I was able to directly confirm that 1K ohm protection resistors don’t work for Unidisk daisy chaining, but 330 ohm resistors do work. But dropping from 1K to 330 ohm would be a significant reduction in the amount of protection for the CPLD. I’m also reluctant to make any changes to the Floppy Emu hardware design, which has become like a supertanker that’s difficult to change course. Any changes now would cost lots of time and money, and wouldn’t help owners of existing hardware anyway.
Another possibility is some kind of external adapter, with a physical switch for shorting pin 16 to ground. That would work, but the time needed to design, build, and stock such an adapter would be too high relative to the importance of Unidisk 3.5 daisy chaining. It’s unlikely that many people would be interested in buying such an adapter.
Read 15 comments and join the conversation