HFM.BAC -- Programnyhet!

10 posts in thread

• Kristoffer Eriksson <5357> · Text 7738 · w8 · inlagg

  1987-11-14 02:55

  Ärende: HFM.BAC -- Programnyhet!

  Någon kanske minns att jag får några månader sedan skickade in ett program för Huffmann-kodning av filer. Det var skrivet i basic och ganska långsamt. Nu har jag skrivit en version i assembler, som är betydligt snabbare. Den heter HFM.BAC och finns nu i inlådan, tillsammans med bruksanvisningen HFM.INF. Bruksen är inte helt nödvändig för att kunna köra HFM. HFM tar alltså en infil och kodar den med Huffmann-kodning till en utfil. Utfilen blir kortare än infilen. Hela syftet med HFM är just att man kan spara diskutrymme genom att låta HFM komprimera filer. Man kan också spara dyrbar telefontid vid modemöverföring. Och till skillnad mot det gamla HUFFMANN är HFM tillräckligt snabbt för att vara användbart. HFM kan förstås också dekomprimera en komprimerad fil, så man får tillbaks originalet. Som en biprodukt kan HFM även visa hur ofta olika tecken förekommer i en fil. Ha nu inte överdrivna förväntningar på HFM. Denna version har inte såna finesser som ARC på PC, t ex packning av fler infiler till en enda utfil. Och komprimeringen görs endast med Huffmann-kod. Det ger 20-35% krympning av textfiler tror jag. Källkoden, 274 sektorer allt som allt, kommer jag att skicka in senare om ingen hittar några fel i HFM. Den som vill veta hur HFM fungerar behöver bara titta på HUFFMANN.BAS, det går till på samma sätt. HFM.BAC är inte listbart. (Naturligtvis är det tänkt att HFM ska fungera i REMOTE också.)
  • Stefan Gartz <2600> · Text 7756 · w8 · kommentar

    1987-11-17 09:20

    Ärende: HFM.BAC -- Programnyhet!

    Jag har en fundering på om Huffmann kodningen kan omvandla byte området 0-31 till andra koder. Det skulle med andra ord expandera data antalet EX: infilen har alla bytevärden och .hfm filen har endast bytevärden 32 - 255. Orsaken till frågan är ett kommunikationsproblem där vi ska skicka binärfil via modem som endast kan ascii med xon xoff. Binärfilerna har majoriteten av datat inom 32-127 men lite ligger utanför och det kan vara över hela bytevidden. Jag testade HFM.bac på en fil som var 112 sektorer före komprimering och den blev 60 sektorer efter. Min fåga gäller om det går att 'snedvrida' algoritmen så att den undviker vissa koder i utfilen. Om det inte går så får man väl 'tvätta' filen efteråt med viss expandering som pris. Synpunkter !? MVH Sgz
    • Nils Hammar <4341> · Text 7760 · w8 · kommentar

      1987-11-19 20:30

      Ärende: HFM.BAC -- Programnyhet!

      Det brukar inte vara modemet som hanterar XON/XOFF utan datorn Om du har ett modem med buffert och hastighetskonvertering kan det dock hantera XON/XOFF, men annars är det inte troligt,utan det sväljer vad det får. m.v.h Nils Hammar.
    • Kristoffer Eriksson <5357> · Text 7775 · w8 · kommentar

      1987-11-22 02:54

      Ärende: HFM.BAC

      Huffmann-kodningen kan inte modifieras till att bara producera bytes med koder inom ett visst område. Den kod som produceras ska över huvud taget inte betraktas som bytes. Koden är en följd av enskilda bittar som produceras individuellt. Om bittarna när de grupperas åtta och åtta råkar bilda koder från 0-31 ibland, så är det oturligt för dig, men inget som kan åtgärdas i Huffmann- algoritmen. Vad som återstår är alltså mycket riktigt en "tvättning" i efterhand av den komprimerade filen - som ett separat program, eller möjligen som ett extra steg i komprimeringen. En enkel lösning är förstås att använda kermit till den där överföringen, för den har så att säga inbyggd "tvättning" när kommunikationslinjen bara klarar en del av de möjliga koderna. Men är du säker på att det inte går att överföra alla byte-koder?
      • Stefan Gartz <2600> · Text 7793 · w8 · kommentar

        1987-11-23 08:03

        Ärende: HFM.BAC

        Error controllern har ett mode där man kan styra div parametrar och om man skriver ///EF så kommer man ut i det läget och sändningen upphör Så det är endast den kombinationen som är förbjuden. Vet du om det finns en rutin för 'tvättning' (Convert - Unconvert) Mvh Sgz
        • Kristoffer Eriksson <5357> · Text 7824 · w8 · kommentar

          1987-11-29 02:39

          Ärende: HFM.BAC

          I förra inlägget var det koderna 0-31 du ville bli av med, nu kombinationen ///EF. Hur hänger det ihop? Nej, det finns ingen "tvättningsrutin" här i programbanken. Men det borde inte vara alltför svårt för dig att skriva en sådan själv. Om du bara vill slippa ///EF kan du t ex översätta det till QQQQQA och QQQQQ i sin tur till QQQQQB. Det skulle ge en mycket obetydlig ökning av fillängden.
          • Stefan Gartz <2600> · Text 7826 · w8 · kommentar

            1987-11-29 09:14

            Ärende: HFM.BAC

            Det hänger ihop med min undring om man kunde förvrida algoritmen så att vissa områden kunde undvikas, alltså inte för lösningen på hela problemet. Jag tror jag kan göra tvätten själv, tänk om infilen har QQQQQA eller QQQQQB det kommer att få upppackaren att tappa spåret?!. Jag har i stället en lösning (ej implementerad) som är så här: (fillängd)(<paketlängd><typ><...paket...><paketlängd><typ><..paket..>) så vid tvätten skriver jag dit filens totallängd inklusive justeringar och vid justering av någon eller några bytes så skrivs en längd och typ för den sortens omvandling (rightshift/hex/etc) som använts på det avsnittet. det om detta Mvh Sgz
            • Kristoffer Eriksson <5357> · Text 7834 · w8 · kommentar

              1987-11-29 23:19

              Ärende: HFM.BAC

              Jo, men om originalfilen innehåller QQQQQA så översätts det till QQQQQBA, och allt är frid och fröjd. Det är ju därför det behövs en kod även för QQQQQ.
  • Kristoffer Eriksson <5357> · Text 7874 · w8 · kommentar

    1987-12-11 20:11

    Ärende: HFM.BAC -- Källkod

    Nu har jag skickat in källkoden till HFM.BAC. Den består av ett antal separata filer, som binds samman av huvud-filen HFM.ASM. Filerna är: HFM.ASM HFMMAIN.ASM HFMTREE.ASM BITIO.ASM CONSPACK.ASM DEFEXT.ASM GIO.ASM IDIV.ASM OPENFILE.ASM TRIBASC.ASM WORDSPLT.ASM plus några som redan finns i ABC800/ASMKOD: I2ASC.ASM CLINEPAR.ASM ENDINIT.ASM ENDREL.ASM Alla filer som inte börjar på HFM är smårutiner som även kan användas till andra program. ENDINIT och ENDREL och i viss mån CLINEPAR bygger till stor del på att min egen assemblator används. Har man inte den, är det inte så lätt att i detalj förstå vad dessa gör, än mindre kompilera dem.
    • Stefan Gartz <2600> · Text 7921 · w8 · kommentar

      1987-12-30 15:42

      Ärende: HFM.BAC -- Källkod

      Du säger att det är svårt att förstå och ännu svårare att kompilera källkod utan din assemblator. Hur/Var kan man få tag i den då da? Mvh Sgz