@Talisman post eens een foto waar die epld op zit, gewoon om een indruk te krijgen wat voor spul eromheen zit en af te schatten wat voor speed je nodig hebt.
Als het wat simpele logica is of low speed communicatie zou het wel eens gewoon kunnen werken.

Is het een commercieel product wat je moet servicen?

Op woensdag 29 mei 2024 12:57:14 schreef Arco:
Rochester heeft ze nog wel, maar niet goedkoop: https://www.rocelec.com/global-search/ep610pc-15

Voor een OTP is dat een pittige prijs...

Op woensdag 29 mei 2024 13:40:16 schreef Bobosje:
[...]

Voor een OTP is dat een pittige prijs...

De wet van vraag en aanbod... :+

Op woensdag 29 mei 2024 13:53:57 schreef Arco:
[...]
De wet van vraag en aanbod... :+

De wet op z'n kop, zo te zien meer dan genoeg aanbod en maar weinig vraag. :)

Fantastisch nieuws mannen.

Henri, hartstikke bedankt.

Weardguy heeft het denk ik bij het goede eind gehad, ik kan mij niet voorstellen dat het security bit niet is gezet, het betreft een professioneel product.

Voor wat de 15ns betreft geloof ik niet dat dat echt zo snel hoeft te zijn.
Maar liever het zekere voor het onzekere, de belangen zijn te groot.
Ik heb een spare part zaak gevonden die acht nieuwe EP610PC-15 heeft liggen voor €16,50 per stuk, die ga ik bestellen.

Je kunt ook naar de iPLD610 of de D85C060-15 / TD85C060-15 gaan zoeken die zijn compatible.

Nu ben ik natuurlijk ook benieuwd wat er dan aan die devices stuk gaat? Heb je enig idee?

Anders een defecte mee opsturen zodat ik die eens kan uitlezen of die compleet stuk is of dat het programma corrupt is wat erin zit.

Het probleem van dat oude spul is nog groter dan het Y2K millenium probleem!
Er staat nog ontzettend veel spul overal uit de jaren 80-90 met epld's, (e)eprom's, gals etc. Die hebben meestal maar een retention time van ca 10-30 jaar max.
Dus nog een wonder dat er nog zo veel spul draait.
Ik heb ook al de nodige eproms uitgelezen en bewaard van spullen die ik eens gefixed heb, spul van 30 jaar+.

[Bericht gewijzigd door henri62 op (81%)]

Op woensdag 29 mei 2024 18:03:34 schreef Talisman:
Fantastisch nieuws mannen.

Henri, hartstikke bedankt.

Weardguy heeft het denk ik bij het goede eind gehad, ik kan mij niet voorstellen dat het security bit niet is gezet, het betreft een professioneel product.

Voor wat de 15ns betreft geloof ik niet dat dat echt zo snel hoeft te zijn.
Maar liever het zekere voor het onzekere, de belangen zijn te groot.
Ik heb een spare part zaak gevonden die acht nieuwe EP610PC-15 heeft liggen voor €16,50 per stuk, die ga ik bestellen.

Het Security-Bit in de EP610 was/is niet gezet anders had het van Dataman zo gelopen : Problem try to read and program a AT89C51CC02.

Mogen we de naam / url van de spare part zaak weten?

Dan kun je nog zien dat die leeg is, alles bits 1.
Er zijn ook devices die geven alleen de laagste 4 bits terug, kun je nog een beetje iets verifieren. (Ik dacht dat het sommige PIC controllers waren?)

Over de fotos: Lijkt misschien op iets van een adres decoder of zo?
Je zou dan echt een stukje moeten reverse engineren om te kijken wat er op de pinnen hangt, of meten wat voor signalen je ziet.

[Bericht gewijzigd door henri62 op (33%)]

Op woensdag 29 mei 2024 19:30:59 schreef henri62:
Nu ben ik natuurlijk ook benieuwd wat er dan aan die devices stuk gaat?

