BMOW title
Floppy Emu banner

Circuit Fixes and Pulldown Problems

I’m continuing work on the daisy chain adapter concept for Floppy Emu, and I’ve run into a problem. There’s a pulldown resistor on the Floppy Emu board that’s too weak (resistor value is too large) to reliably pull the voltage all the way down to the logic low threshold. This causes upstream drives and computers in the daisy chain to sometimes mis-detect what type of drive the Floppy Emu is currently emulating, resulting in a malfunction of the whole chain. I’d like to add some extra circuitry between the Emu and the upstream drive to fix this problem, but the details are complex and I haven’t found any great solutions. Here are some diagrams to illustrate what’s happening:

Figure 1 shows a Floppy Emu connected directly to an Apple IIGS.

Figure 2 shows a Floppy Emu daisy-chained to an Apple 3.5 Drive, A9M0106.

Apple designed a disk interface with double-purposed signals. Depending on the disk drive type, the data signal EN35 is either an input to the drive (3.5 inch drives), or is pulled low by the drive (5.25 inch and Smartport drives). The double use requires an open drain driver or inline resistors, to avoid potentially shorting power to ground if both ends drive the signal with different values.

For equipment that’s “3.5 inch aware”, it can detect whether a daisy-chained drive is a 3.5 inch drive by monitoring the voltage of EN35. The SR latch in figure 2 shows one example. At reset, it assumes the daisy-chained drive is not a 3.5 inch drive. But if EN35 is ever observed to go high, then it knows the daisy-chained drive *is* a 3.5 inch drive.

Need More Pulldown

On a real floppy drive’s input, EN35 is either connected to an input buffer or tied directly to ground. But Floppy Emu can do either one, depending on the emulated drive type, and that’s where the problem appears. To protect the Emu’s CPLD chip when EN35 is treated as an input, there’s an inline protection resistor of 1K (Model B) or 330 ohm (Model C). When the Emu wants to pull down EN35, it must do it through that resistor. This forms a voltage divider with the resistor in the upstream equipment, preventing the EN35 voltage from being pulled fully to 0 volts.

In figure 1, with the Model C’s 330 ohm pulldown, the voltage at Vt is pulled down to 2.0 volts. That’s not low enough for equipment (like my proposed daisy-chain adapter) to detect as a valid logic low. With the Model B’s 1K pulldown, the situation is worse, and the voltage at Vt is only pulled down to 3.3 volts. When the pulldown is inactive, the voltage measured at Vt is about 4.9 to 5.0 volts.

In figure 2, with the Model C’s 330 ohm pulldown, the voltage at Vt is pulled down to 0.49 volts. That almost works, with correct behavior about 75% of the time. On the Model B with the 1K pulldown, the voltage at Vt is only pulled down to 1.16 volts. That’s not low enough, and the circuit doesn’t work correctly. By butchering a board and testing various resistances, I found that a 200 ohm pulldown works reliably.

Potential Fixes

I’m in search of a magic circuit that can be inserted between Floppy Emu and the upstream device, that will fix this ugly problem:

When Floppy Emu is driven from the Apple IIgs as in figure 1, I can control both the “magic circuit” and the buffer used to sense the EN35 voltage, so a solution is relatively simple. But finding a solution that works with the Apple 3.5 drive (figure 2) is more difficult, because that feedback path to the SR latch is outside my control.

Passive Resistors – How about adding an extra pulldown resistor to bias the EN35 voltage lower? Or some kind of voltage divider? I don’t think that can work. An extra pulldown would need to be fairly strong in order to pull EN35 to a reliable logic low, so it could no longer reach a reliable logic high.

Voltage Controlled Pulldown Booster – Maybe the magic circuit could monitor the EN35 voltage, and if it ever went below ~3.5 volts, the circuit could activate a second strong pulldown to bring the voltage to 0 volts. The problem with this idea is that it would create a feedback loop. Once the second strong pulldown was activated, it would hold the voltage at 0 and keep itself activated forever.

Current Controlled Pulldown Booster – Maybe the magic circuit could monitor whether more than 1 mA is flowing into the Floppy Emu, meaning that the pulldown is active. Then it could engage a pulldown booster of some type to bring the voltage to 0 volts. This sounds like a job for a BJT, perhaps, but I’m not sure. Once the second pulldown was activated, I think all the current would flow through that pulldown instead of to the Floppy Emu, causing the booster circuit to shut off again. Maybe there’s a solution here, but I don’t see it.

