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

Nya multitask rutiner

7 posts in thread

Mikael Lidén <5651> · Text 3209 · w8 · inlagg

1986-03-30 14:44

Ärende: Nya multitask rutiner

Nu finns multitask hanteraren i sitt slutliga tillstånd i inlådan, dvs filerna MULTITASK.BAS, MULTITASK.DOC och MTASK.BAS Multitask hanteraren tar ca 450 byte i anspråk och laddas på stacken. För ABC806, kommer en multitask hanterare+litet OS med bla minnes- allokering, långa hopp, minnes mappning och möjlighet att köra processer i extern minnet som är upp till 256K byte stora. 16 processer kan köras samtidigt. Denna hanterare körs som en task under den vanliga multitaskhanteraren, och upptar totalt 85 bytes av det vanliga primär minnet. Det som finns klart idag är ett program som kan ladda en boot fil för den externa multitaskdrivern, även själva multitask drivern finns klar & fungerande, det som saknas är alla system anrop - men de kommer. Tanken är att man med hjälp av en laddare skall kunna ladda en typ av EXE filer, begära minnesallokering och sedan starta processen. Tanken är att varje process skall kunna vara 256K stor, dvs 64st 4K-block Under körning så mappas 16K minne in där 8K skall vara en program sida, och 4K global stack, och resterande 4K global dataarea. Sedan kan långa hopp och CALLs göras mellan program sidor genom RST anrop Ex: LD HL,adress LD A,rst funktion LD B,program sida RST 30H ; Nu blockas den nya program sidan in och ; exekvering startas på HL. Sedan skall man kanske göra det möjligt att blocka sidor ut & in från fil på disk om primär minnet inte räcker till, tänk att kunna köra 16 processer på 256K vardera + 16 processer i det vanliga minnet ! Det blir bökigt att skriva assembler program som utnyttjar sig av mer än 16K minne, speciellt då misstag gör att man måste boota om igen, däremot skulle en kompilator kunna generera kod på så sätt att den la funktioner & procedurer i olika sidor, tex small C omskriven. Nå det blir mycket på engång, jag kommer att skriva multitask hanteraren och system anropen klart, jag är mycket tacksam för synpunkter på och förslag på det hela.
- Jan Lundmark <2765> · Text 3212 · w8 · kommentar
  
  1986-03-30 17:54
  
  Ärende: Nya multitask rutiner
  
  Länkaren till os8 (databoard) lägger ut kod för segmenthopp automatiskt. Det enda man behöver tänka på själv är att ange segmentstorleken samt att i början av varje segment inkludera modulen SEG¤HDR. Där finns kod som mappar in det rätta segmentet. Och eftersom koden är identisk i början av varje segment så kommer inte segmentbytet att märkas. Kan de' va' nåt ? (nu börjar önskelistorna droppa in...)
  - Mikael Lidén <5651> · Text 3214 · w8 · kommentar
    
    1986-03-30 18:41
    
    Ärende: Nya multitask rutiner
    
    Ja det är vettigt, men det ligger inte på system anropsnivå, utan det är snarare något som länkaren/assemblern skall fixa kod för. Man får nog skriva en assembler+länkare för multitask- hanteraren. Men det krävs en kompilator, som ger "safe code" för att det skall fungera bra, ty det finns ju inget minnes-skydd, så ett "skenande assemblerprog" gör att man måste boota om. Är det någon som hjälper mig med filhantering från assembler så blir det kanske möjligt att swappa minnes-sidor ut och in på fil också, samt system anrop som laddar och exekverar EXE filer. Tänk att kunna köra kompileringar,assembleringar mm i bakgrund !
    - Jan Lundmark <2765> · Text 3220 · w8 · kommentar
      
      1986-03-30 21:43
      
      Ärende: Nya multitask rutiner
      
      Minnesskydd skulle som sagt vara bra att ha. En bit på vägen skulle kunna vara att titta var stackpekaren pekar varje gång det kommer ett klockinterrupt. Är sp < processens högsta adress så får inte den processen köra mer. Det är givetvis inget fullständigt skydd men det kanske hindrar den skenande processen från att förstöra för andra. Ej heller är det ett skydd mot att processen indexerar sig utanför matriser. Men det kostar inte så mycket att implementera.
      - Mikael Lidén <5651> · Text 3222 · w8 · kommentar
        
        1986-03-31 12:19
        
        Ärende: Nya multitask rutiner
        
        Det är iofs ett sätt kolla det hela på, men in hindrar exempelvis processen från att göra dos anrop mm, anropa läs tkn mm, så att det blir svårt att kolla.
