Audiocassette più vive che mai ... e i Commodore ringraziano !

Guida sintetica per trasferire su audiocassetta i file TAP di Commodore.

Questa non è una guida passo-passo per scimmie: dopotutto non abitate in uno zoo ! Non vengono dati link ai programmi: google è più che sufficiente per trovarli tutti.

Prima di tutto toglietevi dalla mente le conversioni da TAP a qualunque file sonoro Wav, Mp3, ecc... Dimenticatevi di Hz, bit rate, ecc... Nascondete lettori Mp3, riproduttori CD , vari telefoni intelligenti.

Tanto tutta sta roba funziona 1 o 2 volte su 10 sui Commodore ! Se vi va bene...

Quella che segue può sembrare la via più difficile e tortuosa (e in realtà non lo è), ma è sicuramente quella che garantisce una ottima affidabilità. Le audiocassette verranno registrate direttamente dal computer Commodore con il suo Datassette : meglio di così...

Cosa serve:

• Commodore 64
• Commodore Datassette
• Una cassetta audio (?!?)
• PC con MS-DOS e porta parallela (LPT)
• Cavo di connessione PC<-->C64 tipo X-1541 o XE-1541
• Programma VC1541.EXE e relativi file di supporto, per PC (versione 0.04pl6)
• Programma TAPSERV.PRG , per C64 
• Programma PTAP.EXE e relativi file di supporto, per PC
• Un file TAP.....a scelta, come più vi piace, che verrà trasferito su audiocassetta

Cosa serve "optional":

• Se non volete diventare pazzi a trasferire files tra un PC con Windows ed un PC con MS-DOS, vi consiglio l'installazione su quest'ultimo di un drive/programma capace di leggere le chiavette USB: verrà molto più comodo trasferire i files con la chiavetta !
• Programma TAPCLEANFE per PC Windows , per la verifica dei file TAP
• Programma MTAP.EXE per PC, se si desidera trasferire il contenuto di una audiocassetta su un file TAP.

Concetto di base del processo di trasferimento

Il PC con MS-DOS invia al C64 , tramite il cavo parallelo/IEC X1541 o XE1541, il file TAP scelto , che verrà salvato direttamente sul Datassette.

In dettaglio, il programma del PC PTAP.EXE trasferisce il file TAP al programma del C64 TAPSERV.PRG , il quale provvede a salvarlo sulla cassette , il tutto in tempo reale.

Inizio

Prima di tutto è necessario salvare su audiocassetta il programma TAPSERV.PRG , così che sarà più comodo utilizzarlo in futuro , caricandolo direttamente dal Datassette.

Per fare ciò è necessario avviare sul PC MS-DOS , il programma VC1541.EXE (utilizzate l'ultima versione, quella con le "finestre" per la selezione dei file) che emulerà un lettore floppy 1541; sempre con il cavo di collegamento PC-C64 inserito , caricate sul C64 il programma TAPSERV.PRG

Una volta che si ha a disposizione TAPSERV.PRG su cassetta , il programma VC1541.EXE non vi servirà più; sarà infatti sufficiente caricare TAPSERV.PRG sul C64 e il programma PTAP.EXE sul PC.
Caricare quindi TAPSERV.PRG sul C64 dalla cassetta (il solito comando LOAD"TAPSERV.PRG", e poi RUN), e lanciate sul PC MS-DOS il programma PTAP.EXE con le opzioni del caso ed il nome dil file TAP da trasferire; se è tutto ok, a video apparirà la richiesta di premere REC+PLAY sul Datassette. Non preoccupatevi se TAPSERV si trova in modalità ricezione oppure in modalità trasmissione, si sincronizzerà automaticamente .

PTAP.EXE trasferirà un qualunque file con estensione TAP ( con il comando PTAP.EXE "nomefile.TAP" ) al C64 che provvederà al salvataggio.

Verifica dei files TAP , ed operazioni su di essi

Il Programma TAPCleanFE (gira solo su Windows !) permette di verificare l'integrità/bontà dei file TAP, che è sempre una buona cosa da fare prima di iniziare l'intero processo di trasferimento.

Lanciato il programma, aprite un file TAP, cliccate sul pulsante TEST, attendete il risultato e verificate la qualità del TAP.
Se all'interno del file TAP sono presenti porzioni "non riconosciute" da TAPClean ("Unrecognized"), personalmente preferisco rimuoverle: avrete maggiori probabilità di successo nel successivo processo di trasferimento.

E' anche possibile fare cosa carucce come ad esempio estrarre un singolo programma/gioco da una raccolta TAP di più programmi/giochi , come ad esempio capita nei file TAP delle cassette allegate alle vecchie riviste, dove sulla cassetta erano generalmente presenti più programmi/giochi.

E il VIC-20 ?

E se volete trasferire su audiocassetta i file TAP del VIC-20 ? Utilizzate sempre il C64 nel solito modo indicato, con la sola eccezione di lavorare sui file TAP del VIC-20; il programma PTAP ha delle opzioni specifiche per il VIC-20 (verificatele digitando "PTAP -h" dal prompt dei comandi DOS) ; non è necessario utilizzare il VIC per il trasferimento...anzi, non funzionerebbe nemmeno...

Suggerimenti

Verificate sempre la documentazione dei programmi (VC1541.exe e PTAP.exe) leggendo i vari file README.TXT , in particolare per i settaggi da utilizzare , ad esempio il numero di porta parallela (lpt1, lpt2, ecc..) , il cavo di trasferimento utilizzato (X-1541 oppure XE-1541) , settagi vari ed eventuali , specifici di ciascun programma.
Verificate sempre il funzionamento del file TAP, prima e dopo l'utilizzo di TAPCleanFE (se ne decidete l'uso) su uno qualunque degli emulatori disponibili per le macchine Commodore.