Bidirectional Level Shifter – I’m not actually doing level shifting here, but level shifters have the useful property of electrically isolating the two sides. The classic bidirectional shifter based on an N channcel MOSFET won’t work here, though. It prevents a high voltage from damaging a lower-voltage circuit, but does nothing to help if a low voltage source is too weak. Maybe there’s a solution based on some other bidirectional isolation technology?

Op Amp, or Diode – Sure, why not? Now I’m just naming random electronic components, hoping for a solution. Try enough permutations, and something must work…

Final Thoughts

The only plausible path that I see right now is a state-based solution, similar to the SR latch that’s in the Apple 3.5 drive. This could be used to enable one of two buffers that isolate the sides of the circuit, such that the direction of data flow is always definitively in one direction or the other. Data flow would be assumed to go from the Floppy Emu to the upstream device until proven otherwise. And a weak pullup on the Floppy Emu side would compensate for the weak pulldown.

I’m not thrilled with this solution, because it’s state based, requires reset circuitry, and overall seems cumbersome. I’ll elaborate more in a future post. Meanwhile if you have other suggestions, please leave a note in the comments box.

Read 7 comments and join the conversation 

Introducing the Floppy Emu Model C

Today I’m thrilled to announce the newest member of BMOW’s Floppy Emu disk emulator family – the Model C. Floppy Emu is a floppy and hard disk emulator for classic Apple II, Macintosh, and Lisa computers. The new Model C introduces an eye-catching 1.3-inch 128×64 OLED display, with crisp text and amazing contrast. Fonts are more detailed, and the OLED shows eight lines of text for better context when scrolling through a long list of filenames. The new display is a real treat for the eyes.

The extra resolution of the OLED helps a lot. Text characters are 5×7, compared to 3×6 characters on the previous generation LCD. This provides a nice improvement in legibility.

The Model C also features a new push-pull style micro-SD card holder, for improved durability. Some past customers lobbied for the change to a push-pull vs push-push style, and after some experimentation I decided that I agreed. This is the same style of SD card holder found in most mobile phones today, and if you’re the sort of person who’s constantly inserting and removing the SD card then you’ll appreciate this change.

With the introduction of the Model C, Floppy Emu is also moving to a gloss piano black color scheme. It won’t impact the disk emulation, but it sure looks good.

The same great disk emulation features from earlier models are also supported in the Model C. It’s directly compatible with the entire Apple II line, emulating 5 1/4 inch disks, 3 1/2 inch disks, or Smartport hard disks all without the need for a separate adapter. Of course classic Macintosh and Lisa disk emulation is supported too. Model C reads and writes emulated 140K, 400K, 800K, or 1.4MB floppy disk images, or hard disk images up to 2GB, if supported by your Apple computer.


  • Apple II Floppy – 140K (5 1/4 inch) and 800K (3 1/2 inch) disks
  • Apple II Hard Disk – Smartport disk volumes up to 32 MB
  • Macintosh Floppy – 400K, 800K, and 1.4MB disks
  • Macintosh Hard Disk – HD20-type disk volumes up to 2 GB
  • Lisa Floppy – 400K and 800K disks, Lisa Office System and MacWorks
  • See the compatibility table for more details

Model C Case

A new board requires a new case, so today I’m also announcing the Frosted Ice Acrylic Case for Model C. The cut-out surrounding the SD card has been enlarged, to make it easier to remove from the push-pull card holder. The opening in the top has also been repositioned and resized to fit the OLED, and there’s a subtle engraving surrounding it.

The new case is designed specifically for the Model C. If you need a case for the older Model A or B, I’ve still got that too.

All of this new hardware is available now on the Floppy Emu product page, or directly from the BMOW Store. Thank you for supporting retro computer designs!

Read 16 comments and join the conversation 

Part Selection and Schmitt Trigger Oscillator

I often obsess over little details of my circuit designs, and the daisy-chain adapter for Floppy Emu is no exception. The design needs a small CPLD for the daisy-chaining logic, and for various reasons I have narrowed the choices to the Lattice ispMACH LC4032ZE and LC4032V. These are both 32 macrocell CPLDs, and are very similar except for a few details:

