Retro Preservation Workspace

Monitorn

Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.

← Back to ABC Tools

Meetings · ABC800 · Thread

EOF i maskinkod

20 posts in thread

Patric Ljung <5455> · Text 3005 · w8 · inlagg

1986-03-09 12:01

Ärende: EOF i maskinkod

Vad händer när man får EOF när man gör ett anrop till IO (eller motsvarande denna som mna får genom lång PEEK2-kedja). Så länge man inte kommer till BASIC med ett felmeddelande så är det bra. Vad jag då vill veta är hur man vet att filen är slut. Om man läser ett tecken med INPUT från filen. LD HL,BUFF LD BC,1 LD A,3 CALL IO WHAPPENS ?????? Tacksam för snabbt svar. PS. Annars får man väl läsa filen med GET och kolla när man får EOF, vilket är CHR¤(3) eller tre CHR¤(0)?? muh / Patric
- Kristoffer Eriksson <5357> · Text 3015 · w8 · kommentar
  
  1986-03-12 19:31
  
  Ärende: EOF i maskinkod
  
  Sann carry-flagga samt felkoden i register A, har jag för mig. Ganska logiskt va?
  - Patric Ljung <5455> · Text 3018 · w8 · kommentar
    
    1986-03-12 20:03
    
    Ärende: EOF i maskinkod
    
    Mmm, inte alltför ologiskt i alla fall. Fast jag änvände mig av GET asv andra skäl. Tack, ohej. OHOJ!!! - Wake up puppet boy!
