https://wiki.sandboxpedal.com/api.php?action=feedcontributions&feedformat=atom&user=MatthewSandbox Pedal Wiki - User contributions [en]2026-09-18T20:59:04ZUser contributionsMediaWiki 1.43.9https://wiki.sandboxpedal.com/index.php?title=Using_the_simulator_indicator_lamps&diff=27Using the simulator indicator lamps2026-09-05T01:14:25Z<p>Matthew: </p>
<hr />
<div>The simulator's '''Indicators''' section has two lamps, '''LED1''' and '''LED2''', which<br />
follow the registers <code>REG30</code> and <code>REG31</code> as your program runs. They<br />
give you a way to see a value you cannot hear while you are developing — an envelope<br />
follower, a tempo, the state of a switch.<br />
<br />
== How brightness is worked out ==<br />
<br />
The lamp reads its register as S1.23:<br />
<br />
* '''0''' is off.<br />
* '''1.0''' is full brightness.<br />
* A negative value is off. It is not rectified, so a bipolar signal lights the lamp only<br />
on its positive half.<br />
<br />
The scale is linear on purpose. A program that wants a curve is two instructions from the<br />
curve it wants.<br />
<br />
'''The FV-1 has no LEDs.''' The lamps exist in the simulator only — nothing lights up on<br />
the pedal when your program writes to <code>REG30</code> or <code>REG31</code>. They are a<br />
debugging aid for the time you spend writing code, not an output you can ship. A design<br />
that needs an indicator on the finished pedal needs one built into the hardware.<br />
<br />
== Lighting a lamp ==<br />
<br />
Write the value you want to see into <code>REG30</code> or <code>REG31</code>:<br />
<br />
<pre><br />
; #LED1 Rate<br />
<br />
skp run, loop<br />
wlds sin0, 12, 32767<br />
<br />
loop:<br />
cho rdal, sin0 ; bipolar, -1 to +1<br />
sof 0.5, 0.5 ; fold to 0..1 so the lamp follows the whole cycle<br />
wrax reg30, 0<br />
</pre><br />
<br />
Without the <code>sof 0.5, 0.5</code> the lamp is dark for half of every LFO cycle.<br />
<br />
== Naming the lamps ==<br />
<br />
A comment tag renames a lamp in the panel:<br />
<br />
<pre><br />
; #LED1 Tempo<br />
</pre><br />
<br />
The tag is read from the comment part of the line, so it never collides with code. It is<br />
the same mechanism that names the pots — see<br />
[[Labelling pots and lamps in your source]].<br />
<br />
== A gotcha ==<br />
<br />
Nothing on the FV-1 reserves <code>REG30</code> or <code>REG31</code>. A program that parks<br />
scratch values there will light the lamps by accident. If a lamp flickers for no reason you<br />
can explain, check whether those two registers are being used as general-purpose storage.<br />
<br />
== See also ==<br />
* [[Using the FV-1 simulator]]<br />
* [[Controlling the simulator with MIDI]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=How-to_guides&diff=26How-to guides2026-09-05T01:11:39Z<p>Matthew: </p>
<hr />
<div>This page collects the step-by-step guides for building, programming and coding the FV-1 Sandbox.<br />
<br />
If you are starting from nothing, work through them in this order.<br />
<br />
== Getting the hardware running ==<br />
<br />
* [[Building the FV-1 Sandbox pedal]] — where to find the PCB, schematic and firmware files.<br />
* [[Installing the RP2040 programmer firmware]] — turn a bare RP2040 board into a Sandbox programmer.<br />
* [[Programming an EEPROM with HEX files]] — drag a HEX file onto a drive and your pedal reloads.<br />
<br />
== Writing code ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]] — the browser-based code editor and assembler.<br />
* [[Writing your first FV-1 program]] — from pass-through to a working tremolo.<br />
* [[Using the FV-1 simulator]] — hear an algorithm before you program hardware.<br />
* [[Controlling the simulator with MIDI]] — drive the pots and the effect switch from a hardware controller.<br />
* [[Using the simulator indicator lamps]] — watch REG30 and REG31 while a program runs.<br />
* [[Labelling pots and lamps in your source]] — comment tags that name the simulator's controls.<br />
<br />
== When something goes wrong ==<br />
<br />
* [[Troubleshooting]]<br />
<br />
== Tools ==<br />
<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]<br />
* [https://github.com/DisasterAreaDesigns/Sandbox-FV1 Sandbox-FV1 on GitHub]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Using_the_FV-1_simulator&diff=25Using the FV-1 simulator2026-09-05T01:10:30Z<p>Matthew: </p>
<hr />
<div>The [[Using the Sandbox FV-1 Editor|Sandbox FV-1 Editor]] includes a software model of the FV-1 chip. Your assembled program runs through it in real time, so you can hear an algorithm on a test tone, an audio file or live input before you program any hardware.<br />
<br />
Open it with the '''TEST DRIVE''' tab on the right-hand edge of the editor.<br />
<br />
== Getting sound out of it ==<br />
<br />
# Assemble your program. The simulator will show '''Not loaded''' if no program is assembled.<br />
# Choose an input under '''Input Source'''.<br />
# Press '''Play'''.<br />
<br />
Leave '''Reload on assemble''' ticked and every successful build drops straight into the running simulator without interrupting playback. This is the fast way to work: edit, assemble, listen, repeat.<br />
<br />
'''Reset''' stops playback and clears delay memory. Reach for it when a program has filled the delay line with something horrible and you want a clean start.<br />
<br />
'''Alt+P (⌃+P on Mac)''' plays and stops from anywhere, including the editor, and opens the tab as it starts.<br />
<br />
== Input sources ==<br />
<br />
{| class="wikitable"<br />
! Source !! Good for<br />
|-<br />
| Sine tone || Filters, pitch effects, anything where you need to hear one frequency clearly. The frequency slider covers 20 Hz to 8 kHz.<br />
|-<br />
| Sawtooth / Square || Harmonically rich material — filters and distortion show their character better than on a sine.<br />
|-<br />
| White noise || Filter shapes and reverb tails.<br />
|-<br />
| Clicks || Short impulses 1 second apart - useful for testing reverb and delay trails<br />
|-<br />
| Audio file || Load a guitar DI or drum loop and hear the effect in context.<br />
|-<br />
| Live input || Play into it through your audio interface.<br />
|}<br />
<br />
== Pots ==<br />
<br />
The three sliders map to '''POT0''', '''POT1''' and '''POT2''' exactly as the physical controls do on the pedal, and they update while the program is running. If your algorithm reads <code>POT0</code>, moving the slider changes it live.<br />
<br />
== Levels ==<br />
<br />
'''Input''' and '''Output''' trim the signal either side of the simulated chip, in dB. Input defaults to −6 dB.<br />
<br />
This matters more than it sounds. The FV-1's accumulator saturates, and the simulator models that saturation, so an input that is too hot will clip inside your algorithm in the same way it would on hardware. If something sounds unexpectedly crunchy, pull the input level down before you go hunting for a bug in your code.<br />
<br />
'''Bypass''' passes the dry signal through so you can A/B against the effect.<br />
<br />
== The crystal setting ==<br />
<br />
The '''Clock''' section changes the rate the simulated chip runs at, the same way swapping the crystal does on real hardware. The standard FV-1 clock is 32.768 kHz.<br />
<br />
Your program does not change — it still runs 128 instructions per sample. What changes is everything measured in samples:<br />
<br />
* Delay times scale with the clock. The FV-1 has a fixed 32768 words of delay memory, so a faster clock buys you proportionally ''less'' delay time. The readout under the selector shows the maximum delay and Nyquist frequency for the rate you have chosen.<br />
* LFO sweeps scale too, so a chorus tuned at 32.768 kHz will modulate faster at 48 kHz.<br />
<br />
Changing the crystal rebuilds the audio engine, which clears delay memory. The '''Audio File''' input source will be resampled to the FV-1 crystal frequency.<br />
<br />
== What the model does and does not get right ==<br />
<br />
The simulator is faithful about the things that give the FV-1 its character:<br />
<br />
* 24-bit accumulator saturation.<br />
* The 14-bit companded delay memory — the reason FV-1 delays sound the way they do.<br />
* LFO rates and depths, following the equations in Spin's application note AN-0001.<br />
<br />
One approximation to know about: the fractional interpolation inside <code>CHO</code> is approximated rather than modelled exactly. Chorus and flange will sound right, but they will not match hardware sample for sample.<br />
<br />
'''Always confirm a design on the real pedal before you ship it.''' The simulator is for iterating quickly, not for signing off.<br />
<br />
== See also ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Writing your first FV-1 program]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Using_the_FV-1_simulator&diff=24Using the FV-1 simulator2026-09-05T01:10:19Z<p>Matthew: </p>
<hr />
<div>The [[Using the Sandbox FV-1 Editor|Sandbox FV-1 Editor]] includes a software model of the FV-1 chip. Your assembled program runs through it in real time, so you can hear an algorithm on a test tone, an audio file or live input before you program any hardware.<br />
<br />
Open it with the '''TEST DRIVE''' tab on the right-hand edge of the editor.<br />
<br />
== Getting sound out of it ==<br />
<br />
# Assemble your program. The simulato will show '''Not loaded''' if no program is assembled.<br />
# Choose an input under '''Input Source'''.<br />
# Press '''Play'''.<br />
<br />
Leave '''Reload on assemble''' ticked and every successful build drops straight into the running simulator without interrupting playback. This is the fast way to work: edit, assemble, listen, repeat.<br />
<br />
'''Reset''' stops playback and clears delay memory. Reach for it when a program has filled the delay line with something horrible and you want a clean start.<br />
<br />
'''Alt+P (⌃+P on Mac)''' plays and stops from anywhere, including the editor, and opens the tab as it starts.<br />
<br />
== Input sources ==<br />
<br />
{| class="wikitable"<br />
! Source !! Good for<br />
|-<br />
| Sine tone || Filters, pitch effects, anything where you need to hear one frequency clearly. The frequency slider covers 20 Hz to 8 kHz.<br />
|-<br />
| Sawtooth / Square || Harmonically rich material — filters and distortion show their character better than on a sine.<br />
|-<br />
| White noise || Filter shapes and reverb tails.<br />
|-<br />
| Clicks || Short impulses 1 second apart - useful for testing reverb and delay trails<br />
|-<br />
| Audio file || Load a guitar DI or drum loop and hear the effect in context.<br />
|-<br />
| Live input || Play into it through your audio interface.<br />
|}<br />
<br />
== Pots ==<br />
<br />
The three sliders map to '''POT0''', '''POT1''' and '''POT2''' exactly as the physical controls do on the pedal, and they update while the program is running. If your algorithm reads <code>POT0</code>, moving the slider changes it live.<br />
<br />
== Levels ==<br />
<br />
'''Input''' and '''Output''' trim the signal either side of the simulated chip, in dB. Input defaults to −6 dB.<br />
<br />
This matters more than it sounds. The FV-1's accumulator saturates, and the simulator models that saturation, so an input that is too hot will clip inside your algorithm in the same way it would on hardware. If something sounds unexpectedly crunchy, pull the input level down before you go hunting for a bug in your code.<br />
<br />
'''Bypass''' passes the dry signal through so you can A/B against the effect.<br />
<br />
== The crystal setting ==<br />
<br />
The '''Clock''' section changes the rate the simulated chip runs at, the same way swapping the crystal does on real hardware. The standard FV-1 clock is 32.768 kHz.<br />
<br />
Your program does not change — it still runs 128 instructions per sample. What changes is everything measured in samples:<br />
<br />
* Delay times scale with the clock. The FV-1 has a fixed 32768 words of delay memory, so a faster clock buys you proportionally ''less'' delay time. The readout under the selector shows the maximum delay and Nyquist frequency for the rate you have chosen.<br />
* LFO sweeps scale too, so a chorus tuned at 32.768 kHz will modulate faster at 48 kHz.<br />
<br />
Changing the crystal rebuilds the audio engine, which clears delay memory. The '''Audio File''' input source will be resampled to the FV-1 crystal frequency.<br />
<br />
== What the model does and does not get right ==<br />
<br />
The simulator is faithful about the things that give the FV-1 its character:<br />
<br />
* 24-bit accumulator saturation.<br />
* The 14-bit companded delay memory — the reason FV-1 delays sound the way they do.<br />
* LFO rates and depths, following the equations in Spin's application note AN-0001.<br />
<br />
One approximation to know about: the fractional interpolation inside <code>CHO</code> is approximated rather than modelled exactly. Chorus and flange will sound right, but they will not match hardware sample for sample.<br />
<br />
'''Always confirm a design on the real pedal before you ship it.''' The simulator is for iterating quickly, not for signing off.<br />
<br />
== See also ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Writing your first FV-1 program]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Writing_your_first_FV-1_program&diff=23Writing your first FV-1 program2026-09-05T01:05:28Z<p>Matthew: </p>
<hr />
<div>This guide builds up a working tremolo from nothing, one step at a time. Every example here assembles cleanly and can be pasted straight into the [https://fv1.sandboxpedal.com Sandbox FV-1 Editor].<br />
<br />
You do not need a pedal to follow along — the [[Using the FV-1 simulator|simulator]] will play all of it.<br />
<br />
== How an FV-1 program works ==<br />
<br />
The FV-1 runs your program '''once per audio sample''', 32768 times a second. There is no main loop that you write; the chip loops for you.<br />
<br />
That gives you a hard budget of '''128 instructions'''. Anything shorter is padded with NOPs automatically. There is no way to spend more time on one sample than another.<br />
<br />
Almost everything flows through a single '''accumulator''' (ACC). You read a value into it, do arithmetic on it, and write it somewhere. Most instructions multiply by a coefficient on the way past.<br />
<br />
The registers you will use first:<br />
<br />
{| class="wikitable"<br />
! Register !! Meaning<br />
|-<br />
| <code>ADCL</code>, <code>ADCR</code> || Audio input, left and right<br />
|-<br />
| <code>DACL</code>, <code>DACR</code> || Audio output, left and right<br />
|-<br />
| <code>POT0</code>–<code>POT2</code> || The three control knobs, 0.0 to 1.0<br />
|-<br />
| <code>REG0</code>–<code>REG31</code> || General-purpose storage<br />
|}<br />
<br />
Coefficients are fixed-point fractions in the range −1.0 to just under 1.0. You cannot write <code>1.0</code> and expect exactly one in every field, which is why you will see <code>0.999</code> in places where you might expect 1.<br />
<br />
== Step 1: pass-through ==<br />
<br />
The smallest useful program copies input to output.<br />
<br />
<pre><br />
RDAX ADCL, 1.0 ; ACC = left input<br />
WRAX DACL, 0.0 ; left output = ACC, then clear ACC<br />
<br />
RDAX ADCR, 1.0 ; ACC = right input<br />
WRAX DACR, 0.0 ; right output = ACC, then clear ACC<br />
</pre><br />
<br />
Two instructions per channel. <code>RDAX</code> reads a register into the accumulator, multiplying by the coefficient on the way in. <code>WRAX</code> writes the accumulator to a register and then multiplies what remains in ACC by ''its'' coefficient.<br />
<br />
That second coefficient is the part that catches people out. <code>WRAX DACL, 0.0</code> means "write ACC to the left DAC, then zero the accumulator" — which is what you want before starting work on the other channel. Using <code>WRAX DACL, 1.0</code> would leave the value in ACC and the right channel would come out as a mix of both.<br />
<br />
Assemble this and play it through the simulator. It should sound like nothing at all, which is the correct result.<br />
<br />
== Step 2: a volume control ==<br />
<br />
Now put POT0 in charge of the level.<br />
<br />
<pre><br />
RDAX ADCL, 1.0<br />
MULX POT0 ; ACC = ACC * POT0<br />
WRAX DACL, 0.0<br />
<br />
RDAX ADCR, 1.0<br />
MULX POT0<br />
WRAX DACR, 0.0<br />
</pre><br />
<br />
<code>MULX</code> multiplies the accumulator by the contents of a register. Because <code>POT0</code> reads 0.0 to 1.0, this is a straightforward volume knob.<br />
<br />
Open the SIM panel and move the POT0 slider while it plays.<br />
<br />
== Step 3: an LFO ==<br />
<br />
A tremolo is a volume control that moves on its own, so the next piece is a low-frequency oscillator.<br />
<br />
The FV-1 has two sine LFOs (<code>SIN0</code>, <code>SIN1</code>) and two ramp LFOs (<code>RMP0</code>, <code>RMP1</code>). You start a sine LFO with <code>WLDS</code>:<br />
<br />
<pre><br />
WLDS SIN0, 40, 32767 ; LFO 0: rate 40, full amplitude<br />
</pre><br />
<br />
This only needs to happen once, not on every one of the 32768 samples per second. The idiom for that is a conditional skip on the <code>RUN</code> flag, which is clear on the very first pass through the program and set on every pass after:<br />
<br />
<pre><br />
SKP RUN, loop<br />
WLDS SIN0, 40, 32767<br />
loop:<br />
</pre><br />
<br />
On the first sample, <code>RUN</code> is clear, so the skip does not happen and the LFO is set up. On every subsequent sample the program jumps straight over <code>WLDS</code> to the <code>loop</code> label.<br />
<br />
To read the LFO's current value, use <code>CHO RDAL</code>:<br />
<br />
<pre><br />
CHO RDAL, SIN0 ; ACC = the sine LFO, swinging -1.0 to +1.0<br />
</pre><br />
<br />
== Step 4: shaping the LFO into a gain ==<br />
<br />
The LFO swings from −1.0 to +1.0, but a gain needs to be positive. <code>SOF</code> — scale and offset — fixes that in one instruction. <code>SOF a, b</code> computes <code>ACC = ACC × a + b</code>.<br />
<br />
<pre><br />
CHO RDAL, SIN0 ; -1.0 .. +1.0<br />
SOF 0.5, 0.5 ; halve it, shift it up: now 0.0 .. 1.0<br />
</pre><br />
<br />
Next, depth. Multiplying by POT1 scales the swing down, and a second <code>SOF</code> flips it so the gain sits just below unity at minimum depth:<br />
<br />
<pre><br />
MULX POT1 ; 0.0 .. depth<br />
SOF -1.0, 0.999 ; (1 - depth) .. 1.0<br />
</pre><br />
<br />
With POT1 at zero the gain is a constant 0.999 — effectively off. With POT1 fully up the gain swings across the full range.<br />
<br />
== The finished tremolo ==<br />
<br />
<pre><br />
; Simple tremolo<br />
; POT0 = rate, POT1 = depth<br />
<br />
EQU mod REG0<br />
<br />
; Start the sine LFO once, on the first pass only<br />
SKP RUN, loop<br />
WLDS SIN0, 40, 32767<br />
<br />
loop:<br />
; POT0 sets the LFO rate<br />
RDAX POT0, 0.5<br />
SOF 1.0, 0.02<br />
WRAX SIN0_RATE, 0.0<br />
<br />
; Read the LFO and fold it into a 0..1 gain<br />
CHO RDAL, SIN0<br />
SOF 0.5, 0.5<br />
MULX POT1<br />
SOF -1.0, 0.999<br />
WRAX mod, 0.0<br />
<br />
; Apply the gain to both channels<br />
RDAX ADCL, 1.0<br />
MULX mod<br />
WRAX DACL, 0.0<br />
<br />
RDAX ADCR, 1.0<br />
MULX mod<br />
WRAX DACR, 0.0<br />
</pre><br />
<br />
Sixteen instructions, out of the 128 available.<br />
<br />
Two new things appear here. <code>EQU mod REG0</code> gives <code>REG0</code> a readable name — the assembler substitutes it, and it costs nothing at runtime. Writing to <code>SIN0_RATE</code> changes the LFO rate while the program runs, which is what turns POT0 into a rate knob; the <code>SOF 1.0, 0.02</code> keeps the rate from reaching zero at the bottom of the sweep.<br />
<br />
Load it into the simulator, press Play, and move POT0 and POT1.<br />
<br />
== Where to go next ==<br />
<br />
* '''Delay memory.''' The <code>MEM</code> directive allocates space in the FV-1's 32768 words of delay memory: <code>MEM delay 16000</code>. It creates three symbols — <code>delay</code> (start), <code>delay#</code> (end) and <code>delay^</code> (midpoint). <code>RDA</code> and <code>WRA</code> read and write it.<br />
* '''The built-in examples.''' '''Load File…''' in the editor offers Pass-through, Delay, Chorus and Tremolo. Reading working code is the fastest way to pick up the idioms.<br />
* '''The instruction reference.''' The '''HELP''' tab lists the full instruction set with operand formats.<br />
* '''Spin's documentation.''' The FV-1 datasheet and application note AN-0001 are the authoritative source on LFO behaviour and the fixed-point formats.<br />
<br />
== A few things that bite beginners ==<br />
<br />
* '''Forgetting to clear ACC.''' If a channel sounds like it has the other channel bleeding into it, check your <code>WRAX</code> coefficients.<br />
* '''Coefficient range.''' Coefficients are fractions below 1.0. If you need gain above unity, do it in stages or use a format that allows it.<br />
* '''Setup code running every sample.''' <code>WLDS</code> and friends belong behind a <code>SKP RUN</code> guard.<br />
* '''Running out of instructions.''' 128 is a hard ceiling. If you hit it, the answer is usually a cheaper filter, not a cleverer one.<br />
* '''Trusting the simulator on chorus.''' <code>CHO</code> interpolation is approximated. Confirm modulation effects on hardware.<br />
<br />
== See also ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Using the FV-1 simulator]]<br />
* [[Programming an EEPROM with HEX files]]<br />
* [[Controlling the simulator with MIDI]] — drive the pots and the effect switch from a hardware controller.<br />
* [[Using the simulator indicator lamps]] — watch REG30 and REG31 while a program runs.<br />
* [[Labelling pots and lamps in your source]] — comment tags that name the simulator's controls.<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Labelling_pots_and_lamps_in_your_source&diff=22Labelling pots and lamps in your source2026-09-05T01:04:55Z<p>Matthew: Created page with "A slider marked '''POT0''' tells you nothing when you come back to a program six months later. The editor reads short tags out of your comments and uses them to label the simulator's controls as you type. == The tags == {| class="wikitable" ! Tag !! Labels |- | <code>; #POT0 Delay time</code> || POT0, POT1, POT2 |- | <code>; #LED1 Tempo</code> || The two indicator lamps |} Tags are read from the comment part of a line, so they n..."</p>
<hr />
<div>A slider marked '''POT0''' tells you nothing when you come back to a program six months<br />
later. The editor reads short tags out of your comments and uses them to label the<br />
simulator's controls as you type.<br />
<br />
== The tags ==<br />
<br />
{| class="wikitable"<br />
! Tag !! Labels<br />
|-<br />
| <code>; #POT0 Delay time</code> || POT0, POT1, POT2<br />
|-<br />
| <code>; #LED1 Tempo</code> || The two [[Using the simulator indicator lamps|indicator lamps]]<br />
|}<br />
<br />
Tags are read from the comment part of a line, so they never collide with code. Hovering a<br />
renamed pot still shows which one it is underneath.<br />
<br />
== A related tag ==<br />
<br />
<code>; #slot 5</code> works the same way on the hardware side. With<br />
'''Filename / Toggle Position''' set to '''AUTO''', the editor reads the tag and writes to<br />
that slot, so a program carries its own destination. With no tag it writes<br />
<code>3.hex</code>, the slot a board with no toggles fitted reads. See<br />
[[Using the Sandbox FV-1 Editor]].<br />
<br />
== See also ==<br />
* [[Using the FV-1 simulator]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Using_the_simulator_indicator_lamps&diff=21Using the simulator indicator lamps2026-09-05T01:04:29Z<p>Matthew: Created page with "The simulator's '''Indicators''' section has two lamps, '''LED1''' and '''LED2''', which follow the registers <code>REG30</code> and <code>REG31</code> as your program runs. They give you a way to see a value you cannot hear — an envelope follower, a tempo, the state of a switch. == How brightness is worked out == The lamp reads its register as S1.23: * '''0''' is off. * '''1.0''' is full brightness. * A negative value is off. It is not rectified, so a bipolar signa..."</p>
<hr />
<div>The simulator's '''Indicators''' section has two lamps, '''LED1''' and '''LED2''', which<br />
follow the registers <code>REG30</code> and <code>REG31</code> as your program runs. They<br />
give you a way to see a value you cannot hear — an envelope follower, a tempo, the state<br />
of a switch.<br />
<br />
== How brightness is worked out ==<br />
<br />
The lamp reads its register as S1.23:<br />
<br />
* '''0''' is off.<br />
* '''1.0''' is full brightness.<br />
* A negative value is off. It is not rectified, so a bipolar signal lights the lamp only<br />
on its positive half.<br />
<br />
The scale is linear on purpose. A program that wants a curve is two instructions from the<br />
curve it wants.<br />
<br />
== Lighting a lamp ==<br />
<br />
Write the value you want to see into <code>REG30</code> or <code>REG31</code>:<br />
<br />
<pre><br />
; #LED1 Rate<br />
<br />
skp run, loop<br />
wlds sin0, 12, 32767<br />
<br />
loop:<br />
cho rdal, sin0 ; bipolar, -1 to +1<br />
sof 0.5, 0.5 ; fold to 0..1 so the lamp follows the whole cycle<br />
wrax reg30, 0<br />
</pre><br />
<br />
Without the <code>sof 0.5, 0.5</code> the lamp is dark for half of every LFO cycle.<br />
<br />
== Naming the lamps ==<br />
<br />
A comment tag renames a lamp in the panel:<br />
<br />
<pre><br />
; #LED1 Tempo<br />
</pre><br />
<br />
The tag is read from the comment part of the line, so it never collides with code. It is<br />
the same mechanism that names the pots — see<br />
[[Labelling pots and lamps in your source]].<br />
<br />
== A gotcha ==<br />
<br />
Nothing on the FV-1 reserves <code>REG30</code> or <code>REG31</code>. A program that parks<br />
scratch values there will light the lamps by accident. If a lamp flickers for no reason you<br />
can explain, check whether those two registers are being used as general-purpose storage.<br />
<br />
== See also ==<br />
* [[Using the FV-1 simulator]]<br />
* [[Controlling the simulator with MIDI]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Controlling_the_simulator_with_MIDI&diff=20Controlling the simulator with MIDI2026-09-05T01:04:06Z<p>Matthew: Created page with "The simulator in the Sandbox FV-1 Editor can be played from a MIDI controller plugged into your computer. The pots and the effect switch respond to control changes, so you can sweep a parameter with a real fader while a program runs. The Sandbox pedal itself has no MIDI input. This drives the simulator only. == Before you start == Web MIDI needs Chrome, Edge or Firefox. Safari does not implement it, so the '''MIDI Control''' section w..."</p>
<hr />
<div>The simulator in the [[Using the Sandbox FV-1 Editor|Sandbox FV-1 Editor]] can be played<br />
from a MIDI controller plugged into your computer. The pots and the effect switch respond<br />
to control changes, so you can sweep a parameter with a real fader while a program runs.<br />
<br />
The Sandbox pedal itself has no MIDI input. This drives the simulator only.<br />
<br />
== Before you start ==<br />
<br />
Web MIDI needs Chrome, Edge or Firefox. Safari does not implement it, so the<br />
'''MIDI Control''' section will not connect there. Everything else in the simulator still<br />
works — see [[Using the FV-1 simulator]].<br />
<br />
== Connecting a controller ==<br />
<br />
# Open the '''TEST DRIVE''' tab and find the '''MIDI Control''' section.<br />
# Press '''Enable MIDI''' and allow the browser's prompt.<br />
# Choose an '''Input'''. ''All inputs'' listens to every device attached.<br />
# Choose a '''Channel''', or leave it on ''Omni'' to accept all sixteen.<br />
<br />
The status line beside the button shows the last message that was accepted. If it never<br />
changes while you move a control, the message is not reaching the page at all — check the<br />
input and channel before you check anything else.<br />
<br />
Your input and channel are remembered between sessions, and a controller that is unplugged<br />
and plugged back in is picked up again on its own.<br />
<br />
== What the controls do ==<br />
<br />
{| class="wikitable"<br />
! Control change !! Moves<br />
|-<br />
| CC50 || POT0<br />
|-<br />
| CC51 || POT1<br />
|-<br />
| CC52 || POT2<br />
|-<br />
| CC102 || The effect switch: 0–63 bypasses, 64–127 engages<br />
|}<br />
<br />
MIDI moves the same controls the sliders do, at the full 128 steps a control change<br />
carries, so a program cannot tell the difference between a fader and a mouse.<br />
<br />
== See also ==<br />
* [[Using the FV-1 simulator]]<br />
* [[Using the Sandbox FV-1 Editor]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Main_Page&diff=19Main Page2026-08-23T23:53:30Z<p>Matthew: Link the how-to guides index</p>
<hr />
<div><strong>Welcome to Sandbox Pedal!</strong><br />
<br />
Knowledge Base for DSP Guitar Pedal DIY.<br />
<br />
What is Sandbox? It's an open-source hardware and software package that allows for digital pedal DIY. It uses the Spin Semiconductor FV-1 digital signal processing (DSP) integrated circuit and an off-the-shelf RP2040 microcontroller board, and presents the user with the simplest possible way to get started.<br />
<br />
# Write your signal processing code or find some cool code from another user.<br />
# Use our code editor to assemble into a HEX file.<br />
# Drag the HEX file into the Sandbox FV-1 pedal.<br />
# Play.<br />
<br />
No drivers to install. No operating system requirements. No need to be tied to any particular hardware. If you don't want to buy anything from us, that's okay - we made it all free anyway.<br />
<br />
The bare minimum thing you'll need is an RP2040 board like a RP2040-Zero or Raspberry Pi Pico. These are open-source microcontrollers with a USB port and lots of pins you can use to interface with the outside world. Connect it to your computer, drag our firmware into the board, then hook up a couple of wires to the EEPROM in your pedal. Drag a HEX file into the RP2040 and the EEPROM will program automatically. You don't need any drivers, no software, nothing but the normal file explorer / Finder / file manager application on your computer.<br />
<br />
Why do we need this? Honestly, we don't. There are plenty of other ways to get started with DSP, including several other FV-1 based projects. Go ahead and try some of them out.<br />
<br />
[https://www.pedalpcb.com/product/fv1dev/ PedalPCB FV-1 DEV] <br />
<br />
* Requires building a PCB including two 28-pin surface-mount ICs.<br />
* Requires command-line tools for Mac / Linux.<br />
* Programming software needs .BIN files instead of native FV-1 HEX.<br />
* Works best on Windows but limited / basic Mac / Linux support.<br />
* Requires at least two applications to work (FV-1 assembler or SpinCAD and AsProgrammer or CLI tools)<br />
* Base hardware is mono in and out<br />
<br />
Okay, I see you're back! How was that experience? A little cryptic, maybe? You need to install some drivers, or maybe update your Python install, something like that? Then you need to build a pedal from a kit and maybe that doesn't work first time, sure, we get it.<br />
<br />
We're trying to remove as much friction as possible, and that starts with good tools. Ask your granddad about good tools vs. cheap tools and you'll probably hear something like "buy it nice or buy it twice," and that definitely agrees with our findings.<br />
<br />
Making a chorus algorithm isn't harder than swapping diodes in a Tube Screamer, but the current state of the industry makes it ''seem'' a lot more difficult''.'' Starting DSP isn't hard, but there are a lot of steps and every single one of them has a path to failure.<br />
<br />
The traditional way of getting started with FV-1 was to buy the official development board (US$120) from Spin Semiconductor, then use their SpinASM IDE program on a Windows computer to develop and deploy your algorithms. The dev board has RCA inputs and isn't particularly guitar-friendly, so you really need some extra hardware to get something that's closer to a real pedal.<br />
<br />
Once you have your algorithms, you need to burn them to an EEPROM for use with an actual pedal. You can use the dev board to program EEPROMS but it's a bit clunky and you need the IDE to use it. It's fine for one pedal but if you wanted to make 50 or 100 a standalone EEPROM programmer makes more sense.<br />
<br />
== Getting started ==<br />
* [[How-to guides]]<br />
* [[Building the FV-1 Sandbox pedal]]<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]<br />
* [[Troubleshooting]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Writing_your_first_FV-1_program&diff=18Writing your first FV-1 program2026-08-23T23:53:27Z<p>Matthew: Add how-to guide</p>
<hr />
<div>This guide builds up a working tremolo from nothing, one step at a time. Every example here assembles cleanly and can be pasted straight into the [https://fv1.sandboxpedal.com Sandbox FV-1 Editor].<br />
<br />
You do not need a pedal to follow along — the [[Using the FV-1 simulator|simulator]] will play all of it.<br />
<br />
== How an FV-1 program works ==<br />
<br />
The FV-1 runs your program '''once per audio sample''', 32768 times a second. There is no main loop that you write; the chip loops for you.<br />
<br />
That gives you a hard budget of '''128 instructions'''. Anything shorter is padded with NOPs automatically. There is no way to spend more time on one sample than another.<br />
<br />
Almost everything flows through a single '''accumulator''' (ACC). You read a value into it, do arithmetic on it, and write it somewhere. Most instructions multiply by a coefficient on the way past.<br />
<br />
The registers you will use first:<br />
<br />
{| class="wikitable"<br />
! Register !! Meaning<br />
|-<br />
| <code>ADCL</code>, <code>ADCR</code> || Audio input, left and right<br />
|-<br />
| <code>DACL</code>, <code>DACR</code> || Audio output, left and right<br />
|-<br />
| <code>POT0</code>–<code>POT2</code> || The three control knobs, 0.0 to 1.0<br />
|-<br />
| <code>REG0</code>–<code>REG31</code> || General-purpose storage<br />
|}<br />
<br />
Coefficients are fixed-point fractions in the range −1.0 to just under 1.0. You cannot write <code>1.0</code> and expect exactly one in every field, which is why you will see <code>0.999</code> in places where you might expect 1.<br />
<br />
== Step 1: pass-through ==<br />
<br />
The smallest useful program copies input to output.<br />
<br />
<pre><br />
RDAX ADCL, 1.0 ; ACC = left input<br />
WRAX DACL, 0.0 ; left output = ACC, then clear ACC<br />
<br />
RDAX ADCR, 1.0 ; ACC = right input<br />
WRAX DACR, 0.0 ; right output = ACC, then clear ACC<br />
</pre><br />
<br />
Two instructions per channel. <code>RDAX</code> reads a register into the accumulator, multiplying by the coefficient on the way in. <code>WRAX</code> writes the accumulator to a register and then multiplies what remains in ACC by ''its'' coefficient.<br />
<br />
That second coefficient is the part that catches people out. <code>WRAX DACL, 0.0</code> means "write ACC to the left DAC, then zero the accumulator" — which is what you want before starting work on the other channel. Using <code>WRAX DACL, 1.0</code> would leave the value in ACC and the right channel would come out as a mix of both.<br />
<br />
Assemble this and play it through the simulator. It should sound like nothing at all, which is the correct result.<br />
<br />
== Step 2: a volume control ==<br />
<br />
Now put POT0 in charge of the level.<br />
<br />
<pre><br />
RDAX ADCL, 1.0<br />
MULX POT0 ; ACC = ACC * POT0<br />
WRAX DACL, 0.0<br />
<br />
RDAX ADCR, 1.0<br />
MULX POT0<br />
WRAX DACR, 0.0<br />
</pre><br />
<br />
<code>MULX</code> multiplies the accumulator by the contents of a register. Because <code>POT0</code> reads 0.0 to 1.0, this is a straightforward volume knob.<br />
<br />
Open the SIM panel and move the POT0 slider while it plays.<br />
<br />
== Step 3: an LFO ==<br />
<br />
A tremolo is a volume control that moves on its own, so the next piece is a low-frequency oscillator.<br />
<br />
The FV-1 has two sine LFOs (<code>SIN0</code>, <code>SIN1</code>) and two ramp LFOs (<code>RMP0</code>, <code>RMP1</code>). You start a sine LFO with <code>WLDS</code>:<br />
<br />
<pre><br />
WLDS SIN0, 40, 32767 ; LFO 0: rate 40, full amplitude<br />
</pre><br />
<br />
This only needs to happen once, not on every one of the 32768 samples per second. The idiom for that is a conditional skip on the <code>RUN</code> flag, which is clear on the very first pass through the program and set on every pass after:<br />
<br />
<pre><br />
SKP RUN, loop<br />
WLDS SIN0, 40, 32767<br />
loop:<br />
</pre><br />
<br />
On the first sample, <code>RUN</code> is clear, so the skip does not happen and the LFO is set up. On every subsequent sample the program jumps straight over <code>WLDS</code> to the <code>loop</code> label.<br />
<br />
To read the LFO's current value, use <code>CHO RDAL</code>:<br />
<br />
<pre><br />
CHO RDAL, SIN0 ; ACC = the sine LFO, swinging -1.0 to +1.0<br />
</pre><br />
<br />
== Step 4: shaping the LFO into a gain ==<br />
<br />
The LFO swings from −1.0 to +1.0, but a gain needs to be positive. <code>SOF</code> — scale and offset — fixes that in one instruction. <code>SOF a, b</code> computes <code>ACC = ACC × a + b</code>.<br />
<br />
<pre><br />
CHO RDAL, SIN0 ; -1.0 .. +1.0<br />
SOF 0.5, 0.5 ; halve it, shift it up: now 0.0 .. 1.0<br />
</pre><br />
<br />
Next, depth. Multiplying by POT1 scales the swing down, and a second <code>SOF</code> flips it so the gain sits just below unity at minimum depth:<br />
<br />
<pre><br />
MULX POT1 ; 0.0 .. depth<br />
SOF -1.0, 0.999 ; (1 - depth) .. 1.0<br />
</pre><br />
<br />
With POT1 at zero the gain is a constant 0.999 — effectively off. With POT1 fully up the gain swings across the full range.<br />
<br />
== The finished tremolo ==<br />
<br />
<pre><br />
; Simple tremolo<br />
; POT0 = rate, POT1 = depth<br />
<br />
EQU mod REG0<br />
<br />
; Start the sine LFO once, on the first pass only<br />
SKP RUN, loop<br />
WLDS SIN0, 40, 32767<br />
<br />
loop:<br />
; POT0 sets the LFO rate<br />
RDAX POT0, 0.5<br />
SOF 1.0, 0.02<br />
WRAX SIN0_RATE, 0.0<br />
<br />
; Read the LFO and fold it into a 0..1 gain<br />
CHO RDAL, SIN0<br />
SOF 0.5, 0.5<br />
MULX POT1<br />
SOF -1.0, 0.999<br />
WRAX mod, 0.0<br />
<br />
; Apply the gain to both channels<br />
RDAX ADCL, 1.0<br />
MULX mod<br />
WRAX DACL, 0.0<br />
<br />
RDAX ADCR, 1.0<br />
MULX mod<br />
WRAX DACR, 0.0<br />
</pre><br />
<br />
Sixteen instructions, out of the 128 available.<br />
<br />
Two new things appear here. <code>EQU mod REG0</code> gives <code>REG0</code> a readable name — the assembler substitutes it, and it costs nothing at runtime. Writing to <code>SIN0_RATE</code> changes the LFO rate while the program runs, which is what turns POT0 into a rate knob; the <code>SOF 1.0, 0.02</code> keeps the rate from reaching zero at the bottom of the sweep.<br />
<br />
Load it into the simulator, press Play, and move POT0 and POT1.<br />
<br />
== Where to go next ==<br />
<br />
* '''Delay memory.''' The <code>MEM</code> directive allocates space in the FV-1's 32768 words of delay memory: <code>MEM delay 16000</code>. It creates three symbols — <code>delay</code> (start), <code>delay#</code> (end) and <code>delay^</code> (midpoint). <code>RDA</code> and <code>WRA</code> read and write it.<br />
* '''The built-in examples.''' '''Load File…''' in the editor offers Pass-through, Delay, Chorus and Tremolo. Reading working code is the fastest way to pick up the idioms.<br />
* '''The instruction reference.''' The '''HELP''' tab lists the full instruction set with operand formats.<br />
* '''Spin's documentation.''' The FV-1 datasheet and application note AN-0001 are the authoritative source on LFO behaviour and the fixed-point formats.<br />
<br />
== A few things that bite beginners ==<br />
<br />
* '''Forgetting to clear ACC.''' If a channel sounds like it has the other channel bleeding into it, check your <code>WRAX</code> coefficients.<br />
* '''Coefficient range.''' Coefficients are fractions below 1.0. If you need gain above unity, do it in stages or use a format that allows it.<br />
* '''Setup code running every sample.''' <code>WLDS</code> and friends belong behind a <code>SKP RUN</code> guard.<br />
* '''Running out of instructions.''' 128 is a hard ceiling. If you hit it, the answer is usually a cheaper filter, not a cleverer one.<br />
* '''Trusting the simulator on chorus.''' <code>CHO</code> interpolation is approximated. Confirm modulation effects on hardware.<br />
<br />
== See also ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Using the FV-1 simulator]]<br />
* [[Programming an EEPROM with HEX files]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Using_the_FV-1_simulator&diff=17Using the FV-1 simulator2026-08-23T23:53:25Z<p>Matthew: Add how-to guide</p>
<hr />
<div>The [[Using the Sandbox FV-1 Editor|Sandbox FV-1 Editor]] includes a software model of the FV-1 chip. Your assembled program runs through it in real time, so you can hear an algorithm on a test tone, an audio file or live input before you program any hardware.<br />
<br />
Open it with the '''SIM''' tab on the right-hand edge of the editor.<br />
<br />
== Getting sound out of it ==<br />
<br />
# Assemble your program.<br />
# Press '''Load Current Build''' in the Program section. The state indicator changes from ''Not loaded''.<br />
# Choose an input under '''Input Source'''.<br />
# Press '''Play'''.<br />
<br />
Leave '''Reload simulator on each assemble''' ticked and every successful build drops straight into the running simulator without interrupting playback. This is the fast way to work: edit, assemble, listen, repeat.<br />
<br />
'''Reset''' stops playback and clears delay memory. Reach for it when a program has filled the delay line with something horrible and you want a clean start.<br />
<br />
== Input sources ==<br />
<br />
{| class="wikitable"<br />
! Source !! Good for<br />
|-<br />
| Sine tone || Filters, pitch effects, anything where you need to hear one frequency clearly. The frequency slider covers 20 Hz to 8 kHz.<br />
|-<br />
| Sawtooth / Square || Harmonically rich material — filters and distortion show their character better than on a sine.<br />
|-<br />
| White noise || Filter shapes and reverb tails.<br />
|-<br />
| Audio file || Load a guitar DI or drum loop and hear the effect in context.<br />
|-<br />
| Live input || Play into it through your audio interface.<br />
|}<br />
<br />
== Pots ==<br />
<br />
The three sliders map to '''POT0''', '''POT1''' and '''POT2''' exactly as the physical controls do on the pedal, and they update while the program is running. If your algorithm reads <code>POT0</code>, moving the slider changes it live.<br />
<br />
== Levels ==<br />
<br />
'''Input''' and '''Output''' trim the signal either side of the simulated chip, in dB. Input defaults to −6 dB.<br />
<br />
This matters more than it sounds. The FV-1's accumulator saturates, and the simulator models that saturation, so an input that is too hot will clip inside your algorithm in the same way it would on hardware. If something sounds unexpectedly crunchy, pull the input level down before you go hunting for a bug in your code.<br />
<br />
'''Bypass''' passes the dry signal through so you can A/B against the effect.<br />
<br />
== The crystal setting ==<br />
<br />
The '''Clock''' section changes the rate the simulated chip runs at, the same way swapping the crystal does on real hardware. The standard FV-1 clock is 32.768 kHz.<br />
<br />
Your program does not change — it still runs 128 instructions per sample. What changes is everything measured in samples:<br />
<br />
* Delay times scale with the clock. The FV-1 has a fixed 32768 words of delay memory, so a faster clock buys you proportionally ''less'' delay time. The readout under the selector shows the maximum delay and Nyquist frequency for the rate you have chosen.<br />
* LFO sweeps scale too, so a chorus tuned at 32.768 kHz will modulate faster at 48 kHz.<br />
<br />
Changing the crystal rebuilds the audio engine, which clears delay memory.<br />
<br />
== What the model does and does not get right ==<br />
<br />
The simulator is faithful about the things that give the FV-1 its character:<br />
<br />
* 24-bit accumulator saturation.<br />
* The 14-bit companded delay memory — the reason FV-1 delays sound the way they do.<br />
* LFO rates and depths, following the equations in Spin's application note AN-0001.<br />
<br />
One approximation to know about: the fractional interpolation inside <code>CHO</code> is approximated rather than modelled exactly. Chorus and flange will sound right, but they will not match hardware sample for sample.<br />
<br />
'''Always confirm a design on the real pedal before you ship it.''' The simulator is for iterating quickly, not for signing off.<br />
<br />
== See also ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Writing your first FV-1 program]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Using_the_Sandbox_FV-1_Editor&diff=16Using the Sandbox FV-1 Editor2026-08-23T23:53:24Z<p>Matthew: Add how-to guide</p>
<hr />
<div>The Sandbox FV-1 Editor is a browser-based code editor, assembler and simulator for the Spin FV-1. Nothing is installed and nothing is uploaded — the assembler runs entirely in your browser.<br />
<br />
Open it at [https://fv1.sandboxpedal.com fv1.sandboxpedal.com].<br />
<br />
== Browser requirements ==<br />
<br />
{| class="wikitable"<br />
! What you want to do !! Browser<br />
|-<br />
| Write and assemble code || Any modern browser<br />
|-<br />
| Run the simulator || Any browser with AudioWorklet support<br />
|-<br />
| Save straight to hardware, or use a project folder || '''Chrome or Edge only'''<br />
|}<br />
<br />
Firefox and Safari do not implement the File System Access API, so they cannot write files to your pedal's drive. You can still assemble and download a HEX file by hand and copy it across yourself.<br />
<br />
If Chrome refuses to talk to your hardware, see [[Troubleshooting]] for the site permission settings.<br />
<br />
== The layout ==<br />
<br />
The main window has a '''Source Input''' pane with the code editor and a '''Build Results''' pane underneath showing the assembled Intel HEX output. Three tabs along the edge open flyout panels:<br />
<br />
* '''OPTIONS''' — editor preferences and hardware setup.<br />
* '''HELP''' — the FV-1 instruction set reference.<br />
* '''SIM''' — the [[Using the FV-1 simulator|built-in simulator]].<br />
<br />
== Assembling code ==<br />
<br />
Write or load your source, then press '''Assemble''' (or Alt+A on Windows, Ctrl+A on Mac).<br />
<br />
Warnings and errors appear in the message area with the line number. The FV-1 has a hard limit of 128 instructions; anything shorter is padded out with NOPs automatically, so you do not need to fill the space yourself.<br />
<br />
Once a build succeeds you can save it in several formats:<br />
<br />
* '''Download HEX''' — Intel HEX, the format the programmer wants.<br />
* '''Download Binary''' — raw <code>.bin</code>.<br />
* '''Download C Headers''' — the program as a C array, for embedding in other firmware.<br />
* '''Save Source…''' — your assembly source.<br />
<br />
'''Load File…''' opens a source file from disk, and also offers four built-in examples: Pass-through, Delay, Chorus and Tremolo. These are a good starting point if you want something working in front of you before you start editing.<br />
<br />
== Sending a build to the pedal ==<br />
<br />
This is the part that needs Chrome or Edge.<br />
<br />
# Open the '''OPTIONS''' panel.<br />
# Under '''Hardware Options''', press '''Select Output Directory''' and choose your pedal's '''SANDBOX-FV1''' drive.<br />
# Pick a destination from the '''Filename / Toggle Position''' grid. The buttons are labelled by physical switch position — ▲ is switch up, ● is middle, ▼ is down — with the slot number in the middle.<br />
# Assemble, then press '''Download to Hardware''' (Alt+D / Ctrl+D).<br />
<br />
The editor writes the HEX file into the drive under the right filename, the programmer picks it up, and the FV-1 reloads. See [[Programming an EEPROM with HEX files]] for what happens at the hardware end.<br />
<br />
'''Download to Hardware''' stays greyed out until all three of a directory, a filename and a successful build are in place.<br />
<br />
'''Clear Hardware''' (Alt+C / Ctrl+C) writes empty files over <code>0.hex</code> through <code>7.hex</code>, <code>all.hex</code> and <code>dump.txt</code>, wiping the slots. It only touches files that currently have content.<br />
<br />
== Working from a project folder ==<br />
<br />
'''Select Project Folder''' in the Editor Options section points the editor at a directory of source files, so you can move between the files of a multi-program project without opening each one through a file dialog.<br />
<br />
== Editor options ==<br />
<br />
* '''Large editor window''' — a taller code pane.<br />
* '''Show editor mini-map''' — the Monaco overview strip down the right-hand side.<br />
* '''Show full build results''' — verbose assembler output rather than just errors. Useful when you are debugging an instruction encoding.<br />
* '''Theme''' — System, Light or Dark.<br />
<br />
These preferences persist between sessions.<br />
<br />
== Keyboard shortcuts ==<br />
<br />
{| class="wikitable"<br />
! Action !! Windows !! Mac<br />
|-<br />
| Find || Ctrl+F || ⌘+F<br />
|-<br />
| Replace || Ctrl+Shift+F || ⌘+⌥+F<br />
|-<br />
| Find next || F3 || F3<br />
|-<br />
| Assemble || Alt+A || ⌃+A<br />
|-<br />
| Download to Hardware || Alt+D || ⌃+D<br />
|-<br />
| Clear Hardware || Alt+C || ⌃+C<br />
|}<br />
<br />
== Running the editor locally ==<br />
<br />
The web app must be served over HTTP. Opening <code>Assembler/index.html</code> as a <code>file://</code> page will not work — browsers block the audio engine the simulator needs from <code>file://</code> origins, and the directory and serial access need a secure context. <code>localhost</code> counts as secure, so any static file server will do:<br />
<br />
<pre><br />
python3 -m http.server 8000 --directory Assembler<br />
</pre><br />
<br />
Then open <code>http://localhost:8000</code>. If you prefer Node, <code>npx serve Assembler</code> works the same way.<br />
<br />
== See also ==<br />
<br />
* [[Writing your first FV-1 program]]<br />
* [[Using the FV-1 simulator]]<br />
* [[Programming an EEPROM with HEX files]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Programming_an_EEPROM_with_HEX_files&diff=15Programming an EEPROM with HEX files2026-08-23T23:53:23Z<p>Matthew: Add how-to guide</p>
<hr />
<div>Once the [[Installing the RP2040 programmer firmware|programmer firmware is installed]], writing a new algorithm to your pedal means copying a file onto a USB drive. There is no software to launch and no driver to install.<br />
<br />
== Quick version ==<br />
<br />
# Plug the RP2040 board into USB. A drive named '''SANDBOX-FV1''' appears.<br />
# Connect the target 24LC32A EEPROM to the I<sup>2</sup>C pins.<br />
# Drop a HEX file onto the drive, named for the slot you want (<code>0.hex</code> … <code>7.hex</code>, or <code>all.hex</code>).<br />
# Watch the LED: dim blue while writing, green on success, blinking red on error.<br />
<br />
On success the programmer pulses the FV-1's control pin so the chip reloads immediately. You do not need to power-cycle the pedal.<br />
<br />
== Naming the file ==<br />
<br />
The filename is not cosmetic — it is how you choose which of the eight FV-1 program slots gets written.<br />
<br />
{| class="wikitable"<br />
! Filename !! EEPROM address !! Notes<br />
|-<br />
| <code>0.hex</code> || <code>0x0000</code> || On a Sandbox pedal this slot is bypass<br />
|-<br />
| <code>1.hex</code> || <code>0x0200</code> ||<br />
|-<br />
| <code>2.hex</code> || <code>0x0400</code> ||<br />
|-<br />
| <code>3.hex</code> || <code>0x0600</code> || Also the destination for any unrecognised filename<br />
|-<br />
| <code>4.hex</code> || <code>0x0800</code> ||<br />
|-<br />
| <code>5.hex</code> || <code>0x0A00</code> ||<br />
|-<br />
| <code>6.hex</code> || <code>0x0C00</code> ||<br />
|-<br />
| <code>7.hex</code> || <code>0x0E00</code> ||<br />
|}<br />
<br />
A file with any other name is written to <code>0x0600</code> — program 3. That is deliberate: program 3 is the slot the FV-1 selects when no toggle switches are fitted to the PCB, so a bare board with a single algorithm on it just works.<br />
<br />
== Toggle switch positions ==<br />
<br />
If your pedal has the two toggle switches fitted, the switch positions map to slots like this:<br />
<br />
{| class="wikitable"<br />
! !! Right switch up !! Right switch down<br />
|-<br />
! Left switch up<br />
| <code>2.hex</code> || <code>6.hex</code><br />
|-<br />
! Left switch middle<br />
| <code>3.hex</code> || <code>7.hex</code><br />
|-<br />
! Left switch down<br />
| <code>1.hex</code> || <code>5.hex</code><br />
|}<br />
<br />
The [[Using the Sandbox FV-1 Editor|editor]] shows the same grid, so you can pick the physical switch position you want rather than remembering slot numbers.<br />
<br />
== File format rules ==<br />
<br />
The programmer validates every file before it writes anything. A file that fails validation is rejected outright — it will not half-program your chip.<br />
<br />
'''Single-slot files''' (anything except <code>all.hex</code>):<br />
<br />
* Exactly '''129 lines'''.<br />
* Address range '''0x000–0x1FF''' — 512 bytes, which is one FV-1 program.<br />
<br />
'''Full-image files''' (<code>all.hex</code>):<br />
<br />
* Exactly '''1025 lines'''.<br />
* Address range '''0x000–0xFFF''' — the whole 4096-byte chip.<br />
* The EEPROM is cleared to <code>0xFF</code> first, then written from <code>0x0000</code>.<br />
* If <code>all.hex</code> is present it is processed '''first and alone'''. Other HEX files dropped in the same batch are skipped that cycle, so do not mix a full image with single slots.<br />
<br />
These line counts are what the assembler produces naturally. If your file is the wrong length, it almost certainly did not come from an FV-1 assembler.<br />
<br />
== Reading the status indicators ==<br />
<br />
'''RGB LED:'''<br />
<br />
{| class="wikitable"<br />
! Colour !! Meaning<br />
|-<br />
| Off || Idle, waiting<br />
|-<br />
| Dim blue || Writing<br />
|-<br />
| Green || Write succeeded<br />
|-<br />
| Blinking red || Error — check the serial console for the reason<br />
|}<br />
<br />
'''OLED display''' (production programmer only):<br />
<br />
* <code>No target / Connect EEPROM</code> — nothing detected on the I<sup>2</sup>C bus.<br />
* <code>EEPROM found / Waiting for .hex</code> — ready.<br />
* <code>Complete / Waiting for .hex</code> — the last write succeeded.<br />
<br />
After about 20 seconds of inactivity a screensaver bounces an "FV-1 PROG" label around the display. Press the button to dismiss it; it is not an error state.<br />
<br />
== Re-flashing the same file ==<br />
<br />
The programmer remembers which files it has already handled in the current session, so dropping an unchanged <code>2.hex</code> a second time does nothing. To force a re-flash, disconnect and reconnect the EEPROM — that clears the processed list.<br />
<br />
After a successful write the programmer also creates a marker file such as <code>0.hex.programmed</code>. It is purely a record and is safe to delete.<br />
<br />
== Common failures ==<br />
<br />
{| class="wikitable"<br />
! Symptom !! Likely cause<br />
|-<br />
| Stuck on <code>Connect EEPROM</code> || EEPROM not seen on I<sup>2</sup>C. Check wiring and that the chip answers at address <code>0x50</code>.<br />
|-<br />
| <code>BAD LINE COUNT</code> || Not 129 lines (single slot) or 1025 lines (<code>all.hex</code>).<br />
|-<br />
| <code>BAD ADDR RANGE</code> || The HEX addresses do not match the expected range for that slot.<br />
|-<br />
| Red blink at startup || I<sup>2</sup>C bus locked, or no EEPROM present during the initial scan.<br />
|-<br />
| File copied, nothing happens || The file is a dotfile, is zero bytes, or was already processed this session.<br />
|}<br />
<br />
A zero-byte HEX file is ignored but still marked as processed. This is how the editor's '''Clear Hardware''' button works — it writes empty files over the slots.<br />
<br />
macOS users: Finder likes to write hidden <code>._</code> companion files onto removable drives. The programmer ignores dotfiles, so these are harmless.<br />
<br />
== See also ==<br />
<br />
* [[Installing the RP2040 programmer firmware]]<br />
* [[Using the Sandbox FV-1 Editor]]<br />
* [[Troubleshooting]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Installing_the_RP2040_programmer_firmware&diff=14Installing the RP2040 programmer firmware2026-08-23T23:53:21Z<p>Matthew: Add how-to guide</p>
<hr />
<div>The Sandbox programmer is an off-the-shelf RP2040 board running [https://circuitpython.org CircuitPython] plus a few files from the Sandbox repository. Once it is set up, programming an FV-1 pedal is a matter of dragging a HEX file onto a USB drive — there is no driver to install and no programming application to run.<br />
<br />
This guide covers installing the firmware. For day-to-day use, see [[Programming an EEPROM with HEX files]].<br />
<br />
== What you need ==<br />
<br />
* An RP2040 board. We use a '''Waveshare RP2040-Zero''' for its small size and USB-C port, but a Raspberry Pi Pico or a clone will also work.<br />
* A USB cable that carries data. Charge-only cables are a common cause of "nothing happens when I plug it in".<br />
* The firmware files from the [https://github.com/DisasterAreaDesigns/Sandbox-FV1 Sandbox-FV1 repository], in the <code>Firmware</code> folder.<br />
<br />
== Which firmware folder do I want? ==<br />
<br />
The repository contains two builds of the same programmer:<br />
<br />
{| class="wikitable"<br />
! Folder !! Use it for<br />
|-<br />
| <code>Firmware/src</code> || The programmer module fitted to a Sandbox pedal. This is the one most people want.<br />
|-<br />
| <code>Firmware/production programmer</code> || A standalone bench programmer with an SSD1306 OLED and a button, for programming EEPROMs in quantity.<br />
|}<br />
<br />
Both share the same file layout and the same HEX file rules. The production build adds the OLED status display.<br />
<br />
== Step 1: Put the board into bootloader mode ==<br />
<br />
# Unplug the RP2040 board from everything.<br />
# Hold down the '''BOOTSEL''' button on the board.<br />
# While still holding BOOTSEL, plug the USB cable into your computer.<br />
# Release the button.<br />
<br />
A removable drive named '''RPI-RP2''' will appear on your computer. If it does not, the cable is the first thing to suspect.<br />
<br />
== Step 2: Install CircuitPython ==<br />
<br />
Drag the CircuitPython <code>.uf2</code> file onto the '''RPI-RP2''' drive. The repository ships a known-good build as <code>Firmware/firmware.uf2</code>; alternatively download the CircuitPython build for your specific board from [https://circuitpython.org/downloads circuitpython.org].<br />
<br />
The board reboots on its own as soon as the copy finishes — the RPI-RP2 drive disappearing is expected and is how you know it worked. A new drive named '''CIRCUITPY''' appears in its place.<br />
<br />
== Step 3: Copy the Sandbox files ==<br />
<br />
Copy these four items from the firmware folder onto the '''CIRCUITPY''' drive:<br />
<br />
* <code>boot.py</code><br />
* <code>code.py</code><br />
* <code>hardware_id.json</code><br />
* the <code>lib</code> folder<br />
<br />
If your computer asks whether to merge or replace the contents of <code>lib</code>, say yes. CircuitPython ships its own <code>lib</code> folder and the Sandbox libraries need to sit alongside whatever is already there.<br />
<br />
<code>hardware_id.json</code> is what lets the web editor recognise the drive as a real Sandbox target, so do not skip it.<br />
<br />
== Step 4: Confirm it worked ==<br />
<br />
Eject the drive and re-plug the board. Two things should change:<br />
<br />
* The drive is now named '''SANDBOX-FV1''' instead of CIRCUITPY. <code>boot.py</code> renames it at power-on.<br />
* The board identifies itself over USB as ''Disaster Area Designs SandboxFV1''.<br />
<br />
If you still see CIRCUITPY, <code>boot.py</code> did not run. Check that it is in the root of the drive and not inside a subfolder.<br />
<br />
== What the two files do ==<br />
<br />
<code>boot.py</code> runs once at power-on, before anything else. It sets the drive label, enables the USB drive, and sets the USB manufacturer and product identity (VID <code>0x1209</code>, PID <code>0x3811</code>). You never interact with it directly.<br />
<br />
<code>code.py</code> is the main loop. It watches the I<sup>2</sup>C bus for an EEPROM and the drive for HEX files, and programs the chip when it finds both.<br />
<br />
Note that <code>boot.py</code> remounts the filesystem read-only ''to the board's own code''. Your computer keeps write access, which is exactly what makes drag-and-drop programming work.<br />
<br />
== Reading the serial console ==<br />
<br />
For detailed logs — validation results, byte dumps, the reason a write failed — open the board's serial REPL with a terminal program such as <code>screen</code>, <code>tio</code>, PuTTY or the Mu editor. Every action the loop takes is printed there. This is the fastest way to diagnose a write that goes red for no obvious reason.<br />
<br />
== See also ==<br />
<br />
* [[Programming an EEPROM with HEX files]]<br />
* [[Building the FV-1 Sandbox pedal]]<br />
* [[Troubleshooting]]<br />
<br />
[[Category:How-to]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=How-to_guides&diff=13How-to guides2026-08-23T23:53:20Z<p>Matthew: Add how-to guide</p>
<hr />
<div>This page collects the step-by-step guides for building, programming and coding the FV-1 Sandbox.<br />
<br />
If you are starting from nothing, work through them in this order.<br />
<br />
== Getting the hardware running ==<br />
<br />
* [[Building the FV-1 Sandbox pedal]] — where to find the PCB, schematic and firmware files.<br />
* [[Installing the RP2040 programmer firmware]] — turn a bare RP2040 board into a Sandbox programmer.<br />
* [[Programming an EEPROM with HEX files]] — drag a HEX file onto a drive and your pedal reloads.<br />
<br />
== Writing code ==<br />
<br />
* [[Using the Sandbox FV-1 Editor]] — the browser-based code editor and assembler.<br />
* [[Writing your first FV-1 program]] — from pass-through to a working tremolo.<br />
* [[Using the FV-1 simulator]] — hear an algorithm before you program hardware.<br />
<br />
== When something goes wrong ==<br />
<br />
* [[Troubleshooting]]<br />
<br />
== Tools ==<br />
<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]<br />
* [https://github.com/DisasterAreaDesigns/Sandbox-FV1 Sandbox-FV1 on GitHub]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Main_Page&diff=9Main Page2025-08-17T13:38:37Z<p>Matthew: </p>
<hr />
<div><strong>Welcome to Sandbox Pedal!</strong><br />
<br />
Knowledge Base for DSP Guitar Pedal DIY.<br />
<br />
What is Sandbox? It's an open-source hardware and software package that allows for digital pedal DIY. It uses the Spin Semiconductor FV-1 digital signal processing (DSP) integrated circuit and an off-the-shelf RP2040 microcontroller board, and presents the user with the simplest possible way to get started.<br />
<br />
# Write your signal processing code or find some cool code from another user.<br />
# Use our code editor to assemble into a HEX file.<br />
# Drag the HEX file into the Sandbox FV-1 pedal.<br />
# Play.<br />
<br />
No drivers to install. No operating system requirements. No need to be tied to any particular hardware. If you don't want to buy anything from us, that's okay - we made it all free anyway.<br />
<br />
The bare minimum thing you'll need is an RP2040 board like a RP2040-Zero or Raspberry Pi Pico. These are open-source microcontrollers with a USB port and lots of pins you can use to interface with the outside world. Connect it to your computer, drag our firmware into the board, then hook up a couple of wires to the EEPROM in your pedal. Drag a HEX file into the RP2040 and the EEPROM will program automatically. You don't need any drivers, no software, nothing but the normal file explorer / Finder / file manager application on your computer.<br />
<br />
Why do we need this? Honestly, we don't. There are plenty of other ways to get started with DSP, including several other FV-1 based projects. Go ahead and try some of them out.<br />
<br />
[https://www.pedalpcb.com/product/fv1dev/ PedalPCB FV-1 DEV] <br />
<br />
* Requires building a PCB including two 28-pin surface-mount ICs.<br />
* Requires command-line tools for Mac / Linux.<br />
* Programming software needs .BIN files instead of native FV-1 HEX.<br />
* Works best on Windows but limited / basic Mac / Linux support.<br />
* Requires at least two applications to work (FV-1 assembler or SpinCAD and AsProgrammer or CLI tools)<br />
* Base hardware is mono in and out<br />
<br />
Okay, I see you're back! How was that experience? A little cryptic, maybe? You need to install some drivers, or maybe update your Python install, something like that? Then you need to build a pedal from a kit and maybe that doesn't work first time, sure, we get it.<br />
<br />
We're trying to remove as much friction as possible, and that starts with good tools. Ask your granddad about good tools vs. cheap tools and you'll probably hear something like "buy it nice or buy it twice," and that definitely agrees with our findings.<br />
<br />
Making a chorus algorithm isn't harder than swapping diodes in a Tube Screamer, but the current state of the industry makes it ''seem'' a lot more difficult''.'' Starting DSP isn't hard, but there are a lot of steps and every single one of them has a path to failure.<br />
<br />
The traditional way of getting started with FV-1 was to buy the official development board (US$120) from Spin Semiconductor, then use their SpinASM IDE program on a Windows computer to develop and deploy your algorithms. The dev board has RCA inputs and isn't particularly guitar-friendly, so you really need some extra hardware to get something that's closer to a real pedal.<br />
<br />
Once you have your algorithms, you need to burn them to an EEPROM for use with an actual pedal. You can use the dev board to program EEPROMS but it's a bit clunky and you need the IDE to use it. It's fine for one pedal but if you wanted to make 50 or 100 a standalone EEPROM programmer makes more sense.<br />
<br />
== Getting started ==<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]<br />
* [[Troubleshooting]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Main_Page&diff=8Main Page2025-08-16T23:18:44Z<p>Matthew: </p>
<hr />
<div><strong>Welcome to Sandbox!</strong><br />
<br />
Knowledge Base for DSP Guitar Pedal DIY.<br />
<br />
== Getting started ==<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]<br />
* [[Troubleshooting]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Troubleshooting&diff=7Troubleshooting2025-08-16T23:17:30Z<p>Matthew: </p>
<hr />
<div>== USB devices not connecting in Chrome: ==<br />
<br />
Chrome requires permissions to access your USB-HID devices like Sandbox. Here's how you can verify those permissions are correct.<br />
<br />
Open Chrome and select Settings > Privacy & Security > Site Settings > HID Devices<br />
<br />
<br />
[[File:HID_privacy.png|thumb|center]]<br />
<br />
<br />
Make sure that fxcore.sandboxpedal.com and fv1.sandboxpedal.com are allowed to access your HID devices.<br />
<br />
[[File:Hid_settings.png|thumb|center]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Troubleshooting&diff=6Troubleshooting2025-08-16T23:16:41Z<p>Matthew: </p>
<hr />
<div>USB devices not connecting in Chrome:<br />
<br />
Chrome requires permissions to access your USB-HID devices like Sandbox. Here's how you can verify those permissions are correct.<br />
<br />
Open Chrome and select Settings > Privacy & Security > Site Settings > HID Devices<br />
<br />
<br />
[[File:HID_privacy.png|thumb|center]]<br />
<br />
<br />
Make sure that fxcore.sandboxpedal.com and fv1.sandboxpedal.com are allowed to access your HID devices.<br />
<br />
[[File:Hid_settings.png|thumb|center]]</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=File:HID_privacy.png&diff=5File:HID privacy.png2025-08-16T23:07:03Z<p>Matthew: </p>
<hr />
<div></div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=File:Hid_settings.png&diff=4File:Hid settings.png2025-08-16T23:06:11Z<p>Matthew: </p>
<hr />
<div></div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Troubleshooting&diff=3Troubleshooting2025-08-16T23:01:37Z<p>Matthew: Created page with "USB devices not connecting in Chrome: Chrome requires permissions to access your USB-HID devices like Sandbox. Here's how you can verify those permissions are correct. Open Chrome and select Settings > Privacy & Security > Site Settings > HID Devices"</p>
<hr />
<div>USB devices not connecting in Chrome:<br />
<br />
Chrome requires permissions to access your USB-HID devices like Sandbox. Here's how you can verify those permissions are correct.<br />
<br />
Open Chrome and select Settings > Privacy & Security > Site Settings > HID Devices</div>Matthewhttps://wiki.sandboxpedal.com/index.php?title=Main_Page&diff=2Main Page2025-08-16T22:38:56Z<p>Matthew: </p>
<hr />
<div><strong>Welcome to Sandbox!</strong><br />
<br />
Knowledge Base for DSP Guitar Pedal DIY.<br />
<br />
== Getting started ==<br />
* [https://fv1.sandboxpedal.com FV-1 Sandbox Pedal Editor]<br />
* [https://fxcore.sandboxpedal.com FXCore Sandbox Pedal Editor]</div>Matthew