LC4032ZE – 48 pins, 0.5 mm pin pitch, 1.8V core, built-in oscillator

LC4032V – 44 pins, 0.8 mm pin pitch, 3.3V core

The 4032ZE is the newer of the two options, and the 4032ZE supply at distributors is a bit more plentiful. It also has a built-in 5 MHz RC oscillator with +/- 30% accuracy, which can be divided down to the kHz range or lower frequencies without using any macrocells. As it happens, the daisy chain adapter needs a clock source in the kHz range for periodic tasks, but the exact frequency isn’t too important, so this is perfect.

The drawbacks of the 4032ZE are its core voltage and its pin pitch. With a 1.8V core serving 3.3V I/O to and from 5V disk drives, I’d need to design a three-voltage system. In practice that means an additional voltage regulator, some extra decoupling capacitors, and a bit more headache with the board layout. 0.5 mm pin pitch means the pins are very tightly spaced. It creates a greater likelihood of soldering errors and hard-to-see solder shorts during assembly. Basically it will make assembly and testing of boards more challenging.

The 4032V looks like a good alternative, with a 3.3V core and a much wider pin pitch. But it lacks any built-in oscillator. If I want a clock source, even an inaccurate one, I’ll have to provide one externally. That will add a bit to the board cost and complexity. The 4032V itself is also slightly more expensive than its twin. In the end, it’s not obvious to me whether the 4032V or 4032ZE is the better choice overall.

Which one would you choose?

Schmitt Trigger Oscillator

If I choose the 4032V, then I’ll be looking for a simple and inexpensive way to provide an external clock signal to it. Something around 10 kHz would be preferred. I can probably tolerate inaccuracies in the frequency of 50% or more, over time on the same board or between different boards.

I could use a single chip oscillator like a MEMS oscillator, but I’m drawn instead to the idea of a Schmitt Trigger RC oscillator. It’s cheaper, and it also has a nice old-school vibe. The circuit is simply a single inverter with its output fed back to its input through a resistor, and with its input also connected through a capacitor to ground.

The frequency of the Schmitt Trigger RC oscillator depends on the values of the capacitor and resistor, the hysteresis of the inverter, and the supply voltage. Calculators exist to help predict the frequency, but in practice I’d probably need to tune it experimentally.

I’m fine with some variation in the frequency, as long as it doesn’t vary wildly. A variance of 2x or more could become problematic. Given the tolerance of the capacitor and resistor values, temperature-dependent capacitance changes, process variations between inverters, and possible supply voltage fluctuations, what range of frequency variation is a Schmitt Trigger RC oscillator likely to experience?

Would I be better off paying more for a standard oscillator, even though I don’t need the high accuracy? Or would I be better off using the 4032ZE with its built-in oscillator, and not stressing about the core voltage and pin pitch?

Read 7 comments and join the conversation 

Daisy Chain Daydreams

Some Apple II computers can daisy-chain disk drives: connect multiple disks, one after another in a single chain. I’m exploring options for the BMOW Floppy Emu disk emulator to support daisy-chaining more flexibly than it does now. I’d love your thoughts on whether you’d find this personally useful – please read below and leave a note in the comments section.

Daisy Chain Basics

Daisy-chaining makes it possible to connect many different disk drives to the same computer, without needing a separate disk controller card for each drive. Among early Apple computers, only the Apple II family has daisy-chaining capability – the Macintosh and Lisa don’t support it. Even among Apple IIs, daisy-chaining is only very useful on the Apple IIgs, the rare Apple IIc+, and to a lesser extent the Apple IIc. Other Apple II models lack the necessary hardware or the ability to control multiple types of drives, so this discussion will focus on the IIgs.

The Apple IIgs supports three different types of disk drives:

  • “dumb” 3.5 inch drives, like the Apple 3.5 Drive (A9M0106)
  • “smart” drives, like Floppy Emu’s Smartport HD mode, or the Apple Unidisk 3.5 (A2M2053)
  • 5.25 inch drives

At most two drives of each type can be placed in the chain, six drives in total.

Drive Ordering and Boot Limitations

A critical requirement is the ordering of drives in the daisy chain: the dumb 3.5 inch drives must appear before the smart drives, which must appear before the 5.25 inch drives. This requirement stems from the way the disk port’s control signals are multi-purposed to serve several different types of drives, where some types didn’t yet exist when the older types were designed. You can try physically connecting the drives in a different order, but some of them won’t work and may even be damaged.