Qualche aiutino :

• programma VC1541  http://vc1541.sourceforge.net/vc1541/download.html
• programma PTAP http://markus.brenner.de
• programma TAPSERV.PRG http://www.findthatzipfile.com/search-38698281-hZIP/winrar-winzip-download-ptap36.zip.htm

Mirko / Dr_Who

GALAXIAN - Gli Invasori sono tornati !!!

A volte anche le flotte aliene devono fare i conti con la tecnolgia: centinaia di navi spaziali rese inutilizzabili a causa del malfunzionamento di un piccolo ed insignificante (almeno così si pensava) chip ...

Ma sostituito il chip difettoso , gli invasori di Galaxian , uno dei videogiochi che andava per la maggiore nei primi anni ottanta , sono tornati , e sono più incazzuti che mai !

Ovvero, come riparare una scheda di Galaxian
(versione Coin-op)

La mia collezione di schede di videogiochi da bar derivano per la maggior parte dei casi da schede non funzionanti , sostanzialmente per due motivi : uno , costano meno, e due è più facile trovare vecchi videogiochi guasti piuttosto che funzionanti. Ultimo ma non ultimo, per quel che mi riguarda , il mio rapporto ludico con tali giochi è :

• 25% di incazzatura perchè la scheda non è riparabile...
• 25% di gratificazione quando la scheda si mette a funzionare...
• 25% di incazzatura perchè non riesco a passare neanche il primo livello...
• 25% di gratificazione quando, dopo mesi di duro allenamento, muoio all'inizio del secondo livello...

Nel caso di Galaxian , all'accensione della scheda si vedeva a malapena la schermata del selftest (tutto di colore grigio scuro), con dei notevoli problemi anche nella visione in attract mode




Attract Mode:
- nella parte superiore le scritte "1UP" e "HIGH SCORE" e rispettivi punteggi sono in colore grigio scuro, quali indistinguibili dallo sfondo
- la scritta "WE ARE..." dovrebbe essere in colore rosso
- non si vede la scritta "SCORE ADVANCE TABLE"
- non sono correttamente visualizzati i punteggi e le navicelle nemiche
- compaiono bande orizzontali di colore blu e verde












Se si fa partire il gioco, si hanno i seguenti difetti:
- nella parte superiore le scritte "1UP" e "HIGH SCORE" e rispettivi punteggi sono in colore grigio scuro, quali indistinguibili dallo sfondo
- le navicelle rimenenti non sono visualizzate
- la scritta "CREDIT" è visualizzata per metà
- le navi nemiche in "attacco" presentano una banda colorata orizzontale che si muove in sincronia alla navi stesse








Visto così sembrerebbe un problema alla catena video, composta da:

• due eproms grafiche (gfx roms)
• quattro bidirectional shifter register (74LS194)
• un multiplexer 74LS157
• tre memorie ram utilizzate come buffer della memoria video