- Kristoffer Eriksson <5357> · Text 3059 · w8 · kommentar
  
  1986-03-14 20:17
  
  Ärende: EOF i maskinkod
  
  EOF är varken CHR¤(3) eller tre CHR¤(0). CHR¤(3) är "slut på sektorn" i filer som skrivits med PRINT. Var filen tar slut bestäms av fillängden som är angiven i LIB (eller RIB i LUX- NET) och av segmentlistan i RIB ("headerblocket", filens första sektor, som inte syns när man läser filen normalt).
  - Patric Ljung <5455> · Text 3075 · w8 · kommentar
    
    1986-03-15 13:06
    
    Ärende: EOF i maskinkod
    
    Jag upptäckte att CHR¤(3) låg sist i en sektor, och det var ju inte bra. Men å andra sidan ligger det faktiskt ett CHR¤(3) när texten är slut. Du kan ju testa genom att skapa och skriva ; #fil,'HEJSAN !!!' och sedan stänga filen. Då ligger det ett CHR¤(3) efter HEJSAN !!! + CR. Men jag har löst det genom att använda en räknare som ökas med ett varje gång som jag läser från filen. Och när ett CHR¤(3) läses kollas om denna räknare är 253, i sådana fäll kan jag fortsätta att läsa från filen och nollställa räknaren. Men om räknaren inte är 253 är filen slut. Detta fungerar jättebra! mvh / Patric
    - Kristoffer Eriksson <5357> · Text 3096 · w8 · kommentar
      
      1986-03-17 22:33
      
      Ärende: EOF i maskinkod
      
      Som sagt så betyder CHR¤(3) inte "slut på filen" utan bara "slut på texten i denna sektor". Antal sektorer i senast använda fil brukar kunna avläsas med PEEK2(64778), men jag garanterar inte att det funkar på alla DOS, och man MÅSTE ha läst från den fil som ska kollas innan avläsningen görs. (Detta är en variabel för "aktuell fil". Variabler för varje öppen fil kan återfinnas på annan plats om man vet vilken dosbuffert filen ligger i.)
      - Kristoffer Eriksson <5357> · Text 3130 · w8 · kommentar
        
        1986-03-20 01:31
        
        Ärende: EOF i maskinkod
        
        Så här tycks det ligga till enligt en närmare undersökning: CHR¤(3) betyder "fortsätt med nästa sektor", och behöver inte nödvänigtvis ligga sist i sektorn, även om den gör det när filen skrivits med PRINT. CHR¤(0) betyder "slut på filen" (åtminstone den del av filen som innehåller text). När denna påträffas, kasseras den ev text som inte avslutats med CR som kommer före. Av någon anledning skrivs det ut ett flertal CHR¤(0) efter sista textsektorn, men det räcker med EN för att indikera EOF vd läsning.
        
        Benny Löfgren SYSOP <2615> · Text 3135 · w8 · kommentar
        
        1986-03-20 14:13
        
        Ärende: EOF i maskinkod
        
        Observera att <NUL> måste ligga först i en sektor för att tolkas som EOF !
        
        Kristoffer Eriksson <5357> · Text 3140 · w8 · kommentar
        
        1986-03-21 00:01
        
        Ärende: EOF i maskinkod
        
        Du har fel! (så långt jag kan avgöra i alla fall) När INPUT-rutinen för block-enheter träffar på ett NULL-tecken sätter den utan vidare spisning upp carry-flaggan och felkoden 34. Jag har även (förutom disassemblering) provat att skriva en fil och därefter sätta ett NULL-tecken mitt i en sektor. Då slutar filen vad närmast föregående radslut.
        
        Patric Ljung <5455> · Text 3149 · w8 · kommentar
        
        1986-03-22 01:06
        
        Ärende: EOF i maskinkod
        
        Hmm, båda har ni olika uppfattningar och inga av dem stämmer överens med min, som jag VET fungerar. Experiment: Jag har skapat en fil. PREPARE 'FIL.TXT' AS FILE 1 Sedan har jag skrivit på den. ; #1,'Detta är litet text...' ; #1,'Och detta ännu litet till!' ; #1,'HEJ Å HÅ, SISTA RADEN!' Stängt filen CLOSE 1 När jag sedan Öppnat filen med OPEN.... Och läst tecken för tecken med GET. Då inträffar följande: Efter SISTA RADEN!<CR> ligger, tro det eller ej, men ett CHR¤(3). Sedan är det bara skit. Jag använder en rutin som bygger på en konstruktion som innebär att CHR¤(3) betyder Läs nästa sektor om det ligger sist, om det ligger nånstans i sektorn betyder det EOF. Detta FUNGERAR. Rutinen används, nån nolla har aldrig stötts på. So it is?....????? mvh / Patric
        
        Arne Hartelius <2731> · Text 3151 · w8 · kommentar
        
        1986-03-22 02:59
        
        Ärende: EOF i maskinkod
        
        Det stämmer helt med mina iaktagelser på ABC80-sidan.
        
        Patric Ljung <5455> · Text 3157 · w8 · kommentar
        
        1986-03-22 09:34
        
        Ärende: EOF i maskinkod
        
        Shhhuu. (som man säger när man håller med). För att verkligen vara på den rätta sidan, tog jag och testade experimentet ytterligare i går kväll. Anledning till att det ligger nollor: Det beror på att när du skriver i bufferten (eller öppnar filen) rensas bufferten så det ligger bara nollor. När du sedan skriver två eller tre rader och stänger filen åker alla dessa nollor med, men texten ligger först i sektorn. Eftersom HELA bufferten måste skrivas ut. När man skriver fler än en sektor så vet jag inte om den rensas, jag tror inte det. Om så är fallet skulle det märkas genom att texten som låg i slutet av förra sektorn (inte skrivits över) av den nya texten i den senare sektorn, slutet av den gamla sektorn ligger kvar i den sista. Vidare observationer: När jag i mitt försök inte skrev mer än en sektor, sparas på skivan den sista sektorn ytterligare en gång. Dvs det fanns två exakt likadana kopior av den enda egentliga sektorn (orsak ?????). Till slut the final cut: CHR¤(3) markerar helt och riktigt enbart RNS (Read next sector). Men chansen är mycket liten att texten skall ta slut precis på position 252 i sektorn. Därav kommer att RNS ligger nånstans mitt i sektorn när filen är slut. Vad mjukvaran då gör är egentligen försöka läsa nästa sektor, men ty, det fanns ingen => EOF. Således är min rutin inte till hundra procent korrekt (99.5%). Det mystiska är att den sista egentliga sektorn ligger dubblerad sist. Och nollorna kommer av att bufferten rensats när man gör OPEN eller om det bara beror på att hela minnet fylls med noll vid reset vet jag inte. Det är obetydligt. Hoppas att begreppen är utredda nu? (Inte behövs det nån dissambler för att kolla detta inte) Men mycket vänliga hälsningar / Patric
        
        Sven Wickberg <1384> · Text 3159 · w8 · kommentar
        
        1986-03-22 11:30
        
        Ärende: EOF i maskinkod
        
        Jag undrar vad ni andra använder för metod att läsa direkt på skivorna. Jag har Magnus Lundbergs program DDISP som visar exakt hur det ser ut i en viss sektor på skivan. Jag ksrev PREPARE etc och två rader FÖRSTA RADEN och SISTA RADEN och sedan CLOSE etc. På min skiva och med DDISP får jag ut följande filutseende: Headerblocket (som ligger först och aldrig syns i vanliga fall): 192 0 0 255 10 66 255 255 etc Första siffran ger det interna numret på filen, andra siffran talar om vilken sektor det är i den aktuella filen, tredje tycks alltid vara en nolla och fjärde alltid 255. De följande två talar om på vilket spår (10) programmet ligger och hur stort det är (någon binär kod som jag inte orkar redogöra för här). Sedan kommer 255 och resten av sektorn är vad som råkade finnas i bufferten vid det tillfälle då denna sektor senast skrevs. Det är alltså skrot och används inte vid läsningen. Nästa block (sektor): 192 1 0 FÖRSTA RADEN 13 ANDRA RADEN 13 3 (sedan skrot) Jag skriver FÖRSTA RADEN i st f motsvarande ASCII-nr. Skrotet är alltså även nu vad som fanns i bufferten och har ingen inverkan. Nu är ju texten slut, men det finns ett block till: 192 2 0 0 0 0 0 0 0 3 (skrot) De tre första talen följer numreringen som ovan. Sedan kommer sex nollor och sedan en trea. Resten är det vanliga skrotet. Det verkar alltså som om chr¤(3) betyder hoppa till nästa sektor, medan sex nollor i början på en sektors läsdel betyder end of file. (Möjligtvis har den följande trean också betydelse.) Programfiler ser ut på ett annat sätt, men det är en annan historia. Om dett ha för övrigt minst två gånger skrivits Bladet. Bo Kullmar brukar vara en överdängare att veta var - men jag medger att det är länge sen. Första gången var omkring 1980-1 i artiklar av Mgnus Lundberg NYFIKEN, och andra ganska kort tid därefter DISKA RENT på skivorna. Det har dessutom nämnts i förbifarten vid andra tillfä'llen.
        
        Kristoffer Eriksson <5357> · Text 3189 · w8 · kommentar
        
        1986-03-25 20:56
        
        Ärende: EOF i maskinkod
        
        Både den andra och den tredje byten i varje sektor anger logiskt (=inom filen) sektornummer. Det är nämligen ett tvåbytestal så filerna kan bli lite längre än 255 sektorer som det skulle bli om det måste rymmas i en byte. Den därefter följande 255:an används åtminstone i filens RIB ("header- blocket" med segmentlistan) i LUX-NET till att markera vilka filer som blivit säkerhetskopierade, men det var nog inte avsikten när ABC-DOSet konstruerades... Om du är intresserad av hur filer är upplagda och framförallt RIB:s organisation, så föreslår jag att du tittar på programmet ABC800/UTILITY/- FILSTAT3.BAS.
        
        Jens Carlberg <6640> · Text 3169 · w8 · kommentar
        
        1986-03-23 22:58
        
        Ärende: EOF i maskinkod
        
        Sköter inte maskinen om det där genom att kolla storleken på filen på bibliotekspåren ? Och därmed bara läsa det antal sekt. som står där ?
        
        Patric Ljung <5455> · Text 3178 · w8 · kommentar
        
        1986-03-24 22:05
        
        Ärende: EOF i maskinkod
        
        Givetvis gör den väl det. Men texten tar ju till 251/252*100 % chans slut mitt i en sektor. mvh / Patric
        
        Mikael Lidén <5651> · Text 3167 · w8 · kommentar
        
        1986-03-23 21:33
        
        Ärende: EOF i maskinkod
        
        Se även Avancerad programmering på ABC80 sid 56.
        
        Peter Öhlén <4659> · Text 3161 · w8 · kommentar
        
        1986-03-22 23:18
        
        Ärende: EOF i maskinkod
        
        Det fungerar, men om du tittar i sektorn efter din slut-3a så ser du att de (sex tror jag) första byten är nollor. Detta är det egentliga slutmärket (som tolken ser det). CHR¤(3) betyder där alltid nästa sektor och först där liggeren nolla. Som du gör funkar inte alltid. Säg att den text du skriver ut är precis 252 tecken lång (med CR mellan rader). När du stänger filen läggs ett CHR¤(3) i 253e positionen. Därefter skulle din rutin läsa nästa sektor och tro att filen fortsatte, medan tolken där märker att det ligger en CHR¤(0) och säger slut på filen.
        
        Kristoffer Eriksson <5357> · Text 3188 · w8 · kommentar
        
        1986-03-25 20:50
        
        Ärende: EOF i maskinkod
        
        Givetvis är det jag som har rätt! :-) CHR¤(3) har alltså som konstaterats, oavsett var i sektorn den finns, endast till effekt att läsningen fortsätter i nästa sektor. Det är CHR¤(0) som markerar slutet på en textfils text, och inget annat! Det ser man lätt om man har en disassemblering. Först testas om nästa tecken i dosbufferten är en trea, i så fall hämtas nästa sektor och positionen inom bufferten nollställs. Om det är en nolla så görs retur med felkoden för filslut och ev påbörjad rad kasseras. Så det så! (Om jag nu inte kastat om ordningen på testerna) Det räcker med en CHR¤(0) var som helst i sektorn, men av någon anled- ning läggs dessa normalt i början av nästa sektor i sex exemplar. Dessa nollor kan inte vara någon rest av en nollställning av hela bufferten, eftersom någon sådan mig veterligen aldrig görs, och varför skulle det i så fall ligga rester från sektorn före i slutet av denna sektor! Den är heller inte någon kollav filens verkliga längd enligt biblioteket som avgör var texten slutar. Det testet ger felkod 38 och inte 34. Prova gärna med att först skriva en lång fil (text som ryms i en enda sektor är allt ganska klent testmaterial), och därefter öppna samma fil på nytt och skriva en mycket kortare text. När filen sen läses upptäcker man att filen tar slut efter den senare kortare texten, inte fortsätter med den intakta delen av den långa texten.
        
        Lars Hedberg <2497> · Text 3190 · w8 · kommentar
        
        1986-03-25 21:30
        
        Ärende: EOF i maskinkod
        
        Tillägg: Det finns ALLTID 6 st <NUL> (CHR¤(0)) i slutet på en textfil! TFP blandar sig in i leken...