The ordering requirements have the side-effect of constraining the computer’s options for boot disks. With complex daisy chains, these constraints can become inconvenient and annoying.

Dumb 3.5 inch drives and smart drives are placed in a single logical group that’s mapped to slot 5. Only the first drive in that group can be used as a slot 5 boot drive. If two dumb 3.5 inch drives are connected, only the first can be used to boot the computer. And if both a dumb 3.5 inch drive and a smart drive are connected, only the 3.5 inch drive can be used to boot the computer. The smart drive can never serve as a boot drive, in this case.

With the Floppy Emu

The Floppy Emu was originally designed as a Macintosh device, and it lacks a daisy chain output connector. That means it can work happily in an Apple II daisy chain with other drives, but only as the last drive in the chain. Often this isn’t an issue, but for some combinations of emulation modes and disk drives, it causes difficulties. Here are some Apple IIgs setups that aren’t currently supported, due to Floppy Emu’s absence of a daisy chain output:

  • Floppy Emu in Smartport HD emulation mode, combined with one or two 5.25 inch drives.
  • Floppy Emu in 3.5 inch emulation mode, combined with one or two 5.25 inch drives.
  • Floppy Emu in 3.5 inch emulation mode, combined with another 3.5 inch drive, where Floppy Emu serves at the first (boot) drive.
  • Floppy Emu in 5.25 inch emulation mode, combined with another 5.25 inch drive, where Floppy Emu serves at the first (boot) drive.

Giving a daisy chain output to the Floppy Emu would enable all of the above setups. Unfortunately it would also add more complexity to the device, because the daisy chain output isn’t simply another physical connector with its data signals bussed from the daisy chain in. It’s a complex logic device whose behavior must change depending on what type of drive is being emulated, whether that drive is currently enabled by the computer, and what type of drive (if any) appears next in the daisy chain. Depending on the circumstances it must alternately cross-over, gate, or otherwise modify the disk control signals. This would require a new programmable logic device, likely a small CPLD similar to the one Floppy Emu uses for disk emulation. But the added cost and complexity would be little benefit to anyone except Apple IIgs owners.

I’ve been exploring a different route – a stand-alone daisy chain adapter rather than a modification to the Floppy Emu. This adapter would function like a T splitter, taking Floppy Emu’s place in the daisy chain, with a connection for the Floppy Emu as well as a standard daisy chain output for additional drives. This would provide a daisy chaining option for Floppy Emu owners who want one, without negatively impacting anything else.

Note there’s still one Apple IIgs setup that can’t be supported: Floppy Emu in Smartport HD emulation mode, combined with another 3.5 inch drive, where Floppy Emu serves as the boot drive. The Apple II drive ordering and boot requirements make this combination impossible, as described earlier (except for some very awkward work-arounds). This has nothing to do with the Floppy Emu or its lack of a daisy chain output – the same limitation exists with other 3.5 inch and smart drives.

My question to you, Apple II reader, is whether a stand-alone daisy chain adapter would interest you for enabling the Apple IIgs daisy chain setups listed above. It would be clearly a niche item for a niche product, so I’m unsure if it makes sense.

Aside from the cost of manufacturing and possible low demand for this adapter, the biggest hurdle would be finding a supply of female DB-19 connectors for the daisy chain output. This could be a major challenge. When the global supply of male DB-19 connectors was exhausted a few years ago, I had to commission the manufacturing of 10,000 new ones to continue with Floppy Emu production. That was very expensive, and I definitely can’t afford to do something like that here. Hopefully enough DB-19F’s are still in a surplus parts warehouse somewhere!

Read 16 comments and join the conversation 

The End of the ROM-inator

All good things must come to an end, and today it’s the end of the Macintosh ROM-inator II SIMM and SIMM programmer. The DIY ROM-inator I kit was discontinued a year ago, and now the ROM-inator II is also being retired. I hate to see it go, but as I’d cautioned more than year ago, this was inevitable.

The ROM-inator II SIMMs (both standard and MEGA sizes) use a set of 16 megabit 5 volt flash memory chips to interface directly with the Macintosh bus. There was only one manufacturer still making this chip, and they moved it to “end of life” status in March 2018. Supplies dwindled, prices went up, and now they’re all gone. The 64-pin SIMM socket needed for the SIMM programmer became similarly hard to get, with only one known remaining supplier with a finite number of new-old-stock parts.