- Kristoffer Eriksson <5357> · Text 3248 · w8 · kommentar
  
  1986-04-02 21:17
  
  Ärende: Nya multitask rutiner
  
  Arbeta inte ihjäl dig nu! Jag skulle föredra en maskinoberoende anordning i stil med den jag beskrev tidigare (några veckor sen) där man inte låsr sig till 806:ans 4K-block- ning, utan i stället arbetar med anrop som tilldelarden anropande processen ett avsnitt minne av ospecificerat slag. Även 802:an har ju extramine, men inte av samma slag som 806:an, och det gör ju inget om det tilldelade minnet till att börja med rent av ligger i det vanliga arbetsminnet. Tänk på att eftersom inget minnesskydd är kopplat tll blocken, så behöver inte tilldelningarna nödvändigtvis vara hela block (inte så bra när blocket har storleken 30K: 800, 802) utan kan ha gänsen på godtycklig adress. Blocken behöver inte heller ligga i följd i adressutrymmet om prgrammet är gjort så att det kan klara av utspridda minnessegment genom att hålla reda på använda adresser. På så sätt slipper man program som MÅSTE ha en 806:a för att kunna köras (utom sådana som verkligen behöver mer än 60K minne på en gång, men de skulle ju kunna buffra på disk när primärminne fattas).
  - Mikael Lidén <5651> · Text 3262 · w8 · kommentar
    
    1986-04-03 16:29
    
    Ärende: Nya multitask rutiner
    
    Det är naturligtvis bra om man köra det på alla maskiner i 800:serien, men med den driver som jag har klar nu, den innefattar, bla lågnivå anropen för multitask-handlern (den som körs i extern minne under MULTASK), samt fungerande minnesallokering i 4K - block. Det som återstår är rutinerna för att hålla reda på en process, sidor, så att den kan göra långa JUMP & CALL:s + laddning av EXE-fil. Så här är det tänkt inblockning sker med 8K prog minne 4K data, & 4K global stack., sedan kan långa hopp & call:s utföras mellan 8K sidorna, och de rutiner som är under utveckling skall kunna hantera processer som är upp till 256K stora. Vitsen med att extern minnes hanteraren körs under en task i MULTASK är att den blir lite enklare, samt att MULTASK kan köras på samtliga maskiner i 800:serien, och att BASIC fortfarande kan som en normal task. Inblockning sker idag med början på adress 32768, först 4K XOS och sedan 16K för processen. Att länka in över 0-32K är inte lämpligt då det ständigt pågår olika typer av INTERRUPT i maskinen bla tangentbord, V24:a mm som hoppar dit dessa funktioner skall fungera felfritt fast man har taskar gående i bakgrund, OK man kan skriva om alla INT runtiner om man vill att det skall fungera. Har ni bra ideér på hur man fixar det här med INT när man blockar in så pass stora areor som 32K, (DI är en mycket dålig lösning). Åter till XOS (Xternt multitask OS) som är utvecklat med alla lågnivå anrop, dock krävs högnivå anropen + en assembler + länkare innan allt är klart. Assemblern skall automatiskt generera sid blocknings kod när den upptäcker att JP eller CALL är längre än 8K mm. Sedan kan man skriva assembler kod helt utan hänsyn tagen till 64K begränsningar, fastän man kanske gör ett JP 128K längre fram i koden. Vitsen med en sådan assembler är att då kan tex en kompilator typ SmallC generera assembler kod, utan att modifieras för minnesblockning, som direkt fungerar att köra under XOS. Vi för se några helger längre fram då skall de högre systemanropen även vara klara, och då kan jag skicka in något.