Newsgroup: it.comp.retrocomputing
Titolo: Apple IIc

Ho per le mani un Apple IIc in ottime condizioni estetiche, ed ho qualche dubbio.
Il lettore interno, è in grado di leggere floppy scritti da un Disk ][ di
un Apple IIe?
Se sì, il lettore ha qualche problema, oppure c'è qualcosa che non so.
All'avvio con un disco inserito, le testine calibrano, il motore gira, 
ma non accade altro.
 
Naturalmente ho pulito e lubrificato: potrebbe anch'esser che la velocità 
raggiunta non sia quella giusta.
 
Dopo un CTRL-RESET, il Basic funziona, più o meno.
Nel senso che nella metà superiore del video (utilizzo un televisore)
la prima colonna è sempre in reverse video :(
Problema di ram?
Il segnale, però, è ottimo.
 
Il tasto 80 colonne non sembra aver alcun effetto.
Ho trovato, invece, all'interno, lo Z80 (D780C).
 
Grazie!

 
 
proverei con un monitor prima... 
 
F

 F
 
Il televisore è un Sony, ed funziona con gli Apple IIe, C64, Vic20, Spectrum
ed ogni altro dispositivo con uscita composita (ha un jack RCA sul frontale).
Per questo ipotizzo un problema del IIc...

Aggiornamento.
 
Sul volano del floppy drive ci sono le linee stroboscopiche, e la velocità
sembra corretta.
Escludiamo la cinghia.
 
Domani controllo la scheda elettronica del drive.
 
Vorrei provare ADT, ma devo prima costruirmi il cavo DIN-DE9

Dimenticavo: all'interno c'è una scheda che prende il posto 65C02, e 
contiene il succitato 65C02 ed il D780C


probabile che sia il IIc allora, ma potrebbe essere anche un difetto sulla generazione dei sincronismi. Bisognerebbe munirsi si sonda logica o oscilloscopio e vedere se c'e' qualche bit di ram "bloccato" a +5 o 0V.
 
F

 Ho trovato, invece, all'interno, lo Z80 (D780C).
gli apple ][ potevano montare la scheda cp/m il //c mi pare di no
 
 
 
 
 
-- 
klatu barada nikto!


 
Interessante... potrebbe essere una schedina custom per 
poter utilizzare il CP/M anche sul IIc... il quale in 
effetti non avrebbe nessun impedimento ad usare la SoftCard, 
se non che gli manca lo slot.
 
Se la ROM funziona, all'avvio premi:
 
CTRL + mela piena + mela vuota + Reset
 
e rilascia i tasti. Partirà il diagnostico interno della ROM 
(se la ROM non ha problemi ovviamente).
 
La linea in reverse potrebbe benissimo essere un problema di 
RAM.
 
*Gabriele*
 
 

 
Dopo la prima serie gli Apple //c vennero venduti con una scheda madre che integrava i due processori. Non mi pare fosse una opzione in Italia mentre negli States sicuramente lo era (ci sono pubblicità in questo senso su Nibble e Byte). Questa serie diciamo plus, è la più comune in Italia dove evidentemente i //c sono giunti mesi (forse anche un anno) dopo il lancio negli USA.
Il CP/M era un must all'epoca e rese il //c molto più appetibile per l'aumentata disponibilità di software nell'uso professionale (WordStar e DBII in primis).
Benché i sistemi bi-processori e in particolare 6502 + Z80 non fossero una assoluta novità, la soluzione Apple, probabilmente grazie alla grande esperienza fatta con le schede Z80 da montare sulla serie //e o precedenti, è al top per flessibilità e trasparenza d'uso.

 
 
E mi dimentico sempre che qui non piace il news reader di Google....
Ecco la versione plain, scusate.


Devo rivedere meglio la scheda, ma non sembra di provenienza Apple.
Dalla scheda parte un conduttore che termina con una clip che sembra quella
delle sonde dell'oscilloscopio e si connette al pin #2 dell'integrato
TMG2.
Sulla scheda c'è solo la serigrafia
AIIc DE.
 
La versione delle ROM è quella originale
PRINT PEEK (64447) restituisce, infatti, 255.
Il self test non c'è: la sequenza CTRL-Open Apple-Closed Apple-RESET
riempie solo lo schermo con un pattern pressoché inutile, mentre il led
del floppy (rosso) lampeggia e s'ode un click.

>> I have a family and a full time job, but still have time to get
much hours of Amiga hacking a day :-)  <<< 
 
 


Il "Terry's exercise"... che, IIRC, non ci sta nel firmware //c..
 
aspettiamo il parere dell' esperto (Giorgio Morocutti)
 
Saluti,
dott. Piergiorgio.
 
 

 c'è, e nel caso ci sia come si dovrebbe attivare la cpu Z80?
 
Ecco, il mio è tedesco (almeno così sembra osservando la tastiera), e la scheda 
Z80 sembra proprio "third party".
Che io sappia, lo Z80 si attivava automaticamente inserendo un floppy
contenente il CP/M ed effettuando il boot...


 
 
Dovrebbe essere un pattern a scacchiera dinamico, della 
durata di circa un minuto prima dei risultati. Se non c'è 
hai 3 alternative:
 
1) Brucia una EPROM col firmware aggiornato e sostituisci la 
vecchia ROM. In genere sono zoccolate.
 