Both technical challenges might be solvable, with enough effort. Perhaps level converters with 3.3 volt flash memory could be integrated on the SIMM. The top edge of the SIMM might be redesigned with a different edge connector to fit a programmer socket that’s still commercially available. But candidly, the ROM-inator was always a somewhat poor value proposition for me, requiring more effort to maintain and support than was reasonable given its sales. I’m not interested in a big new engineering effort to redesign the hardware now.

There are also some issues on the software side that would need attention, if the ROM-inator II were to continue. There’s an unknown bug involving the SIMM programmer’s bootloader, which often causes the programmer to fail to be detected by the software. On MacOS Sierra and later, the software requires an awkward series of quitting and restarting before it will successfully connect. The driver and software application also need to be digitally signed, to shut up the warnings from the latest versions of Windows 10 and MacOS.

Smaller capacity 5V flash memory chips remain available, and I could conceivably design a “ROM-inator II Mini” with 512KB or 1MB of total storage. That would be enough for a modified system ROM with the new startup sound, new icons, HD20 support, and 32-bit clean ROM. But it would leave no space available for a ROM disk, and no way for users to reprogram the SIMM. And there’s already somebody on eBay who’s selling almost exactly that.

Thanks, ROM-inator. It’s been a fun ride!

Read 11 comments and join the conversation 

Yellowstone Goes Open Source

Happy birthday and merry Christmas, Apple II collectors! I’ve decided to make a gift of my design for an FPGA-based disk controller card, and release it under a Creative Commons – BY-SA license. This means anyone else is welcome to use it, modify it, build it, or sell it. And I hope they will! This mostly-finished design has languished for so long on my workbench, I finally decided it was better to let others take advantage of it than for it to gather dust forever. I know there’s economic value in what I’m giving away here today, but that value is only theoretical while I sit idle. It’s been almost a year since I last worked on the project, and almost two years since I began work on the design, and that’s too long. So here you go!

The only restrictions are on the terms “Yellowstone”, “BMOW”, and “Big Mess o’ Wires”. They’re not covered by this license, and are reserved for my exclusive use. If you build something based on this design, don’t use any of those words. You’ll need to pick a new name like Turbo-Disk Mega Ultra Elite.

You can download the design data here: FPGA disk controller Github repository

Ground Rules

Please don’t send me detailed questions and requests for help with this design, or expect me to be your engineering consultant. I’m releasing the design to the community because I don’t have time to pursue it myself. That means I can’t work on it for you, either. The design is released as-is, with no promise of technical support. I may be able to answer general questions, but the rest is up to you.

What is This?

Yellowstone is the code name for an Apple II disk controller card that’s based on an FPGA, rather than using discrete logic chips and ROM chips. By reprogramming the FPGA, the card can be made to emulate various other disk controller cards made by Apple in the 1980s and 1990s. The work so far has focused on emulating an Apple Liron disk controller card, but it would also be easy to emulate a Disk II controller card. It’s theoretically also possible to emulate a Disk 3.5 controller card, though this possibility has not been explored in detail.

What’s Liron?

The Liron disk controller was introduced by Apple in 1985. More formally known as the Apple II UniDisk 3.5 Controller, it’s designed to work with a new generation of “smart” disk drives more sophisticated than the venerable Disk II 5.25 inch floppy drive. The smart disk port on the Liron is appropriately named the Smartport, and it can communicate with block-based storage devices such as the Unidisk 3.5 (an early 800K drive) and Smartport-based Apple II hard drives.

Why care about the Liron? The Apple IIc and Apple IIgs have integrated disk ports with built-in Smartport functionality, but for the earlier Apple II+ and IIe, the Liron is the only way to get a Smartport. For owners of the BMOW Floppy Emu disk emulator, having a Liron card makes it possible to use the Floppy Emu as an external hard drive for the II+ and IIe. Unfortunately finding a Liron is difficult, and although they occasionally turn up on eBay, they’re quite expensive. That makes cloning the Liron a desirable goal.

How it Works

