Hoe denkt TS te achterhalen welke fuse-bits in de Jedec file overeenkomen met de beschikbare fuse-bits in het device (waar ze in het device moeten worden geprogrammeerd) en in welke volgorde deze fuse-bits (hoogstwaarscnlijk) serieel naar het device moeten worden gestuurd?
Als je constant een device moet programmeren (en weer wissen) om daar achter te komen dan raken de devices snel opgebrand vrees ik.
De fuse matrix staat wèl in de datasheet. 
Met cel nummers erbij.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Er zijn maar heel weinig programmers die de PALC konden programmeren, een weinig en kort gebruikte serie.
Goedkoopste die ik zie is de EP1132 van BPMicrosystems: https://www.ebay.com/itm/297527078122 (is wel 110v)
PALCxxx was de 'advanced low power' ('maar' 100mA!... 
) versie van de PALxxx...
Device list:
De EP1132 is voor EPROMs, programmeerd geen PLD's volgens de Device list, de GALs van Lattice ook niet, die van MMI evenmin.
Volgens pagina 16 van die pdf kan de EP1132 geen PALs. Pas vanaf de PLD1128 worden PALs ondersteund. Er staat een CP1128 op eBay, maar buiten mijn budget.
Op zaterdag 8 november 2025 22:40:32 schreef MNM(tm):
De fuse matrix staat wèl in de datasheet.
De positie (adressen) van de fuse-bits in de Jedec file hoeven niet 1 op 1 overeen te komen met de positie (adressen) zoals die in het Device zitten of zoals je die achter elkaar naar het device moet toesturen.
De adres-mapping van de Jedec-fuse bits naar de daadwerkelijke overeenkomstige fuse-bits in een device gebeurt in de programmeer software van het betreffende device.
Dat is een van de zoveel trucks van een fabrikant om het programmeer algoritme geheim te houden.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Een tijd geleden had ik nog reverse engineering gedaan op een EP610. Met mijn dataman-48LV. Zoek hier maar eens naar EP610.
Die ondersteund best veel, zowel pals,gals,eeproms,eproms, wel op XP met een par-port.
Ik weet niet of je die nog ergens kunt kopen tweede hands en wat ze er voor vragen.
Anders eerst een de device list checken.
Dat kan ik nu niet, ben niet thuis.
@bobosje: Dat zal wel, maar uiteindelijk moet het toch een keer van de programmer naar de chip. En dat kun je me lezen met een logic analyzer. En ik kan me eerlijk gezegd niet voorstellen dat dat als in de jedec file op een specifieke positie en bit op 0 staat, dat die dan elke keer dat je die file in een PAL dumpt, dat bitje dan ergens anders in de (elektrische) sequence zit.
@henri: helaas, geen ondersteuning voor PALC devices.
Jedec files worden gecompileerd naar het type PAL of GAL dat je gebruikt. De fuse-bits van het AND-Array, I/O macrocellen, UES en het security bit kunnen dan andere adressen hebben afhankelijk de mate van complexiteit (grootte van het AND-Array / aantal I/O macrocellen) in het gebruikte device.
Daar bovenop kunnen de fuses in de Jedec file niet altijd in de getoonde volgorde elektrisch naar een device worden gestuurd.
Meeluisteren op de pinnen van het device tijdens het programmeren van de Jedec data en evt. UES en security bit en tijdens het teruglezen (verify) van het geheel kan natuurlijk altijd. Je zult hoogstwaarchijnlijk ook de timing (delays) in de gaten moeten houden voor het timen van een programmeercyclus.
KGE
Golden Member
De ' Bees Knees' voor deze PAL chips schijnen de BeeHive programmers te zijn..
Prijzen nieuw vanaf $3000 en 2e-hands vanaf $1000 
Op zondag 9 november 2025 14:37:50 schreef Bobosje:
Jedec files worden gecompileerd naar het type PAL of GAL dat je gebruikt. De fuse-bits van het AND-Array, I/O macrocellen, UES en het security bit kunnen dan andere adressen hebben afhankelijk de mate van complexiteit (grootte van het AND-Array / aantal I/O macrocellen) in het gebruikte device.
Daar ben ik me wel van bewust. Sowieso gaat het mij (voorlopig) alleen om de PAL chips die ik hier heb liggen. Dus dat een compiler een andere jedec file genereert voor andere type PALs/GALs, zal me -bot gezegd- een worst zijn.
Op zondag 9 november 2025 14:37:50 schreef Bobosje
aar bovenop kunnen de fuses in de Jedec file niet altijd in de getoonde volgorde elektrisch naar een device worden gestuurd.
Ook dat vind ik niet relevant. Wat ik echter niet geloof is dat de volgorde waarin de data in de jedec-file naar de chip wordt gestuurd, elke keer anders is. Dát het anders is, is heel goed mogelijk. Maar wel elke keer hetzelfde. Dus JEDEC-file -> vertaalslag -> elektrische datastroom naar de chip. De inhoud van de jedec-file is een gegeven, die verandert niet. De vertaalslag is het black-box deel wat zich in de programmer afspeelt. De elektrische datastroom van de programmer naar de chip is, volgens mij, gewoon elke keer hetzelfde, als je er dezelfde jedec-file in stopt. Ik kan me niet voorstellen dat de plek van bijvoorbeeld de protection fuse bit ineens ergens anders in de datastroom zit als je er een andere jedec-file naartoe stuurt.
Dat het elke keer anders is voor een device bedoelde ik niet te zeggen.
De volgorde waarin de Jedec fuse bits worden verpakt in het elektrische protocol kan verschillend zijn per device.
De Jedec fuse-bits 0,1,2, etc. hoeven niet perse bit 0,1,2 in byte 0 van het elektrische protocol te zijn, ze kunnen gespiegeld of nog anders worden gemapped, de Jedec fuse-bits naar elektrisch protocol bit/byte mapping zal fixed zijn per device.
Dan zitten we dus toch op één lijn. 
Mijn gedachte is om uit te zoeken wat die 'vertaalslag' in de programmer doet. Ik weet wat erin gaat; de jedec-file. Ik kan met een logic analyzer uitlezen wat de programmer naar de chip stuurt. Ook dat is m.i. een stroom vaste gegevens.
Dus: bekende data > black box > gemeten data. Dan moet er toch uit te vlooien zijn wat er in de black box met de ingaande data gebeurt om de zooi die eruit komt te verkrijgen?
Het is denkbaar dat dat te achterhalen is.
Je zult in het begin alle pinnen van het device moeten monitoren (ook in de tijd om evt. de delays vast te stellen) om te kijken op welke pinnen er activiteit is bij het programmeren en het verifieren. Hopenlijk kun je het programmeren monitoren zonder een device in de programmer te hoeven plaatsen als de programmer geen feedback van het device verwacht of nodig heeft tijdens het programmeren (dat is een gok of dat zo is).
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
Op zaterdag 8 november 2025 19:40:54 schreef MNM(tm):
[...]
Dat is wel de bedoeling, ja. Mits betaalbaar (lees: max. €100).@free: zover ik weet hebben die GAL dingen van Lattice (16V8, 20V8, 22V10) ook een externe programmeerspanning nodig, al is het maar om het ding in programmeer modus te zetten.
voor de PAL devices ja. voor de GAL chippies niet dacht ik.
het programmeer algoritme voor GAL is gekend. Elketuur heeft ooit een zelfbouw GAL programmer gemaakt die 20v8 kon doen.
https://www.elektormagazine.com/magazine/elektor-199205/32613
en
https://www.elektormagazine.com/magazine/elektor-199306/32846
ik heb die ooit gebouwd.
je kan die oude elektuurs vinden op de site van Jose Verstraeten of op archive.org.
hing gewoon op een printerpoort
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Op zondag 9 november 2025 14:59:05 schreef MNM(tm):
[...]
Ook dat vind ik niet relevant. Wat ik echter niet geloof is dat de volgorde waarin de data in de jedec-file naar de chip wordt gestuurd, elke keer anders is. Dát het anders is, is heel goed mogelijk. Maar wel elke keer hetzelfde. Dus JEDEC-file -> vertaalslag -> elektrische datastroom naar de chip. De inhoud van de jedec-file is een gegeven, die verandert niet. De vertaalslag is het black-box deel wat zich in de programmer afspeelt. De elektrische datastroom van de programmer naar de chip is, volgens mij, gewoon elke keer hetzelfde, als je er dezelfde jedec-file in stopt. Ik kan me niet voorstellen dat de plek van bijvoorbeeld de protection fuse bit ineens ergens anders in de datastroom zit als je er een andere jedec-file naartoe stuurt.
helemaal mee eens.
Op maandag 10 november 2025 00:23:04 schreef free_electron:
ik heb die ooit gebouwd.
Idem, inclusief de uitbreiding.
Die GAL programmer van Elektuur ken ik. Heb ik ook aan zitten denken om die te bouwen. Maar omdat ik, zover ik weet, maar één 20V8 device heb, maak ik daar geen haast mee. Voor m'n 16V8 devices heb ik de TL866IIplus.
Ik zit dus alleen om 't hand met m'n MMI PALC22V10H en Atmel ATV750 devices.
Maarreh, uitbreiding?!
Er was een uitbreiding op de Elektuur GAL-programmer beschikbaar in een latere editie van Elektuur waarmee ook de volgende types konden worden geprogrammeerd :
GAL16V8B
GAL20V8B
GAL22V10
GAL20RA10
GAL6001
//Offtopic. Als het bij ons in de familie over dementie ging maakte ik de grap dat dat handig was want dan kon je iedere verjaardag de zelfde kado's uitpakken
In dat kader, en opruimende blijkt dat ik ook nog een Hi-Lo ALL-11 in mn bezit heb, zal m komende tijd eens aanzwengelen, ik heb nog een werkende XP machine staan.
Op dinsdag 18 november 2025 16:02:58 schreef bprosman:
In dat kader, en opruimende blijkt dat ik ook nog een Hi-Lo ALL-11 in mn bezit heb, zal m komende tijd eens aanzwengelen, ik heb nog een werkende XP machine staan.
Ik hoop voor je dat ie het nog doet, een waardevolle programmer voor nog redelijk moderne en legacy devices...