Spiacente, questo articolo non è disponibile in inglese. United-Kingdom-flag-icon-26
This email address is being protected from spambots. You need JavaScript enabled to view it.

 

 

Real Time Clock e nuovo Buzzer per lo Z80  by Pino Giaquinto

 
Quello che cercherò di descrivervi stavolta è frutto del mio amico Piergiorgio: l’implementazione (dal punto di vista HW, ma anche SW) di un modulo RTC basato sul diffusissimo chip DS1302 (con tanto di batteria tampone) ed ‘integrato’ nel nostro sistema Z80 sfruttando le possibilità di espansione offerte dal connettore C della scheda video-grafica LX.529.
Fatta questa premessa, che ritenevo assolutamente doverosa da parte mia, rimbocchiamoci le maniche e passiamo agli schemi elettrici del nostro computer Z80. Come è possibile dedurre studiando attentamente lo schema della video-grafica, i progettisti hanno lasciato ‘liberi’ sul connettore di espansione (sarebbe quello su cui viene montata la scheda ‘figlia’ LX.530) i ‘segnali’ PB2-PB7 corrispondenti ai bit b2-b7 della porta B dello Z80-PIO 2 (vedi IC8 sullo schema della LX.529). Utilizzando appunto tre dei segnali disponibili, ovvero PB5-PB7, Piergiorgio ha realizzato un prototipo perfettamente funzionante di un modulo RTC per Z80-NE ‘appoggiandosi’ alla scheda figlia LX.530, come si può vedere nelle foto che seguono:

 

   front millefori back millefori   assembled  


(sottolineo "prototipo" ndr)

Ovviamente è stato necessario scrivere un bel po’ di codice per adattare l’hardware al CPM-3 del DarkStar, ma spiegare questo va oltre quello che è il mio compito, credo e spero che se ne occuperà quanto prima l’autore del progetto in persona ????

In particolare il compito che mi è stato affidato dal buon Piergiorgio riguarda la realizzazione pratica di un piccolo modulo che comprenda il CICALINO (ovvero la scheda figlia LX.530) ed il suo modulo RTC… il tutto montato su un’unica schedina di facile realizzazione e che occupi poco spazio.

Per quanto riguarda la ‘sezione’ RTC, ricordando di aver visto qualcosa presso il mio rivenditore di elettronica di fiducia (piccoli moduli da utilizzare con le schede Arduino), ho deciso da subito di utilizzare un modulo ‘commerciale’ basato, così come previsto nel suo progetto, su DS1302 ma realizzato in tecnologia SMD… e questo per contenere al massimo gli ingombri:

  arduino module  RTC  

 

Per farvi un’idea delle dimensioni del modulo considerate che la pila è una CR1220 che ha un diametro di 12,5mm e che il passo del connettore SIL è quello classico da 1/10” (ovvero 2.54mm). Su questo minuscolo ed economicissimo modulo c’è tutto e più di quanto occorre per quanto riguarda il discorso RTC, resta quindi da considerare e risolvere ‘solo’ per quanto riguarda i ‘suoni’ di sistema.

 

Lo schema originale della scheda ‘figlia’ LX.530 (che vi mostrerò subito a seguito), necessaria per generare in particolari condizioni il classico ‘BEEP’ di sistema, prevedeva l’utilizzo di due NE555 configurati rispettivamente il primo (IC1) come multivibratore monostabile (che generava all’occorrenza un impulso della durata t1 di circa 0.1s) ed il secondo (IC2) come multivibratore astabile (che generava, in presenza dell’impulso di cui sopra, un segnale ad onda quadra con frequenza f di circa 1KHz):

  ne schema  





