
    29 Juni 1991, Ramon van der Winkel
     

    Concept definitie Modem drivers en Datacommunicatie Protocollen
    ---------------------------------------------------------------


    Omdat er momenteel aan een datacommunicatie programma wordt gewerkt 
    en er binnenkort ook een mailer geschreven gaat worden voor de MSX 
    lijkt het me verstanding een standaard te definieeren, waarbinnen 
    de Modem Drivers en Datacommunicatie Protocollen geschreven moeten 
    worden.

    Mijn idee is dat de drivers - zo zal ik ze maar even noemem - als 
    TSR ingeladen worden en door het betreffende programma worden 
    opgezocht en aangeroepen.

    Zo kan er voor ieder modem dat er nu is, of er in de toekomst nog 
    zal komen, een eigen set routines geschreven worden die het modem 
    besturen. Deze set routines wordt door het programma aangeroepen, 
    op een hieronder te definieeren manier.

    Voor het overzenden van bestanden over het modem zijn bepaalde 
    protocollen - regels - bedacht om de gegevens over te sturen. 
    Momenteel zijn er protocollen als Xmodem en Ymodem voor de MSX 
    beschikbaar. Maar het moet natuurlijk ook mogelijk zijn een 
    protocol als Zmodem of SeaLink, of TelLink of Kermit of wat dan ook 
    te gebruiken, zonder dat het programma er zelf voor hoeft te worden 
    aangepast. Ook hier kunnen drivers van pas komen.

    Hieronder eerst een opsomming van alles wat volgens mij in een 
    Modem Driver moet zitten:


    1)  Nummer bellen

    Als eerste moet het modem verbinding kunnen maken met een ander 
    modem. Hiervoor is een telefoon nummer nodig. Oke, ik weet dat er 
    ook zoiets is als een nul-modem verbinding, maar daar kan altijd 
    nog een apart telefoonnummer (uitroepteken ofzo) voor gebruikt 
    worden of een aparte funktie voor gemaakt worden.

    Bij de aanroep van deze funktie moet dus het telefoon nummer worden 
    opgegeven. Terug kan een verbindings code worden doorgegeven. 


    2) Ophangen

    Aan het einde van een sessie moet de verbinding weer verbroken 
    worden. Meestal gaat dit automatisch als de andere kant ophangt, 
    maar als de verbinding direct verbroken moet worden, dan kan deze 
    funktie daarvoor gebruikt worden.


    3) Verbindings status

    Via deze info funktie kan de verbindings status worden opgevraagd. 
    Het is namelijk ook mogelijk dat de andere kant de verbinding 
    verbreekt.


    MJV> Het lijkt me beter om hier twee aparte functies van te 
	 maken. Er moet worden voorkomen dat er een functie-aanroep 
	 ongewenste handelingen uitvoert. Dus wanneer je de 
	 verbindings status.
	 `status' functie een heleboel


    Verder moet via deze funktie de actieve snelheid kunnen worden 
    opgevraagd. In het SeaLink protocol is de blok-grootte namelijk 
    afhankelijk van de snelheid: Des te hoger de snelheid, des te 
    groter de blokken worden.


    4) Teken versturen

    Deze funktie kan een teken versturen. Of het teken alleen gebufferd 
    wordt, ofdat het meteen verstuurd wordt, dan ligt aan de methode 
    van de driver zelf. Soms is het handiger om te wachten totdat het 
    teken verstuurt is, maar in de meeste gevallen is het sneller als 
    het teken in het buffer wordt gezet en ergens op de interrupt, met 
    een x aantal tekens tegelijk, verstuurt wordt.


    5) Ontvangen teken ophalen

    Als het modem een teken klaar heeft staan, wordt er een Interrupt 
    signaal naar de computer gegeven. Op dat moment wordt deze driver 
    benaderd, die het teken ophaalt bij het modem en in het ontvangst 
    buffer stopt.

    Via deze funktie kan een teken uit het ontvangst buffer worden 
    opgehaald. Natuurlijk volledig voorzien een foutvlag of wat dan 
    ook, als er geen teken in het buffer aanwezig is.


    6) Aantal tekens vrij in het verzend buffer opvragen

    Om te bepalen of een heel blok in het buffer kan worden geplaatst, 
    kan hiermee worden opgevraagd hoeveel ruimte in het buffer is, 
    zodat kan worden bepaald of het blok erin past.


    7) Aantal tekens aanwezig in het ontvangst buffer opvragen

    Om te controleren of er tekens ontvangen zijn, kan deze routine 
    gebruikt worden.

    Over het werkelijke nut van deze routine, even als de vorige, moet 
    nog even worden nagedacht, want de routines die een teken ontvangen 
    of zenden kunnen natuurlijk ook een foutmelding geven als het 
    buffer leeg c.q. vol is.


    8) Blok tekens versturen 

    Via deze routine kan een heel blok van tekens in een keer worden 
    verstuurd. Dit kan handig zijn voor de datacommunicatie 
    protocollen, want in de tijd dat de modem driver bezig is het blok 
    te versturen, kan het protocol een nieuw blok klaar zetten.

    Verder gaat het versturen van een blok tekens natuurlijk sneller 
    dan telkens een teken versturen.

    
    9) Blok tekens ontvangen

    Via deze routines kan een heel blok tekens tegelijk worden 
    opgehaald uit het buffer. Zo kan een protocol - maar weer eens - 
    een blok ophalen en verwerken, terwijl de modem driver het volgende 
    blok al weer ophaalt. Dat kan natuurlijk ook door steeds een teken 
    op te halen, omdat de modem driver toch wel door gaat met het 
    ontvangen van de tekens, via de interrupt.

    Hetzelfde als bij de vorige funktie: Het is sneller dan steeds een 
    teken ophalen.


    10) Buffer leeg maken

    Via deze routine kan het ontvangst of verzend buffer worden 
    leeggemaakt. Dit kan soms handig zijn en zeker als initialisatie 
    van de buffers moet deze routine worden aangeroepen. Intern deze 
    routine zal een afsplitsing moeten komen voor het wissen van alleen 
    het ontvangst buffer, alleen het verzend buffer of beide buffers.


    Tot zo ver de Modem Drivers, nu de datacommunicatie protocollen.
    
    Ik denk niet dat de Datacommunicatie Protocollen veel opties naar 
    buiten hoeven te hebben. Intern zullen er veel zaken geregeld 
    moeten worden, maar van buiten hoeven volgens mij alleen de 
    volgende zaken aanwezig te zijn:


    1) Verzend een file / meerdere files (batch transmission)

    Zoals al eerder gezegd zijn er verschillende protocollen. De meeste 
    'oude' protocollen kunnen slechts een file per keer versturen. Er 
    zijn echter ook een aantal uitbreidingen, waardoor het protocol 
    meerder files achter elkaar kan verzenden, gebruik makend van de 
    'oude' basis protocollen.

    Als invoer moet niet alleen een bestands naam, maar ook meerdere 
    opeenvolgende namen worden opgegeven en ook paden moet niet 
    vergeten worden.


    2) Ontvang een file / meerdere files (batch reception)

    Ook hier weer hetzelfde verhaal als bij het versturen van de 
    files. Alleen zal hier moeten worden opgegeven in welk pad de files 
    terecht moeten komen. Bij de versturing wordt namelijk geen pad 
    meegegeven. Dat zou ook een beetje vreemd zijn om dat wel te doen.


    3) Status

    Misschien dat er een aparte status funktie voor het ontvangen en 
    zenden moet komen.

    Via deze status funktie kan de stand van het downloaden of uploaden 
    bekeken worden. Zo moet er kunnen opgevraagd met de hoeveelste file 
    er in een batch ontvang of verzonden wordt. Hoeveel bytes van de 
    hoeveel in totaal er al klaar zijn en hoeveel blokken van de 
    hoeveel in totaal (indien beschikbaar) er al klaar zijn. Misschien 
    nog een aantal andere dingen, maar daar moet nog maar even over 
    gedacht worden.

    Er staat `indien beschikbaar' omdat protocollen als Xmodem niet 
    weten hoeveel bytes er in totaal verwacht worden. Bij het verzenden 
    kan dat natuurlijk wel bepaald worden.

    Verder kunnen er misschien nog wat tijd-tellers mee doen. Dan kan 
    ook de effectiviteit van de download bepaald worden.


    Ik heb nog veel meer ideeen. Zo denk ik dat de Modem Driver moet 
    kunnen melden aan het protocol - of wat dan ook - dat het verzend 
    buffer leeg is. Op dat moment is bijvoorbeeld een blok voor het 
    protocol verstuurd en kan het volgende worden verstuurd.

    Ik denk hieraan, omdat ik ook een multi-lijns BBS wil maken. Op dat 
    BBS moet de computer dan twee dingen tegelijk doen. Dit lijkt op 
    zich niet zo moeilijk, maar in de praktijk zal er toch wel even op 
    gelet moeten worden dat als de protocollen en TSR worden, ze niet 
    constant bezig mogen zijn met het versturen van data blokken, omdat 
    het bbs ook de andere lijn af moet kunnen blijven helpen.

    Misschien dat iemand - die ervaring heeft met multi-tasken en 
    time-sharen - eens een aantal ideeen kan geven hoe je zoiets op zou 
    kunnen lossen.


    Ik hoor de reakties nog wel,

    Ramon van der Winkel
    
