3 ms·

OK, look, it was a long time ago, but I don't actually think we used Flash. Maybe one of the later versions where we tried to make it look sexier and/or more i

OK, look, it was a long time ago, but I don't actually think we used Flash. Maybe one of the later versions where we tried to make it look sexier and/or more integrated? The original client side architecture was basically: 1) Some wrapper that let us embed a web browser that wasn't too buggy 2) Some crazy bridge that got us down to native (ish) code 3) Some crazy native code that abused the HID protocol to talk to the remote itself We had this working for: Windows - pretty sure it was VB embedding Internet Explorer that bridged down to a C++ COM component for communication Mac - Safari talking to java HID bridge Linux - Firefox talking to java HID bridge It was a long time ago, but that sounds 80% correct. Originally we wanted to use full java on all 3 platforms, but back then (2000), it was too slow and buggy. Ironically, we ended up using VB for the server stuff (for a consistent dev environment), and then had to rewrite back to java in 2003 ish. Fun times.

jaywalk 6y ago
I was talking about on the remote itself. In the Twitter thread, it was clearly discovered that the UI on the remote is written in Flash.
- glenharris 6y ago
  OK, that must be a much later remote (2006+). The original remotes were heavily COGS optimized. For example, the first remote used a PIC microchip with 1kB of ram. We had 2MB of flash, so the server would create a massive state machine that the remote would then interpret (dumbly). For example, on menu #27 it would show four textual menu items, where say item #3 would cause IR command #38 to be sent then jump to menu #11. This core architecture (server working out all of the UI and then sending it down to a psychotically dumb remote) was in place for all remotes between 2000-2005.
- glenharris 6y ago
  It is worth noting that in 1024 bytes of ram, we managed: 1) Call stack frame and local variables 2) Full graphical menuing system with text and icons 3) Infrared sending 4) Infrared learning 5) Smart State Control (i.e. for each device, simulate what state it 'should' have been in, then work out what commands needed to be sent to hopefully get it into the new state' 6) Synchronization (i.e. when Smart State didn't work, sending the user through a graphical workflow that would get it going again) 7) Interactive TV listings (i.e. when watching TV, it could show you what programmes were on which channel, select to change to that channel) 8) Dynamic content 'zapping'. OK, it was a dumb feature, but you could press the 'Zap' button and it would remember what channel you were watching at what time, and then take you to relevant content (e.g. ads). 9) Favourite channel lists - pressing channel up would only cycle you through the channels you liked, working out if it was 2 or 3 digits, zero prefixed, 'channel up shortcut' etc. 10) USB HID protocol stack (the USB chip was only a dumb transceiver).

jaywalk 6y ago

I was talking about on the remote itself. In the Twitter thread, it was clearly discovered that the UI on the remote is written in Flash.

glenharris 6y ago
OK, that must be a much later remote (2006+). The original remotes were heavily COGS optimized. For example, the first remote used a PIC microchip with 1kB of ram. We had 2MB of flash, so the server would create a massive state machine that the remote would then interpret (dumbly). For example, on menu #27 it would show four textual menu items, where say item #3 would cause IR command #38 to be sent then jump to menu #11. This core architecture (server working out all of the UI and then sending it down to a psychotically dumb remote) was in place for all remotes between 2000-2005.
glenharris 6y ago
It is worth noting that in 1024 bytes of ram, we managed: 1) Call stack frame and local variables 2) Full graphical menuing system with text and icons 3) Infrared sending 4) Infrared learning 5) Smart State Control (i.e. for each device, simulate what state it 'should' have been in, then work out what commands needed to be sent to hopefully get it into the new state' 6) Synchronization (i.e. when Smart State didn't work, sending the user through a graphical workflow that would get it going again) 7) Interactive TV listings (i.e. when watching TV, it could show you what programmes were on which channel, select to change to that channel) 8) Dynamic content 'zapping'. OK, it was a dumb feature, but you could press the 'Zap' button and it would remember what channel you were watching at what time, and then take you to relevant content (e.g. ads). 9) Favourite channel lists - pressing channel up would only cycle you through the channels you liked, working out if it was 2 or 3 digits, zero prefixed, 'channel up shortcut' etc. 10) USB HID protocol stack (the USB chip was only a dumb transceiver).