In questo caso la mia idea è stata quella di realizzare un piccolo modulo, sempre in tecnologia SMD per ridurre gli spazi, prendendo spunto dal progetto originale da cui ho ‘prelevato’ solo la prima parte (il multivibratore monostabile, mi riferisco sempre a IC1) e che ho utilizzato per pilotare un piccolo BUZZER del tipo ‘attivo’. Questo tipo di buzzer, quando alimentato, emette un tono di frequenza prestabilita (generalmente intorno ai 2KHz) ed In tal modo ho risparmiato anche dal punto di vista del numero di componenti. Infatti, utilizzando un buzzer attivo, non ho avuto bisogno di generare l’onda quadra ed ho risparmiato un NE555 e qualche altro componente passivo!
Il buzzer da me utilizzato è economicissimo, di facile reperimento, può essere alimentato con tensioni di 3-5V ed assorbe mediamente poche decine di mA (quindi il NE555 riesce a ‘sopportarlo’ tranquillamente).
A questo punto, in possesso dei due minuscoli moduli, uno per il BEEP di sistema e l’altro per il RTC… come ‘collegarli’ alla video-grafica? L’idea di una schedina HOST mi è subito piaciuta e nella foto qui di seguito vi mostro il risultato finale del mio lavoro. Le foto saranno sicuramente più esplicative di qualsiasi altra presentazione ‘scritta’. L’idea ci è piaciuta tanto… e spero piaccia altrettanto anche a voi ????

  final1 final2  
  final3 final4  

 (La schedina che si vede a destra è quella relativa all'interfaccia ps/2. ndr)

 

Nella foto a seguito l’interfaccia tastiera PS/2 e la schedina di espansione BEEP & RTC appena descritta, entrambe montate sulla video-grafica LX.529:

   inplace lx529  

Ovviamente renderò disponibili tutte le informazioni necessarie per realizzare questo piccolo ‘lavoro’, compresi i disegni dei due stampati che troverete da subito sul sito del mitico Z80-DarkStar (ovvero qui! ndr).

A presto!

 

 Il software di gestione è reperibile qui (monitor/bios) e qui (cp/m 3 module).

 

Download

 

Layout PCB

Spiacente, questo articolo non è disponibile in inglese. United-Kingdom-flag-icon-26
This email address is being protected from spambots. You need JavaScript enabled to view it.

 

 

WP 20160228 11 27 12 Pro.1 WP 20160228 11 29 24 Pro.1

 

 

Una interfaccia per tastiera PS/2 by Pino Giaquinto

 

new30 Versione 3.3.1 (vedi sotto)

La tastiera del computer Z80 pubblicata sul fascicolo nr.72 di Nuova Elettronica è stata progettata e realizzata basandosi su quelle che sono le funzionalità offerte dal chip KR-2376 prodotto da SMC Microsystems Corporation.

Esclusi i tasti SHIFT, CONTROL, BREAK e SHIFT-LOCK che vengono gestiti separatamente, tutti gli altri tasti (che da ora in poi chiameremo per comodità ‘alfanumerici’) sono disposti su una matrice di 6 righe ed 11 colonne, corrispondenti rispettivamente ai pin X2-X7 e Y0-Y10 del KR-2376 (vedi datasheet).

Nel momento in cui viene pigiato un alfanumerico il KR-2376 ne identifica la posizione nella matrice ed in funzione anche dello stato dei tasti SHIFT e CONTROL determina il codice da inviare in output verso la scheda video.

In pratica questo chip restituisce in modalità ‘parallela’ (quindi su 8 linee, corrispondenti ai pin B1-B8 come da datasheet) il codice ASCII (complementato) corrispondente al tasto o alla combinazione di tasti pigiati, attivando inoltre una linea Strobe dopo circa 1.5ms (il tempo ritenuto necessario a rendere ‘stabile’ lo stato logico delle 8 linee e determinato dai valori di R4 e C4 come visibile nello schema elettrico a pag.48 della rivista numero 72) e che rimane attiva fin quando il tasto che ha determinato l’evento non viene rilasciato. Ciò comunica quindi al sistema la disponibilità sull’output della tastiera di un codice ASCII ‘valido’ che il software in uso interpreterà secondo le sue particolari esigenze.

Utilizzando una piccola interfaccia, realizzata utilizzando un PIC-16F628A (economicissimo microcontrollore a 8 bit della Microchip Tecnology), sono riuscito a interfacciare il mio Z80NE con una comune tastiera PS/2 risolvendo l’eterno problema della mancanza di una tastiera ‘originale’. [Ma anche di una più comoda e "ricca". ndr]

In sostanza il mio firmware, realizzato utilizzando MPLAB IDE e HI-TECH C, ‘legge’ lo scan-code generato dalla tastiera secondo quello che è il protocollo PS/2, determina a quale tasto o combinazione di tasti corrisponde tenendo conto dello stato dei tasti Shift, Alt e Ctrl, infine tramite delle tabelle opportunamente implementate (che tengono conto anche del layout della tastiera… ma di questo parleremo più avanti) lo converte nel corrispondente codice ASCII (complementato), lo trasmette alla scheda video ed attiva dopo circa 1,5ms la linea Strobe simulando in output il comportamento del KR-2376.

Le tabelle utilizzate per la conversione scan-code PS/2 -> ASCII sono in tutto 3, anche se ognuna di esse può essere immaginata come suddivisa ulteriormente in 3 ‘sotto-tabelle’… una per ognuno dei 3 layout che ho previsto e che sono: IT per la tastiera italiana, US per quella americana e GB per quella inglese.

La scelta del layout viene eseguita pigiando la combinazione di tasti L-Alt + F1 (tasto Alt sinistro + tasto funzione F1): i tre led del ‘pannello’ della tastiera lampeggeranno una sola volta se il layout corrente è IT, due volte per quello US e tre volte per GB. Ad ogni successiva pressione dei suddetti tasti il layout cambierà passando in sequenza da IT a US, poi da US a GB, poi di nuovo IT… e così via.

Ovviamente se il sistema verrà spento e riacceso il layout tornerà ad essere quello di default, ma ho previsto anche la possibilità di cambiarlo pigiando la combinazione di tasti Ctrl + L-Alt + F10. I tre led del pannello lampeggeranno 5 volte per segnalarvi l’avvenuta modifica nel PIC ed alla successiva riaccensione del sistema il layout predefinito sarà sempre quello da voi ‘impostato’.

Siccome seguo da tempo e con grande entusiasmo il progetto del mio carissimo amico Piergiorgio Betti (fantastico: una scheda multifunzione che vi permetterà di fare tante cose interessanti con il vostro Z80NE… ma preferisco sia lui a spiegarvi per bene questa cosa) [grazie Pino. ndr], ci sono delle scelte che sono state determinate dal fatto che ormai io e lui utilizziamo lo Z80NE solo ed esclusivamente con il CP/M 3 (con BIOS da lui opportunamente modificato e ricompilato per adeguarlo al nuovo HW) ed i tanti software che si trovano in rete per questo OS.

Tra le cose che abbiamo deciso di comune accordo mi vengono in mente:

  • La sostituzione del tasto SHIFT-LOCK con il più utile CAPS-LOCK

  • L’eliminazione del tasto LINE FEED: ho riassegnato al tasto TAB la sua vecchia funzione di ‘Tabulatore’

  • L’assegnazione delle combinazioni di tasti più diffuse (prese dalla cosiddetta WordStar Diamond) ai tasti cursore, Home, End, Ins, Del, PgUp, PgDn, etc.

Chi dedicherà qualche minuto al sorgente noterà che sono stati implementati anche combinazioni di tasti tipo Ctrl + Alt + Del ed i tasti funzione F1-F12. Non sono stati ancora utilizzati da Piergiorgio (non tutti, almeno credo!) ma presto lo saranno.

In ogni caso chi vorrà utilizzare questa interfaccia con NE-DOS potrà farlo tranquillamente restando alla larga dai tasti sopra citati che in tale contesto potrebbero avere un comportamento ‘anomalo’.

Spero di essere riuscito a spiegarmi in modo semplice e chiaro, per ogni vostro dubbio sarò a vostra disposizione.

Tra gli ‘allegati’ alla presente descrizione troverete un ‘estratto’ semplificato della tabella di conversione del KR-2376 che ho voluto rifare in modo (a mio avviso, spero anche per voi) più comprensibile e che voglio spiegarvi con un semplice esempio. Supponiamo sia stato pigiato (mi riferisco alla tastiera ‘originale’ NE) il tasto numerico ‘1’. L’interruttore corrispondente a tale tasto è collegato tra le linee X7 e Y8 (vedi schema elettrico, vedi schema e tabella sul datasheet). Osservando la mia tabella del KR-2376, incrociando la colonna X7 con la riga Y8 (come nella battaglia navale!) vi ritroverete in corrispondenza di un riquadro

scan1

contenente nella prima riga (N) il codice ASCII in notazione binaria a 7 bit (0110001), poi quella in notazione esadecimale (31) infine il carattere ASCII corrispondente (‘1’) nel caso in cui il tasto sia stato premuto ‘da solo’, nella seconda riga (S) ci sono i codici (in binario ed esadecimale) e l’ASCII (‘!’) corrispondenti alla combinazione SHIFT + 1 e la terza riga (C) invece corrisponde alla combinazione CONTROL + 1 che restituisce NUL perché non gestita dal sistema. Ogni codice così ottenuto dalla tabella viene poi complementato ed inviato in output dal KR-2376.

Altra tabella allegata (in realtà sono tre) è quella dei layout. Osservando questa tabella si può dedurre, partendo dall’alfanumerico pigiato, gli scan-code del corrispondente tasto in ‘battuta’ (Down) ed in ‘rilascio’ (Up), ed i codici da complementare ed inviare in output a seconda dello ‘stato’ dei tasti Shift e Ctrl.

scan2

Procediamo con un esempio osservando la tabella corrispondente al layout italiano: se pigio il tasto ‘1’ sulla tastiera PS/2 verrà inviato all’interfaccia lo scan-code 16 (sempre da considerare in esadecimale!) ed al rilascio invece uno scan-code costituito da due byte: F0,16. Se non viene pigiato altro che il tasto ‘1’ il codice inviato in output sarà IL COMPLEMENTO di quello della colonna ‘Normal’ (ovvero 31) che corrisponde appunto al carattere ‘1’. Nel caso in cui sia stata utilizzata la combinazione Shift + 1 allora il codice in output sarà IL COMPLEMENTO di quello della colonna ‘Shift’ (ovvero 21) che corrisponde appunto al carattere ‘!’. Nel caso in cui la combinazione sia stata Ctrl + 1 allora il codice da complementare ed inviare in output sarà NUL ovvero 00.

Detto questo credo/spero non sarà difficile interpretare correttamente quanto indicato in tutte e tre le tabelle, per qualsiasi layout.

Ultima nota riguarda il tastierino numerico: ho deciso fin dalla prima versione del firmware che resta SEMPRE abilitato, ovvero il tasto NumLock è inibito ed il led corrispondente resta SEMPRE acceso. Una scelta per snellire la procedura e ridurre al minimo le dimensioni del codice ;-)

