· Text 3957 · w8 · inlagg
Hur kan jag enkelt och billigt föra över mina ABC80-filer
till en PC och tvärtom?
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
ABC80<>PC
13 posts in thread
-
-
· Text 3958 · w8 · kommentarKöp programmet ABCDISK! Se annonser i ABC-Bladet.
-
· Text 3998 · w8 · kommentarFinns det inget billigare sätt??!! Kan man inte göra programmet själv? Vad behöver man veta? Kan man inte koppla ihop datorerna eller nåt liknande?
-
· Text 3999 · w8 · kommentarJovisst, du kan koppla ihop datorerna på V24:an och köra Kermit om det finns en fungerande sådan till ABC80. Jovisst kan du göra ett konverteringsprogram till PC själv, men jag tror inte att det blir billigare. Du måste ha mycket god kundskap om både ABC och PC för att få till ett sådant. Har du det så går det väl även om jag inte tycker att det är lönt. ( Kommentar i text 4000 av Arne Hartelius <2731> ) ( Text 3999 )
-
· Text 4000 · w8 · kommentarDen Kermit som ligger i banken just nu ( Anders Franzén's ver. ) verkar hyggligt avlusad. Inga reproducerbara fel har rapporterats.
-
· Text 4005 · w8 · kommentarJust nu är det bara en kille på Gotland som har problem med KERM. Har inte, trots djupa undersökningar, inte kommit på varför. Har jämfört linjelyssningar utförda av mig och av honom och de är identiskt lika. Ändå sparas hans filer underligt. Om inte någon annan har några fel att rapportera måste jag nog säga att KERM fungerar. Kan inte koppla ihop Gotlandsproblemet med programfel.
-
· Text 4006 · w8 · kommentarSkickar nog snart in källkoden så kan kanske andra avlusa?
-
· Text 4009 · w8 · kommentarJag använder numera för det mesta KERM, när jag hämtar filer från ABC-MONITORN, såväl text- som binärfiler, och det har aldrig varit några problem. Däremot får jag ibland felmeddelande från den sändande datorn, när jag med nollmodem för över sådana filer, som är hämtade till den sändande datorn med TERM-100. Trots detta blir filerna rätt överförda. Felmeddelandet har säkert att göra med den tidigare påtalade något " standardavvikande " fillagringen med TERM-100. Den sändande och den mottagande ABC80 har vid överföringens slut olika uppfattning om hur måmga block som förts över. Detta gäller endast sådana filer, som tidigare överförts med TERM-100. Vid nollmodemöverföringarna ( med 5 m kabel ) använder jag hastigheten 2400 bd. Då blir det i allmänhet ingen eller få omsändningar. Högre hastighet leder ofelbart till omsändningar. Detta tror jag inte har något med KERM att göra. Jag har nämligen inte lyckats bättre med högre fart med något annat program heller. Jag misstänker att något i ABC80:s maskinvara utgör ett hinder för säkra överföringar i högre hastigheter än 1800 bd. Därmed torde det vara meningslöst att med ABC80 köra modem i högre standardfart än 1200 bd. Jag vill gärna motsagd i det senaste påståendet av någon med egna erfarenheter.
-
· Text 4011 · w8 · kommentarJo, storleken på en fil som hämtats med TERM100 är något större än en fil som sparats på skiva på annat sätt. Det beror på att flera mellanslag i en följd inte packas ihop av TERM100. Rent teoretiskt torde 2400 baud vara den maximala överföringshastigheten med ABC80 om terminalrutinen utnyttjar 128üs-interruptet (vilket samtliga (?) gör). Jag har för mig att man kan ställa KERM i 4800/4800 baud men det borde inte fungera! Kan man göra en terminalrutin som inte bygger på 128üs-interruptet skulle man nog kunna komma upp i 19200 baud!
-
· Text 4013 · w8 · kommentarÄntligen lite förståelse! Jag trodde väl det! Det finns flera stycken för ABC-klubbsmedlemmar tillgängliga rutiner, som avses fungera upp till 2400 bd eller mera. exempel: TERM 100 2400 bd T80PRT/ABCV24 2400 bd KERM 4800 bd KERMIT 80 3905 bd Det vore intressant, om någon kunde komplettera listan med ev. befintliga andra terminal-och printerrutiner, även kommersiella, och berätta hur bra de fungerar i höga hastigheter. Enligt min erfarenhet är det i första hand mottagningsegenskaperna som blir kritiska i höga farter. Sändningen verkar hänga med bättre.
-
· Text 4015 · w8 · kommentarJo, sändningen fungerar antagligen bättre eftersom den som sänder inte vet vad den sänder! Sändaren tror visserligen att den kan sända riktigt snabbt men i verkligheten blir det praktiskt omöjligt att sätta ihop nollorna och ettorna till hela bytes igen. I ABC80 utnyttjar man ett interrupt som återkommer var 128:e millisekund. Detta interrupt styrs hård- varumässigt och används av terminalrutinen som en klocka. Det får alltså plats ca 7800 interrupt per sekund. Vid varje interrupt rycker en programlogik in och sänder samt tar emot bitar. För att kunna garantera säker överföring bör en bit uppta minst två interrupt för att biten inte skall försvinna, t ex genom att förskjutas i tid så att två bitar blir en. Delar man alltså 7800 med två får man 3900 och var det inte där någonstans som KERMIT80 hade sin gräns? Naturligtvis sänder man oftast med en standardiserad hastighet och då tvingas man välja 2400 baud eftersom 4800 är för snabbt. Möjligen kan man sända från ABC80 med 4800 baud och ta emot med en snabbare dator. Men det är inte säkert. Sänder man med 4800 betyder det ca 1.6 st interrupt per bit att sända. Eftersom den lägsta tidsenheten med interruptet som klocka är 1 (jämfört med 1.6) kommer kanske varannan bit att bli lite längre och varannan lite kortare. När man tar emot data finns det beräkningar som säger när i biten man skall mäta. Man kan ju också tänka sig att "sampla" flera gånger under bittiden och av dessa mätningar beräkna ett medelvärde som motsvarar värdet på mottagen bit. Men det kräver mer logik och det tar tid. Uj, det bästa är nog att låta ett chips sköta kommunikationen så man i sitt program bara behöver läsa i en buffert.
-
-
· Text 4016 · w8 · kommentarMen hur filen ser ut på disken på vardera Kermit-sidan kan väl inte spela någon roll för Kermit-överföringen? Vad som kontrolleras är ju kontrollsumman på de paket som sänds och tas emot, och summan beräknas på de sändande sidan EFTER läsningen från disk, och på den mottagande sidan FÖRE skrivning till disk. Att det kan bli olika långt på disken är ju helt tillåtet eftersom Kermit kan överföra mellan olika typer av maskiner med olika diskformat.
-
· Text 4020 · w8 · kommentarNä, hur filen ser ut på disken spelar ingen roll. Men KERM visar antalet överförda block och även storleken på filen (i vissa fall) innan den sänds och denna blockräknare visas på skärmen. Det var nog det som gjorde att det såg annorlunda ut. Innehåller filen några slasksektorer på slutet (t ex en textfil som man uppdaterat så att den blev mindre) visar sändande KERM en större filstorlek än den mottagande KERM. Men det får man stå ut med om man vill se filstorleken innan! Tyvärr räknar KERM lite dåligt ibland när han räknar överförda och mottagna block.
-
-
-
-
-
-
-
-
-