2) Se puoi far girare programmi, fatti un dischetto con XPS 
Diagnostics e lancia il test RAM.
 
3) Guardati la mappa di memoria e scrivi un semplice 
programmino BASIC che fa POKE e PEEK ad ogni locazione non 
critica, per vedere se rilevi qualche discrepanza. Dal 
confronto dei byte dovresti poter risalire ad una eventuale 
RAM farlocca.
 
*Gabriele*
 

 *Gabriele*
 


Bene, ho sbagliato :(
Le eprom erano coperte dalla scheda Z80: sono zoccolate...
 
Costruito il cavo seriale adatto, ho provato il trasferimento con ADTpro.
 
Tutto sembra in ordine, o quasi...
 
ProDOS si scarica, ADT anche. Spediboot (con la nuova versione di ADTpro) 
funziona, il disco virtuale no, il IIc si blocca ed è necessario spegnerlo.
Però mi sembra d'aver letto che il disco virtuale funzioni solo sul II e sul
///, non è chiaro per il IIc.
 
Dov'è il vero problema?
Se tento di formattare un floppy, per verificare se, per caso, il drive
fosse solo(?) disallineato, ADTpro non rileva alcun drive!
La lista degli slot è desolantemente vuota, neanche lo slot RAM.
Se effettuo il rescan, il led rosso si accende, il motore gira per qualche
secondo, ma nulla è rilevato.
A disco inserito, non formattato, avrebbe dovuto visualizzare
SLOT 6        I/O ERROR
Invece nulla.
 
Fra l'altro, premendo Q per terminare ADTpro, lo schermo si riempie di
caratteri casuali (il contenuto della memoria) in rapido scorrimento.
È necessario spegnere.
 
Certo che senza un diagnostico per la ram la vedo dura, escluderla.
Avessi un cavo per collegare il Disk ][, potrei provare e vedere se sia
un problema di drive o di logica interna.
 
E quel maledetto drive Apple non genera neanche l'index pulse, da controllare
con l'oscilloscopio.
Ci sono dei test points sul PCB del drive, ma a che corrisponderanno????


per la ram, io proverei a controllare un po' di locazioni (aiutandosi con una mappa di indirizzamento del IIc) tramite il monitor LM interno: call -151 dal prompt ].
I comandi del monitor dovrei andarmeli a riguardare, ma penso si trovino in rete.
Puoi inserire dei programmini in LM 6502 per fare check di blocchi interi di memoria, per aiuti con il linguaggio macchina 6502 mi puoi scrivere privatamente.
 
F


 
Buona idea, potrebbe fare un loop per riempire la RAM con 0x55 e poi 
fare il dump a video con il comando del monitor, così vede subito se c'è 
qualche locazione farlocca. Poi ripetere con 0xAA.
 
*Gabriele*
 


beh magari qualcosa di un po' piu' elaborato con mappa di memoria alla mano.
Se inizi a sovrascrivere la pagina 0 e la pagina 1 (che e' lo stack), non ne esci. Per non parlare di quando arrivi a sovrascriverti il tuo stesso programma :-)
 
Anche sovrascrivere a tappeto la ram video non e' il massimo. 
Inoltre se si volesse provare la RAM bank switched bisognerebbe testarne un banco alla volta e scambiare i banchi (che non ricordo come si fa, ma si fa).
Io pensavo a qualcosa che faccia read - replace - read - compare - restore, in modo da lasciare quello che c'era prima, se fra replace e read le cose non tornano, si puo' scrivere a video la locazione incriminata. Con le subroutine interne e' facile scrivere a video da linguaggio macchina.
Comunque con il monitor dell'apple II si fanno gia' parecchie cose volendo, basta avere un minimo di documentazione alla mano.
 
F

 se fra replace e read le cose non tornano, si puo' scrivere a video la locazione incriminata.
 
Si, intendi il contenuto (l'indirizzo non è importante), oppure
lo può lasciare in una locazione buona e lo recupera col 
monitor.
 
*Gabriele*
 
 
 

 monitor.
 
anche... ma visto che i caratteri li legge, puo' farsi anche stampare eventuali errori. 
Penso comunque che fara' prima con la diagnostica :-)
 
F

> *Gabriele*
 
Io qualche tempo fa ho scritto questo pgm (+o-, a memoria, perche' l'ho 
scritto senza poterlo salvare) e sono riuscito a trovare un chip di RAM 
guasto in un Apple //e
 
10 FOR I=16384 TO 49151
20 POKE I,0: IF PEEK(I)<>0 PRINT “ERR LOC ”;I;” 0—>”;PEEK(I)
30 POKE I,255: IF PEEK(I)<>255 PRINT “ERR LOC ”;I;” 255—>”;PEEK(I)
40 NEXT
 
Attenzione che ci mette un bel po’, tipo 10-15 minuti. Ogni tanto puoi 
bloccarlo con CTRL-C, fare “PRINT I” per vedere dove e' arrivato e poi 
riprendere con “CONT”.
Se c'e' un chip guasto, guardando gli errori noterai che sbaglia sempre lo 
stesso bit.
Ho usato quel range perche' sospettavo la memoria alta in quanto non 
funzionava il DOS. Puoi partire da parecchio piu' basso, poco oltre l'inizio 
dell'area programmi basic, non mi ricordo piu' se e' $800 o $1000; se 
sovrascrivi il programma te ne accorgi subito :). Se vuoi provare memoria 
della "language card" devi ingegnarti...
 
Ciao,
 
-- RoV - IW3IPD
http://digilander.libero.it/rvise
 
 

Ho scritto un miniprogrammino in Basic, giusto per
dar un'occhiata alla RAM.
Ho utilizzato il range propostomi (16k-49151).
A mie spese ho scoperto che oltre i 49151 si sovrascrive il programma in Basic :)
Ho utilizzato, come patterns, 0x0, 0xFF, 0x55 e 0xAA
Ci sono errori sempre nelle stesse locazioni di memoria e sempre nel MSB
Gli errori sono (good, bad):
 
(255,127) (0xFF,0x7F)
(0,128)   (0x00,0x80)
(85,213)  (0x55,0xD5)
(170,42)  (0xAA,0x2A)
 
In alcune locazioni c'è un doppio errore: impostando l'MSB a 0, si legge 1, 
impostandolo a 1 si legge 0.
 
Ora, nel IIc ci sono due banchi da 64k, uno identificato come ADRx,
l'altro come MDRx.
Quale sarà il primo?


esegui il test e controlla con l'oscilloscopio l'attivita' dei segnali RAS/CAS sui chip... quelli che sta testando dovrebbero essere selezionati in continuazione. Inoltre se imposti come valore di prova 0x80 (128 decimale), trovi subito il chip incriminato perche' e' l'unico il cui pin di dati va ad un valore diverso dagli altri.
Di che ram si tratta? Mi pare strano il fatto che alcune volte fallisca 0 per 1 e altre 1 per 0. Forse sono di quei chip con uscita negata rispetto all'ingresso.
 
 
F
 


mi rispondo da solo, si tratta di MCM6664, D e Q collegati insieme (data in/out).
Se provi usando il valore di prova 128 trovi il chip da cambiare anche con il multimetro (ram/cas si muovono, piu' dato fisso a 5V).
 
F
 

On Friday, January 31, 2014 1:23:47 PM UTC+1, Apple_Tester wrote:

mi ririspondo da solo... si tratta di UF12 e lo puoi sostituire con un qualunque 4164/8264 di pari velocita' (o piu' veloce). Il piedino /REFRESH delle 6664 non pare utilizzato sul IIc, risulta collegato a +5V.
Ovviamente le verifiche che suggerivo conviene farle lo stesso per sicurezza.
Ah, ovviamente c'e' anche la possibilita' che la linea D7 del 65C02 sia difettosa o che altri integrati sul bus la pilotino quando (o come) non devono (ma la probabilita' che sia la dram e' molto piu' elevata).
F