N.B.: pigiando Alt e AltGr si attiva /NMI fin quando non vengono rilasciati.
In pratica, se pigiati insieme, equivalgono ai due tasti BREAK della tastiera originale. Da utilizzare solo ed esclusivamente con NE-DOS ;-) 

 

Versione 3.3.1

 La mappatura della tastiera è stata notevolmente estesa, prima di tutto, e questo rende necessario utilizzare una 16F648 al posto della 16F628.

La prima novità di questa nuova versione è il controllo del NumLock ed il salvataggio del suo 'stato' nella EEPROM del PIC con le stesse modalità del layout. In tal modo ad ogni accensione si avrà il NumLock nello stato preferito e/o più comodo.
La seconda novità riguarda la scelta della 'modalità' di utilizzo della tastiera che può essere cambiata con la combinazione L-Alt + F2. Le modalità previste sono due: NEDOS/SONE (un lampeggio) e DS/CPM-WS (due lampeggi) e quella 'preferita' può essere salvata (insieme al layout e allo stato del NumLock) nella EEPROM del PIC con la solita combinazione di tasti Ctrl + L-Alt + F10.
Nella prima modalità la tastiera PS/2 funziona in modo da somigliare quanto più è possibile alla tastiera originale dello Z80NE... ovvero:
  • il tasto TAB funziona da LINE FEED
  • il tasto CapsLock funziona da SHIFT LOCK
  • pigiando insieme i tasti L-Alt e AltGr viene simulata la pressione dei due tasti BREAK (con attivazione del /NMI sulla cpu)