Kan data retention time zijn...

Dat denk ik ook, misschien dat die gewoon overgeprogrammeerd kan worden, vandaar de vraag om ook een defecte mee te sturen (waar ik ook een goede van heb natuurlijk) dan kan ik de jedec files vergelijken.

Dat zijn trouwens gewoon ascii files op een paar bytes na (STX, data ETX, checksum).
In de meeste macroblocks/outputs zijn maar 2-4 rows van het (input) array gebruikt.

Zit er in PLDShell-Plus een JED2EQN functie?

Ja, zover ik in het boek vanmorgen heb gelezen zit dat erin. Ik heb 3x 3.5" floppies waar het op staat geen idee of ze nog te lezen zijn.

[Bericht gewijzigd door henri62 op (39%)]

Om er meer zeker van te zijn dat de uitgelezen Jedec file klopt zou je deze door de JED2EQN functie kunnen laten converteren en kijken of dat zinnige PLD equations oplevert.

Hier zit een JED2EQN in , zal waarsch wel in DOSBOX moeten draaien :

opaljr21.zip

De snelste crystal op de CPU print is 8Mhz, de uitbreidingsprinten hebben geen eigen klok signaal.

Een 15ns chip zou theoretisch 66Mhz aankunnen lijkt mij.
De 45ns chip die Henri nog heeft liggen zou nog werken met 22Mhz.
Dat is nog steeds bijna een factor drie meer dan wat er maximaal van de CPU print afkomt.

De EP610 gaat meestal defect na een blikseminslag in de buurt.
En dan alleen als er lange kabels van de relaisprint naar ventielen in het open land lopen.
Het witte versienummer stickertje op de chip is dan precies in het midden van de behuizing waar zich de feitelijke chip bevind zwart geworden, zo heet is hij geworden.

De systemen zijn tot 2005 uitgeleverd, het is niet zo dat alle defecte chips uit 1992 stammen.

Mijn RP2040 printen hebben een 12MHz kristal. Ze draaien op 125MHz (of in het actuele geval: 100MHz) en ik heb gisteren een 50MHz signaal gemeten op de "clock out" van de CPU.

Ik ben het met je eens, dat zal wel niet op een print uit de jaren negentig, maar "het kan niet" is niet 100% correct.

Dat gezegd zijnde: De fabrikant meet die 15ns propagatie-tijd door 1 "logic cell". Maar het is niet uitgesloten dat er meerdere logic cells in serie staan.

Daarnaast als die CPU een cycle van 125 heeft, dan zou ie best randapparatuur op de kaarten kunnen adresseren die via de EPLD als decoder op het adres moeten reageren.

Als de CPU nu zijn adres 50ns na de clock pas satabiel op de bus heeft zodat een 70ns RAM chip nog net op tijd is, dan zou een peripheral op de kaart met zeg 30ns access time, 20ns bus-vertraging en 45ns EPLD net te laat zijn, terwijl 15ns EPLD net kan.

De kloksnelheid zegt niet zo veel. Het gaat om de functie die de epld moet uitvoeren.

Als het bijvoorbeeld een adres decoder is om een chip select signaal te maken, gaat dat af van de setuptijd van een device wat erachter hangt. De Tpd van de epld moet er dan af. Dat hangt dus heel sterk af wat je voor timing budget hebt.

Veel IC's uit die tijd (80-90 jaren) hadden een cycletijd van 1 us of 500 ns met CS lijnen die bijvoorbeeld ca 450 ns laag waren tijdens read/write access decoderen met simpele 74LS logic was geen probleem.
Die logic had een Tpd van 11-41ns voor bijvoorbeeld een 74LS138 die vaak daarvoor gebruikt wordt.

Op woensdag 29 mei 2024 22:46:28 schreef Talisman:
De EP610 gaat meestal defect na een blikseminslag in de buurt.
En dan alleen als er lange kabels van de relaisprint naar ventielen in het open land lopen.
Het witte versienummer stickertje op de chip is dan precies in het midden van de behuizing waar zich de feitelijke chip bevind zwart geworden, zo heet is hij geworden.

