LanBox-LCX | |
---|---|
Owner | User:zmatt |
Status | Infrastructure |
Hostname | lanbox |
Tool | |
Tool category |
LanBox-LCX.jpg {{{InventoryOwner}}}Property "Tool Owner" (as page type) with input value "{{{InventoryOwner}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. {{{Location}}}Property "Tool Location" (as page type) with input value "{{{Location}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Description
This networked box controls the DMX lights which illuminate the space. The LanBox-LCX gets its commands from SpaceBot.
Applications
News
- Firmware has been upgraded to latest version. This has been done via TCP, hence the console is now available via TCP port 778.
- The bootloader settings have been changed to disable the CRC-verification of the firmware. This allows hassle-free customization of the firmware. This was done with the following Forth command:
mon" setsysparams 08 RAMsys 10000 210000 2A0000 *0
- The destination address for udp transmit turned out to be hardcoded to -1 (i.e. 255.255.255.255):
see udptxpacket
UdpTxPacket 0884B8 DA 04 EA 1C 041CEA CALLS ROT 0884BC EC F3 R3 PUSH 0884BE EC F2 R2 PUSH 0884C0 98 20 R0 [+] R2 MOV 0884C2 98 30 R0 [+] R3 MOV 0884C4 DA 08 94 34 083494 CALLS UdpOutPort 0884C8 DA 04 8A 3E 043E8A CALLS -1 0884CC DA 08 5A 37 08375A CALLS UdpSock 0884D0 88 30 R3 R0 [-] MOV 0884D2 88 20 R2 R0 [-] MOV 0884D4 FC F2 R2 POP 0884D6 FC F3 R3 POP 0884D8 DA 08 94 30 083094 CALLS SOCK-UDP-WRITE 0884DC DA 04 C4 1B 041BC4 CALLS DROP 0884E0 DB 00 RETS ok
since calls use absolute addresses (with funny byteorder) this was easy to patch to use UdpInAddr instead (which is convenient for the purpose since it's already configurable via global settings). First check its address
' udpinaddr .hex
83590 ok
Patch the call (again, beware of byte ordering):
$359008DA $0884C8 !
Check the results:
0884C8 DA 08 90 35 083590 CALLS UdpInAddr
w00t.
Stop the application (in retrospect, maybe it was a better idea to do that *before* doing the patching), save code, and reboot
stop savecode reset
Features
The LanBox is typically controlled via a simple ascii protocol via TCP port 777 (max 5 connections), USB-serial, or MIDI-SysEx. If the last firmware upload was done via USB then it will consider that to be its console stream, otherwise it has a separate console on TCP port 778 (1 connection).
It also supports a variety of other MIDI messages and can broadcast/receive data via UDP. It supports up to 31 layers, each with an independent sequencer. Up to 3072 channels can be enabled across all layers combined, each with an independent fader. The layers are merged into the mixer buffer according to their configured mix-mode, and up to 512 channels can be output via DMX (freely selectable from the mixer buffer and with post-processing such as curve-mapping and slope-limiting).
DMX in and UDP in can be mapped to a layer or directly into the mixer. Some misc other stuff can optionally also be mapped into the mixer, such as its 8 analog inputs, clock (NTP), and MIDI timecode, and its 8 digital outputs can be controlled directly by mixer channels. The sequencers can set channels (with or without fade), control other layers, send arbitrary MIDI messages, bit-bang serial data over some or all of the digital outputs (independently), etc.
Internals
The firmware is based on a Forth system which you can enter by sending the command *b7#
on its console stream (see above). For symmetry, there's also a Forth word called *b7#
which gets you back into the normal command mode. Entering the Forth console does not affect other streams or normal operation (as long as you don't mess anything up).
The LanBox-LCX Forth system is fairly complete, with integrated help (not very complete unfortunately), assembler, disassembler, debugger, etc. Although the processor is 16-bit with segmented addressing, the Forth system is 32-bit with flat addressing for convenience. Several key routines of the firmware are written in assembly for performance.
The firmware has several callback hooks (set to nop by default) to allow custom code to be run at various relevant moments:
' nop VALUE 'StartTick \ called in "start" after initialization, before the frame timer is started ' nop VALUE 'StopTick \ called in "stop" after frame timer has halted but before any cleanup ' nop VALUE 'PreMixTick \ called for every dmx frame before the sequence-fade-mix loop ' nop VALUE 'PostMixTick \ called after mixer buffer is updated but before postprocessing
It's also quite easy to patch dispatch tables to hook custom commands on e.g. MIDI messages.
With some care you can directly manipulate internal buffers and structures (e.g. in 'PostMixTick you can manipulate the updated mixer buffer before anything else gets to see it), and many serial commands also have an equivalent high-level Forth word, for example:
( 44 ) EnConfigure ( layerID destlayerID -- ok? ) ( 44 ) EnConfigureWithOptions ( layerID destlayerID newlayerID flags cuelist cuestep -- ok? ) ( 56 ) EnGo ( layerID cuelist cuestep -- ok? ) ( 57 ) EnClear ( layerID -- ok? ) ( 73 ) EnNextCue ( layerID -- ok? )