Nella modalità DS/CPM-WS invece:

  • niente BREAK, niente LINE FEED e niente SHIFT LOCK!
  • il tasto TAB funziona… come TAB
  • il tasto CapsLock funziona… come CapsLock ????
  • i tasti cursore, PgUp, PgDn, Home, End, Del e Ins funzionano secondo lo 'standard' WordStar
  • i tasti F1-F12 tutti mappati, generano Esc + A, Esc + B, …, Esc + L
 
La terza ed ultima novità riguarda il reset reale dello Z80. Pigiando insieme i tasti Ctrl + L-Alt + Del il pin 2 del PIC (RA3) passa dallo stato TRI-STATE a LOW (e ci rimane fin quando non si rilascia almeno uno dei tre tasti, poi ovviamente ritorna in TRI-STATE!) e pertanto, collegandolo DIRETTAMENTE alla linea /RESET della CPU, si ottiene il riavvio del sistema esattamente come premendo il tasto reset della scheda cpu. Per realizzare questo collegamento si può fare un ponticello sulla interfaccia PS/2 tra il pin 2 del PIC ed uno dei pin liberi del connettore DIP-20 e successivamente realizzare un collegamento tra la linea /RESET e la corrispondente piazzola del pin libero prescelto sul lato saldature della video-grafica, proprio sotto il connettore tastiera.
Presto un nuovo PCB...
 
 ps2 schematic
 Schema interfaccia PS/2

 

Downloads

 

Firmware Documentazione

Spiacente, questo articolo non è disponibile in inglese. United-Kingdom-flag-icon-26
Please ask, if you wish an english translation added

 

original kit

Il mio Z80 NE

 a.k.a. ZDS or Z80 Darkstar

 

 

  

 

Il declino

Se avete letto l'articolo introduttivo alla Z80 di Nuova Elettronica, potete facilmente immaginare che, con il trascorrere degli anni, anche il buon vecchio Z80 andò in pensione.

Con l'arrivo in casa del primo PC IBM 8088, poi AT 286 e così via, di passo con la mia carriera professionale (oggi lavoro su cluster massivi), fu inevitabile che lo Z80 venisse progressivamente abbandonato. E così, anche se, nonostante la "concorrenza" di molto più performanti PC, la mia amata macchinina abbia caparbiamente proseguito la sua carriera per qualche anno con un programma di gestione abbonati per la rivista ferroviaria di mio padre scritto in DBII, fu inevitabile che infine trovasse la strada per la soffitta...

 

Tutti noi cresciamo negli anni e le prospettive cambiano. Così, ad un certo punto, come probabilmente è capitato a molti di voi, una maggiore disponibilità di tempo e una crescente nostalgia per i vecchi amori ha fatto sì che nascesse l'esigenza di "recuperare" il mio primo ed insostituibile computer.

2006, via la polvere!

Disceso dalla soffitta, non era messo poi tanto male, anche se recuperare i vari pezzi sparsi tra uno scatolone e l'altro non è stata impresa da poco.

A seguire le classiche operazioni di restauro, pulizia innanzitutto, verifica dell'alimentatore e prima ri-accensione. Sfortunatamente non ho fatto una documentazione fotografica di questa attività.

Quindi per farla breve il mio Z80 era di nuovo funzionante!

Bè non proprio.

Al primo tentativo di bootstrappare la macchina ho avuto la sgradita sorpresa di vedere che tutti i floppy del NE-DOS erano rovinati. Non solo quelli del NE-DOS a dire il vero, ma tutti in blocco, incluso quindi CP/M e qualsiasi altro software.

Sulla superficie dei floppy si era formata una specie di patina di muffa. Più tardi ho scritto un programmino per lo Z80 che fosse in grado di recuperare i settori non danneggiati. Visto che di molti floppy avevo copie multiple, in effetti, leggendo un settore da un disco, uno da un'altro, qualcosa sono riuscito a recuperare anche se questo purtroppo è quasi costata la vita ad uno dei drive Tandon da 5".

Tuttavia il problema immediato rimaneva: come caricare software sullo Z80?

All'epoca il sito di Roberto Bazzano, "The Home of Z80 NE", non esisteva e non ero ancora in contatto con altri affezionati dello Z80 NE. L'unica soluzione sembrava utilizzare la schedina parallela LX389 per realizzare una interfaccia parallela tra Z80 e PC. Anche perchè ormai il PC ospitava le immagini di tutti i dischi e il software per lo Z80 in mio possesso.

Fatta una piccola modifica su tale scheda e aggiunto il software necessario tutto si è sbloccato.

Da quel punto in poi sono nate tante idee, alcune realizzate, alcune ancora no (il tempo libero è quello che è). Non voglio annoiare nessuno e quindi vi risparmio la cronistoria delle modifiche apportate allo Z80 e del perchè alcune modifiche ne hanno richieste altre.

La documentazione del tutto è disponibile nelle pagine più in basso dove ho cercato spiegare le cose al meglio e nel dettaglio.

Qualche considerazione generale. 

Tutte le modifiche, alcune realizzate poi anche con l'aiuto dell'amico Pino Giaquinto portano ad avere uno Z80NE con gli "steroidi". Questo è bello da un lato ma comporta delle rinunce dall'altro.

