La prima scheda acceleratrice GVP G-Force Combo 030 50 MHz “full GAL” al mondo
[World’s first full GALs GVP G-Force Combo 030 50 MHz accelerator card]
Fin dal lontano 1990 io e i miei amici amighisti non eravamo “nella media” degli utenti Amiga: la passione per la grafica 3D ci aveva travolto in pieno con programmi come Sculpt-Animate 4D, TurboSilver, Imagine e, più tardi, Real 3D e LightWave 3D.
Va da sé che la bramosia di velocità nel calcolo era all’ordine del giorno: il povero 68000 nudo e crudo arrancava… notti intere passate con l’Amiga acceso e la mattina, al risveglio, il primo pensiero non era la scuola: era quello d’accendere il 1084S e vedere “se aveva finito”!
Al fine di potenziare il mio Amiga 2000 il primo passo fu quello d’acquistare, intorno al 1991, una scheda acceleratrice, si trattava di un prodotto italiano: Hardital Big Bang.
Montava un 68030+68882 a 25 MHz e 2 Megabyte di RAM.
L’accelerazione era davvero notevole, ma buona parte del sistema (espansione RAM SupraRAM 2000 e controller HD Commodore A2090A) rimaneva a 16 bit stretta nel collo di bottiglia del bus Zorro II.
Venduta la Big Bang ad un amico (Andrea!), convinsi mio padre, fortunatamente appassionato di tecnologia anche lui, a spendere una fortuna per acquistare una splendida scheda acceleratrice GVP G-Force Combo 030 clockata a ben 50 MHz… praticamente un missile all’epoca (1992)!
Questa scheda ha potenziato il mio Amiga 2000 in tutti questi anni ed è in uso ancora oggi.
Caratteristiche:
- CPU 68030 a 50 MHz, PGA
- FPU 68882 a 50 MHz, PGA
- 4 Megabyte 32-bit Fast RAM saldati on-board
- 3 SIMM sockets (supportano solo moduli SIMM a 64 pin proprietari GVP da 1 o 4 Megabyte)
- controller SCSI-II con chip 33C93A a 14 MHz, connettore SCSI interno 50 pin ed esterno DB25
- 32 bit expansion bus proprietario per la potente scheda grafica GVP EGS 110/24 (un sogno, introvabile!)
Ulteriori info:
http://amiga.resource.cx/exp/gforce2030
https://bigbookofamigahardware.com/bboah/Product.aspx?id=178
Ammiratela in tutto il suo splendore originale, completa di 3 SIMM GVP da 4 Megabyte ciascuna (RAM totale 16 Megabyte):
Il disco SCSI IBM è attaccato alla “schiena” della scheda
(è proprio il disco originale che usavo all’epoca, funziona ancora!)
Completa di Guru-ROM per prestazioni SCSI da paura!
Le schermate di Sysinfo non lasciano dubbi sulla potenza del prodotto, guardate soprattutto le performance del disco SCSI: quasi 4 Megabyte al secondo nel 1992!
Smell the Rubber? 🙂
L’Amiga 2000 così potenziato è stato il mio computer principale d’uso quotidiano fino al 2000-2001: oltre alla grafica 3D navigavo su Internet, gestivo la posta elettronica, masterizzavo audio CD e compilation di MP3, ecc…
Poi, per circa 15 anni, è rimasto inutilizzato nella mia cameretta a casa dei miei, ma in questi ultimi anni, col “ritorno di fiamma” della passione per il retrocomputing, l’ho riscoperto e sto cercando di restaurarlo/conservarlo al meglio.
Durante alcuni severi test di lettura/scrittura su HD mi sono accorto che alcuni file risultavano corrotti (copie non fedeli al 100% del file d’origine):
Ho cominciato ad indagare per capire quale potesse essere la fonte del problema.
Il primo indiziato è stato il disco fisso: ne ho messo un altro (grazie Matte!) ma il problema persisteva identico.
Provando e riprovando ho notato che gli erorri erano assenti a sistema appena acceso (da freddo) ma si presentavano sempre più numerosi via via che passavano i minuti.
Di conseguenza, ho pensato potesse essere un problema di surriscaldamento: su questa scheda ci sono 8 PAL che diventano bollenti, si fa fatica ad appoggiarci sopra i polpastrelli!
La prima azione che ho pensato di fare è stata quella di migliorare il flusso d’aria che raffredda la scheda: le 8 PAL si trovano vicine al fianco dell’alimentatore dell’A2000, fianco che è privo di asole per il passaggio d’aria (le asole sono presenti soltanto sul lato frontale).
Non è proprio la posizione migliore per una buona dissipazione del calore…
Mi sono quindi trasformato in un fresatore 😀 ed ho fresato 38 asole sul fianco dell’alimentatore rivolto verso la scheda acceleratrice; inoltre, per mantenere un flusso d’aria veloce, ho parzializzato le asole originali incollando un lamierino all’interno dell’alimentatore stesso.
Ora l’aria passa anche lateralmente!
Infine, ho applicato un dissipatore di alluminio su ciascuna PAL:
I successivi test di lettura/scrittura su HD hanno mostrato un notevole miglioramento, gli errori erano pochissimi, ma qualche errorino rimaneva… non potevo accettarlo… 😉
La convinzione che il problema potesse essere il risultato di anni di forte surriscaldamento di queste benedette PAL mi ha spinto a cercare una strada per sostituirle.
Ma come fare?
Parallelamente, l’amico Nicola stava sperimentando la lettura di alcune PAL e la loro sostituzione con GAL (chip più moderni) programmate in modo da risultare perfettamente compatibili.
Le GAL sono chip più performanti e non scaldano come le PAL.
Avete capito, ora il nostro comune obiettivo sfidante era chiaro: dovevamo in tutti i modi riuscire a sostituire le 8 PAL con 8 GAL! 😀
Il primo problema da risolvere era ovviamente quello di reperire il codice con cui gli ingegneri della GVP avevano programmato le 8 PAL: sul web non si trovava nulla di nulla!
Abbiamo quindi tentato di leggere il codice delle PAL, ma tutte 8 sono risultate protette… delusione totale!!!
A questo punto, incredibilmente, il destino si è fatto vivo: Nicola ha trovato ed acquistato (fra l’altro a Rubiera, di fianco a casa!) una rara scheda praticamente IDENTICA alla mia, eccola qua:
Era un chiaro segnale che non dovevamo per nessun motivo mollare, anzi: dovevamo puntare ancora più dritti verso il nostro obiettivo! 😀
Infatti, incredibilmente, la lettura delle 8 PAL della scheda di Nicola ha avuto pieno successo, nemmeno una è risultata protetta! Questa cosa ci ha davvero sorpreso, mai ce lo saremmo aspettato.
Le PAL presenti sulla mia scheda (REV 3 – 1.02) sono:
- U34-74F4 AMD PAL20L8-5PC
- U35-5F54 MMI PAL16L8DCN
- U36-90C6 TI TIBPAL20R6-7CNT
- U37-4D7B AMD PAL16L8-5PC
- U38-38CC AMD PAL16L8-5PC
- U39-F029 AMD PAL20L8-7PC
- U40-B520 AMD PAL16L8-5PC
- U53-A2B1 AMD PAL20L8-7PC
Le PAL presenti sulla scheda di Nicola (REV 3 – 1.03) sono:
- U34-74F4 TI TIBPAL20L8-5CNT
- U35-5F54 MMI PAL16L8DCN
- U36-90C6 AMD PAL20R6-7PC
- U37-4D7B AMD PAL16L8-5PC
- U38-38CC AMD PAL16L8-5PC
- U39-F029 AMD PAL20L8-7PC
- U40-B520 AMD PAL16L8-5PC
- U53-A2B1 AMD PAL20L8-7PC
Si tratta, sostanzialmente, di 2 set di PAL identici: tutti i checksum coincidono!
Bene, eravamo finalmente in possesso dei file JED contenenti le programmazioni delle 8 PAL, ed era già un bel risultato perché, in caso di rottura, avremmo avuto la possibilità di ricreare una PAL sostitutiva.
Ma il nostro obiettivo, come detto, era di creare un set di 8 GAL sostitutive.
Nicola, ormai esperto dopo aver smanettato per giorni con diversi software, è riuscito a convertire i file JED delle PAL in 8 file GJD pronti per programmare 8 GAL.
[segue]
>>> APPROFONDIMENTO: CONVERSIONE PAL ==> GAL
Per trasformare una PAL in GAL si parte da una copia del JED, la “Fuse Map” della PAL, poi con un semplice programma di conversione a riga di comando si trasforma in una Fuse Map compatibile con la programmazione di una GAL.
Le GAL che utilizziamo per rimpiazzare le vecchie PAL, anche se di generazione successiva rispetto a quest’ultime, sono comunque una tecnologia vecchia di anni e ormai sorpassata, ora rimpiazzata dalle moderne FPGA.
Comunque in rete si possono trovare ancora due programmi, uno della Lattice PALTOGAL e uno della National PAL2GAL.
Entrambi validi e compatibili con MSDOS. È possibile comunque utilizzarli su un sistema moderno in emulazione DosBox.
Prima di mostrare come fare la conversione è bene precisare che le funzionalità delle diverse tipologie di PAL possono essere riprodotte su una sola tipologia di GAL: infatti, quest’ultime si possono configurare sia in modalità puramente combinatoria che “registered” (R).
Questo vuol dire che con una GAL16V8 o GAL20V8 possiamo programmare PAL16 L4 L6 L8 R4 o PAL20 L4 L6 L8 R4 R6 ecc…
Utilizzare PALTOGAL della Lattice è molto semplice, si possono specificare i parametri sulla riga di comando oppure eseguirlo in modalità interattiva e fornire una alla volta le informazioni necessarie.
I parametri sono tre: il file JED di input che contiene la Fuse Map della PAL, il file di output ed il numero corrispondente alla conversione che vogliamo fare.
Esempio:
paltogal.exe PAL16L8.JED GAL16V8.GJD -c 2
L’estensione GJD sul file di output non è importante, serve soltanto per identificare la tipologia del JED (GAL JED); più importante è indicare il numero di conversione adatto secondo il seguente elenco da 1 a 64:
È bene notare che questa tipologia di conversione è una “traduzione” della mappa di bit della Fuse Map: le equazioni non vengono estrapolate, l’ordine dei fattori non viene toccato e non viene eseguito nessun tipo di semplificazione.
Questo nella maggior parte dei casi può andare benissimo ma come abbiamo visto può essere necessario ottimizzare ulteriormente la programmazione con tool come WinCupl o OPALJR. Ma questa è materia per un altro articolo…
Le GAL sono state scelte come da elenco seguente:
- U34-74F4 LATTICE GAL20V8B 15LP
- U35-5F54 LATTICE GAL16V8D 15LP
- U36-90C6 ATMEL ATF20V8B-15PC
- U37-4D7B LATTICE GAL16V8D 15LP
- U38-38CC LATTICE GAL16V8D 15LP
- U39-F029 LATTICE GAL20V8B 15LP
- U40-B520 LATTICE GAL16V8D 15LP
- U53-A2B1 LATTICE GAL20V8B 15LP
NOTA per U36: utilizzando una LATTICE GAL20V8B 15LP per U36 l’acceleratrice è risultata un po’ più lenta e si sono ripresentati numerosissimi errori di scrittura su HD, invece una ATMEL ATF20V8B-15PC si è dimostrata compatibile al 100%.
Scaricate qui il set completo di file GJD pronti per programmare le 8 GAL:
[Here you can download a complete set of GJD files ready to program the 8 GALs:]
NOTA BENE: questo set è applicabile soltanto alla G-Force 030 a 50 MHz!
[PLEASE NOTE: this set is only applicable to the G-Force 030 @ 50MHz!]
[segue]
>>> APPROFONDIMENTO: COME SI COMPORTA LA SCHEDA PRIVANDOLA DELLE PAL?
A mano a mano che sostituivo le PAL con le GAL ho provato a vedere, una ad una, come si comportava il sistema privo della PAL (zoccolo vuoto).
Di seguito elenco tutte le prove che ho fatto.
U34 zoccolo vuoto: il sistema non vede più la RAM montata sulla scheda.
U35 zoccolo vuoto: inizialmente non ho riscontrato alcuna differenza.
Ho letto che U35 è coinvolto nell’Autoconfig della memoria.
Questa scheda può configurare la sua RAM in 2 modi settando il jumper J12:
– J12 CHIUSO: i primi 8 Megabyte nello spazio Autoconfig e gli altri 8 estesi
– J12 APERTO: tutti i 16 Megabyte estesi
La mia scheda è sempre stata configurata con tutti i 16 Megabyte estesi, ecco perchè non ho notato alcuna differenza lasciando vuoto lo zoccolo di U35.
Col jumper J12 aperto (tutta la RAM estesa), la presenza o meno di U35 nello zoccolo, come detto, non comporta evidenti differenze (Sysinfo vede la sola acceleratrice e 16 Megabyte estesi):
Chiudendo il jumper J12 la differenza invece diventa tangibile.
U35 nello zoccolo (J12 CHIUSO): Sysinfo elenca una scheda di memoria (virtuale) in più, si tratta degli 8 Megabyte nello spazio Autoconfig.
Questo è confermato anche dalle successive due schermate d’informazioni sulla memoria:
U35 zoccolo vuoto (J12 CHIUSO): la scheda di memoria (virtuale) Autoconfig da 8 Megabyte sparisce e rimangono soltanto 8 Megabyte di RAM estesa.
Le schermate di Sysinfo lo confermano:
U36 zoccolo vuoto: il sistema non parte, schermo nero.
U37 zoccolo vuoto: il sistema non vede più la RAM montata sulla scheda.
U38 zoccolo vuoto: il sistema non parte, il led di power passa da bassa ad alta luminosità.
U39 zoccolo vuoto: il sistema non parte, schermo nero.
U40 zoccolo vuoto: il sistema diventa lento (~50%) e dà errori al boot.
U53 zoccolo vuoto: il sistema parte ma va in GURU ad ogni boot (errori: 8000 0003, 8000 0004 e 8000 000A).
Ed ecco la scheda acceleratrice nella sua nuova veste “full GAL”: obiettivo raggiunto il 24/10/2020! 😀
Le alte temperature delle PAL sono soltanto un ricordo: le 8 GAL rimangono praticamente fredde anche molto tempo dopo l’accensione! 😉
Ed una decina d’ore di file test continuo senza alcun errore dimostra che i problemi di scrittura sono stati finalmente risolti:
Beh, alla fine devo proprio dire che è stata un’avventura lunga ma divertente, molto emozionante… e la soddisfazione di esserci riusciti è unica, vero Nicola? 😀
Che meraviglia!
Scaricate qui il set completo di file GJD pronti per programmare le 8 GAL:
[Here you can download a complete set of GJD files ready to program the 8 GALs:]
NOTA BENE: questo set è applicabile soltanto alla G-Force 030 a 50 MHz!
[PLEASE NOTE: this set is only applicable to the G-Force 030 @ 50MHz!]
Amazing work! Could you dump U7 at some point? That’s the only PAL missing – and the one I think is faulty on my card =/
Regards
Chris
Hello GadgetUK164,
I am very happy that you liked the article and thanks for your compliments!
I’m sorry but, at least for the moment, I don’t think I will desolder U7 to attempt a reading, especially since, probably, it will also be protected …
U6 (MACH130) is also a chip that has been programmed but its code isn’t on the web.
However, I agree with you: you should also be able to find / get the programming files of U6 and U7 … maybe trying to read those of a broken board, in order not to risk breaking a working one …
If you have any news on this subject please let me know as soon as possible!
Thank you so much.
Luca B
Buongiorno Luca. Ho la versione EC della tua stessa scheda (quindi che gira a 40MhZ e, suppongo, anche senza MMU). Nello specifico è la GVP A2000-030 EC COMBO Rev. 4. Nel mio caso avrei intenzione di usarla in combinazione con un controller ZuluSCSI e scheda SD (l’hard disk quantum originale, ahimè, non funziona più. Anche io ho notato che le pal scaldano maledettamente. Come mi suggeriresti di operare? In più vorrei anche cambiare cpu e fpu e portarlo a 50 MhZ (praticamente come la tua). Me lo consigli? Grazie
Ciao Giuseppe,
innanzitutto grazie per l’interesse dimostrato al mio articolo: fa sempre piacere condividere le nostre passioni!
Confermo che la tua scheda, avendo una CPU 68EC030, è priva di MMU.
Tuttavia, da quello che so, è dotata di una logica che permette comunque d’eseguire il “FASTROM”, ovvero la copia del Kickstart nella veloce RAM a 32 bit della scheda per poi proteggerla (un’operazione che normalmente è possibile solo con una CPU dotata di MMU). Se hai almeno 4 MB di RAM sulla GVP ti consiglio di mettere il comando “gvpcpuctrl FASTROM” nella tua startup-sequence per avere le prestazioni migliori.
Detto questo, ti chiedo: utilizzando la tua scheda GVP si verificano errori di lettura/scrittura su HD? Hai fatto dei test severi per stabilire l’affidabilità dell’interfaccia SCSI? Ti sarei grato se lo facessi e riportassi qui i tuoi risultati.
Comunque, per creare un set di 8 GAL che possano rimpiazzare pari pari le tue 8 PAL, credo che tu non possa usare tutti i file che ho postato nell’articolo, perché la tua scheda è a 40 MHz e qualche tua PAL avrà un checksum differente (almeno U36 da quanto so, ma forse anche altre).
Sarebbe molto utile se tu pubblicassi l’elenco delle tue 8 PAL scrivendo anche il checksum di ciascuna (il checksum è costituito dagli ultimi 4 caratteri incisi sulla PAL o presenti in una etichetta attaccata sopra alla PAL.
Conoscendo gli 8 checksum delle tue PAL posso provare a cercarti le fuse map e, se le trovo, posso provare a convertirtele in file GJD creando così un pacchetto di file per GAL adatto alla tua scheda.
Hai poi la possibilità di programmarti le GAL?
Fammi sapere, grazie!
Ti aggiorno un po sulle novità, dal momento che ho dovuto aspettare che mi arrivassero alcuni pezzi. Dunque ho installato un controller zuluscsi che ho connesso alla 030 EC COMBO V4. Installato AmigaOS 3.2.1 e tutto sembra funzionare alla perfezione. Per quanto riguarda le PAL le mie hanno codici identici alle tue con l’eccezione di U36 che risulta essere 90C4. Ho però il seguente problema: ho sostituito l’oscillatore con uno a 50 Mhz, messo una CPU MC68030RC50B ed una FPU MC68882RC50A. Solo che il sistema presenta adesso delle instabilità. In caso di passaggio da PAL a GAL pensi che dovrei sostituire la U36 con il file del tuo set? Nell’eventualità ho un programmatore di EPROM (https://amzn.eu/d/bBVhDch). La configurazione dei jumper sulla mia scheda pare essere identica a quella in questa foto: https://bigbookofamigahardware.com/bboah/media/download_photos/gforce030_3_big.jpg
Ciao Giuseppe, grazie per i tuoi interessanti aggiornamenti e scusa per il mio ritardo.
Da quello che ho visto, sul Web si trovano molte più foto di schede col checksum di U36 a 90C4 rispetto a 90C6.
Non so se programmando una GAL col codice che trovi nell’articolo risolvi i tuoi problemi di stabilità, ma una prova andrebbe fatta.
Se vuoi tentare ricorda che occorre utilizzare una GAL esattamente di questo tipo: ATMEL ATF20V8B-15PC (con altre marche, per es. Lattice, ho riscontrato delle instabilità).
Per quanto riguarda i jumper, se noti differenze prova a settarli come da foto della mia scheda presenti nell’articolo o, meglio ancora, come da foto della scheda dell’amico Nicola (sempre nell’articolo) e fai delle prove.
Se non ricordo male, nel manuale dell’acceleratrice c’è l’elenco dei jumper con descrizione e settaggi di default in base alla versione della scheda.
Tienici aggiornati!
Ciao il problema è che non avrei proprio modo ne le conoscenze di riprogrammare le GAL. Se potessi aiutarmi in questo (anche previo compenso) te ne sarei grato. In più gli errori che riporto sono di tipo 8000 0003, 8000 0004 e 8000 000A. Non vorrei che a danneggiarsi fosse proprio la U53 come nel tuo caso…
Purtroppo non ho più la possibilità di programmare le GAL. Ma se cerchi sul web dovresti trovare qualcuno che ti fa il favore.
In alternativa, se sei pratico di elettronica, potresti autocostruirti questo programmatore:
ELM – Simple GAL Programmer
Ovvio che se non si è skillati in elettronica è dura autocostruirsi una roba del genere…
Dai non mollare!!!! Fammi sapere le news.
Ciao, hai poi risolto in qualche modo? Sarei interessato anche io…
Domanda per l’autore di questo stupendo articolo:
Potrebbe cortesemente indicarmi se il disco montato è terminato o meno? Questa scheda è un pò strana per quanto riguarda le terminazioni scsi…
Grazie.
Ciao Nikoh,
grazie dei complimenti e dell’interesse dimostrato per il mio articolo, fa sempre piacere! 🙂
Dalle varie foto la catena SCSI interna non si vede chiaramente, comunque te la descrivo.
Il cavo SCSI 50 pin parte dalla GVP, arriva all’HD IBM fissato sulla scheda stessa e poi procede fino al lettore CD-ROM SCSI (qui finisce).
Il controller SCSI della GVP (che ha ID 7) ha la terminazione SCSI sempre in funzione, poiché le resistenze che la governano sono saldate (dovrebbero essere le reti resistive gialle RP14 e RP15 visibili nelle foto, si trovano sotto al connettore SCSI 50 pin).
Il disco SCSI IBM ha la terminazione disattivata in quanto si trova a metà della catena interna, mentre la terminazione è attiva sul lettore CD-ROM, che è l’ultima unità della catena interna.
Detto questo, io attacco spesso anche dischi fissi SCSI esterni sul connettore DB25 della GVP.
In questi casi, teoricamente, la terminazione presente sul controller andrebbe disattivata: per fare questo occorrerebbe dissaldare le reti resistive che costituiscono la terminazione passiva del controller, tuttavia non l’ho mai fatto e le periferiche SCSI esterne funzionano ugualmente, grossi problemi non li ho mai avuti.
Hallo.
I wanted to programm my new GALs with the TL866II, but the program is asking for JED instead of GJD file format. Would it be possible that you also share the JED versions?
Thank you, René
Hallo René,
I think it can work just by changing the extension from GJD to JED.
Try it and let me know if the files are processed this way.
Also, don’t forget to let me know if your GVP card will work with the new GALs!!! 🙂
Thanks
I changed the filenamen and it looks okay. I was able to write it to the chip.
But there are several topics on my side. First of all I do not have the card you are describing, but a GVP A530 board. I know that U36 is broken for sure, because I only get zeros when reading. The other chips come with ones so they are protected and cannot be read. Nevertheless the checksum of U36 is identical to your U36 checksum so I am hoping that this might work.
After creating the chip the problem I am facing now is that I see only a red screen (the color is a little differnt to the Amiga red screen) or when I put the switch to no turbo a green screen (also not the same color as the Amiga green screen) I am not sure what might be the problem, but the Amiga 500 is changed to 1MB chip mem maybe this also interferes. When I remove the A530 the Amiga starts up with no problem.
It’s not easy to understand what the problem is…
Can you post here the list of checksums of all your 8 PALs?
I’m curious to know how many checksums match mine.
Keep in mind that the problem could also be in the big MACH130 chip, I heard that in some GVP accelerators this chip has failed.
Some ideas:
– to recreate U36 did you use an ATMEL GAL type ATF20V8B-15PC exactly? it’s important for correct operation!
– you could also try to program new GALs of all the other PALs that have a corresponding checksum… it’s an attempt.
Good luck, René!
Actually the only PAL with the same checksum is U36. All others are having different checksums:
U34: 751E
U35: 63D1
U36: 90C6 (identical checksum)
U37: 3789
U38: 429F
U39: F9FC
U40: BEF3
U53: 976D
Unfortunately all those chips are read protected on both of my boards. So no chance to get the programming files from there.
I am using Atmel ATF20V8B-15PC. So exactly the same chip you proposed.
Ah, too bad only U36 has the same checksum…
GVP PALs were almost always protected.
I was really lucky to find a GVP card with unprotected PALs!!
I read that you have two A530 cards: are both broken?
It seems strange to me that with two complete sets of PALs you can’t compose a working card!… Maybe the problem is elsewhere.
Yes. Both are broken. And it is always U36, but on one of them also U38 only returns zeros. So there are 2 broken chips on the second one.
I need to find some time. Then I would anyway burn all your files to the chips and try what happens with this setup.
Hi Luca. Some update from my side. I got now a vanila Amiga 500 which was never opened and I tried the GVP 530 with this one. As long as I have switched off HD Autoboot (JP9) I am able to start. CPU, co-pro and 8MB are discovered. Only the HD is not found in this setup yet. But I am still working on this one. This means that at least U36 can be replaced by your version. If I can replace all I still need to check. I am currently working on getting the HD to work first. It would make things much easier because at the moment I am booting from the original DF0, which some times gives me read errors. But after cleaning this is much better already. Nevertheless I do not know how long this old drive will survive.
Also I need to find out why the board is not working on my 1MB chip mem Amiga, but this is for later.
PS: Do you know what U36 is responsible for?
Hi René,
thanks for the update! 😀
The fact that the replaced U36 works is a great thing. 💪
I don’t know what U36 is responsible for, but I think it’s a pretty important part of the system; I can only tell you what I already wrote in the article above:
– using a “Lattice GAL” for U36 slowed down the card and produced many HD read/write errors (in short, a general malfunction);
– removing U36 from the card the Amiga 2000 does not start (black screen).
At this point, I think you should try swapping other PALs between the two A530 cards in search of a fully functional setup.
You also need to check if the hard disk is working properly: check with another SCSI controller (if you have one).
Be careful: I am basically sure that the only way you have is to recover the code of all PALs with the EXACT same checksum as yours; do not waste time creating a set of GALs with my versions (50 MHz set): it will not work on your board! (also because, if I am not mistaken, U53 is actually a different PAL with a lower number of pins!).
Good luck! 👍