Linus Walleij
Elektroingenjörslinjen
Högskolan i Växjö 1993
Microbus TSS (Tid/Sök-System) tillkom mer eller mindre av en slump 1988. En anställd vid dåvarande Jönköpingskontoret fick ett datablad över kretsen UCN500 tillsänt sig. Tanken var att kretsen skulle användas till styrning av termoskrivhuvuden, men bland tänkbara applikationer fanns också nämnt möjligheten att styra LED-segment displayer. Kretsen som är uppbyggd som ett stort seriellt skiftregister med 32 bitars ordlängd, kunde klocka in seriella data och föra över dessa till utgångar, vilka kunde driva en för skiftregister ovanligt hög effekt. Vid åsynen av detta datablad föddes en ide. Ett antal företag hade sedan länge tillverkat dels system för Centraltid, dvs fjärrstyrda klockor, dels system för optisk personsökning, dels i form av segmentdisplayer, och dels i form av lampor, symmetriskt placerade på en cirkelformad skiva, de såkallade "ruter fem" systemen. Dessa ger ifrån sig en summerton för att påkalla uppmärksamheten då någon söks. Ett vanligt centralur styrs av en spänningspuls som kommer en gång i minuten, och rent mekaniskt drar fram visaren ett steg, om man har en vanlig analog klocktavla. Har man en "digital" display adderas en minut till denna. Gemensamt för dessa är att de inte kan göra något annat än visa tid, och att de måste ställas in för hand vid installationen. (Om man önskar ställa om samtliga klockor lika mycket, t.ex vid växling mellan sommar och vintertid, kan detta dock göras genom att ge en snabb serie spänningspulser, och därigenom rucka klockan till önskad tid.) I och med den nya kretsen öppnades en möjlighet att tillverka en kombination av dessa båda, som till på köpet skulle visa sig bli billigare. Genom att integrera fyra segmentvis styrbara sjusegmentsiffor, ett sekundkolon och en summer, och koppla dessa till kretsen, fick man en klocka som också kunde användas till optisk personsökning. Segmenten kunde enkelt byggas upp av lysdioder, och förutom kretsen behövdes förhållandevis lite styrelektronik. Denna konstruktion kräver endast två ledningar för kommunikation (data respektive klocka) och två ledningar för spänningsförsörjning, varför 4-trådig (billig!) EKKX-kabel kan användas.
De tidiga TSS-anläggningarna använder sig av en specialkonstruerad enkortsdator med inbyggt tangentbord för att styra både klocka och personsökning. Det var ju vanligt förr, att man byggde enkortsdatorer för speciella arbetsuppgifter. På senare år har dock priserna på vanliga persondatorer (PC, Personal Computer) sjunkit så pass mycket att vi nått den gräns där det blir billigare att köpa en hel PC och låta den göra jobbet som tidigare gjordes av den specialiserade enkortsdatorn. En egenutvecklad enkortsdator lönar sig numera faktiskt bara om den tillverkas i större serier, omkring 1000 st. och uppåt. (Detta givetvis förutsatt att datorn skall sköta något som lika väl kan skötas av en PC.) Av denna anledning vill man utveckla ett program för att styra TSS-anläggningar från en PC. Denna dator, som endast skall ha till uppgift att sköta TSS-anläggningen kallas hädanefter för TSS-konsoll. Man skall också ta i beaktande att det är lättare att göra programändringar i ett PC-program än i en EPROM-baserad enkortsdator, då TSS-programmet från och till kommer att revideras. Utöver detta vill man kunna koppla TSS-anläggningen till ett lokalt nätverk (LAN), då tillverkare av diverse system numera implementerar nätverksfunktioner i sina utrustningar. Tidredovisning och intern elektronisk post går numera till stor del genom företagens nätverk, och andelen ökar stadigt. Att då kunna söka en person över det optiska personsökningssystemet bara genom att helt enkelt slå in vederbörandes sifferkombination på vilken nätverksterminal som helst, är en lockande tanke. En "riktig" nätverksadapter är dock i sig en enkortsdator, och kräver milt sagt MYCKET stora utvecklingsresurser. MEN om TSS-systemet styrs av en PC, kan man lätt plugga in ett billigt, masstillverkat nätverkskort i denna, och därmed uppnå nätverkssupport via det system med virtuella hårddiskar som flertalet PC-nätverk använder sig av idag. Därmed är ytterligare en fördel lagd till konceptet med nätverkskontroll av TSS-anläggningar. Vi vill alltså uppnå:
Det nya konceptet kontra det gamla illustreras i figuren nedan:
FIGUR SAKNAS
Ett konsollprogram till en TSS-anläggning måste uppfylla vissa grundkrav. Dessa utgörs av de funktioner som finns på den speciella enkortsdator som en gång utvecklats för ändamålet, och är som följer:
Utöver dessa fem punkter skall utvecklas nya system för att:
Det är viktigt att klockan på TSS-anläggningen går rätt. Ett företag har ofta tidredovisning för de anställda och liknande på sitt nätverk, och det är därför en fördel att TSS-anläggningen följer denna "företagstid" så nära som möjligt. Därför har möjligheten att synkronisera klockan mot en nätverksserver lagts in i programmet. Denna funktion finns i dagsläget endast tillgänglig för Novells nätverksmjukvara. Det antas att företagets övriga tidsberoende arbetsstationer också synkroniseras mot denna tid. Programmet Angelica använder då Novells kommandolinje-kommando SYSTIME |SERVER| för att ta ned serverns systemtid till den dator programmet körs på. SYSTIME exekveras med kommandot COMSPEC /C |KOMMANDO| som är en del av den minnesresidenta kommandorepertoaren i COMMAND.COM och BIOS. Då programmet också kan köras på en enstaka dator, utan nätverksanslutning, har också möjligheten att synkronisera den interruptdrivna interna klockan (som inte alltid är helt pålitlig) mot den batteridrivna klocka som finns i det såkallade CMOS-RAM:et i maskiner av modell AT och uppåt. Proceduren som gör detta utförs en gång i timmen om sådan synkronisering valts, och heter "GoTimeSync" i källkoden till Angelica (Se annan plats i denna rapport). Proceduren är delvis skriven i assembler, och de portar och register som används beskrivs i AT Technical manual på sidorna 1-45 till 1-55. Om CMOS-klockan körs i 12-timmars mod (börjar om från 1 mitt på dagen) MÅSTE programmet startas på förmiddagen. Detta beror på att IBM inte behagat implementera någon AM/PM flagga, såsom andra fabrikanter av datorer. Om man skulle äga en sådan dator (Jag har överhuvudtaget aldrig sett någon sådan, men rent teoretiskt bör de kunna existera) kan problemet lätt lösas genom att ställa om denna till 24-timmars visning. Det skall sägas att någon form av kompensering kraftigt rekommenderas, då den interna interruptdrivna klockan på inget vis är tillförlitlig (Se även under "Timer-tick avbrottet" på annan plats i denna rapport).
Följande avsnitt skall ses som ett sammandrag av arbetet med att utveckla styrprogrammen till TSS-anläggningen. Att fullständigt beskriva alla de sena kvällar då jag suttit och jagat "buggar" (programlöss) i mina program vore fullständigt hopplöst, och framför allt fullkomligt ointressant. Jag kommer dock att behandla vissa intressanta problem som dök upp, bl.a problematiken med avbrottshantering i datorn och nätverkskommunikation med Novells mjukvara. Låt mig dock börja från början. När jag satte igång med att planera programmen utifrån den tekniska specifikationen såg jag genast att jag skulle vara tvungen att göra minst två stycken. Ett som skötte kommunikationen med displayerna, och som kunde anropas med kommandon över antingen tangentbordet eller nätverket, och ett program som skickade kommandon över nätverket, till det andra programmet. Det sistnämnda skulle också kunna köras på flera datorer samtidigt utan att konflikt uppstod mellan dem. För att ge programmen lite mer personlig prägel döpte jag programmet som kommunicerade mot displayerna till ANGELICA och programmet som styrde detsamma över nätverket till FELICIA. Dessa namn kommer att gå igen genom hela rapporten så lägg dem på minnet. För den som är intresserad kan jag upplysa om att jag inte har tagit namnen ur min omgivning, utan helt enkelt valt namn som jag tycker är vackra. Efter att ha kommit igång en bit med dessa båda program upptäckte jag att jag dessutom behövde göra ett program med enda uppgift att sköta inställningarna på Angelica, kort och gott kallat SETUP. Mer om detta senare dock. Som programspråk valde jag TURBO PASCAL V6.0 dels för att jag var bekant med språket sedan tidigare, och dels för att det har en inbyggd assembler (tolk för maskinspråk), vilket underlättar maskinnära programmering. Också snabbheten hos kompilatorn var en viktig faktor, eftersom jag använder kompilatorn som ett debuggningsverktyg. En eloge till Borland för denna strålande kompilator! Till dokumentationen av programmen har jag använt JSP-diagram med skriftliga kommentarer (den som är intresserad kan redan nu ta en titt på programlistningarna på annan plats i denna rapport). Det är min förhoppning att denna dokumentation skall vara lättförståelig även för en person som inte sysslar med programmering så ofta. I skrivande stund finns även planer på en version av programmet Felicia som skall kunna köras i Windows-miljö, och som är planerat att utvecklas i det absolut bästa språket för Windows-applikationer: Visual C++. Detta ingår dock inte i grundutvecklingen, och tas inte upp till närmare behandling i denna rapport. Härifrån och några sidor framåt kommer rapporten att behandla programutvecklingen och de problem som är förknippade därmed.
På nästa sida finns ett utdrag ur databladen för kretsen UCN-5832 som beskriver hur det seriella pulståget skall se ut för inmatning till kretsen. Det framgår att data läses in på klocka hög, och att data skall skrivas ut på dataledningen något innan klockan går hög, och tas bort något innan klockan går låg. När ett komplett pulståg a' 32 bitar sänts ut skall en STROBE signal ges för att de inmatade 32 bitarna skall dyka upp på utgångarna på kretsen (det vore ju tråkigt om all data "flimrade förbi" på displayernas segment medan man matade ut seriell data). Displayerna använder dock som sagt 4-trådars EKKX-kabel, varav två till drivspänningen, och någon plats för en tredje speciell STROBE-kabel finns inte. Därför har man vid konstruktionen av displayerna löst detta på ett annat sätt: Man gör så att man fördröjer den positiva flanken på CLOCK-signalen ända till nästa pulståg. En timerkrets (555) på displaykortet känner av detta, och skickar en STROBE-signal efter att en viss tid, längre än en normal klockperiod passerats. Kretsen UCN-5832 påverkas ju inte av att klocksignalen fördröjts! Eftersom pulståget till displayerna bara skickas ut en gång i halvsekunden, kan man ha en god säkerhetsmarginal på "STROBE-fördröjningen". När klockan fördröjs på det här viset är det en del saker man får tänka på vid programmeringen, bland annat får man inte ändra DATA-signalen två gånger medan klockan ligger hög. Detta står inte i databladen till kretsen, men så är det trots allt, på vissa versioner av kretsen. Sådana obehagliga överraskningar stöter man ju ofta på när man konstruerar. Hur kretsen sitter kopplad i displayen, och hur gränssnittkortet till datorns prototypkort ser ut, ingår inte i mitt arbete, men för att öka förståelsen för programmet finns dessas kretsscheman som bilagor till denna rapport. En intressant kommentar om gränssnittkortet dock: när jag vill sätta CLOCK eller DATA signalen hög, sker det genom att skriva en nolla till utgången på prototypkortet, och inte en etta som man kunde vänta sig. Detta har att göra med att signalen inverteras i gränssnittkortet.
Prototypkortet som används för att sända pulståget är av typen CIO-DIO från Computer Boards Inc. Detta används mycket inom industrin för just prototyper och för produkter i små serier. Egentligen hade jag velat bifoga delar av programmeringsmanualen, men detta är dessvärre förbjudet. Därför avhandlar jag istället de viktigaste delarna av funktionen här. Kortet kan ställas in på olika portadresser. Alla IBM-maskiner och dess kompatiblier använder PORTAR för att adressera sina In/Ut-enheter, med undantag för grafikkort och vissa hårddiskkort. Ide'n med portar är att man har ett helt eget 64KByte område som bara kan användas till portar. Varje port omfattar 8 bitar, dvs en byte. Portarna nås med instruktionerna IN AL,PortX resp. OUT PortX,AL i Assembler, X=INP PortX resp. OUT PortX,X i BASIC, och Port[PortX]:=X resp. X:=Port[PortX] i Pascal. Om vi kallar den BASADDRESS vi valt för kortet för Y, är registren enligt följande:
| Port: | Funktion: | Användning i Angelica: |
| Y | Port A | Bit 0 och 1 är DATA resp. CLOCK. |
| Y+1 | Port B | Används EJ. |
| Y+2 | Port C | Används EJ. |
| Y+3 | DDR | Datariktningsregister. |
Datariktningsregistret ger oss en möjlighet att kontrollera om de tre portarna används som In- eller Utgångar. De olika bitarna används för att kontrollera de olika portarna. Jag skall inte gå närmare in på exakt hur detta fungerar, men i programmet Angelica används följande instruktion:
PORT[PortAdd+3]:=$8B
Detta sätter portA till utgång, bland annat. Sedan kan man använda instruktioner ungefär så här:
PORT[PortAdd]:=3 - CLOCK och DATA låga
PORT[PortAdd]:=2 - CLOCK låg, DATA hög
PORT[PortAdd]:=1 - CLOCK hög, DATA låg
PORT[PortAdd]:=0 - CLOCK hög, DATA hög
Jag skall passa på att nämna att den vanligaste addressen för prototypkort är 300H (hexadecimalt) och jag har inte använt någon annan address under utvecklingen av programmet. Om du är mycket intresserad av hur portar fungerar, läs PC Technical Manual, och om du är mycket intresserad av hur prototypkortet fungerar, så försök komma över manualen till CIO-DIO kortet om du inte redan har den.
Microbus TSS-system för nätverk har byggts upp enligt principer som påminner om andra realtidsstyrda nätverksapplikationer. Problemet när man arbetar mot PC-nätverk med realtidsapplikationer, är att nätverken oftast är uppbyggda som en form av asynkrona diskoperativsystem. Om man begär tillgång till en fil kan man få vänta ett tag innan man får den. Sedan kan överföringen gå olika snabbt. Programmet Angelica som hanterar all utsändning till displayerna, samt läser kommandofilen AURORA00.TSS, räknar med att det har mycket snabb tillgång till kommandofilen. När kommandon skickas till Angelica via kommandofilen kommer kommandona inte att accepteras förrän Angelica gått ut på nätverket och läst in densamma. Då Angelica kan fås att gå ut på nätverket mycket ofta om så fordras, upp till en gång per sekund, brukar detta sällan innebära några problem.
För att TSS-programmet Angelica ska kunna fungera mot andra program än Felicia, går kommunikationen mot programmet via en standardiserad fil i nätverket. Vi skall till att börja med beröra styrning via den mest rekommendabla metoden: Rå binärfil. Denna fil kallas AURORA??.TSS (där frågetecknen svarar mot det gruppnummer som avses) och ger möjlighet att lägga upp och ta ned ett flertal sökningar, samt att (vid behov) styra de individuella segmenten samt summern var för sig. Filen består av fyra word (16 bitars tal) sökningar, där de fyra sökningarna kodats i BCD-format, och där siffror som ej skall synas har en icke-giltig BCD-kod, Från AH till FH. (BCD-siffrorna ligger ju som bekant mellan 0H och 9H.) På det här viset möjliggörs sökningar på alla siffror från 0000D till 9999D, med tomma sifferplatser där så önskas. Om ett sökningsword har det hexadecimala värdet FFFFH innebär detta att sökningen inte är utlagd, dvs. att ingen söks. Om alla fyra sökningsworden har värdet FFFFH innebär detta att ingen sökning överhuvudtaget pågår, och att klockan normalt visas. Efter de fyra sökningarna kommer två word som möjliggör direkt styrning av segmenten och summern. Nollor i dessa bägge word innebär att ingen styrning önskas. Om innehållet i dessa båda word är skilt från noll, kommer segmenten att styras efter dessas bitinnehåll. Två bitar används för att styra speciella funktioner som brandvarning, SOS etcetera. Sökningar som skrivs ut samtidigt som segmenten styrs individuellt kommer att ignoreras. Filen består således av 6 word, som utgör en fullgod kommunikationskanal mot Angelica-programmet. Det skall också poängteras att flera Angelica-program kan läsa från samma kommandofil, och därigenom styras från ett enda gemensamt styrprogram. En fördel med att filen är så kort är att den inte belamrar nätverket (tidsmässigt) i onödan. Filformatet är alltså översiktligt:
| Word nummer: | Funktion: |
| 0 | Fyra nybblar (=4 bitar) med BCD-kodat söknummer för sökning ett. Värden över 9 tolkas som tom position. Värdet FFFFH innebär att sökning inte ligger ute. |
| 1 | Samma som ovanstående för sökning nummer två. |
| 2 | Dito för sökning tre. |
| 3 | Dito för sökning fyra. |
| 4 | Individuell segmentkontroll word ett. |
| 5 | Individuell segmentkontroll word två. |
De två word som kontrollerar de individuella segmenten har bitvärden enligt följande:
H O W @
**** **** **** ****
* * * * * * * *
B* G* I* N* * Q* V* X* Ö*
* * * * * * * * *
* F * * M * * U * * Ä *
**** **** P **** **** Summer: A
* * * * * * * *
C* E* J* L* * R* T* Y* Å*
* * * * * * * * *
* * * * * * * *
**** **** **** ****
D K S Z
| KOMMANDOWORD 1: | KOMMANDOWORD 2: | ||
| Bit nr: | Segment: | Bit nr: | Segment: |
| 0 | CMD0 | 0 | O |
| 1 | CMD1 | 1 | P |
| 2 | A | 2 | Q |
| 3 | B | 3 | R |
| 4 | C | 4 | S |
| 5 | D | 5 | T |
| 6 | E | 6 | U |
| 7 | F | 7 | V |
| 8 | G | 8 | W |
| 9 | H | 9 | X |
| 10 | I | 10 | Y |
| 11 | J | 11 | Z |
| 12 | K | 12 | Å |
| 13 | L | 13 | Ä |
| 14 | M | 14 | Ö |
| 15 | N | 15 | @ |
Den mot respektive segment svarande biten skall sättas för att tända segmentet. (eller starta summern) Nollor i samtliga bitar innebär att ingen direkt styrning tillämpas. CMD-bitarna används enligt följande:
| CMD1: | CMD0: | Kommando: |
| 0 | 0 | Inget kommando |
| 0 | 1 | Fire! |
| 1 | 0 | SOS |
| 1 | 1 | Reserverad. |
Sammanfattnig av kommunikationsfilens egenskaper: När ingen styrning önskas skall filen bestå av fyra word med innehållet FFFFH följda av två word med innehållet 0000H. När sökningar skall läggas ut skrivs dessa till någon av de fyra kommandoworden som inte redan är upptaget av någon sökning. Om brandlarm önskas skall kommandoord 1 sättas till 0001H och om SOS-larm önskas skall kommandoord 1 sättas till 0002H.
Det skall här också tilläggas att programmet Angelica självt plockar bort sökningar som legat ute i sextio sekunder, dvs. att det går ut och skriver över sökningar med FFFFH i kommandofilen efter sextio sekunder. Bygg därför aldrig upp program som kräver att kommandofilen förblivit oförändrad då den läses in i ett senare skede. Givetvis går det alldeles utmärkt att ta bort sökningar också genom att skriva över dem med FFFFH. Dock måste Brandlarm, SOS-larm och specialstyrning tas bort av det kommenderande programmet, detta sköter inte Angelica.
Den som inte är så van vid att behandla tal i binär och hexadecimal form kan nog lätt tycka att ovanstående filformat är en aning komplicerat. Därför finns det också andra möjligheter att styra Angelica. I SETUP-programmet kan man ställa in de två lägena Rå ASCII och ASCII/DOS-TEXT. Skillnaden mellan Rå ASCII och ASCII/DOS-TEXT är att DOS-TEXT fogar in ett CR (Carriage Reurn, vagnretur) och ett LF (Line Feed, linjeframmatning) mellan varje sökning. Sökningarna skrivs här in med rena ASCII tecken. Prova till exempel följande:
EDLIN TEST.TXT <CR>
*I <CR>
1: 1234
2: @@@@
3: @@@@
4: @@@@
5: <CTRL+C>
*E <CR>
COPY TEST.TXT |PATH|AURORA??.TXT
Ange PATH (Sökstig till kommandofil) om så behövs, ersätt frågetecknen med gruppnummret för den grupp du jobbar mot. Sökningen "1234" bör nu dyka upp på displayerna och konsollskärmen. Alla fyra sökningarna kan skrivas in på det här viset, om tomrum önskas kan man skriva in ett mellanslag. Tomma sökningar representeras som synes av tecknet @ (alfaslang).
När du kör med ASCII utan DOS-TEXT, kan du behandla filen som en sträng med 16 tecken. Till exempel för sökning två upplagd med nummer 1657:
STRÄNG = "@@@@1657@@@@@@@@"
Detta format är oftast lättast att implementera i lite mindre avancerade programspråk.
Filen AURORA00.TSS skall ligga i ett bibliotek i nätverkets server. Eftersom programmet öppnar och läser filen med jämna mellanrum, måste åtkomsten vara god. Programmet Angelica skall ligga inloggat som en user och typiskt ha tillgång till endast filen AURORA00.TSS. (Detta för att förhindra att någon kommer in i nätverket genom att logga in sig som TSS-enheten.) Om servern blir överbelastad kan detta innebära att sökningar blinkar två eller flera gånger istället för att växla regelbundet. (Detta beroende på att huvudprogramslingan inte går vidare förrän filen lästs in) Angelica hämtar även klockan från servern då det används mot vissa typer av nätverk. (I Novell med kommandot SYSTIME |SERVER|) Även denna operation kan om den blockeras av en överbelastad server ge symptom som de ovanstående. Jag vill poängtera ännu en gång vikten av att ge Angelica mycket begränsad tillgång till systemet, helst bara till ett bibliotek som innehåller endast filen AURORA00.TSS. Om det finns möjlighet att i nätverket prioritera åtkomsttiden för olika användare, är det rekommendabelt att ge TSS-programmet Angelica HÖG prioritet. (Snabb filaccess)
De flesta nätverk låter en användare vänta på en annan om de båda samtidigt begär tillgång till en och samma fil. Detta innebär att Angelica får vänta på att programmet som skriver kommandon till AURORA00.TSS skall bli färdigt med filskrivningen. För att denna tid skall bli så kort som möjligt, om det skulle slumpa sig så att programmen begär tillgång till filen samtidigt, rekommenderas följande metod till programmerare som vill ge kommandon till Angelica:
På det här viset minimeras den tid programmet får vänta på att komma åt kommandofilen. Följande program visar ett exempel på hur detta med fördel kan utföras i den vanliga Quick-Basicen som följer med MS- och PC-DOS 5.0 och uppåt:
REM Demonstrationsprogram för Quick Basic (QBASIC)
CLS
PRINT "Enkelt exempel på sökprogram, (C) MICROBUS i Ljungby AB 1993"
sok1l% = 255: sok1h% = 255: REM söktabell i minnet
sok2l% = 255: sok2h% = 255
sok3l% = 255: sok3h% = 255
sok4l% = 255: sok4h% = 255
com0% = 0: com1% = 0
com2% = 0: com3% = 0
INPUT "Sök vilket nummer:", a$
dig1$ = MID$(a$, 1, 1): REM en sträng för varje tecken
dig2$ = MID$(a$, 2, 1)
dig3$ = MID$(a$, 3, 1)
dig4$ = MID$(a$, 4, 1)
PRINT dig1$, dig2$, dig3$, dig4$
INPUT "Sökstig till kommandofil:", b$
REM Sista "backslashen (\) måste inkluderas!
b$ = b$ + "AURORA01.TSS": REM aktuellt gruppnummer
dummy% = ASC(dig1$): GOSUB adjust: dig1% = dummy%
dummy% = ASC(dig2$): GOSUB adjust: dig2% = dummy%
dummy% = ASC(dig3$): GOSUB adjust: dig3% = dummy%
dummy% = ASC(dig4$): GOSUB adjust: dig4% = dummy%
REM konvertera till BCD-kod
sok1l% = (16 * dig1%) OR dig2%
sok1h% = (16 * dig3%) OR dig4%
REM tillverka BCD-talet
OPEN b$ FOR BINARY ACCESS READ WRITE SHARED AS #1 LEN = 2
REM öppna kommunikationsfilen
PUT #1, 1, sok1h%
PUT #1, 2, sok1l%
PUT #1, 3, sok2h%
PUT #1, 4, sok2l%
PUT #1, 5, sok3h%
PUT #1, 6, sok3l%
PUT #1, 7, sok4h%
PUT #1, 8, sok4l%
PUT #1, 9, com1%
PUT #1, 10, com0%
PUT #1, 11, com3%
PUT #1, 12, com2%
REM skriv ut sökningen och de tomma sökplatserna
CLOSE #1
REM stäng filen igen
PRINT "Programmet avslutat."
END
adjust:
IF dummy% < 48 OR dummy% > 57 THEN dummy% = 10 ELSE dummy% = dummy% - 48
RETURN
Den som har erfarenhet av nätverk påpekar här säkert att kommunikationsfilen inte hanteras på absolut bästa möjliga sätt. Informationen som sänds över nätverket skickas ju i PAKET, där varje paket har en address och en checksumma. Basicprogrammet ovan skickar 12 paket, med address och checksumma i varje, ett för varje PUT-sats. Det hade givetvis varit bättre att i det här fallet deklarera en egen datatyp, innehållande 12 bytes, och sedan skicka denna som ett enda paket över nätverket. Denna metod har inte använts här, då avsikten endast varit att ge ett enkelt programexempel. Om man konsulterar programlistningarna till Angelica och Felicia upptäcker man att denna optimering inte gjorts på dessa program. Detta beror på att programmet skall kunna läsa även textfiler som kommandogivare, varför ordvis hantering är att föredra. Informationen hanteras därför i sex paket med två bytes i vardera. Observera också hur programmet deklarerar filen. Egentligen behöver vi bara läsa filen, men deklarationen har gjorts med tanke på att användaren kanske vill bygga ut programmet till att omfatta även kontroll av kön, dvs att en ny sökning inte skriver över en gammal, och då måste man ju även läsa in filen för att kontrollera att inget annat program också begärt sökning. Som jämförelse kan nämnas att programmet Felicia kan köras på flera datorer samtidigt utan några som helst problem. Det enda "problemet" är att man kan ta ned varandras sökningar.
För att testa hur nätverket belastas av att Angelica läser in kommunikationsfilen så pass ofta, har jag gjort ett test med programmet Ethervision från Triticom. I testresultaten som redovisas på nästa sida kan man se (Överst) hur många bytes (8-bitars tecken) som sänds ut från varje station. Stationen med nummer 0000C03781C (hexadecimalt) är datorn med programmet Angelica i full fart med att läsa kommunikationsfilen var annan sekund. Stationen inunder är Servern, och under denna finns datorn där programmet Felicia startats upp. Under de cirka fem minuter som programmet registrerade nätverkstrafiken vandrade således 468 bytes över ledningen till Angelica-programmet (Detta inkluderar de bytes som används för ramsynkronisernig, Address och Cyklisk redundanskontroll). De andra två stationerna är andra nätverksanvändare. Det diagram med vandrande staplar som finns inunder visar proportionerna på hur lite programmet verkligen belastar nätverket. Staplarna visar dock inte Angelicas användning av nätet, utan en serie uppstarter och stängningar av programmet Windows över nätverket (mycket datakrävande). Endast programmet Angelica gav så litet utslag att det överhuvudtaget inte syntes (observera att detta är på en logaritmisk skala!). Ytterligare ett test har dock gjorts, då alla stationer på nätverket var fullt sysselsatta med att kopiera ett flertal stora filer fram och tillbaka till nätet, och därigenom avsiktligt överbelastade detta. En topp på 78% användning och ett stort antal kollisioner detekterades innan Servern stängde av nätverket på grund av överbelastning. Detta till trots fungerade tidsvisningen från Angelica dock hela tiden utmärkt! När Servern sent om sider återupptog nätverkshanteringen fortsatte Angelica att läsa kommandofilen som om inget hänt. Vi gjorde även ett försök med att fullkomligt "fimpa" nätverket, dvs stänga av servern. Då stannade klockan. Även om man drog ur nätverkskabeln stannade programmet. Datorn krävde återstart och ny inloggning på nätverket för att fortsätta fungera. Detta problem kommer att bli föremål för åtgärd i senare programrevisioner.
Utsändning av seriell data till TSS-displayerna skall ske kontinuerligt, och det är av stor vikt att klockorna inte stannar (Punkten slutar blinka) för att datorn är sysselsatt med att till exempel läsa av kommandofilen från nätverket. Därför programmeras utsändningsrutinen lämpligen i form av ett avbrott (interrupt). Detta avbryter programmet med jämna mellanrum och utför den seriella datautmatningen. Eftersom data skall sändas till displayerna en gång varje halvsekund, vore det idealiskt med ett avbrott som avbryter programmet med 500 millisekunders intervall. Något sådant avbrott finns dock inte på PC:n. Däremot finns det ett såkallat "timer-tick" avbrott som uppdaterar den interna klockan. Detta inträffar exakt 18,2 gånger per sekund, och har avbrottsvektornummer $1C. Just vektor $1C är avsedd för användartillämpningar. Man programmerar därför ett avbrott som utförs i sin helhet var nionde gång det anropas, och får då ett intervall mellan utsändningarna som ligger nära 500 ms (494,5 ms för att vara exakt). När man ger sig på att programmera detta avbrott kommer man dock att stöta på problem. Pulståget som skall sändas ut till displayerna är ju längre än 1/18.2 sekund! Alltså kommer "timer-tick" generatorn att generera avbrott medan ett annat avbrott utförs. För att se vad som kommer att hända måste man konsultera DOS tekniska manual. Där finner man att ett avbrott när det inträffar spärrar alla överlappande avbrott. Om man önkar åstadkomma ett avbrott som i sig kan avbrytas, måste man utföra maskinkodsinstruktionen STI (=SeT Interrupt enable flag) som första instruktion i avbrottet. Detta måste man i ett sådant här fall göra, ty "timer-tick" avbrottet uppdaterar som sagt var klockan, och om det inte utförs kommer klockan i datorn att gå efter, vilket vore synd (Nähä, för synd är något helt annat! ,granskarens anm.) eftersom vi använder just denna klocka till TSS-anläggningen. Nu råkar man dock på ett ganska stort problem. Av de hög- och mellannivåspråk som kan tänkas användas till programmet är det bara en handfull (Pascal, C, C++ och några till) som överhuvudtaget understöder avbrottshantering och ABSOLUT INGA kända, som har stöd för överlappande avbrott. Vad gör man då? Jo, man tar till tjuvknep. Både Pascal och C kan förses med inskjuten maskinkod när så önskas. Därför utför man STI-kommandot i ren maskinkod som första instruktion i avbrottsrutinen. Nu är det dock trots allt inte så enkelt! Ett avbrott, eller i varje fall ett "timer-tick" avbrott, kan inte avbrytas av ett avbrott av samma typ (Detta finns inte dokumenterat, det har bara visat sig erfarenhetsmässigt och kan tänkas bero på hur BIOS är programmerat). DÅ gör man istället så att man kompenserar datorns lokala klocka för den tid som avbrottet "stjäl". I programlistningen på annan plats i denna rapport kan intresserade se exempel på hur detta lösts i Pascal (Närmare bestämt i rutinen SyncTimeToMilli i sektionen "Avbrott").