Per chiarire: usare ad esempio la scheda multifunzione, che si porta a bordo 768k di ram, è possibile solo rinunciando alle schede di memoria originali. Ciò che alla fine ottenete non è più esattamente in linea con lo Z80NE, ma uno ZDS come io lo chiamo o Z80 Darkstar, nomignolo che il mio Z80 ha avuto praticamente da sempre, per via del suo case nero.

L'idea è avere lo Z80 dei miei sogni e vedere fin dove è possibile portare l'architettura di base di Nuova Elettronica, senza progettare un computer da zero, come per esempio hanno fatto i ragazzi del N8VEM.

Personalmente ho risolto il problema mettendo da parte tutto il "non serve più" e duplicando "il modificato" in modo da avere l'occorrente per uno Z80NE suo gemello, puro così come mamma lo ha fatto (grazie Pino per la scheda floppy...)

Una seconda importante considerazione è la seguente: tutto il software realizzato lato PC gira ed è stato sviluppato su Linux. Questo vuol dire che se non utilizzate questo sistema operativo vi dovrete attrezzare. Il software di per se è in puro C quindi non dovrebbe essere difficile il porting su DOS/Windows utilizzando Cygwin, ma io non l'ho mai fatto. Questo sforzo spetta a voi e anzi, se ci riuscite, This email address is being protected from spambots. You need JavaScript enabled to view it..

Tutto il software sviluppato, il software adattato (quasi tutto per il CP/M), la documentazione, i progetti e quant'altro è disponibile qui:

https://github.com/pbetti/ZDS

indipendentemente dalla descrizione dei singoli progetti che trovate sotto. Il materiale è disponibile su github sia per la facilità della distribuzione, sia perchè, bè, non ho mica smesso di lavorarci sopra... ????

Per avere una copia del repository il requisito software è avere installato "git", che è disponibile su qualunque versione di Linux o che, a vostra scelta potete compilare prelevandolo da https://git-scm.com/downloads, quindi, posizionatevi in una cartella appropriata al contesto in cui creare la sottodirectory di github e date il comando:

$ git clone https://github.com/pbetti/ZDS.git

In seguito per mantenere il repo sempre aggiornato, entrate nella cartella ZDS ed usate il comando:

$ git pull origin master

Buon divertimento!

 

Progetti

Le modifiche realizzate e quelle in via di realizzazione sono documentate nella lista qui sotto. Cliccate sui titoli per la pagina corrispondente.

 

 Software, Tips&Tricks

 

 


 

Spiacente, questo articolo non è disponibile in inglese. United-Kingdom-flag-icon-26
Please ask, if you wish an english translation added

 

 

LX389

 

Interconnettere lo Z80 ed il PC

 

Questo è il tema: scambiare dati tra i due mondi. Nel mio caso l'esigenza è diventata una necessità nel momento in cui, facendo ripartire il mio Z80 dopo anni, mi sono accorto che i floppy da 5" erano ormai irrimediabilmente rovinati.

La comunicazione seriale è la prima risposta che viene in mente per questa esigenza. Peccato che, al momento, interfacce seriali per lo Z80NE non esistevano (ora si!).

Di conseguenza, la soluzione al problema più immediato e con la necessità di utilizzare l'hardware a disposizione, mi ha indirizzato quasi obbligatoriamente verso l'utilizzo di una comunicazione basata da un lato sull'interfaccia parallela/stampante LX389 e la corrispondente porta parallela del PC dall'altro lato.

Non ci sono altre porte disponibili, la porta stampante sulla video grafica sebbene gestita da uno Z80 PIO (quindi perfettamente bidirezionale), purtroppo è abbinata ad un line driver 7407 che ne blocca la funzionalità in input.

 

Hardware

 

La LX389 è una schedina mezza altezza, molto simpatica, progettata da Nuova Elettronica con l'intento di permettere il collegamento di una stampante allo Z80, una parallela Centronics per la precisione.

Ma la buona NE ha comunque predisposto la scheda affinche su di essa, in alternativa alla porta stampante, fossero disponibili due porte parallele entrambe utilizzabili come input e/o come output. Il tutto utilizzando quattro buffer-latch e altri quattro logiche per l'indirizzamento della scheda sul bus.

L'unica "pecca" per così dire di questa progettazione è che le due porte hanno ognuna i pin di input e quelli di output separati, mentre per il collegamento con il PC occorre una porta realmente bidirezionale, una porta cioè dove i pin possano svolgere a comando sia la funzione di input che quella di output.

Prima di procedere con la parte Z80 vediamo cosa ci aspetta dal lato PC. Premesso che qui i requisiti importanti sono due:

  • La disponibilità della porta parallela, requisito non scontato visto che i PC più moderni non la montano più di default. Occorre quindi un PC dove se anche la porta non disponibile nativamente sia possibile aggiungerne una.
  • La porta in questione deve essere bidirezionale. Esistono diverse logiche di funzionamento: SPP, Bidir, EPP, ECP. Tutte sono ok tranne la SPP che NON è bidirezionale. Bisogna anche verificare che da setup del BIOS la porta sia effettivamente impostata come EPP/ECP.

La porta parallela del PC

La porta in questione è sempre abbinata ad un connettore a vaschetta da 25 poli con questa piedinatura

Parallel port pinout

e controllata da tre registri, accessibili sequenzialmente da un indirizzo base

Port access registers

Riassumendo la funzionalità dei pin in una tabella:

