Reference Manual
Fortress
Technical documentation, setup guidance, and patching workflows.
← Back to Fortress overviewFortress Archive
Archived community reference. This page preserves the official LZX Community forum thread for Fortress inside the new documentation site.
Additional related discussions are included below.
Fortress is a low rez hi fi video graphics instrument with no CPU, based on analog clock oscillators and high speed comparators. Generate patterns and animation with 3-bit numbers using the techniques of early digital video art pioneers. Digitize and recolorize video sources in real time with internal palette memory. The perfect video synthesis voice module for recreating the cover art of 1970s textbooks and early arcade graphics.
Features
- Horizontal, vertical and low frequency analog clock VCOs with dedicated 3-bit counting DACs and selectable waveform patterns.
- Three realtime ADCs for 8-level slicing of analog video inputs, based on high speed analog comparators. An intricate Slip Sync mode can chain all three oscillators to create phase scrolling motion for animation.
- 4 Bit ALU (Arithmetic Logic Unit) with 8 selectable operations including Add, Subtract, AND, OR, XOR, NAND, NOR and XNOR.,
- 16 Stage Shift Register Delay Line with 8 selectable output taps.
- 32 Bit Cellular Automata generative drawing algorithm with 8 selectable rulesets.
- 48 Bit Linear Feedback Shift Register for pseudorandom patterned noise with 8 selectable XOR taps.
- 9-bit RGB DACs with palette memory and 8 selectable color palettes.
Specifications
- Width, 22HP
- Mounting Depth, 42mm
- Power +12V @ 180mA
- Power -12V @ 110mA
Designer Notes
Fortress is an encapsulation of the design concepts first presented in the LZX Castle DIY module series. It is also the successor to the LZX BitVision video synthesizer, the LZX Visionary logic series modules, and several unreleased prototypes throughout the years. It was conceptualized and designed by Phil Baljeu, Jonah Lange and Lars Larsen.
Historic design references include video synthesizers such as the EMS Spectre, Stephen Beck’s Video Weaver, realtime logic based arcade games such as Pong and Centipede, and the primitive colorizers found in consumer video cameras throughout the 1980s.
Palette Selection Reference
Program Selection Reference
000 – ARITHMETIC/LOGIC COMPOSITOR – ADC1 is combined with ADC2 according to an operation selected by ADC3: ADD, SUBTRACT, AND, OR, XOR, NAND, NOR, XNOR. The output of the ALU is 3 bits wide and goes directly to the DAC output. The ALU output also selects a 9-bit RGB value from the selected palette.
100 – 16X3-BIT RGB SHIFT REGISTER – ADC2 selects a shift register delay length. The ALU combines the latched and delayed versions of the ADC1 input.
010 – 32-BIT CELLULAR AUTOMATA – ADC2 selects a cellular automata ruleset. The cellular automata pattern is drawn by clocks created by OSC1 and OSC2. The ALU combines the cellular automata pattern with ADC1.
110 – 48-BIT LINEAR FEEDBACK SHIFT REGISTER – ADC2 selects a pseudorandom seed value. The LFSR pattern is drawn by clocks created by OSC1 and OSC2. The ALU combines the LFSR pattern with ADC1.
xx1 – OSCILLATOR SLIP SYNC ON – The last four program select modes are identical to the first four, but with the addition of motion generation through a special chained slip sync mode using OSC1, OSC2, and OSC3. In this mode, the 2-bit mode switches for OSC2 and OSC3 will select phase modulation directions and OSC2 phase swapping options.
Videos
Other Resources
Related Archived Discussions
Fortress Dev Blog August 2018
I’d like to talk a little bit about Fortress, where it comes from and where it’s going. The concept for Fortress started to form as a back and forth with Lars. Lars had been suggesting a ‘best of Castle’ module – something that was a collection of my favorite patches. Lars got me in to CPLD, which is a huge array of logic gates that you can program. After much mucking about I got the Xilinx suite installed on an old laptop. For some reason the software didn’t like my desktop PC, and every time I tried a new install it would just crash. No Joy. I got a dev board from Lars for the CPLD. I started programming the core for a Video Weaver style thing. This is where some ideas really started to form.
The Castle series is very concise in it’s format. 4HP panel width, a maximum of 8 jacks, a maximum of 2.25” depth, and through hole parts, so all the modules had to be designed with that in mind. With a larger format module we could have more complex operations and greater circuit density with SMD parts.
Lars asked me to come up with a panel mock up for a proposed Super-Castle. Since I am completely incapable of using Illustrator I came up with this:
I know, I know…
Derek Holzer posted some pages from a book on the Vasulkas, it had some images from a digital image processor they had made in the 1970’s. It was Some Analog to Digital Converters (ADC), an Arithmetic Logic Unit (ALU), and a Digital to Analog Converter (DAC). I believe it was 4-bit, but besides that, it was very ‘Castle’. I was aware of the Vasulkas work with computers in the 1970s, and this was definitely one of the inspirations for Castle, but I hadn’t seen the stuff with ALUs shown in such a way. This really inspired me. You could combine two digitized signals in really interesting and non-linear ways. So with this in my mind, and the Weaver concept, I started to come up with some block diagrams of modes that I thought would make up my perfect incarnation of an all enclosed Castle. Some of the ideas were the Weaver, an ALU, and a 3*64-bit shift register. All of these modes include Clocks and Waveform Generators so the module can be used by itself as a pattern generator, and ADCs to input signals to control or be used as input signals like the Waveform Generators.
The Video Waver is inspired by Stephen Becks Video Weaver, as seen here
The ALU is inspired by the work of the Vasulkas in this area.
The 3*64-bit shift register is based on my work with the Castles. If you think of the shift register as a bucket brigade, you put a signal in the input and 64 clock cycle later you would get that input at the last tap. It will only let signal in on the start of the clock pulse so it also provides a quantization effect. If you were able to select which tap you were viewing on you could shift the image horizontally. Of course this selecting can be done at video rates, so some real nice wiggles can be made. The registers are 3-bits deep, so you can wiggle a video signal split up in to 8 zones of brightness.
This is the block diagram I came up with to try and illustrate what Fortress could be:
Something I really wanted to do when I was developing concepts for Castle was a Palette swapper. Something you could input your 3-bit values in to and it would assign those 8 values to color values that weren’t just combinations of full red, green, and blue. Something that could give you brown, pink, grey, whatever. Unfortunately the number of inputs and PCB size prohibited this from being a Castle module. But now with Fortress this can be implemented. That’s where the CGA palette comes in. Lars and I are both huge nerds, obviously. We grew up playing computer games. The CGA was a weird thing. It wasn’t designed for gaming really. It was designed for high contrast text like on spreadsheets and stuff. This made for some interesting color choices. Some people hate them, some people might love them. I love them. If you are unfamiliar, there are basically two palettes in CGA, and a half brightness variant of each. The palettes are: Black, Cyan, Magenta, White, and Black, Yellow, Red, and White. The Half brightness variants would make Dark Cyan, Dark Magenta, Grey, etc. A funny thing that IBM did with RGBI monitors, which were used to display CGA was that what would be Dark Yellow would be interpreted in the monitor as Brown. This is something that will be replicated in Fortress, as it’s just a funny thing. I like funny things like that.
Well, that’s all I have to say for now.
I’m open to questions if you’ve got any…
Thread Replies
Loving how this forum is developing into a wealth of various behind the scenes insights.
Thanks
I couldn’t agree more. All of the behind the scenes information is extremely inspiring and helpful for folks like myself with limited video experience.
. can’t wait to see this in action! 
. i’m a big fan of the retro feel as well - have you seen this video on CGA ? as an apple/mac guy, i had no idea how pc video standards worked. i found the history fascinating.
My first CGA memory.
Looking at the rendering on the main product page, it looks like the only inputs are the VC inputs horizontally across the top. Is that correct or am I reading the markings incorrectly?
yes, thats correct. there are 3 vco cv inputs, and 3 adc inputs. the adc vc inputs are what you would use to input camera signals and such in to.
Can’t wait to take some full color RGB footage for a walk into this digital territory.
I can’t wait to see some CGA goodness
I’m pretty sure this will be my first LZX module. Along some necessary utilities, of course. It sounds/looks awfully interesting, as do all your modules, @pbalj! Can’t wait for the demos, and for the Fortress to ship.
Cheers,
Lukasz
fortess will be a blast I’m sure
I’ve got to get some funds together here to pre order
RIBBONS 3-Bit Digitizer Discussion
https://lzxindustries.net/products/ribbons
Ribbons is a 3-bit digitizer module for your EuroRack video synthesizer. Slice your video sources and waveforms into eight discrete bands which invoke the look of primitive digital graphics and video colorizers from the 1970s and 1980s.
Implemented with 9 high speed analog comparators and CMOS logic, the digitization technique employed by Ribbons lack any pixel clock or quantized time base. This reveals a surreal and silky quality to the image under modulation, which we feel is absent from modern digital video.
Features
- Hard edged binary 3-bit ADC and Window Key outputs
- Positive and negative 3-bit DAC outputs provide stepped analog waveforms
- Center and Span controls and CV inputs allow modulation of sampling offset and scale
- Enable and Disable inputs extend utility for masking and compositing in the patch
Legacy
-
Our first 3-bit digitizer module was 2012’s 8 Stage Video Quantizer & Sequencer, which was loosely inspired by the Amplitude Classifier module from the Sandin Image Processor.
-
In 2018, we released Castle 000 ADC and Castle 001 DAC as part of the Castle DIY module series
-
In 2019, we released Fortress, the first module to integrate ADC and DAC capabilities in the same module.
Specifications
- 8HP EuroRack Module
- Powered via 12V DC barrel or EuroRack power header
- Max Depth: 32mm
- +12V Power Consumption: 120mA
Thread Replies
Facebook question:
I’m guessing the lower left jack (arrow) is the input to be digitized? And D0, D1, and D2 are equivalent to the similarly named outputs on the Castle ADC. And I’m guessing that Center and Span are equivalent to Bias and Gain from the Castle ADC so the CV inputs are CV controls over that. But what do the other jacks do (EN, ~EN, ramp up, ramp down, and key)?
Lars answer:
You have the input and D0-D2 output correct. The center & span controls are a bit different. They are a new analog CV processor design with thru-zero modulation of span. The outputs of this internal circuit generate upper & lower thresholds. The area between the upper and lower thresholds is sliced into 8 equal bands, and then encoded to a 3-bit number. When Span goes negative, it inverts – allowing you to create ADC patterns that compress and expand under modulation (to do this with Castle or Fortress, you needed external VCAs). The Ramp up/down are DAC outputs (stair step waveforms) and the Enable/Disable inputs are video rate masking inputs to enable or disable he outputs (so it’s like having a compositor built in, so that you can combine or exclude the outputs from an external key/mask source.)
Facebook question:
How would you say this fits into a setup that already has Fortress in it?
Lars answer from FB:
Ribbons has some more advanced features than the Fortress ADCs, and focuses just on the ADC/DAC part of the workflow.
Lars answer from Discord:
Ribbons should play great with fortress and castle in the same way [as Castle and Fortress work together]. Castles are discrete functions. Fortress encapsulates a full voice. Ribbons encapsulates a component of a voice, it is a complex function with driver circuitry and voltage control.
In patch context, Ribbons is the first way in Gen3 to generate a 3-bit number. Other modules will receive 3-bit numbers. Together, that’s how you achieve Fortress style patches in Gen3.
wah, can’t wait for this! I love that early digital look
Really keen on this. Looking forward to a demo video.
There should be a stream on the LZX Twitch account really soon that’ll be Ribbons centred.
If you’re not on the LZX Discord, I recommend joining as it was announced on there. A couple of people have received their Ribbons orders already but I haven’t seen anyone post any video on there in the Gallery channel.
I am, thanks Robin:)
Fortress troubleshooting?
Hello,
I recently added a Fortress to my rack (in addition to a Bridge and a Memory Palace) and cant tell if I’ve missed a step in setup or if I need to configure the Memory Palace a certain way to display the Fortress’s oscillators, but I cannot get the fortress’s oscillators to create any patterns.
I’ve zeroed all of the switches and faders on the fortress and connected the fortress’s RGB output to the Memory Palace’s RGB inputs but the oscillator faders do not appear to be doing anything (no horizontal or vertical bars from osc 1 / osc 2, no lfo output from osc 3). If I adjust the ADC faders the fortress will output various solid colors but there does not seem to be any pattern generation.
Is there a way for me to troubleshoot this effectively? I just received the module and don’t want to assume that the unit is faulty and want to believe that I just need to tweak a setting somewhere either on the fortress or MP.
Thanks!
Thread Replies
How are you connecting the Sync I/O on the back of Fortress with your Memory Palace?
I initially had the sync out from the memory palace (sync source: internal) connected to the upper sync in rca jack on the fortress (loop thru: sync), but have since tried the other sync in jack on the fortress and the other jack/switch options on the memory palace to no avail. Just a white screen when I connect fortress rgb to memory palace rgb. My understanding is that an rca cable is an rca cable and that there aren’t special types, so I swapped out a different cable and still didn’t have any luck. I tried both in PAL and NTSC, same result. Thoughts?
The three ADCs are normalled to the three oscillators, via the attenuator above the slider.
Set the left two sliders halfway up, third slider down, then turn the 4th and 5th knobs to full - see what you get now.
You can also take the separate oscillator outputs and run them in to something else, just to see what they’re doing too.
Huh, after trying just about every combo of slider/knob values I could imagine last night, I just shut the rack down and came back this morning, tried what you described and seem to be getting pattern generation. Not sure what changed between last night and this morning but thank you for the suggestion!
The correct sync settings are:
Memory Palace - set to internal sync; sync output to either rear RCA jack on Fortress; in menu, source set to RGB
Fortress - sync from Memory Palace to either input; switch set to terminate
After that you can patch any of Fortress’s outputs to the RGB inputs on Memory Palace
Thank you! So if I were to flip the switch on fortress from terminate to loop thru and then add another module to my rack that needs to receive a sync input (ie. diver or tbc2), would I be able to use the other sync jack on the fortress as a thru jack to connect to additional modules? How would I go about syncing additional modules? Sorry if this has been covered a million times already!
Yes, you are correct. That is one way you could additional modules. You could also add modules between the MP and the Fortress. Some modules send stronger sync signals than others. That is why it is recommended to sync the Fortress to the MP and not the other way around.
Fortress doesn’t generate sync on its own. It has to receive it from a sync signal and you can then chain it to another module from there.
Word. Or no sync at all. 
Because of the termination switch, I keep Fortress at the end of my sync chain. I know it’s not necessary. FWIW, I haven’t had any issues with it set up that way.
Fortress Not Syncing
I just got Fortress and it doesn’t seem to sync properly. The modules after Fortress sync just fine, but my Fortress itself is completely unstable. For example, patching oscillator 1 out into Cortex I just get wild, out of sync kind of scrolling. With the Osc 1 fader all the way down I can see some scrolling horizontal bars, and using the trim pot I can kind of slow down the scrolling, but with the fader above the bottom it just freaks out. In the three patches video the same output gave typical vertical bars that multiply or divide in number depending on fader position. Has anyone else had this problem? I tried the sync switch in both positions and the terminate position has a negative effect on modules down stream, so it’s set back to sync thru. I tried both sync jacks, swapping back and forth. I also removed several modules just to be sure it wasn’t a lack of -12v power. Are there any known issues with Fortress sync?
Thread Replies
Gotta check the basics, excuse me for asking this if you already have… are the Program switches D0, D1 and D2 all down?
And does changing the Count switches change the shape of the waveform at all?
Any chance of taking some video to share?
Another good information-gathering test if you haven’t done it already: reduce your sync chain to just Cortex and Fortress, and see if that works.
Well, I’m happy to report that hooked directly to Visual Cortex, Fortress is working as expected. The only modules before Fortress previously were Memory Palace and Escher Sketch. Memory Palace is set to external sync and sync thru and Escher Sketch is set to sync thru. Are there any known issues with this signal flow?
Shouldn’t be any issues. You might try putting MemPal and ES back into the chain individually to see which one is not passing sync. Whichever one is causing the blockage can be put last in the chain.
All set! I previously had sync running from VC to MemPal, Escher, then out into a second case to Fortress, Diver, Navigator, PRay #2, and WotA. For some reason either MemPal (prob not) or Eshcer Sketch (my best guess) were messing up the sync chain. Now I have VC going straight out into the second case, then back into the first to MemPal and Escher and everything is behaving as it should.
My plan is to leave this setup alone and insert TBC2 before MemPal, receiving sync as it comes back into the case. For Chromag I’ll insert it between the two cases, meaning that Escher Sketch will be the planned termination point. I remember reading a while ago that Escher Sketch is best at the end of the chain, and with the current setup my sync problems have disappeared, so I’m a happy camper.
As a side note, PRay #1 syncs just fine in my Mantis being plugged in on the same sub-bus as Visual Cortex, for anyone that might wonder about that in the future.
Community
Search the LZX community forum for build notes, patch ideas, and troubleshooting threads about Fortress.