Il fatto che sia il bit 7 (o 8, dipende se iniziamo da 0 o da 1), in ogni caso
l'MSB, è coerente con il problema video da me riscontrato, cioè la
comparsa del reverse video. Di solito è proprio l'MSB a cambiare il background...
 
Ho utilizzato un metodo semplicissimo, anche se l'oscilloscopio era lì
pronto :)
 
Ho montato un chip 4164 (gli originali sono proprio così, anche se marchiati
4464) a cavallo prima di ADR7 (e non è cambiato nulla) e poi a cavallo di
MDR7 (il banco più vicino alla CPU).
Bene, è sparito il problema del reverse video, ed il test della ram 
non riscontra errori, ora.
 
Non mi resta che rimontare il floppy e far la prova...

 Non mi resta che rimontare il floppy e far la prova...
Il problema video è sparito, ma il floppy continua a non leggere.
Però con l'oscilloscopio, controllando qualche test point (su cui
non ho informazioni) ho trovato dei segnali sensati lato floppy drive. Sospetto
qualcosa lato controller.
 


peccato, sarebbe stato bello risolvere con poco...
Per il floppy bisognerebbe trovare un po' di documentazione. Senno' si potrebbero confrontare i segnali con un IIc funzionante. Se non hai fretta, potrei mettere sotto i ferri il mio, ma se non hai davvero fretta...
 