Pin
Reg Bit
Description
Direction
1 /C0 Strobe Output
2 D0 Data Bit 0 Output
3 D1 Data Bit 1 Output
4 D2 Data Bit 2 Output
5 D3 Data Bit 3 Output
6 D4 Data Bit 4 Output
7 D5 Data Bit 5 Output
8 D6 Data Bit 6 Output
9 D7 Data Bit 7 Output
10 S6 Acknowledge Input
11 /S7 Busy Input
12 S5 Paper End Input
13 S4 Select In Input
   
Pin
Reg Bit
Description
Direction
14 /C1 Auto Feed Output
15 S3 Error Input
16 C2 Initialise Output
17 /C3 Select Output
18 - Ground -
19 - Ground -
20 - Ground -
21 - Ground -
22 - Ground -
23 - Ground -
24 - Ground -
25 - Ground -

 

Il controllo dei vari pin, in Linux, è possibile in tre diverse modalità, ognuna con dei pro e contro. Per una introduzione al problema ma sotto Windows potete leggere qui.

  1. Raw i/o
    In questo caso si accede direttamente all'hardware dei tre registri coinvolti. E' il metodo più semplice e veloce, ma dovendo accedere a così basso livello è necessario avere in privilegi del superutente "root". E' anche possibile impostare l'eseguibile che utilizza la parallela come setuid(0) per semplificarne l'utilizzo.
    Ora, i puristi della security, obietteranno immediatamente che questo crea dei problemi (di sicurezza appunto) e che quindi è altamente sconsigliabile. Cosa del tutto vera.
    Ma, nel nostro caso, stiamo parlando di una applicazione destinata a girare su un sistema non pubblico, da "laboratorio" e quindi possiamo tranquillamente ignorare la cosa nelle giuste condizioni.
  2. Accesso alla device /dev/lpx
    Forse il più corretto da un punto di vista formale, ma lento e in ultima analisi abbastanza macchinoso.
  3. Via ppdev driver
    Probabilmente il migliore dei tre. Non veloce come l'accesso raw (ma sempre a velocità luce rispetto ad uno Z80) però lavora in user space e quindi non crea problemi di sicurezza. La programmazione avviene tramite una serie di chiamate ioctl(), vedi qui e qui per approfondire.

Come vedremo nella parte software, attualmente ho utilizzato il metodo raw i/o ma, con un pò di calma, le future versioni passeranno all'utilizzo di ppdev.

La parallela dello Z80 - funzionamento

Ok, preparatevi a scaldare il saldatore, ma prima vediamo cosa vogliamo realizzare.

Come anticipato la LX389 mette a disposizione due porte parallele dove però ognuna di esse ha i pin di input e output separati. L'idea è collegare insieme, su una delle due porte, gli 8 pin di input e i relativi 8 di ouput. Quindi dai 16 pin iniziali ne otterremo 8 che possono switchare tra le due modalità ingresso/uscita. Chiameremo questa: data port.

La porta rimanente che chiameremo control port avrà assegnate due importanti funzionalità: un pin in uscita andrà a controllare il chip enable della data port (IC5) quindi funzionando come selettore della modalità i/o della porta stessa.

La seconda funzionalità sarà quella di controllore dei segnali di handshake con il PC collaborando con la porta dati al trasferimento delle informazioni. A questo scopo utilizzeremo due pin in output e due in input.

La scelta di avere due pin di handshake per lato è dovuta al fatto che la differenza di velocità tra i due sistemi è veramente notevole, e, più e moderno il PC utilizzato, più questo gap prestazionale si allarga. Quindi i sistemi per ogni byte trasferito asseriscono prima un segnale di READY, ovvero dato disponibile sulla porta, e poi attendono dal corrispondente una segnale di AKNOWLEDGE prima di intraprendere una nuova operazione. Questo rallenta un pò le performance ma elimina la maggior parte degli errori (e nel protocollo logico è inserito anche un CRC per ulteriore sicurezza).

E passiamo allo schema elettrico, perfettamente riprodotto dall'amico Pino Giaquinto (*)

 Schema Parallela Bidirezionale

In questo modo è facile rilevare le differenze rispetto allo schema originale sulla rivista numero 73 di Nuova Elettronica.

In sostanza IC5 e IC6, che sono la porta 1 della LX389, vengono accoppiati bit a bit per ottenere la data port, il pin 1 di IC5 è scollegato dalla massa e collegato al pin 2 di IC7 a controllare la direzione della data port. IC7 e IC8 sono la porta 2 della LX389.

IC6 come ingresso è sempre attivo sul bus dati della parallela mentre IC5, che è in output si trova normalmente in alta impedenza e forza i dati sul bus parallelo solo quando il pin 1 si trova a zero, pilotato a come detto da IC7, pin 2 (D0).

Ora bisogna accoppiare le due porte PC <> Z80 in modo che possano scambiarsi dati. Il cablaggio relativo è il seguente:

 Cablaggio

 La parallela dello Z80 - realizzazione

La realizzazione dell'interfaccia non è affatto complessa. La maggior parte del lavoro consiste nel cablaggio ovvero nel prelavare i segnali dai connettori CONNETTORE 1 e CONNETTORE 2 della LX389 e questo (a parte realizzare correttamente i collegamenti da punto a punto) lascia molto spazio alla fantasia e alla capacità di ognuno.

L'unica modifica che risulta effettivamente sulla LX389 è tagliare la pista di massa al pin 1 di IC5 e collegarlo al pin 2 di IC7.