Le due gfx roms hanno l'uscita dati a 8 bit separata tra loro, ovvero non sono collegati ad un unico bus dati, ma i primi quattro bits (quattro bits vengono definiti "nibble") della prima rom confluiscono all'ingresso del primo shifter 74LS194, i secondi quattro bits della prima rom vanno all'ingresso del secondo 74LS194, e stessa cosa per la seconda rom grafica: quattro bits sono collegati all' ingresso del terzo 74LS194 e gli ultimo quattro bits al quarto 74LS194.
Così facendo , i valori dei quattro nibbles provenienti dalle due gfx roms vengono "serializzati" dagli shifter registers ed inviati agli ingressi del multiplexer 74LS157; una uscita del multiplexer alterna i dati serializzati provenienti dai due nibbles della prima gfx rom, e una seconda uscita alterna i dati serializzati dei due nibbles della seconda gfx rom.
La necessità di dividere ciascun byte delle gfx roms in due nibbles e poi serializzare ciascun nibble in un singolo bit, è dovuta all'utilizzo della ram grafica composta da un solo bit in ingresso (ed un solo bit in uscita) e quindi impossibilitata a ricevere un byte completo !

In fase di boot la scheda dovrebbe fare il test delle roms e delle memorie ram: se vengono riscontrati problemi/anomalie , queste dovrebbero essere visualizzate a video. Considerando che nussun messaggio di anomalia è evidenziato, è da ritenersi che roms e memorie ram siano OK.
Mi sono quindi focalizzato sui quattro shift register 74LS194 e sul multiplexer 74LS157.
E qui una bella botta di fortuna (a volte ci vuole !), poichè essendo i quattro shift register montati su zoccolo, per prima cosa ho provato a sostituirli uno ad uno con uno nuovo e funzionante, e ciò ha dato i suoi frutti:



La grafica, sia in attract mode che in modalità gioco è correttamente visualizzata .
Buon gioco a tutti !
















La scheda è un bootleg

Pictures Archive

Tekken 3 - Coinop pictures

VECTREX

Vectrex Multicart e GI AY-3-8912A

PinMAME comanda un vero Flipper - 2 parte

Provato il sistema direttamente sul playfield, tutto sembra funzionare a dovere : luci, pulsanti e bobine.
Molto tempo è stato portato via dalla realizzazione della schede che controlla i flippanti ; il playfield di prova è un Data East nel quale le bobine dei flippanti hanno una spira sola , al contrario della maggior parte dei flipper dove ve ne sono due, una di "power" per alzare la paletta ed una di "hold" per mantenerla alzata. L'alimentazione della versione a singola spira è un 50 vdc per il power che viene dato solo per i primi 40 millisecondi; allo scadere dei 40 ms , i 50 volt vengono tolti e dati i 9 volt per il mantenimento; il tutto per evitare di bruciare la bobina stessa. E' da notare che non sono presenti gli switch di end-of-stroke.

Siccome qualche lampadina era bruciata, aspetto i ricambi per poi postare qualche foto e video del playfield funzionante.

PinMAME comanda un vero Flipper

Descrizione generale

Il progetto nasce dalla curiosità di sapere come è gestito a livello di elettronica un flipper SS , e dalla curiosità di sapare come il PinMAME lavora e come si interfaccia con programmi come VirtualPinball.
Avendo anche a disposizione un playfield completo di tutto ad esclusione della parte elettrica/elettronica, ho incominciato a pensare come il PinMAME potesse gestire tutte le funzionalità presenti su un piano di gioco. Ed ecco nascere questo progetto ...

Il sistema è formato da due componenti : un computer sul quale gira il PinMAME ed una scheda elettronica a microcontrollore (MCU) , collegata da un lato al PC e dall'altra alle componenti del playfield.
Il trasferimento dati tra PC e MCU avviene tramite un collegamento seriale (RS232 o USB conv.)
Attualmente sono gestiti 32 solenoidi (bobine e flash) , 64 lampade e 64 interruttori.

Scheda elettronica

La scheda elettronica è costituita da tre MCU collegate tra loro per lo scambio di informazioni e la gestione delle unità esterne ; una di esse è collegata al computer via cavo sariale.
Sulla scheda trovano posto i transistor di potenza per l'attivazione dei solenoidi, quelli per le lampade, ed infine gli integrati che gestiscono gli switch.
Al fine di rendere più agevole il lavoro, non sono stati scelti componenti a montaggio superficiale;
I tre microcontrollori hanno una velocità di funzionamento a 8 MHz / 8MIPS , e sono abbastanza veloci da gestire il tutto senza rallentamenti. Il costo dei microcontrollori è di circa 8 euro ciascuno. Nel caso sia necessaria una maggiore velocità di elaborazione, sono già in cantiere 3 MCU da 160 MHz / 40 MIPS

