UDPSlave 0.91
in [Commodore]
|
From: MagerValp on 17 Oct 2006 04:24 UDPSlave has been updated: * Optimized incoming packet code, reduced size significantly. * Base64 decoder for minislave, reducing type-in code from 57 lines of hex to 38 lines of base-64. * Better checksum algorithm catches missing lines. * Exit gracefully when a key is pressed in udpslave. http://www.paradroid.net/udpslave/ -- ___ . . . . . + . . o _|___|_ + . + . + . Per Olofsson, arkadspelare o-o . . . o + MagerValp(a)cling.gu.se - + + . http://www.cling.gu.se/~cl3polof/
From: Wolfgang Moser on 17 Oct 2006 07:09 MagerValp schrieb: > UDPSlave has been updated: > > * Optimized incoming packet code, reduced size significantly. > * Base64 decoder for minislave, reducing type-in code from 57 lines > of hex to 38 lines of base-64. Yeah, puzzl'ing! http://www.paradroid.net/udpslave/minislave.txt > * Better checksum algorithm catches missing lines. > * Exit gracefully when a key is pressed in udpslave. > > http://www.paradroid.net/udpslave/ > Womo
From: MagerValp on 17 Oct 2006 09:55 >>>>> "WM" == Wolfgang Moser <wnhp(a)d81.de.invalid> writes: MV> * Base64 decoder for minislave, reducing type-in code from 57 MV> lines of hex to 38 lines of base-64. WM> Yeah, puzzl'ing! WM> http://www.paradroid.net/udpslave/minislave.txt Actually, the largest gain is from code optimization (164 bytes), rather than the encoding. With this scheme I fit 18 bytes of data per line, plus checksum, instead of 15 + 1. Integrating the checksum into the base-64 data would yield 20+1 and 35 lines of data, but it would make the decoder a little more complicated. Maybe we should hold a competition? Who can write the smallest basic program that copies the 684 bytes of minislave to $cc00? :) Data lines should be max 39 chars long, for readability, while code lines can be up to 79. The data also shouldn't use "l" (el) or "O" (capital Oh), as they're easily confused with 1 and 0. Any takers? :) -- ___ . . . . . + . . o _|___|_ + . + . + . Per Olofsson, arkadspelare o-o . . . o + MagerValp(a)cling.gu.se - + + . http://www.cling.gu.se/~cl3polof/
From: Wolfgang Moser on 17 Oct 2006 10:23 Hello Per, MagerValp schrieb: > MV> * Base64 decoder for minislave, reducing type-in code from 57 > MV> lines of hex to 38 lines of base-64. > > WM> Yeah, puzzl'ing! > WM> http://www.paradroid.net/udpslave/minislave.txt > > Actually, the largest gain is from code optimization (164 bytes), > rather than the encoding. With this scheme I fit 18 bytes of data per > line, plus checksum, instead of 15 + 1. Integrating the checksum into > the base-64 data would yield 20+1 and 35 lines of data, but it would > make the decoder a little more complicated. The subroutine at 300 with its if/else chain asks for optimization.. > Maybe we should hold a competition? Who can write the smallest basic > program that copies the 684 bytes of minislave to $cc00? :) Data lines Sounds interesting, at least much more interesting than these old 20-liners competition from the german magazine 64'er. > should be max 39 chars long, for readability, while code lines can be > up to 79. The data also shouldn't use "l" (el) or "O" (capital Oh), as > they're easily confused with 1 and 0. Instead of reducing the number of bytes of such a BASIC program or the number of lines, the _effort_ for typing in such a program should be reduced. In the first sense, yes, this goes for "stuffing" the DATA lines as much as possible with any good encoding. But for the BASIC part, the bootstrapper, readability as well as sparsely filled lines would be a plus over compactness for typing in such a program. > Any takers? :) Not me, currently, although interested :-( Womo
From: Wolfgang Moser on 17 Oct 2006 11:06
Hi, MagerValp schrieb: > up to 79. The data also shouldn't use "l" (el) or "O" (capital Oh), as > they're easily confused with 1 and 0. Btw. this just remembered me to some old software registration key system, where the following 5-Bit mapping was used. convTable:array [0..$1F] of char =( '0','1','2','3','A','B','C','D','E','F','G','H','4','5','6','J', 'K','L','M','N','7','8','9','P','Q','R','S','T','W','X','Y','Z' ); ... if not (Key[i] in ['0'..'9', 'A'..'H', 'J'..'N', 'P'..'T', 'W'..'Z']) then break; The characters: 'I', 'O' (Oh), 'U' and 'V' were omitted to reduce misinterpretations. Moreover I believe the key validation system was so smart that it automatically took a '1', when an 'I' was given and a '0' for an 'O'. Hmmm.... Using a 5-Bit encoding system would have got the advantage that the user does not need to press <SHIFT> for typing in any of the encoded chars. This let's me stay away from previous proposions on maybe using 7-Bit encoding systems or perhaps something like yenc. Do you think there is a way to measure the _efficiency_, the average user is able to type-in either the hex-encoded or the base64-encoded file? For the first one he does not need to press <SHIFT> IIRC and the BASIC part is somewhat shorter. For the base64 style format he needs to type less chars, if pressing <SHIFT> is not counted as a key press on itself. <sigh> I'm struggling on which would be the best encoding strategy for such type-ins. Womo |