F

 F
 
Adesso il ram test non presenta problemi.
Il disco calibra e richiama le testine se le allontano, e mentre cerca la traccia
0, visualizzo un pattern plausibile sull'oscilloscopio.
Adesso riesumo un paio di Disk ][ e vedo di collegarli, in maniera da
restringere il campo...
Poi devo sempre dissaldare il chip e zoccolarlo, per il momento andiamo a... 
cavallo :P

Buone e cattive notizie, per i più curiosi...
Ho preso un Disk ][ ed un Apple IIe.
Ho verificato che l'interfaccia del Disk ][ fosse la stessa del disco interno
del IIc (in effetti, oltre il connettore identico, le schede montano
gli stessi componenti) ed ho collegato il Disk ][ internamente al IIc.
Ho ottenuto il messaggio "CHECK DISK DRIVE".
Bene, un cambiamento c'era, ma i dischi non erano letti.
Ma come, li ho scritti con quel drive...
Ricollego il Disk ][ al IIe, niente da fare.
Si accende la lampadine: provo alcuni dischi non provati in questi giorni,
si leggono sul IIe.
Collego il Disk ][ al IIc, e si leggono anche lì. Il boot del ProDos
avviene regolarmente.
Questo esclude il controller interno del IIc.
Ho già capito cosa sta succedendo, ma voglio una conferma.
Formatto un disco con il Disk ][ sul IIe (ho una CF con molti programmi,
nel IIe) e provo ad inserirlo nel lettore originale del IIc.
Lo reinserisco nel IIe, non si legge più.
 
Quando si effettua un accesso al disco nel lettore del IIc, i dati sul
disco sono danneggiati.
 
Una cosa, però, non mi è ancora chiara.
Se collego il disco del IIc al IIe, l'accesso al disco fa muovere le testine 
verso la traccia $11 e lì si fermano: il disco è, al solito, illeggibile.
Se è collegato al IIc, tale movimento non è evidente, 
ma il risultato è lo stesso (nel senso che le testine mostrano una rapida
oscillazione, fermandosi di nuovo in traccia 0)
 
Il tentativo di formattare un disco nel lettore del IIc collegato al IIe 
fallisce, TRACK 00 ERROR.
 
Mi sembra di poter affermare che il disco interno al IIc sia in gravi
condizioni e che la gestione del lettore da parte del IIc e del IIe
sia leggermente diversa.
 
Il fatto che il Disk ][ collegato al IIc funzioni, invece, mi assicura
che il IIc, a parte il chip di ram, è in discreta salute.
 
Se non riuscirò a riparare il floppy drive interno, l'alternativa sarà quella 
di reperire un cavo adattatore per collegare esternamente il Disk ][ al IIc.
Già visto, una decina d'euro.

Dimenticavo: con tutti i tentativi che ho fatto, il disco interno del IIc
m'ha danneggiato una decina di dischi (copie, non originali), e mi toccherà
ricrearli con ADT :(

 
 
Il floppy risulta danneggiato permanentemente o se lo riformatti torna come nuovo?
Non ci sono molte possibilita' di guasti su una meccanica, o la testina danneggia fisicamente il floppy oppure c'e' un residuo magnetizzato sulla testina stessa. 
Ho appena aperto un disk ][, non c'e' molto che si puo' guastare ma non ho idea se l'elettronica del drive interno del IIc sia uguale (il IIc e' molto piu' sepolto, al limite lo cerco nel pomeriggio).
Se l'elettronica fosse simile e il disco non e' danneggiato fisicamente e non ci sono residui magnetizzati sulla testina, io cambiarei il CA3146 :-)
Se trovo uno schema del drive interno del IIc o se piu' tardi apro il IIc vedo di dare un suggerimento migliore.
 
F


e anche il 74LS125.
 
F

No, niente danni fisici: basta riformattare.
L'elettronica è identica a quella del IIc, cambia solo leggermente
la posizione dei componenti, data la diversa dimensione dei lettori.
 
In altre parole scrive quando legge, e scrive dove gli pare :P


proverei la sostituzione dei due integrati che ho menzionato prima, sul disk ][ che ho aperto erano tutti zoccolati, quindi non dovrebbe essere difficile fare un paio di prove.
Immagino che tu l'abbia gia' fatto, ma A) pulisci benissimo la testina e B) prova a fare un giro di prova con il connettore della testina magnetica staccato e vedi se il disco si corrompe lo stesso.
 