Solenoidi / Bobine

Al momento solo 32 solenoidi sono gestiti ; essi possono essere bobine oppure flash.
Sono gestiti da una singola MCU , le cui uscite provvedo a pilotare un transistor che funge da pre-driver per il tansistor di media potenza (tipo TIP102) ; qualora la bobina consumi un amperaggio elevato, il TIP102 fungerà da pre-driver per un terzo transistor di potenza (TIP36C).
Il collegamento è quello classico : il solenoide è sempre alimentato (48 volt o 32 volt), ed il transistor che chiude a massa.



Il video mostra l'attività dei solenoidi numerati dal 25 al 32; le uscite della MCU sono collegate agli otto led della scheda di sviluppo; i led accesi indicano i solenoidi non attivi, mentre i led spenti indicano i solenoidi attivati

Lampade

La gestione delle 64 lampade è affidata alla seconda MCU; anche quì si è conservato lo schema classico : 8 colonne/driver e 8 righe/return.

Come per i solenoidi , ogni 10 millisecondi il computer invia lo stato di tutte le colonne e di tutte le righe alla MCU, la quale provvede ad aggiornare i transistor dei driver e dei return.

Il video mostra l'attività delle otto righe delle lampade collegate agli otto led della board. Come prima, i led accesi indicano le uscite poste a zero, e viceversa i led spenti indicano le uscite delle righe attive.

Switch

Il terzo ed ultimo microcontrollore è quello che sovraintende agli switch; i 64 switch sono gestiti come una matrice di 8x8, cosichè risultano facilmente collegabili ai microswitch già presenti nel playfield.

In questo caso, il microcontrollore invia al computer solo le informazione inerenti al cambiamento di stato di ogni singolo switch : in tal modo si evita di sovvracaricare di lavoro il programma sul pc e viene decongestionato il traffico dati sulla linea seriale.

Quì c'è poco da dire...

Considerazioni sulla sicurezza

I microcontrollori che gestiscono i solenoidi e le lampade , sono stati dotati di un watchdog. Questo fa sì che nel caso in cui la MCU non sia più in grado di eseguire correttamente il programma, essa si resetti automaticamente e ponga a livello logico basso le sue uscite, in modo tale da diseccitare le bobine e spegnere le lampade (evitando così di bruciare qualcosa).

La funzione di watchdog entra in funzione quando la MCU è bloccata per più di 500 millisecondi, oppure nel caso in cui non riceva i dati dal computer entro un tempo di 500 millisecondi. Ciò vuol dire che se il computer viene spento oppure si 'pianta', o qualcuno scollega il cavo seriale, i solenoidi e le lampade si spengono.

Sviluppi

La scheda di controllo è completata, non mi resta che raccimolare un paio d'ore per collegarla al playfield e vedere come si comporta nel complesso (già, perchè i singoli componenti sono stati testati all'inizio del progetto)...

Atari Breakout : circuito punteggi - bozza

In Breakout sono presenti 8 file di mattoni per 14 colonne. Partendo dal basso verso l'alto:

• fila 1 e 2 = 1 punto ogni mattone
• fila 3 e 4 = 3 punti ogni mattone
• fila 5 e 6 = 5 punti ogni mattone
• fila 7 e 8 = 7 punti ogni mattone

Per completare il gioco è richiesto di abbattere due muri; abbattuto completamente il primo (448 punti), si ottiene il secondo muro, per un punteggio complessivo di 896 punti. Non sono previsti altri muri dopo il secondo (?!?).



Schema 1a

Guardando lo Schema 1a, troviamo sei contatori BCD 9310 (location N6, M6, L6, H6, J6, K6), i primi tre utilizzati per memorizzare il punteggio del Player 2 , ed i secondi tre per memorizzare il punteggio del Player 1. Sullo schema ho suddiviso le sezioni di ciascun Player.
Ciascuna tripletta di contatori collegati in cascata sono utilizzati per memorizzare i valori delle unità, decine e centinaia dei rispettivi punteggi; è quindi da escludere la possibilità di veder memorizzato e visualizzato un punteggio superiore a 999. I contatori sono azzerati (punteggio=000) all'inizio della partita, ovvero alla pressione del pulsante Start Player il segnale /Start Game va basso azzerando i contatori.

L'incremento dei contatori avviene tramite il segnale Count1 per il giocatore 1 e Count2 per il giocatore 2. Count1-2 è un treno di impulsi generato dal contatore 74192 (location N9) ogni volta che la palla colpisce i mattoni posti nella :