The FPGA disk controller card is little more than an FPGA, a voltage regulator, and a set of level-shifting bus transceivers. The FPGA replaces all of the 7400-series discrete logic chips typically found on a disk controller card. Verilog (hardware description language) replacements for all of the 7400-series parts and other logic were written and programmed into the FPGA. This also includes a full Verilog implmentation of the Apple IWM chip.

The FPGA also replaces the ROM chip containing the boot code for the card. The Apple II executes this code during power-up, and the code knows how to find and load sector 0 from the attached disk drive. The code was obtained from a ROM dump from a real Liron card.

The prototype card also includes a footprint for an 8-pin SPI flash memory chip. It is not used by the current FPGA code, and the chip can be omitted. The idea was that a small number of disk images could be stored in SPI flash memory, so the card could function both as a disk controller and as a disk emulator, but this was never implemented.

The card has a standard 10 x 2 pin disk connector on board. It can be connected directly to a BMOW Floppy Emu disk emulator, using a standard ribbon cable. But for a full Liron clone and connecton to a Unidisk 3.5, a DB-19 female connector is required. A design for a DB-19F adapter PCB is included here, and the adapter can be connected to the disk controller card with a short ribbon cable. The DB-19F is still available from surplus electronics suppliers in small quantities.

Project Status

See here for a complete history of work involving the FPGA disk controller.

The FPGA disk controller card was designed by Steve Chamberlin at Big Mess o’ Wires during the summer of 2017, but the first prototype card wasn’t built and tested until January 2018. The version 1.0 card had errors with the wiring for the output enable signal on one of the bus transceiver chips, and it required a few hand-soldered path wires to fix. After further development, the prototype card was demonstrated to work as a Liron clone, in both an Apple IIe enhanced computer and an Apple IIgs. It worked for controlling a real Unidisk 3.5 drive, as well as a BMOW Floppy Emu disk emulator configured for Smartport emulation mode.

Later testing discovered that the FPGA disk controller card worked reliably when it was the only card installed, but other cards were also present, it sometimes malfunctioned. The more other cards present, the worse the rate of errors became. This was diagnosed as a likely termination or contention problem on the Apple II data bus, and various fixes were tried unsuccessfully. After March 2018, I lost interest in researching the problem further, and no more work has occurred since then.

The design provided here is version 1.1, and it fixes the output enable problem from version 1.0.

Where to Start

  1. Open the FPGA disk controller design (Liron clone) in EAGLE. Export Gerber files and send them to your favorite PCB fabricator. If desired, do the same for the DB19F adapter design.
  2. Purchase the chips and other parts listed in the BOM.
  3. Assemble the card. I did it by hand, you can do it too. A syringe of solder paste and a hot plate or toaster oven works nicely.
  4. Get a Lattice JTAG programmer or appropriate clone. Some clones don’t handle 3.3V logic correctly. Maybe spend the extra money for a genuine Lattice programmer.
  5. Install the Lattice Diamond software.
  6. Apply 5V power to the card at jumper J4. Do not insert the card into your Apple II yet.
  7. Program the FPGA with the bitstream for the Liron clone design – liron_fpgatop.jed
  8. Insert the card in your Apple II. Remove any other cards that are present.
  9. Connect a Smartport-compatible disk drive, such as a BMOW Floppy Emu disk emulator that’s configured for Smartport emulation mode, or an Apple Unidisk 3.5 drive.
  10. Turn on the Apple II. It should boot from the attached drive.

Next Steps

The bus termination or bus contention problem must be solved, in order to get a robust card that works smoothly when other cards are also present. See the blog posts from February-March 2018 for more details about what was already tried. A solution will require a person who’s experienced at electronic design, and has appropriate test equipment such as an oscilloscope and logic analyzer.

The current design uses a Lattice MachXO2 1200HC FPGA, and a Lattice JTAG programmer (or compatible) is required for programming it. The XO2-1200HC has more logic resources than are actually necessary for the Liron clone design. The cheaper XO2-640 or XO2-256 could be substituted instead. They are mostly or entirely pin-compatible with the XO2-1200HC.

Programming the FPGA with a JTAG programmer is fine for development use, but end users are unlikely to have one. If reprogramming by the end user is desired (say to switch between Liron and Disk 3.5 emulation behaviors), a different method of FPGA programming will need to be developed.

Read 5 comments and join the conversation 

« Newer PostsOlder Posts »