di  -  mercoledì 17 settembre 2008

Scrivere codice in linguaggio macchina agli inizi degli anni ’80 servendosi della tabella degli opcode e della calcolatrice era un lavoro a dir poco massacrante: bastava modificare qualcosa e quasi sicuramente si dovevano ricalcolare gli indirizzi dei salti, come ho accennato in un precedente articolo.

C’era, insomma, un’enorme differenza fra programmare soltanto in BASIC e aggiungere codice macchina al sorgente: il lavoro da fare era troppo ed estremamente difficile. Infatti le parti di codice macchina erano generalmente limitate a piccole porzioni. Si faceva poco perché fare di più era oggettivamente una follia.

Eppure leggendo le riviste dell’epoca che riportavano listati completi da digitare, col passare del tempo notavo che le parti in linguaggio macchina erano sempre più lunghe. Addirittura arrivavano a diverse pagine di numeretti da scrivere in fila (nella speranza di non sbagliarne qualcuno: potete immaginare cosa significasse andare scovare un errore di digitazione). C’era chi arrivava a estendere il BASIC aggiungendo alacremente istruzioni e funzioni. Come diavolo facevano?

La risposta non tardò ad arrivare allorché venne recensito un programma “strano”: Supermon64 per il Commodore 64. Si trattava di una cartuccia che metteva a disposizione quello che veniva chiamato “monitor” (per il codice macchina): un utilissimo aggeggio che permetteva di interrompere l’esecuzione di un programma e andare a sbirciare nel codice, seguirne passo passo l’esecuzione, controllare i registri, i dati, lo stack, ecc..

Monitor per Commodore 64

Insomma, l’intero computer era sotto il diretto e assoluto controllo di questo monitor e, quindi, divenne ben presto l’oggetto del desiderio per i programmatori più smanettoni, che non si accontentavano più del BASIC e cercavano strumenti “più potenti“, ma soprattutto da hacker e cracker.

Strumento che, tra l’altro, permetteva di risolvere brillantemente e velocemente il problema della scrittura del codice macchina di cui parlavo prima, visto che era dotato di un artigianale (ma funzionale!) assemblatore che traduceva al volo in linguaggio macchina i ben più comprensibili mnemonici.

L’interesse per questo tipo di applicazioni divenne così forte che la Commodore pensò bene di infilarlo nella ROM di Commodore 16 e Plus 4 prima, e del 128 poi. Si poteva accedere al monitor in diversi modi: digitando una comoda istruzione BASIC (MONITOR), utilizzando una speciale istruzione della CPU (BRK, da inserire in precisi punti del codice macchina), oppure premendo un’opportuna combinazione di tasti (RESET + RUN/STOP).

Tutto ciò portò alla diffusione dell’assembly come linguaggio, che divenne lo strumento d’elezione per i programmatori più esperti.

5 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Lotus
     scrive: 

    Quanta fatica mentale per imparare da zero il linguaggio del 6502 con le poche risorse disponibili, solo qualche rivista di settore – Commodore Computer Club – e un libro che non trovo piu’.

    Avevo iniziato a scrivere un assembler, con il mitico SUPERMONITOR, che sfruttava l’editor del basic, ovvero si scriveva il programma in assembly come fosse in basic, numero + REM (o meglio la sua forma sintetica – le virgolette mi sembra -) + l’istruzione in forma standard 6502, ad esempio :

    10 ” LDA #ff
    20 ” STA $02a9
    30 ” RTS

    Ero arrivato a fargli riconoscere e convertire una decina di istruzioni, poi ho abbandonato tutto, distratto da non mi ricordo piu’ cosa…

    Quanta nostalgia…

  • # 2
    Cesare
     scrive: 

    Abbiamo avuto esperienze, ma vedo anche idee simili. :D

    Io il mio “assemblatore” 65C02 (il “successore” del 6502, che implementavo un bel po’ di altre utili istruzioni) l’ho completato, ma era decisamente diverso da quelli tradizionali:

    module TestEprom

    section Codice code $8000,$ffff

    proc ColdReset
    reset i; x := #255; s := x; reset d
    call ResetAudio; call ResetVideo; call ClearScreen; call ResetIO
    VSync := #0; FuncNum := #0
    jump DumpMem
    end

    (* a = Number of seconds *)
    proc WaitSeconds
    Seconds := a; a := #60; Delay := a
    :WaitVSync
    a := VSync
    if = WaitVSync
    VSync := #0
    dec Delay
    if WaitVSync
    a := #60; Delay := a
    dec Seconds
    if WaitVSync
    ret
    end

    proc ColdNMI
    push a; (*a := io1ca; if = Exit
    a := io1cb; if = Exit
    a := io2cb; if = Exit
    a := io2cb; if = Exit
    a := io2ca; and #$F7; io2ca := a*)
    set VSync[0]
    pop a
    ret i
    end

    proc ColdIRQ
    ret i
    end

    code $fffa,0
    NMIVector : word = ColdNMI
    ResetVector : word = ColdReset
    IRQVector : word = ColdIRQ
    end
    end

    :D

    P.S. Peccato che si sia persa l’indentazione. :|

  • # 3
    Biffuz
     scrive: 

    Io al massimo sono arrivato a scrivermi un interprete di un simil-BASIC in Pascal sotto DOS :-)

    PS terzo tentativo di post, continua a darmi codice di sicurezza errato

  • # 4
    Cesare
     scrive: 

    Quell’assemblatore 65C02 l’ho scritto in Turbo Pascal, per DOS, usando TPYacc. :D

  • # 5
    Some assembly required - Appunti Digitali
     scrive: 

    […] perché con l’introduzione dei monitor (vedi questo articolo) e la maggior facilità di utilizzare l’assembly (al posto del ben più macchinoso […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.