F

 Quale sarà il primo?
 
M = Main Memory
A = Auxiliary Memory.
 
Poiché (fissato il banco) ogni chip controlla un bit di ogni byte, nel 
tuo caso è l'ottavo integrato del banco, ovvero quello che controlla il 
bit più alto.
 
Se hai intenzione di mettere uno zoccolo, assicurati che sia a basso 
profilo (il più basso che riesci a trovare) o avrai una bella sorpresa 
al momento di richiudere il IIc...
 
*Gabriele*

 F
 
Eh, li devo dissaldare... sono zoccolati sul ][, saldati sul disco interno del
IIc.
 
Il disco è corrotto solo se il connettore della testina è inserito.
 
Ho fatto poche prove, perché ho ripristinato i dischi danneggiati, con ADT.
Poi ho provato il IIc con un diagnostico (tutto in ordine) e verificato i dischi
rovinati con CopyIIPlus. 
Solo la traccia 0 risulta danneggiata (praticamente bulkerased...)
Penso che lunedì riuscirò a dissaldare i due integrati...


prima prova con il multimetro i due diodi che collegano la testina al ca3146.
 
F

Grazie ai preziosi suggerimenti di Francesco, il drive del IIc
è finalmente sistemato!
Il guasto era proprio l'SN74LS125...

 Il guasto era proprio l'SN74LS125...
 
Curiosità: nella mia semi-ignoranza elettronica sbaglio, o è il classico componente da due lire (anche all'epoca)?
 
 
m.

 m.
 
Sì... difatti nel cassetto dei recuperi ne avevo una decina...