v2.13 is a significant evolution of the v2.06 firmware with 21 additional functions (82 vs 61). The key changes are:
1.**Three new vendor commands** (0x99, 0x9A, 0x9C) for LNB/tuner control
2.**Restructured INT0 handler** with active satellite front-end polling
3.**I2C-based initialization** with retry logic for the satellite demodulator
4.**Version-aware code paths** (hardware revision detection via descriptor byte)
5.**Refactored DiSEqC GPIO pin assignment** (data pin moved from P0.7 to P0.0, same bit-bang algorithm)
6.**Simplified BCM4500 status polling** (consolidated from 3 register reads to 1)
---
## 1. Vendor Command Dispatch Table Comparison
Both versions use the same two-stage USB control request dispatch:
- **Stage 1** (`FUN_CODE_032a` / `FUN_CODE_034e`): Handles standard USB requests (bRequest 0x00-0x0B) via a 12-entry jump table at CODE:033B / CODE:035F. These handle GET_STATUS, CLEAR_FEATURE, SET_FEATURE, SET_ADDRESS, GET_DESCRIPTOR, SET_DESCRIPTOR, GET_CONFIGURATION, SET_CONFIGURATION, GET_INTERFACE, SET_INTERFACE, SYNCH_FRAME, and FW_VERSION_READ (0x0B).
- **Stage 2** (`FUN_CODE_0056`, identical in both versions): Handles vendor requests (bmRequestType bit 6 set, bRequest 0x80-0x9D) via a 30-entry jump table at CODE:0076. Range check: `(bRequest + 0x80) < 0x1E`, dispatching to `JMP @A+DPTR` at `0x76 + (bRequest - 0x80) * 2`.
### Vendor Command Jump Table (0x80-0x9D)
| bRequest | Name | v2.06 Target | v2.13 Target | Status |
Reads demodulator register 0xF9 via I2C (device address 0x3F) and returns the value to the host. This is a status/diagnostics register read for the satellite demodulator IC.
**0x9A - INIT_DEMOD (new control command)**
```
LCALL 0x231E ; EP0 flush/prepare
if (config_flags.0 == 1) { ; check if demodulator is present
counter = 0;
while (counter <3){
LCALL FUN_CODE_1977 ; initialization step
if (success) break;
counter++;
}
}
EP0BCL = 0 ; no data returned
```
Performs up to 3 attempts to initialize the demodulator, but only if the demodulator-present flag (bit 0 of DAT_INTMEM_4F) is set. This provides host-triggered re-initialization capability.
**0x9C - DELAY_COMMAND (new control command)**
```
R7 = wValue ; delay parameter from USB SETUP packet
LCALL FUN_CODE_1ac6 ; tuning/acquisition delay function
EP0BCL = 0 ; no data returned
```
Calls FUN_CODE_1ac6 with the wValue parameter from the USB SETUP packet. FUN_CODE_1ac6 performs an I2C-based tuning acquisition sequence: it reads demod register 0xF9, writes control values to registers 0xF8 and 0xF9, then polls register 0xF9 up to 40 times (0x28) waiting for bit 0 to be set (lock acquired). If lock fails, it calls FUN_CODE_1e3c which performs a full demodulator reset sequence.
### Commands Removed from v2.13
None were removed -- all commands that were STALL in v2.06 remain STALL in v2.13.
### Changed Command Implementations
**0x87 - GET_SIGNAL_STRENGTH (modified)**
- v2.06 at 0x0140: Checks DAT_INTMEM_6D bit 0 (demod active), reads three I2C status registers (0xA2, 0xA8, 0xA4) to compute signal quality, loops up to 6 iterations polling for demod readiness
- v2.13 at 0x0162: Checks DAT_INTMEM_4F bit 0 (demod active), reads I2C but uses different function call chain (FUN_CODE_1278 vs FUN_CODE_0c97). Same overall logic with relocated internal variables.
- v2.06: `LCALL 0x23e0; LCALL 0x1e41` -- GPIO bit-bang DiSEqC via FUN_CODE_2098, data on **P0.7**, carrier on P0.3
- v2.13: `LCALL 0x231e; LCALL FUN_CODE_0dbc` -- GPIO bit-bang DiSEqC via FUN_CODE_2060, data on **P0.0**, carrier on P0.3
Both versions use the identical algorithm:
1. Read wLength (0xE6BE) as message byte count
2. Clear P0.3 (disable 22kHz carrier)
3. Delay 15 ticks via delay function (7.5ms settling time)
4. If message bytes present: iterate through EP0BUF, sending each byte via Manchester-encoded bit-bang (8 data bits + odd parity, 3 Timer2 ticks per bit)
5. If wValue == 0 and no bytes: tone burst A (25 Timer2 ticks = 12.5ms)
6. If wValue != 0 and no bytes: tone burst B via byte transmit with 0xFF pattern
**CORRECTION**: Earlier analysis incorrectly identified v2.13 as using "I2C-based DiSEqC." Deep decompilation of the sub-functions (FUN_CODE_2060, FUN_CODE_22f3, FUN_CODE_22b0) reveals they are GPIO bit-bang implementations identical in algorithm to v2.06's FUN_CODE_2098 and FUN_CODE_2372. The only change is the data pin assignment (P0.7 -> P0.0), reflecting a different PCB layout.
**0x9D - SET_MODE_FLAG (different logic)**
- v2.06: Reads byte at descriptor_base + 10, checks if value is 4, 5, or 6, and conditionally sets bit flag 0x06 based on wValue - 1
- v2.13: Simply checks if wValue != 0, and if so calls FUN_CODE_21d1 which performs a conditional demodulator reset (calls FUN_CODE_1e3c if `_1_4` flag isn't already set, then writes I2C control registers 0xFC on both device 0x7F and 0x3F)
### USB Descriptor Setup (FUN_CODE_13c3 vs FUN_CODE_11ab)
Both functions are structurally identical:
1. Disable USB disconnect (0xE605 bit 1 clear)
2. Configure IFCONFIG (0xE600) for internal clock, 48MHz
3. Set REVCTL (0xE601) to 0xCA
4. Configure GPIFIDLECTL, PORTACFG
5. Set PORT registers (P0, P3, IPL1)
6. Configure GPIFCTLCFG, FIFORESET, FIFOPINPOLAR
7. Configure Timer2 (RCAP2H=0xF8, RCAP2L=0x2F -> ~2ms period at 48MHz/12)
8. Initialize subsystem modules
Key difference: v2.13 calls `INT0_vector()` (the INT0 handler) during initialization as a probing step. This runs the demodulator availability check during USB setup, before enabling interrupts. v2.06 does not do this.
Descriptor pointer offsets:
- v2.06: BANK1_R4:R5 = 0x1200 (descriptor base)
- v2.13: BANK1_R4:R5 = 0x0E00 (descriptor base, lower due to code restructuring)
---
## 3. Structural Differences
### 3.1 v2.13 Retry Loops (FUN_CODE_1799 and FUN_CODE_1ca0)
In the main init function `FUN_CODE_0800`, v2.13 has:
1. Calls FUN_CODE_1d4b() which writes 4 bytes via I2C to device 0x7F, register 0xF0 (demodulator control)
2. Saves parameters DAT_INTMEM_39:3A
3. Checks if parameters match 0x021C (known good value) - returns early if match
4. Reads 5 I2C bytes via FUN_CODE_0718, each at register 0x0A offset (stepping by 2)
5. Subtracts 0x30 ('0') from each byte (ASCII to binary conversion)
6. Sums the values and compares sum to the saved parameters
7. Returns success (carry set) if checksum matches
This verifies the demodulator responds correctly with the expected identification pattern. The ASCII-to-binary conversion suggests the demod returns a readable version string at register 0x0A.
1. Iterates bytes 6 through 0x29 (36 bytes) of the BANK2_R6:R7 descriptor block
2. Computes running sum, compares against expected value 0x0706
3. If first block passes, iterates bytes 0x2C through 0x4F (36 bytes) of same block
4. Computes second running sum, compares against expected value 0x0686
5. Returns success only if both checksums match
This validates the integrity of a 2-block descriptor/configuration structure (possibly EEPROM-loaded calibration data).
**v2.06 equivalent:** v2.06 does NOT have these retry loops. It calls `FUN_CODE_1a0e` (serial number/EEPROM reader) directly without verification, then proceeds immediately. There is no signature check or checksum validation.
### 3.2 Version Byte Check (Hardware Revision Detection)
This reads byte offset 10 from the USB descriptor base address. Offset 10 in a USB device descriptor is `bMaxPacketSize0` in standard USB, but since this is a custom descriptor area, it likely encodes a hardware revision. The value 0x03 sets bit flag `_1_3`, creating a hardware-revision-aware code path.
**Impact:** The `_1_3` flag is used elsewhere in v2.13 to conditionally execute different initialization sequences, supporting multiple hardware revisions of the SkyWalker-1 board.
### 3.3 FUN_CODE_2031 - USB Reconnect Before Main Loop
```c
void FUN_CODE_2031(void) {
if (_0_0 == 0) {
CPUCS |= 0x08; // Set CPUCS.3 (8051 reset bit? Or re-enumerate)
This performs a controlled USB re-enumeration by pulsing CPUCS.3, then clearing all pending USB/endpoint interrupts. The conditional on `_0_0` adds CPUCS.1 when the flag is set (possibly switching between 12MHz and 48MHz operation).
**v2.06 equivalent:** In v2.06, this exact same logic exists as `INT0_vec` (the INT0 interrupt handler at 0x0003). The critical difference is that in v2.06 this code runs as an interrupt handler, while in v2.13 it's called as a normal function (`FUN_CODE_2031`) before the main loop starts, AND the INT0 vector is repurposed for demodulator polling (see section 4).
---
## 4. INT0 Handler Difference
### v2.06 INT0 (CODE:0003) - USB Re-enumeration
```c
void INT0_vec(void) {
if (_0_7 == 0) {
CPUCS |= 0x08; // CPUCS bit 3
} else {
CPUCS |= 0x0A; // CPUCS bits 3+1
}
FUN_CODE_1dfb(5, 0xDC); // Delay
EPIRQ = 0xFF; // Clear endpoint IRQs
USBIRQ = 0xFF; // Clear USB IRQs
DAT_SFR_91 &= 0xEF; // Clear external interrupt flag
CPUCS &= 0xF7; // Clear CPUCS bit 3
}
```
Simple USB reconnect/re-enumeration handler. Pulses CPUCS.3, clears all pending interrupts.
for (DAT_INTMEM_37 = 0x28; DAT_INTMEM_37 != 0; DAT_INTMEM_37--) {
// Read I2C device 0x7F (demod A), checking for response
byte result = FUN_CODE_2239(0x7F); // I2C read from 0x7F
if (result != 0x01) {
// Try I2C device 0x3F (demod B)
result = FUN_CODE_2239(0x3F); // I2C read from 0x3F
if (result != 0x01) break; // Neither responded normally
}
}
_1_4 = (DAT_INTMEM_37 == 0); // Set flag if loop exhausted (no demod found)
}
```
This is a complete replacement of INT0's purpose. Instead of USB re-enumeration, INT0 now polls two I2C devices (0x7F and 0x3F) up to 40 times (0x28). These are two possible addresses for the satellite demodulator IC.
**FUN_CODE_2239 decompiled:**
```c
undefined1 FUN_CODE_2239(byte device_addr) {
DAT_INTMEM_48 = 0xE1; // buffer address high
DAT_INTMEM_49 = 0; // buffer address low
FUN_CODE_0eea(1, device_addr, 0x51); // I2C read 1 byte from device
return DAT_EXTMEM_e100; // return the read byte
}
```
The function performs an I2C single-byte read from the specified device address, using address 0x51 as a parameter (likely selecting a specific I2C bus or mode via the FX2's auxiliary I2C controller at 0xE678). It stores the result at 0xE100 (XRAM buffer).
**Behavioral meaning:** The flag `_1_4` is set to 1 if neither demodulator responded after 40 attempts - indicating no demodulator hardware is present. This flag is later checked by:
- Various initialization paths to avoid hanging on missing hardware
**Why this matters:** v2.06 assumes the demodulator is always present. v2.13 can detect and gracefully handle boards where the demodulator is absent or unresponsive, making it more robust for manufacturing QC and field failures.
---
## 5. What Can v2.13 Do That v2.06 Cannot?
### 5.1 Demodulator Hardware Detection
v2.13 probes two I2C addresses (0x7F, 0x3F) at startup to determine which demodulator variant is installed, or if none is present. v2.06 blindly assumes the hardware configuration.
The host can trigger a demodulator re-initialization via USB vendor command 0x9A, with up to 3 retry attempts. v2.06 has no mechanism for the host to request re-initialization.
### 5.3 Demodulator Status Read (Command 0x99)
Direct I2C register read of demodulator register 0xF9, returned to host. This enables diagnostic/monitoring software to check demodulator status without going through the full signal quality pipeline.
Allows the host to invoke the tuning acquisition sequence with a configurable delay parameter. In v2.06, the tuning timing is entirely firmware-controlled with no host influence.
### 5.5 DiSEqC GPIO Pin Reassignment
All firmware versions use the same GPIO bit-bang algorithm for DiSEqC signaling. The only change is the data pin assignment per PCB revision:
| Version | Data Pin | Carrier Pin | Byte Transmit | Bit Symbol | Timer Tick |
The algorithm is identical across all versions: Manchester-encoded bit-bang with Timer2-based timing, odd parity per byte, and 25-tick tone bursts for mini-commands.
v2.13 validates demodulator identification (ASCII version string checksum) and descriptor block integrity (two 36-byte checksums) before proceeding. If verification fails after 20 attempts, it falls back to a recovery sequence. v2.06 does no integrity checking.
### 5.7 Hardware Revision Awareness
The version byte check (descriptor offset 10, value 0x03) creates conditional code paths allowing a single firmware image to support multiple SkyWalker-1 hardware revisions. v2.06 has a single code path for one hardware revision.
### 5.8 Simplified BCM4500 Status Polling
v2.06's `FUN_CODE_2000` polls three separate BCM4500 registers (0xA2, 0xA8, 0xA4 via I2C) to determine demodulator readiness. v2.13's `FUN_CODE_208d` polls only one register (0xA4), suggesting either the demodulator firmware was updated to consolidate status, or the additional checks were found to be redundant.
v2.13's 0x9D handler can trigger a full demodulator reset sequence (FUN_CODE_1e3c -> register writes to 0x18 bus) controlled by the host via wValue. This is useful for error recovery without full device re-enumeration.