Per capire meglio, torna ancora un volta utile l'aiuto dell'amico Pino. La mia realizzazione e la sua sono completamente differenti, benchè funzionalmente identiche e, come al solito, quella di Pino è decisamente più ordinata.

Qualche foto, penso, vale più di mille parole. Cliccate sulla foto per vederla ingrandita.

Le foto a sinistra sono l'implementazione originale, quelle a destra la reinterpretazione di Pino Giaquinto:

IMG 20160403 160846 Lato saldature
 Modifica pin 1 di IC5 Modifica pin 1 di IC5 + trasferimento segnali alla porta stampante

 

Il motivo per cui nella foto di destra i segnali di handshake sono portati al connettore della stampante è perchè in questo caso viene utilizzato proprio quel connettore per collegarsi al PC. Nel mio caso invece la soluzione è diversa (si lo so, è un pò incasinata, ma devo precisare che è anche la realizzazione prototipo), ovvero:

connettore parallela Lato componenti
 Il prototipo L'ottimizzazione

 

Nel primo caso si è utilizzata una piccola basetta millefori con montati 3 connettori, due che vanno ad inserirsi sulla LX389 ed uno al centro (in foto non si vede) da cui parte il cavo parallelo. Le connessioni quindi sono tutte filate sulla basetta stessa.

Nel secondo caso invece, il collegamento al PC parte dalla porta stampante, i segnali di handshake sono filati dal lato saldature e l'accoppiamento dei bit dati tra IC5 e IC6 è ottenuto con un piccolo flat inserito nel CONNETTORE 1 in alto a destra.

L'ultimo accorgimento di cui bisogna tenere conto e l'indirizzamento della LX389. La data port ha indirizzo 03H e la control port 02H.

Di conseguenza i ponticelli P1,P2 e P3 della scheda devono essere tutti chiusi.

Ponticelli
Ponticelli LX389

 

Software

 

 Naturalmente senza una adeguato software di gestione dei trasferimenti quanto sopra sarebbe del tutto inutile.

Ci sono due parti da considerare, ciò che va installato su PC e la naturale controparte sullo Z80. Della parte sullo Z80 ce ne possiamo occupare dopo aver visto il lato PC, perchè, per quanto riguarda lo Z80 è necessaria una piccola digressione sullo stato attuale delle cose.

Il PC, server per lo Z80

Quanto sviluppato fa riferimento al mondo Linux, dovuta premessa, ed è sviluppato in C. Detto questo, il porting sotto Windows è senz'altro possibile ma le routine di gestione della porta parallela sono tutte da rifare, in special modo per ambienti Vista/Windows7/Windows10 dove l'accesso diretto all'hardware non è possibile.

Nel nostro caso invece si è utilizzato la gestione della porta via raw i/o cosa che richiede, come detto precedentemente, i privilegi di root. Questa e altre problematiche sono in corso di risoluzione (vedi Todo più avanti).

Altra premessa è che il software per lo Z80 è scritto per il CP/M e quindi compatibile con il SONE (vedi Todo), niente NEDOS. La gestione del NEDOS è rimandata ad un secondo momento, principalmente perchè non sono ancora a conoscenza del meccanismo dei drivers su questo s.o., peraltro uguale al TRS-DOS (o NEWDOS nello specifico).

Tornando al punto, esistono tre utility per il trasferimento tra Z80<>PC, due dedicate al traferimento diretto send_Z80DS e receive_Z80DS che come i nomi suggeriscono, effettuano rispettivamente invio verso lo Z80 e ricezione dallo Z80 di file e/o regioni di memoria.

Il pezzo "forte" però è un server per dischi virtuali che opera, appunto, attraverso la parallela chiamato vdsk_server.

Il vdsk_server ha diverse caratteristiche di cui le principali:

  • Gestione floppy in formato .IMG/.DSK accessibili come da cpmtools tramite la definizione del formato disco.
  • Gestione floppy in formato .DMK, utilizzato anche da Roberto Bazzano per l'archiviazione del software su www.z80ne.com.
  • Gestione floppy in formato .IMD, che, come sopra, viene utilizzato da Roberto Bazzano per l'archiviazione del software.
  • Accesso trasparente in lettura/scrittura per lo Z80 alle immagini floppy.

Ho usato il termine floppy ma in realtà sarebbe più appropriato "volume" in quanto le immagini possono essere anche relative ad HD.

Utilizzo:

> sudo ./vdsk_server -h
ZDS - Z80NE Virtual Disk Server v1.8

Usage: vdsk_server [-zZ] [-f A:format] [-F B:format] [-b boot] [-L label] [-n base] image [image2]

Options:

-z              No skew for drive A:
-Z              No skew for drive B:
-c              Create image for for drive A: if not exist
-L <label>      Label drive A: if not exist (CP/M only)
-b <fname>      Up to four code files to initialize boot tracks (CP/M only)
-f <type>       Diskdefs type for drive A:
-F <type>       Diskdefs type for drive B:
-n <X>          Drive id remap base X: (CP/M only)
-h              Usage help (this)
-u              Dump sectors during transfer
-D              DMK mode for non CP/M images (NE-DOS/NEWDOS/other)
-I              IMD mode for non CP/M images (NE-DOS/NEWDOS/other)
-p <d:h:t:s:z:k>
                Disk parameters for DMK create density:heads:tracks:sectors:sec. size:skew factor
                where:
                d       0 = FM, 1 = MFM
                h       1 = SS, 2 = DS
                t       # of tracks per side
                s       # of sectors per track
                z       Sector size in bytes 128/256/512
                k       skew factor

 

