
           ----------------------------------------------------------
           XRK Extra RedCode Kit v1.50 - (C) 1992-2002 Marco Pontello
           ----------------------------------------------------------


    INTRODUZIONE:

    XRK e` l'acronimo di Extra Redcode Kit e, come suggerisce il nome
    stesso, si compone di un set di tools per lo sviluppo di programmi
    per Core War, dalle prime fasi di testing/debugging fino
    all'esecuzione di veri e propri tornei.

    Passiamo alla presentazione dei vari moduli:

    XRA, XRD, XRS, XRC
    + RedMap Editor

    Tutti i moduli sono conformi alle direttive dello standard ICWS-86. C'
    e` da dire che, pur trattandosi in teoria di uno standard, in pratica
    sono fiorite diverse interpretazioni, probabilmente per una certa
    imprecisione di quello che doveva essere il documento di riferimento.

    Giusto per chiarire, quindi, diciamo che questa implementazione e`
    conforme a quanto descritto nelle varie puntate sull'argomento
    pubblicate su MC Microcomputer, numeri dal 67 al 69 (piu` qualche
    altra puntatina, in seguito), in cui le Core War sono state presentate
    ai lettori). Per quanto riguarda i principali parametri del sistema,
    quindi, si puo` riassumere come di seguito:

       Max Istruzioni per programma:      512
       Dimensione del Core:             8.192
       Distanza Minima iniziale:        2.048
       Max tasks attivi per programma:     64

       Nuovi tasks eseguiti immediatamente dopo il task generante

       Time Out (clock ticks): 50.000

       Il contenuto di ogni istruzione viene copiato in appositi
       registri interni prima di essere eseguita.

    Inoltre, vengono implementate caratteristiche originali di un certo
    interesse, che vengono illustrate e spiegate ampiamente di seguito,
    unitamente al funzionamento di ogni modulo.
    Molto sinteticamente:

    - Il compilatore e` in grado di "digerire" sorgenti scritti in
      praticamente qualsiasi modo, accetta la pseudo istruzione "EQU",
      valuta espressioni (da sx a dx), riconosce l'autore dai commenti nel
      sorgente. Inoltre puo' segnalare il tipo di errore, la linea e la
      colonna secondo un formato ridefinibile, in modo da poter essere
      interfacciato con praticalmente qualsiasi editor per programmatori.

    - Simulatore e programma per competizioni dispongono di un algoritmo
      di allocazione ottimizzata (non casuale) dei programmi, che assicura
      risultati piu` affidabili e assolutamente ripetibili.

    - E' implementato un sistema di record/playback degli scontri, in modo
      da accelerare enormemente lo svolgersi di un torneo, tanto da
      permettere di testare un programma facendogli disputare numerosi
      tornei in pochissimo tempo.
      Collateralmente, permette anche di non preoccuparsi in caso di
      black out durante un torneo, in quanto gli scontri eseguiti fino a
      quel momento saranno comunque recuperati automaticamente al
      sucessivo avvio.

    - Si possono svolgere tornei in rete in modo da ridurre drasticamente
      il tempo di esecuzione e visualizzare simultaneamente la classifica
      aggiornata su piu` monitor. I vari computer in rete possono
      collegarsi e scollegarsi dinamicamente, in qualsiasi momento, senza
      pregiudicare lo svolgersi del torneo.

    Preciso che comunque non trovere spiegazioni sull'uso dei vari
    comandi e modi di indirizzamento Redcode in questo file; se pensate
    che il Redcode sia un qualche codice crittografico in uso presso i
    paesi aldila` degli Urali, leggetevi il file "COREWAR.TXT", compreso
    nel pacchetto di XRK.
    Potete anche fare riferimento ai numeri di MC sopracitati (considerate
    come incentivo che il Redcode e` un ottimo modo per avvicinarsi alla
    logica della programmazione Assembly!).

    Sono inclusi i sorgenti, gli eseguibili e relativo Playback file di
    alcuni programmi, che vanno da vecchi classici (Dwarf, Imp), a
    gloriosi ex campioni (Mice, Ferret) e diversi altri.

    Passiamo ora senz'altri sproloqui perditempo alla descrizione piu` o
    meno dettagliata dei vari moduli, non senza ricordare che ogni modulo
    fornisce un succinto riepilogo dei vari parametri utilizzabili,
    utilizzando gli switch /HELP, /H, /?, etc.:


    XRA - Extra Redcode Assembler
    -----------------------------
    Formato: XRA [path]<file>[.RED] /NN /NS /F:string
                 <file> nome di un sorgente .RED
                 /NN    inibisce richiesta nome autore"
                 /NS    non mostra le linee del sorgente con errori
                 /F:    permette di specificare il formato con cui generare
                        i msessaggi d'errore/warning


    E' l'assemblatore o compilatore che dir si voglia, che a partire dai
    file ASCII con i sorgenti in Redcode (.RED), produce i moduli oggetto
    (.RBJ, da Redcode Object) che possono essere utilizzati con gli altri
    moduli.
    XRA accetta tutti i comandi standard:

       DAT   B
       MOV A B
       ADD A B
       SUB A B
       JMP A
       JMZ A B
       JMN A B
       DJN A B
       CMP A B
       SPL   B

    e gli altrettanto standard modi di indirizzamento:

       # Immediato
       $ Diretto
       @ Indiretto
       < Indiretto autodecrementato

    Inoltre XRA tratta label con fino a 16 caratteri (solo alfabetici e
    numerici, con il primo carattere obbligatoriamente alfabetico).
    La label di sistema START, che indica la linea da cui deve cominciare
    l'esecuzione del programma, puo` essere soppressa (argh!), nel qual
    caso l'esecuzione iniziera` dalla prima linea (come indicato da
    apposito pedante Warning in fase di compilazione).
    Il Warn in questione ha anche cura di mostrare la linea da cui
    comincera` l'esecuzione, in modo che ci si possa rendere subito conto
    di eventuali errori; l'esperienza, infatti, insegna che non e` poi
    una gran tattica, partire con un DAT!

    A proposito di "DAT", preciso che, indipendentemente dal modo di
    indirizzamento utilizzato nel sorgente, viene comunque sempre
    assemblato come "DAT #x". Quindi, una locazione contenente un "DAT 0",
    si puo` considerare al pari di una locazione vuota.

    E' supportata la pseudo istruzione "EQU", che serve per assegnare un
    valore ad una label. Possono essere usate ovunque nel sorgente (in un
    numero massimo di 32), poiche` vengono in ogni caso valutate prima, di
    qualsiasi altra linea eseguibile. Ex:

       Step EQU 7

    Possono essere utilizzate espressioni ovunque sia richiesto un
    operando.  Le espressioni devono essere racchiuse da parentesi e
    possono contenere i classici quattro operatori (+ - * / o \), numeri o
    label. Le operazioni consentite sono eseguite senza tener conto di
    alcuna priorita`, da sinistra a destra.

       Step   EQU (512+37)
       Max    DAT (2048/Step)

    E' inoltre consentito l'utilizzo di espressioni racchiuse tra
    parentesi quadre, che permettono di ottenere un indirizzamento
    relativamente assoluto (ovvero assolutamente relativo!), rispetto
    alla prima istruzione del programma. In altre parole permette di
    indicare valori come offset dall'inizio del programma, delegando al
    compilatore il compito di calcolare i valori effettivi, risultando di
    grande utilita` per semplificare la scrittura di programmi (o
    porzioni di essi) che si rilocano nel Core. Ex:

       IstA   Mov -1,<-1             Mov $-1   <-1
       IstB   Jmp -1                 Jmp $-1
       IstC   Djn 0,<-1              Djn $0    <-1
       Start  Mov IstA,[2000]        Mov $-3   $1997
              Mov IstB,[2001]  -->   Mov $-3   $1997
              Mov IstC,[5000]        Mov $-3   $4995
              Spl [2000]             Spl       $1994
              Jmp [5000]             Jmp $4993

    N.B. Nelle precedenti versioni di XRA, lo stesso risultato era
         ottenuto utilizzando lo pseudo-modo di indirizzamento "*"
         (tuttora supportato per compatibilita` verso il basso). Il fatto
         di racchiudere l'espressione tra parentesi quadre serve a
         permettere di utilizzare qualsiasi modo di indirizzamento (e non
         solo quello di default, cioe` l'indiretto).

    XRA ignora eventuali pseudo istruzioni END o SPACE.
    I commenti vanno semplicemente fatti precedere da i consueti caratteri
    ['] [;] o "REM".

    In caso di incomprensioni, label mancanti o duplicate, comandi
    mancanti, errati o inventati di sana pianta, espressioni
    irragionevolmente cervellotiche ecc.  il compilatore emette dei
    messaggi di errore mirati, con l'evidenziazione della linea errata e
    della posizione approssimativa dell'errore.
    Utilizzando lo switch "/NS", verranno visualizzati solo i messaggi d'
    errore, e non le corrispondenti linee del sorgente.

    Il modo in cui viene composto il messaggio d'errore puo' essere
    personalizzato in modo da adattarlo al parser del proprio programmer's
    editor preferito, con lo switch "/F:string".
    Nella stringa di formattazione possono essere utilizzati i seguenti
    simboli speciali:

       \F nome del file            \P path
       \T tipo (errore o warning)  \E messaggio d'errore
       \L linea incriminata        \C colonna
       \N a capo                   \_ spazio
                                   \\ backslash
    Il default e': \L\_\T:\_\E

    Qualche esempio. Prendiamo un sorgente TEST.RED come segue:

    Target  Dat     0
    Loop    Mov     !Bomb,@Target
            Sub     #4,Targt
            Jmp     Loop
    Bomb    Dat     0


    Lanciando "XRA test" liscio otteniamo:

    4 ERR: Illegal Adressing Mode '!' (A)
    Loop    Mov     !Bomb,@Target
                    ^
    5 ERR: Undefined label 'TARGT' (B)
            Sub     #4,Targt
                       ^

    Volendo richiamare XRA da un editor che si aspetta che il compilatore
    ritorni i messaggi d'errore in formato tipo Turbo Pascal, si potrebbe
    lanciare "XRA test /NS /F:\f(\l):\_\e" per ottenere:


    TEST.RED(4): Illegal Adressing Mode '!' (A)
    TEST.RED(5): Undefined label 'TARGT' (B)


    Una volta sistemati gli errori di cui sopra, otterremmo:


    TEST.RED(3): Label 'Start' not found. Execution start at 1st inst.
    TEST.RED(3): Program start with a DAT!

    Finished.

    Author: Fracchia

    Writing file TEST.RBJ...
    File lenght = 5 lines / 106 Bytes

    XRA visualizza un warning segnalando che l'esecuzione comincera' con
    un DAT, e che quindi il programma avra' vita molto ma molto breve!
    In ogni caso, essendo il programma formalmente del tutto corretto,
    XRA ritiene che non siano poi affari suoi, e viene comunque creato il
    codice oggetto corrispondente.

    Un'altra caratteristica, meno appariscente, di XRA e` quella di
    inserire nei file oggetto anche delle informazioni supplementari, tra
    cui la data della compilazione e il nome dell'autore del programma. Da
    notare che inserendo nel sorgente un commento con l'indicazione del
    programmatore (il classico "by xxxxx xxxx", ad esempio), XRA assume
    automaticamente come autore il testo successivo al "By". Esempio:

     ' Test - By Pallino Pinco

     ' Test (1994)
     ' By Pallino Pinco          --> Author: Pallino Pinco

     ;program Test
     ;author Pallino Pinco

    Nel caso XRA non trovi informazioni sull'autore all'interno del
    sorgente, queste vengono richieste espressamente, a meno che XRA non
    sia stato richiamato con lo switch "/NN" (per No Name), nel qual caso
    l'autore verra` indicato semplicemente come "Unknowed Anonym".

    N.B. Il fatto di vedersi comparire ad ogni compilazione la richiesta
         del nome dovrebbe, nelle intenzioni del sottoscritto,
         incoraggiare  ad inserire il nome direttamente nel sorgente, e
         non a premere [RETURN] ogni volta senza aver scritto niente.
         Infatti al momento di fare uno scontro o meglio ancora un torneo
         si rivelera` molto utile poter sapere chi e` che ha scritto quel
         maledetto programma che vi sta facendo a pezzi!



    XRD - Extra Redcode Disassembler
    --------------------------------
    Formato: XRD [path]<file>[.RBJ]
                 <file> nome di un modulo oggetto .RBJ

    Questo e` il modulo piu` semplice e piu` standard di tutto il lotto,
    ma non e` comunque del tutto privo di una qualche utilita`, giacche`
    e proprio questo che utilizzerete per vedere, studiare nonche`
    scopiazzare spudoratamente il maledetto programma di cui prima (vedi
    N.B. - XRA)!

    Appena lanciato XRD visualizza qualche riga di informazioni sul
    programma indicato, quali l'autore, la versione del compilatore
    utilizzata e la data di creazione.
    Seguono a ruota la lunghezza in linee, quella da eseguire per prima,
    e, prodigio, perfino il disassemblato del programma, con le linee
    numerate e i vari campi adeguatamente spaziati, in bella copia.
    Il disassemblato viene anche scritto nel file XRD.RED.

    Inutile dire che poi ci si potra` trastullare ad editarlo
    aggiungendoci label con un qualche significato, in modo da renderlo
    piu` confacente ai nostri gusti estetici e anche un tantino piu`
    comprensibile.



    XRS - Extra Redcode Simulator
    -----------------------------
    Formato: XRS [path]<fileA>[.RBJ] [[path]<fileB>[.RBJ]]
                 [/G] [/S] [/R:xxxx] [/D:xxxx]
                 <fileX> nome di un modulo oggetto .RBJ
                 /G      rappresentazione grafica dello scontro
                 /S      sistema di allocazione standard (casuale)
                 /R:xxxx specifica il numero di rounds
                 /D:xxxx specifica la distanza tra i programmi

    A questo punto, prima di ogni spiegazione sui vari parametri e` di
    rito un noiosissima quanto necessaria digressione teorica
    sull'allocazione dei programmi.

    Perche` di norma i programmi vengono inseriti nel core in posizioni
    casuali, vincolate solo da una distanza minima ? ... Boh! ... uhm ...
    mumble, mumble, ... ah, ecco! Perche` la programmazione in Redcode e
    piu` in generale le Core War e, ancora piu` in generale, la fisica,
    gira attorno al concetto di relativita`, e nella fattispecie,
    tornando nel seminato, un programma non deve avere la benche` minima
    idea di dove si trovi l'avversario (gli e` dato infatti di essere
    solo ragionevolmente sicuro di dove non e` l'avversario, ovvero entro
    tot (2.048 ?) locazioni dalla sua origine, sempre a meno di una
    rilocazione).
    Orbene, cosi` facendo la cosa funziona ma presenta spiacevoli effetti
    collaterali: e` necessario fare un numero di rounds molto elevato per
    avere un risultato significativo e stabile, altrimenti limitandosi ad
    un centinaio di partite i risultati oscillano pericolosamente e
    spesso in modo clamoroso, come tutti gli appassionati di CW sanno per
    averlo provato direttamente (basti l'esempio classico del Dwarf
    contro Dwarf, che raramente finisce in parita`).
    La soluzione piu` semplice, sicura e affidabile, e` quella di
    eseguire le necessarie 4.096 partite per ogni coppia di programmi,
    che portano ad un risultato assolutamente esente da qualsiasi
    polemica sulla s/fortuna di questo o quel partecipante. Se non vado
    errando, questo e` quello che e` stato fatto, ad esempio, in
    occasione del primo Torneo Mondiale organizzato dall'ICWS.
    Per contro in altri Tornei ufficiali sono state fatte cose un tantino
    piu` strane (tipo divisione in gironi, per ridurre il numero di
    scontri), con risultati probabilmente altrettanto strani.

    A-ri-orbene, la soluzione che ho adottato (che comunque non ha nessuna
    pretesa tipo verita` assoluta) si basa, in soldoni, sulla
    distribuzione uniforme dell'avversario lungo tutta la superfice utile
    del Core, ovviamente con tutta una serie di altri piccoli accorgimenti
    correttivi, in modo cercare di avere una rappresentanza significativa
    di tutte le distanze e gli step possibili.

    Ovviamente poi, tra il dire e il fare etc. etc., quindi i risultati
    non sono comunque, ripeto, assolutamente certi, e in qualche raro
    caso si puo` avere un risultato un po` fuori del normale.
    Ciononostante e` comunque un gran miglioramento rispetto
    all'allocazione casuale e con 100 partite si possono avere risultati
    dall'affidabilita` sicuramente superiori alla norma. In particolare,
    nel caso dello scontro tra due avversari uguali, il risultato e`
    sempre e comunque un pareggio, e vi assicuro che non e` ottenuto
    barando!
    Sicuramente e` comunque l'ideale per mettere sottotorchio un programma
    da testare, magari in vista di una partecipazione ad un qualche torneo.

    E' vivamente consigliato comunque, utilizzare almeno 100 partite (o
    anche 200 nel caso di computer particolarmente avezzi al computo), in
    quanto con numeri inferiori il risultato resta comunque indicativo, ma
    potrebbe comportare qualche anomalia. L'algoritmo di allocazione e`
    stato infatti ottimizzato per funzionare bene con 100 rounds appunto,
    che mi sembra una compromesso senz'altro ragionevole.

    Cosa ancora piu` importante, il risultato di uno scontro, a parita` di
    concorrenti e numero di partite, e sempre costante, e questo ha
    permesso di implementare... taah daaah - lo saprete poi leggendo la
    descrizione di XRC, per ora continuate qui di seguito!

    Ma torniamo alla descrizione dei parametri accettati da XRS.
    Non credo di dovermi dilungarmi molto sulla necessaria indicazione
    dei due moduli oggetto, tranne per dire che e` possibile indicarne
    uno solo, cosa che puo` risultare molto utile durante il debug.

    E' possibile specificare il numero di rounds da eseguirsi tramite
    "/R:tot", mentre nel caso lo si omettesse o si utilizzasse un solo
    programma viene in ogni caso eseguita una solo partita.

    Lo switch "/G" serve per forzare la rappresentazione grafica dello
    scontro (schede VGA e CGA supportate).
    Dico "forzare" perche` nel caso di scontro con una partita sola
    cio` rappresenta il default, in quanto dovrebbe essere inteso come
    test/debug, mentre nel caso di un confronto multi-rounds normalmente
    non viene utilizzata, per questioni velocistiche, ma puo` essere
    appunto attivata, per questioni puramente coreografiche.
    In effetti, la visualizzazione grafica multi-rounds e` veramente molto
    coreografica, presentando un sorta di effetto stroboscopico, visto che
    gli scontri vengono eseguiti alternandosi tra quattro zone dello
    schermo, permettendo anche di vedere come si sono concluse gli ultimi
    tre rounds disputati oltre a quello in corso (vedere per credere!).
    A questo riguardo, rendo nota la notazione cromatica utilizzata per
    visualizzare le locazioni del Core:

                                     Player A   Player B

                         Eseguite    Blu        Rosso
                         Alterate    Azzurro    Giallo
                         "Scandite"  Verde      Viola

    N.B. La modalit video appena descritta richiede una VGA/MCGA. Nel
         caso non sia utilizzabile, e' comunque disponibile una modalita'
         di visualizzazione semplificata (2 colori) compatibile anche con
         una semplice CGA. Una sezione di autodetect provvedera' a
         scegliere automaticamente la modalita' video piu' adatta.

    Si puo` specificare una data distanza tra i programmi con il parametro
    "/D:tot", in modo da poter testare il comportamento di un programma in
    una certa configurazione, senza dover provare e riprovare in attesa
    della distanza desiderata. Ovviamente la distanza deve sottostare ai
    consueti vincoli sulla distanza minima tra i programmi (si, si, anche
    quella massima!).

    Con "/S" si attiva il sistema di allocazione standard, cioe` casuale,
    che altrimenti viene utilizzato solo nel caso di uno scontro con una
    sola partita.

    Due parole sulle semplici possibilita` di debug messe a disposizione
    quando si esegue una simulazione con una sola partita.
    In questo caso l'esecuzione viene eseguita a velocita` bradipea, in
    una schermata occupata in larga parte dalla rappresentazione grafica
    del core e con l'indicazione dei programmi in esecuzione e del numero
    di cicli eseguiti.
    E' possibile accelerare la simulazione con lo SHIFT di destra, per
    superare rapidamente fasi noiose, e passare alla modalita` Step-by-
    Step con lo SHIFT di sinistra.
    In questa modalita` vengono indicati, a lato del nome di ogni
    programma, il task, la locazione e le istruzioni appena eseguite
    (queste con l'eventuale campo non significativo piu` scuro, piccola
    nota di colore).
    Non manca l'indicazione grafica della posizione del task eseguito.
    Anche qui e` possibile utilizzare lo SHIFT di destra per accelerare
    (relativamente) l'esecuzione, come pure premere un qualsiasi altro
    tasto per passare al ciclo successivo. Premendo invece [RETURN] e
    possibile evidenziare graficamente, qualsiasi locazione del core in
    modo da esplorarne il contenuto, utilizzando i tasti cursore ed
    eventualmente il tasto [CTRL] per aumentare la velocita` di
    spostamento. Ripremendo lo SHIFT di sinistra, si torna all'esecuzione
    a velocita` normale (pardon, bradipea).  Naturalmente si puo` uscire
    in qualsiasi momento con il tasto [ESC].

    N.B. Probabilmente detto cosi` sembra piu` contorto di quanto
         effettivamente non sia, quindi il suggerimento e` ovviamente
         quello di provarne in pratica il funzionamento.

    Per concludere (ma solo per quanto riguarda XRS...) alla fine dello
    scontro vengono riassunti i punti ottenuti dai due programmi, la loro
    efficenza (intesa come il rapporto tra il punteggio raggiunto  e il
    massimo punteggio teoricamente ottenibile, leggi
       eff% = punti * 100 / (rounds * 3)
    le partite vinte, perse, pareggiate, il tempo impiegato, i rounds al
    secondo eseguiti e, immancabile, il vincitore).



    XRC - Extra Redcode Competition Simulator
    -----------------------------------------
    Formato: XRC [/PR] [/PW] [/PN] [/PI] [/PD:prg] [/PO]
                 [/T] [/S] [/R:xxxx] [/L:file] [/N] [/NET:Master|Slave]
                 prg      nome di un modulo oggetto .RBJ
                 file     PlayList alternativa
                 /PR      utilizza il Playback solo in lettura
                 /PW      utilizza il Playback solo in aggiornamento
                 /PN      non utilizza affatto il Playback
                 /PX      esclude le registrazioni con meno rounds
                 /PI      visualizza informazioni sul file Playback
                 /PO      ottimizza il Playback file
                 /PD:file elimina un programma dal Playback
                 /T       disabilita i combattimenti nella stessa squadra
                 /S       utilizza l'allocazione standard (casuale)
                 /R:xxxx  specifica il numero di rounds
                 /L       richiama gli ultimi programmi usati
                 /N       controlla che ci sia il nome dell'autore
                 /NET:x   network mode: Master o Slave

    Anche qui una doverosa premessa, questa volta pero` veramente piccola
    piccola.
    Riprendendo il discorso sull'allocazione ottimizzata, in conseguenza
    del fatto che il risultato ottenuto a parita` di programmi e numero di
    rounds e` sempre costante, ho ben pensato di sfruttare adeguatamente
    questa particolarita`.
    Cosi` e nato il Playback System. In pratica, in poche parole, ogni
    qual volta viene eseguito un torneo, XRC controlla nell'apposito file
    PLAYBACK.XRD se e` presente lo scontro da eseguire. In questo caso, i
    risultati parziali vengono letti direttamente dal file azzerando il
    tempo impiegato per lo scontro medesimo; se viceversa lo scontro non
    e` gia` stato archiviato, viene eseguita la simulazione e`, una volta
    in possesso delle risultanze, si provvede all'aggiornamento del file.
    In questo modo una volta creata una sostanziosa base dati, e`
    possibile testare ogni nuovo programma facendolo partecipare ad un
    torneo, dove tutti gli scontri gia` noti verranno caricati, mentre
    dovranno essere eseguite solo quelle partite che riguardano
    direttamente il nuovo arrivato.

    In pratica si profila uno modo completamente diverso di sviluppare un
    programma, rispetto alle consuete prove in successione con un set di
    avversari conosciuti.
    Inoltre viene anche eliminato il problema dell'interruzione
    (volontaria o per cause di forza maggiore, vedi ENEL!) di un torneo,
    visto che i nuovi scontri vengono registrati sul file mano a mano che
    vengono eseguiti, e quindi sara` sufficente ripetere il torneo per
    vedere ricomparire rapidamente la situazione immediatamente
    precedente alla sospensione.

    Qualche precisazione di carattere tecnico/pratico:
    Ogni record nel file occupa 52 bytes, quindi anche un archivio con
    migliaia di registrazioni mantiene comunque delle dimensioni
    tutt'altro che elefantiche.
    Ogni record contiene ovviamente anche una firma e un simil CRC per
    ogni programma, in maniera che i risultati caricati siano sempre e
    comunque consistenti, in relazione alle ultime versioni di ogni
    programma.
    Al momento dell'aggiunta di un record al file, questo viene
    semplicemente accodato al file, in modo da non perdere tempo, visto
    che la routine di ricerca e` in grado trovarlo in qualsiasi posizione.
    In ogni caso, se il file e` almeno parzialmente ordinato la ricerca
    e` molto piu` veloce, e quindi e` consigliabile provvedere al suo
    riordinamento (tramite apposito comando, vedi sotto) ogni tanto,
    magari dopo che sono state aggiunte parecchie registrazioni.

    Un ultimo appunto di una certa rilevanza: quando viene registrato uno
    scontro, il record contiene anche il numero di partite con cui e`
    stato ottenuto, ma la routine di ricerca per dei record ignora
    completamente questo dato, prendendo il primo record aggiornato che
    trova, per ovvie questioni di velocita`.
    Tuttavia, nel momento in cui si esegue l'ottimizzazione del PlayBack
    file, questo viene ordinato, vengono eliminati eventuali doppioni e
    vengono conservati solo i record con il maggior numero di partite, in
    modo da avere un base dati il piu` affidabile possibile. A titolo di
    informazione preciso che le registrazioni riferite a scontri eseguiti
    con l'allocazione ottimizzata hanno priorita` maggiore a quelli
    ottenuti con l'allocazione standard, e che quest'ultimi vengono
    conservate sole se ottenute con un numero di rounds quattro volte
    superiore.


    Per quanto riguarda il network mode, ovvero la possibilita` di
    disputare un torneo sfruttando le capacita` di elaborazione di piu`
    computers collegati in rete, l'unico problema di una certa entita` e
    proprio quello di disporre di piu` computers in rete!
    Se il problema non vi tocca potrete dunque usufruire di questa
    interessante possibilita` in modo molto semplice.
    Nessun problema infatti per i tipo di rete installata, sia essa
    Server/Client che Peer to Peer, dal File Sharing di Win 9x a
    Novell, LANtastic o altre, e` sufficente che permetta la condivisione
    dei files. 

    In pratica ci dovra` essere una stazione "master" (XRC /net:master)
    e una o piu` stazioni "slave" (XRC /net:slave).
    Sulla stazione master, al momento di lanciare XRC si potranno
    specificare anche le normali opzioni di simulazione (vedi sotto);
    subito dopo le normali operazioni di selezione/caricamento dei
    concorrenti e set delle varie opzioni, XRC genera alcuni files che
    verranno utilizzati anche da tutte le altre stazioni per portare a
    termine il torneo.
    Le stazioni slave possono essere lanciate (non dalla finestra, per
    carita`!) in qualsiasi momento, e rimangono in attesa finche` non
    trovano i files di cui prima.
    Quindi, una situazione tipica e` quella in cui si lancia XRC in
    modalita` slaves su tutte le stazioni dell'ufficio e poi, sull'ultima,
    si lancia XRC in modo master specificando il numero di rounds, i
    giocatori, se usare o meno il Playback, etc; nel momento in cui XRC
    cominciera` ad eseguire i primi scontri, tutte le altre stazioni
    partiranno facendosi carico di altre partite.
    Se dopo un po' si libera anche il computer della segretaria, che
    avrete fatto di tutto per cacciare via prima del tempo, bastera`
    lanciare XRC in modalita` slave anche su di esso, per fare si` che
    anche lui si renda utile a cominci a macinare rounds; se viceversa
    dovesse servirvi qualche computer impegnato nel torneo, bastera`
    uscire con [ESC], senza che gli altri esecutori battano ciglio
    (attenzione a non uscire dalla stazione master, perche` anche le
    altre stazioni uscirebbero di conseguenza).
    Alla fine del torneo, la stazione master interrompera` i propri
    servigi, tornando al DOS (o da dovunque sia stato lanciato XRC),
    mentre le altre stazioni si rimetteranno in attesa di un altra
    simulazione.

    Attenzione: in caso di brusca interruzione del torneo sulla stazione
    master (dovuto a cadute di tensione, problemi hardware o bugs!!),
    prima di ricominciare potrebbe essere necessario cancellare il file
    NPort.XRD (utilizzato per lo scambio di messaggi tra le varie
    macchine).
    Se invece fosse una stazione slave a piantarsi durante l'esecuzione
    di una partita, a fine torneo tutte le macchine attive
    visualizzerebbero "waiting results..." e attenderebbero all'infinito
    che la partita in corso al momento del crash venisse portata a
    termine; in questo caso, basta premere [ESC] sulla stazione master
    e scegliere "Free Match".

    Ah, dimenticavo: non c'entra quasi niente, ma alla fine di ogni
    torneo, oltre a presentare a video la classifica definitiva, XRC
    registra sul file RESULTS.TXT la classiface finale, anche per squadre,
    nonche` tutti i risultati parziali degli scontri; nel caso esista
    gia` un file con i risultati, questo viene rinominato in RESULTS.BAK.

    Un'altra cosa, prima di entrare nel vivo: XRC gestisce tornei
    impiegando fino a 75 concorrenti (memoria permettendo, ma non ne
    occorre poi tanta), anche se comunque, durante la "tenzone", vengono
    visualizzati solo i primi trenta; questa in ogni caso non mi sembra
    affatto una grossa limitazione, dato che un concorrente oltre il
    trentesimo posto probabilmente non merita particolare attenzione!

    Passando alla descrizione dei vari comandi, premetto che XRC lanciato
    "liscio" provvede subito alla richiesta dei vari contendenti, che
    vengono controllati sia a livello di modulo oggetto che a livello di
    doppioni, assumendo come default l'attivazione del Playback System,
    100 rounds per scontro e allocazione ottimizzata.

    La modalita` di gioco a squadre viene attivata semplicemente
    inserendo i concorrenti raggruppati per squadra (appunto!), indicando
    la stessa a lato del primo concorrente di ogni gruppo (separata da
    spazi e/o tabulatori). Ad esempio:

    Player 01: Alfa Squadra1
    Player 02: Beta
    Player 03: Uno Squadra2
    Player 04: Due

    Quindi, per quanto riguarda il parametri "/S" e "/R:tot" valgono le
    stesse considerazioni fatte molte, molte righe prima per XRS.
    "/N" permette di fare in modo che XRC controlli, mano a mano che si
    inseriscono i programmi da far combattere tra loro, che ognuno di
    questi porti l'indicazione del nome dell'autore; in caso contrario la
    richiede esplicitamente prima di far cominciare il torneo.

    Il comando "/L" permette invece di richiamare gli ultimi concorrenti
    utilizzati dalla PlayList, molto utile nel caso dell'esecuzione di
    Tornei a ripetizione per i testing di un programma.
    La Playlist normalmente corrisponde al file omonimo "PLAYLIST.XRD"; e`
    comunque possibile indicarne un'altra con "/L:file". Dopo il torneo la
    nuova Playlist viene copiata sopra quella di default.

    Utilizzando "/T" si fa in modo che XRC non faccia combattere fra loro
    i concorrenti di una stessa squadra.

    I parametri "/PR", "/PW" e "/PN" permettono di limitare l'utilizzo del
    Playback System alla sola lettura, scrittura, o ignorarlo del tutto, e
    possono risultare utili in particolare situazioni, come quella di un
    Torneo vero e proprio, alla presenza di pubblico, ove ovviamente si
    vorranno effettuare al momento tutti gli scontri, onde evitare futili
    polemiche su presunti brogli e imbrogli.

    Con "/PX" si comunica a XRC di leggere dal Playback file solo i dati
    relativi ai match ottenuti con un numero di rounds pari a quello
    utilizzato per il torneo che si va a simulare. Eventuali record
    ottenuti con l'allocazioni standard (random) devono avere un numero di
    rounds pari a 4 volte quello utilizzato.

    "/PI" fornisce alcune informazioni sul file Playback.XRD, ad esempio il
    numero di record e i programmi di cui sono presenti delle
    registrazioni, nonche` qualche notizia sull'organizzazione del file
    stesso.

    "/PO" serve per riordinare il file ed aumentarne di conseguenza
    l'efficenza. Ovviamente piu` sono i record non ordinati (leggi
    volgarmente accodati), piu` elevato sara` il tempo impiegato per la
    ricerca.
    E' quindi consigliabile provvedere periodicamente alla
    riorganizzazione, senza comunque arrivare a scadere nella sindrome da
    Speed-Disk, di cui sono affetti parecchi PC users, che ormai sono
    perseguitati dall'angoscia di dover eseguire la riorganizzazione
    totale ad ogni minima alterazione della struttura logica del proprio
    HD, con ovvi e nefaste conseguenze sulla propria psiche, o su cio`
    che ne rimane.
    Da notare che comunque per adesso non e` prevista la rimozione dei
    record ormai non piu` aggiornati, riguardanti cioe` programmi ormai
    modificati e ricompilati. Questo non e` comunque cosi grave da creare
    problemi velocistici e/o di occupazione di spazio, che in ogni caso
    verranno stroncati in una prossima, inevitabile, nuova release.

    "/PD:file" serve per rimuovere tutti i record riguardanti il file
    specificato. Molto utile per chi come il sottoscritto quando sviluppa
    i programmi li fa seguire dal suffisso 1, 2, n. In questo modo,
    arrivati ad una stesura definitiva, si potranno eliminare totalmente
    i record ormai inutili.



    REDMAP - RedMap Editor
    ----------------------
    Questa utility consente di creare in modo molto semplice dei programmi
    che tracciano disegni sulla matrice (o, se preferite, in zona di
    guerra) e risulta utile per aggiungere un logo ad un programma, per
    lanciare qualche minaccia o insulto in formato grafico, etc.
    Il programma si presenta come un editor pixel x pixel che permette di
    alterare il colore di ogni locazione del Core, utilizzando i tasti
    dall'1 al 3 e la barra spaziatrice oltre, naturalmente, ai tasti
    cursore per spostarsi di locazione in locazione.
    Una volta terminato il capolavoro, si puo` premere [ESC] per uscire e
    perdere tutto (!!) o [RETURN] perche` RedMap si diletti a generare il
    sorgente Redcode (RedMap.RED)
    Quest'ultimo puo` essere assemblato e utilizzato cosi` com'e` oppure,
    piu` intelligentemente, inserito all'inizio di un altro programma per
    vivacizzarlo un attimo.

    Ah, se non si fosse ancora capito, e` palese che l'utilita` dell'
    utility (!) e` nulla, limitandosi ad essere di interesse
    esclusivamente coreografico e/o goliardico!

