Source: https://archive.org/serve/ZorkI_r75_earlier_4amCrack/

Zork è il nome di una delle text adventure più famose della storia, rilasciata da Infocom per la prima volta nel 1977. Non la prima, che fu Colossal Cave Adventure (sempre nel 1977), ma di sicuro un nome che evoca in modo iconico questa categoria di giochi. In comune col capostipite prima citato ha l'essere stata sviluppata in prima battuta per il mainframe PDP-10. Infocom ha distribuito successivamente decine di altre text adventure (ricordiamo Hitchhiker's guide to the galaxy) basate sullo stesso modello. A differenza però del capostipite Colossal Cave Adventure che fu scritto in FORTRAN, tutte le text adventure di Infocom sono state in un linguaggio specifico per descrivere il mondo all'interno del quale si muove il giocatore di una adventure: oggi si direbbe un DSL (Domain Specific Language). Linguaggio ZIL e Z-Machine multipiattaforma Questo linguaggio fu denominato ZIL (Zork Implementation Language), è un linguaggio dichiarativo e ha una struttura simile a quella del LISP, e a partire dal

sorgente viene compilato (tramite compilatori appositi, per esempio ZILF) in una sorta di bytecode, pronto a sua volta a essere eseguito da una virtual machine, che viene detta in questo caso Z-Machine, una sorta di ScummVM ante-litteram. Ciò significa che il file eseguibile che viene lanciato per far partire il gioco non contiene il gioco in sé, bensì è un'implementazione della Z-Machine, che legge e interpreta il file compilato a partire dal sorgente ZIL. Tale scelta lungimirante ha permesso a Infocom di rilasciare i suoi titoli su praticamente qualunque piattaforma esistente (negli anni, dalla versione PDP-11, a quella per CP/M, fino ad Amiga), in quanto bastava fare il porting della sola implementazione di Z-Machine per la specifica piattaforma, mentre i file compilati dai sorgenti ZIL dei giochi erano gli stessi ovunque. In questo video del 1986 della BBC vediamo i dipendenti Infocom all'opera, nella produzione delle decine di titoli di text-adventure, che parlano del loro lavoro: https://www.facebook.com/watch/?v=370943990432516   La versione…

The purpose of this document is to clarify how variables are stored in RAM and how this information can be used. This information applies to Apple-1 (both Originals and Replicas) and to most of the emulators. A brief recap, taken from the Apple-1 PRELIMINARY BASIC USERS MANUAL: Let us suppose, from now on, that the memory configuration is "standard" according to the indications in the manual: PRIMARY RAM BANK from address \$0000 to \$0FFF (4096 bytes) OPTIONAL RAM BANK from address \$E000 to \$EFFF (4096 bytes) BASIC will be loaded in the optional RAM BANK. We will not consider memory manipulation made by LOMEM or HIMEM commands. When BASIC is running the user’s RAM, by default, is from \$0800 to \$0FFF (2047 bytes). 1. Program not using variables A BASIC program is stored so that its end coincides with the last byte of memory available. In the two examples above, the one-liner 10 PRINT “HELLO”

is stored from \$0FF4 to \$0FFF. If a second line is added (20 PRINT “WORLD”) the entire program is “shifted”. The two-line program now starts at \$0FE8 and ends at \$0FFF. Is it reasonable to assume that variables will be stored at the opposite end of the available memory, in order to avoid any conflict with the program code. A quick inspection of the first locations shows nothing, which is also reasonable because our program uses no variables at all: 2. Program using numeric variables Let us restart everything and declare a variable, and see what happens: As expected, nothing is stored in the “program area” of the memory, since we did not write any program. I choose 32767 as value for the variable because it is hexadecimal \$7FFF and its HI and LO bytes are quite recognisable among all the others. They look to be stored in little-endian notation, two bytes as expected in locations \$0804 and \$0805. Are we able to spot out…

Can an Apple-1 computer decipher a message encrypted with an Enigma cyphering machine in a reasonable time?

Recently I (re)watched the movie “The imitation game”: the English mathematical genius Alan Turing cracks the German Enigma code with help from fellow mathematicians, using an electro-mechanical device called Bombe. At the end of the movie, I found myself wondering: "Would an Apple-1 be able to decrypt a text ciphered by an Enigma machine? If so, how fast would it be?” The Enigma Machine is well documented in all its versions and variants, and the Internet is full of code and emulators. I am not going to explain the operation principles of the Enigma Machine, on the Internet there is a plenty of valuable sources of knowledge. In the Bibliography section, you will find some link. SEARCHING FOR… THE RIGHT CODE What I was looking for was a short source code that could run in a few kiB of memory. In this article, I will not go deep into the mathematical theories behind the "Enigma", and I will not dwell on the different decryption techniques that could

be used. I found many programs, but unfortunately, many of them needed RAM that the Apple-1 simply does not have. Finally, I found the source code candidate to be adapted for the CC65 cross compiler: http://www.cs.miami.edu/home/harald/enigma/ The small program can encrypt/decrypt messages with an user-defined machine setting or brute-force an encrypted message. How does it work? In the movie they use a word, called crib, they believe was encrypted in the message (i.e. “weather”) to program Turing’s Machine. The machine “simply” tries all the permutations of settings in order to obtain the original crib. Due to the huge number of different initial settings of the Enigma machine, this method was very time consuming: many expedients were put into practice to reduce the number of permutations (i.e. the Diagonal Board method discovered by Turing’s colleague Gordon Welchman). The program, written in C language, needed some adjustment to be compiled by CC65. In this, I…

Sommario Si propone una breve bibliografia ragionata per un primo percorso orientativo destinato a chi intenda (ricominciare a) programmare su C64 in linguaggio Assembly eventualmente affiancato dal BASIC V2, con nozioni architetturali e uso avanzato delle caratteristiche di grafica e suono. Questo medesimo articolo è disponibile anche in PDF. «Mathematics is the art of giving the same name to different things.» (Henri Poincare, 1854-1912) 1 Introduzione. Con oltre 17 milioni di unità prodotte, il Commodore 64 è indiscutibilmente il PET più venduto della storia e il relativo mercato bibliografico è conseguentemente uno dei più sviluppati in assoluto, con centinaia di titoli stampati da decine di editori di ogni dimensione, firmati da autori spesso di fama internazionale nel campo dei microcomputer e relativi processori 8 bit. Qui si vuole proporre un percorso di studio che comprende i testi più essenziali, rivelatisi alla prova del tempo e nella didattica superiori agli altri per qualità dei contenuti, impostazione, accuratezza,

autorevolezza. Per la massima efficacia e qualità dei risultati, il percorso di studio individuale deve necessariamente seguire la consueta progressione: prima l'architettura, poi il linguaggio macchina in sè, poi i vari Assembler con le loro idiosincrasie sintattiche e sistemi di macro profondamente incompatibili gli uni con gli altri (inclusi i moderni ambienti di cross-development, ormai sempre più necessari), poi la programmazione dei singoli chip periferici specializzati e infine le applicazioni, studiando e ristudiando il codice applicativo che ormai si trova in giro, tra disassemblati e rilasci al pubblico dominio, in quantità esorbitanti. L'assioma fondamentale per la programmazione low level su C64 (ma vale anche per qualsiasi altra piattaforma) è che si impara leggendo molto codice Assembly avanzato scritto da programmatori professionisti e ben preparati: lo studio della mediocrità, dice il grandissimo Harold Bloom, non può che generare altra mediocrità. A sua volta, comprendere nei dettagli tale codice richiede lo studio di svariate tipologie di testi, senza limitarsi al solo Assembly che è il punto…