Il server suporta due immagini disco. nativamente, in formati distinti se richiesto. Gli identificativi dei dischi devono essere successivi ad esempio A:, B: fino a O:, P: Al momento però le opzioni per il doppio disco si applicano solo al formato .IMG/.DSK. Per i formati .DMK e .IMD al momento si può usare un solo disco (immagine).

Inoltre la gestione dei .DSK è limitata a dischi CP/M. I formati dei dischi sono specificati in un file esterno "diskdef" esattamente come per cpmtools (vedi più avanti).

Le opzioni nel dettaglio:

-z

Non applica skew factor. I settori vengono letti sequenzialmente come fisicamente presenti sul disco.

-Z

Come sopra, ma per il second disco (solo .DSK)

-c

Richiede la creazione di una immagine. Per il formsto .DSK l'immagine viene creata nel formato specificato con -f, per le immagini .DMK e .IMD occore utilizzare l'opzione -p.

-L
etichetta <nomedisco> assegnata all'immagine creata con -c. Opzione valida solo per il formato .DSK (cp/m)
-b
Utiizzata con -b <fname1> <fname2> <fname3> <fname4>. Permette di specificare fino a 4 frammenti di codice (eseguibile) per inizializzare il bootstrap del disco che verranno caricati a partire al settore 0, traccia 0. (solo .DSK)
-f
Formato diskdef da utiizzare per l'immagine del primo disco (solo .DSK)
-F
Formato diskdef da utilizzare per l'immagine del secondo disco (solo .DSK)
-n

Base di rinumerazione dei drive. Ad esempio -n C significa che all'immagine disco verranno asseganti i drive C: per il primo e D: per il secondo (max P)

-h
Testo di help
-u
Mostra il dump (esadecimale) del settore in trasferimento
-D
Attiva la modalità per immagini in formato .DMK
-I
Attiva la modalità per immagini .IMD
-p

Parametri del disco utilizzati per la creazione di immagini in formato .DSK/.IMD con l'opzione -c. Esattamente occorre specificare una stringa nel formato d:h:t:s:z:k dove:

d       0 = FM, 1 = MFM
h       1 = SS, 2 = DS
t       # of tracks per side
s       # of sectors per track
z       Sector size in bytes 128/256/512
k       skew factor
 

Formati disponibili per le immagini .DSK/.IMG

diskdef SONE128
  seclen 128
  tracks 40
  sectrk 17
  blocksize 1024
  maxdir 32
  skew 4
  boottrk 3
  os 2.2
end

diskdef ZDSdos
  seclen 256
  tracks 40
  sectrk 10
  blocksize 1024
  maxdir 32
  skew 0
  boottrk 0
  os 2.2
end

diskdef ZDS
  seclen 512
  tracks 160
  sectrk 11
  blocksize 2048
  maxdir 256
  skew 4
  boottrk 2
  os 3
end

diskdef ZDSHD8
  seclen 512
  tracks 64
  sectrk 256
  blocksize 2048
  maxdir 1024
  skew 0
  boottrk 1
  os 3
end

 

I vari formati sono disponibili nel file vdsk_server/diskdefs.

Le routine per lo Z80

Ovviamente anche il nostro bravo Z80NE va "istruito" sull'uso della parallela.

Le routine riportate di seguito non sono necessarie se decidete di utilizzare la multifunzione perchè sono tutte già integrate sul monitor della stessa e quindi anche nel CP/M3.

Il codice è riportato qui per due ragioni: per conoscenza e perchè ancora non avuto tempo di integrarle nel SONE. Se qualche volontario si offrisse...

Non mi vorrei ripetere, ma mi ripeto, ricordando che le routine riportate qui non sono necessariamente all'ultima versione. Fate sempre riferimento a github invece.

Qui il codice di basso livello:

 Per chi volesse cimentarsi nell'implementare il tutto sul SONE ecco qui l'occorrente:

Per compilare il SONE, modificato o no, è sufficiente eseguire:

> ./makecpm.sh xx

dove xx indica il taglio di ram disponibile (48/56/60/62). In github il tutto si trova nella cartella "software/SONE/sone".

Sono necessari i tools indicati qui.

Tutto quanto sopra è per l'utilizzo del vdsk_server per l'accesso trasparente ai dischi virtuali, se invece volessimo trasferire il disco montato sul PC direttamente al nostro floppy occorre un utility per lo Z80 chiamata dsktran

Attualmente questa utility è disponibile solo per CP/M ma è in grado di trasferire qualsiasi immagine purchè supportata dal vdk_server e, fisicamente, dal floppy driver. A questo proposito notare, che tutte le opzioni con settori da 512 bytes non sono disponibili se non effettuando alcune modifiche sull'interfaccia floppy.

All'avvio il programma richiede alcune informazioni riguardo il numero di tracce/settori/formato e quindi inizia il trasferimento del disco sector-by-sector. Notare che selezionando il formato NEDOS viene regolarmente trattata la traccia 17 con gli specifici address mark.

 

Esempi di utilizzo

Avvio da disco virtuale. In questo video la console seriale dello Z80 (disponibile sulla multifunzione) è collegata ad un vecchio ma funzionale terminal server Annex e quindi in rete:

 

 

Todo list - Cose da fare

  • Porting vdsk_server su parport driver
  • dsktran versione NEDOS

 

 * Pino, dove trovi la pazienza per queste cose? Ancora grazie per il tuo insostituibile supporto!