Hum, klinkt als een slordigheidje in het design dat er niet genoeg aandacht besteed is om de outputs te beveiligen (transorbs oid?).

Afijn, die borden gaan we wel weer aan de praat krijgen, dat is ook een uitdaging hier nietwaar. Niet opgeven.

Zijn het alleen de EPLD's die na bliksem de geest geven?

Het timing verhaal kunnen we vergeten.
Woensdagavond bij Radio741.com in Griekenland acht hagelnieuwe exemplaren besteld van precies hetzelfde type.
Vrijdag worden ze al bezorgd volgens de transporteur.
Nu maar hopen dat het echt nieuwe zijn.

Tot nu toe zijn alleen de EP610's defect geraakt, nooit een andere chip.
Het slordigheidje lijkt in de EP610 te zitten, niet in het ontwerp (-;
En ook alleen na blikseminslag ondanks dat de ventielen in de grond aangestuurd worden via relais.

Die kleine afstand tussen spoel en contact van het relais houdt echt geen bliksem tegen als het in de buurt inslaat...

Op donderdag 30 mei 2024 16:37:29 schreef Talisman:
Het slordigheidje lijkt in de EP610 te zitten, niet in het ontwerp (-;

Waarschijnlijk latchup in de chip zelf. Sommige chips zijn gevoelig daarvoor, dan gaat het substraat als een thyristor werken en slaat de hele chip door op de voeding, een kortsluiting dus, en klapt de 'die' uit elkaar.
Ik heb complete PLCC68 chips ontploft gezien die in die modus terecht kwamen.
Dus een PLCC68 cabrio geworden. ;)

Een andere mogelijke oorzaak voor het defect / oververhit raken van de EPLD is, is dat er een a-synchrone state-machine in de EPLD zit die door de bliksem ontlading in een illegale state terecht komt en de state-machine in een voortdurende race conditie terechtkomt waardoor de power consumptie van de EPLD te hoog wordt en de EPLD oververhit en defect raakt.

Op donderdag 30 mei 2024 16:42:19 schreef Arco:
Die kleine afstand tussen spoel en contact van het relais houdt echt geen bliksem tegen als het in de buurt inslaat...

Overslag is niet per se nodig, een zeer hoge elektrische veldsterkte bij bliksem ontlading kan al genoeg zijn waardoor IC's defect raken.

Op woensdag 29 mei 2024 22:46:28 schreef Talisman:
De EP610 gaat meestal defect na een blikseminslag in de buurt.
En dan alleen als er lange kabels van de relaisprint naar ventielen in het open land lopen.

Nou, de overeenkomst kan niet treffender: ook de defecte waar ik het over had hadden (zo vermoedden we) vaak te lijden van overspanning, ook al was de ingang een relaiscontact of uitgang een relais-spoel. Afstanden waren naar vermoeden ook zo tientallen meters.

Uitgang dan wel ingang gaat defect, stroomverbruik stijgt flink en trekt vervolgens de voeding onderuit.

Ik zal nog eens navraag doen ;)

Het timing verhaal kunnen we vergeten.
Woensdagavond bij Radio741.com in Griekenland acht hagelnieuwe exemplaren besteld van precies hetzelfde type.
Vrijdag worden ze al bezorgd volgens de transporteur.
Nu maar hopen dat het echt nieuwe zijn.

Tot nu toe zijn alleen de EP610's defect geraakt, nooit een andere chip.
Het slordigheidje lijkt in de EP610 te zitten, niet in het ontwerp (-;
En ook alleen na blikseminslag ondanks dat de ventielen in de grond aangestuurd worden via relais.

(beetje verlaat berichtje, zie nu pas dat ik niet op de knop 'Posten' heb gedrukt.)