• prima e seconda fila genera 1 singolo impulso
• terza e quarta fila genera 3 impulsi
• quinta e sesta fila genera 5 impulsi
• settima e ottava fila genera 7 impulsi

Schema 1b

Guardando lo schema 1b , il segnale che indica che è avvenuto l'abbattimento di un mattone è il Brick Hit. L'assegnazione dei diversi punti per le diverse file di mattoni avviene caricando sul contatore N9 i valori presettati agli ingressi pin# 15, pin# 1, pin 10# e pin# 9.

Con riferimento allo schema 1a, quando il giocatore 1 raggiunge il punteggio di 448 punti, il contatore delle unità segnerà 8 alzando il segnale D1, il contatore delle decine segnerà 4 alzando il segnale G1, ed il contatore delle centinaia segnerà 4 alzando il segnale K1.

D1,G1 eK1 vanno alla porta NAND (location M4), la cui uscita è posta alta quando il punteggio è diverso da 448, per poi andare bassa al raggiungimento dei 448;questa uscita va all'ingresso di una porta OR (location E4) e con il segnale /BP HIT (segnale che va basso quando viene colpito dalla palla il bordo superiore dello schermo o la racchetta) attiva o meno l'uscita della porta OR che funge da clock/trigger del flip-flop F4 ; in dettaglio quando il punteggio è diverso da 448 l'uscita OR è sempre alta, e va bassa solo quando il punteggio è uguale a 448 e contemporaneamente avviene un rimbalzo della palla (segnale /BP HIT).

Ho detto che l'uscita della porta OR (location E4) va al clock del flip-flop F4; questo flip-flop ha il compito di ricostituire (o ricostruire) interamente il muro quando questo è stato completamente abbattuto. Va precisato che l'abbattimento del muro è detectato dalla logica della scheda unicamente andando a testare il punteggio : se questo è uguale a 448 , allora significa che non vi è rimasto più nessun mattone.

Ad ogni modo, il flip-flop è resettato all'inizio del gioco dal segnale /Start Game che andando basso pone le uscite Q=bassa e /Q=alta; abbiamo detto che quando il punteggio è uguale a 448 (quindi nessun mattone presente) ed avviene un rimbalzo della palla, la porta OR E4 va bassa, tenendo quindi basso il segnale di clock del flip-flop; la porta OR torna alta quando è terminata la fase di rimbalzo (segnale /BP HIT nuovamante alto) : il passaggio da basso ad alto dell'uscita della porta OR e quindi del segnale di clock del flip-flop, fa sì che la sua l'uscita /Q sia bassa.

Il passaggio dallo stato alto a quello basso dell'uscita /Q del flip-flip collegata all'ingresso di trigger del multivibratore 9602 (location F3) fa sì che l'uscita FPD1 del multivibratore vada allo stato alto per poi tornare basso; l'inverso dicasi per l'uscita negata /FPD1.

Schema 1c

Il passaggio di stato dei segnali FPD1 e /FPD1 determinano secondo lo schema 1C il ripristino della memoria L3 e di conseguenza il ripristino dell'intero muro.

Lo stesso concetto fin qui espresso per il Player 1 vale per il Player 2

Due muri o tre ?

Considerando che il rispistino del secondo muro avviene solo quando il punteggio è uguale a 448 , il quale alla fine di tutta la catena setta il flip-flop F4, considerando che nussun altro segnale resetta il flip-flop (se non il segnale di inizio nuovo gioco), considerando che al secondo muro il punteggio non può che essere superiore a 448 punti, si direbbe che sia impossibile per il flip-flop F4 resettarsi per poi settarsi nuovamente, e quindi impossibile un ripristino del terzo muro.

E' piuttosto ipotizzabile che durante il gioco in modalità due giocatori si venga a creare una condizione non prevista, tale per cui l'indicazione a schermo del turno di gioco del Player 1 venga erroneamente attribuita al Player 2, e quindi il punteggio del Player 1 venga visualizzato come punteggio del Player 2 : il secondo muro del primo giocatore diverrebbe il famigerato terzo muro ma del secondo giocatore.

Il tutto però potrebbe essere un bug nella gestione della rappresentazione a video dei punteggi e turno dei giocatori; rimane comunque impossibile lo scambio "fisico" dei punteggi tra i giocatori.

Una cosa è sicura : per quanti muri ci siano, il punteggio visualizzato non potrà mai superare i 999 punti.