tl866cs GAL22v10d mit Linux Software minipro brennen

GAL-Assembler zur Erzeugung von JEDEC-Dateien
http://www.sh-elektronik.de/service/index.html

Beispiele:
http://www.sh-elektronik.de/service/demo/ispGDS%20Tutorium%202009.pdf

Gruss Holger.
Kannst du die Chip -ID wenigstens mit dem Progger da lesen?

Normal wird der file mit *.jed geladen.
Erase Chip... Prog Verify ,,bingo.

Hast Du dir die miniprohex angesehen?
Kann die mit der *.jed umgehen und in eine bin wandeln?

Andreas R. schrieb:
> Hab mal die Minipro Sources studiert. Der vergleicht wohl einfach
> Filegrösse mit Chipgrösse. Bei nem EPROM Bin File klappt das wohl, aber
> nicht bei nem jedec File. Ich denke, dass die Sources da geändert werden
> müssen.

There is one issue with GALasm: the JEDEC files generated by GALasm use 
bare newline characters to terminate lines.
My programmer (Wellon VP-190) requires a CRLF (carriage return, newline) 
sequence to terminate
 lines in JEDEC files; otherwise, the file is rejected with a cryptic 
error message.
So, I modified the GALasm source to always output CRLF for line 
termination in JEDEC files

Anhang mit einen Jed File zum Testen, ob der Progger den einlesen kann.


Gruss Holger.
Den Gal Compiler als zip.
Beitrag "JEDEC Dateien erstellen?!?"

Hier noch die C source + Jedec Files zum Testen.
https://github.com/daveho/GALasm

Gruss Holger.

Den modifizierten GALasm hab ich benutzt, um meine jedec Files unter 
Linux zu erstellen. Gebrannt hab ich sie dann unter Win7. Im Moment 
probier ich gerade mal wieder unter Linux rum, bekomm aber schon beim 
Lesen eines Chip einen Gleitkommafehler.

Hab jetzt auch miniprohex probiert:

=============
andreas@Elektronik2:~/pal_gal/c64_z80/gal$ miniprohex -p GAL22V10D -w 
z80logic.jed
Found Minipro TL866CS v03.2.72
Incorrect file size: 1764 (needed 5892)
andreas@Elektronik2:~/pal_gal/c64_z80/gal$
=============

Das Problem liegt aus meiner Sicht hier:

https://github.com/vdudouyt/minipro/blob/master/main.c#L410

Da vergleicht er ja die grösse des ICs (also des möglichen Inhalts) mit 
der Filegrösse. Mein Programm belegt nun halt nicht das ganze ICs, also 
sind die Werte unterschiedlich.

Hier ist das, was ich gebrannt hab, bzw. unter Linux brennen wollte:

https://github.com/vdudouyt/minipro/blob/master/main.c#L410

Vielen Dank für eure Antworten!

Ciao,
Andreas

galasm gibt die
anzahl fuses nach den F und G feldern aus
PALASM (und vmtl die meisten anderen) tun das ganz am anfang.
Ich vermute dass die meisten parser nich mit galasms variante koennen.

galasm:

1

Used Program:   GALasm 2.1

2

GAL-Assembler:  GALasm 2.1

3

Device:         GAL22V10

4

5

*F0

6

*G0

7

*QF5892

Andere:

1

QP24*  Number of pins*

2

QF5892*  Number of fuses*

3

F0*  Note: Default fuse set to 0*

4

G0*  Note: Security fuse NOT blown.*

einfach mal das QF feld vor die F/G und nochmal probieren....

Hi!

Hab den Brenner gerade nicht zur Hand, aber schau mal in main.c Zeile 
135.

Dort ist die Funktion get_file_size . Der macht einfach ein Seek ans 
Fileende und nimmt die Position dort als Filegrösse. Weiter geparsed 
wird da wohl nix. Also wird einfach die Filegrösse in Bytes genommen. 
Das funktioniert aber nur bei einem Eprom und einem bin File, welche 
halt genau soviele Bytes hat, wie das Eprom gross ist.

Ja, stimmt. Da scheint kein .jed parser dabei zu sein. k.A. wie du das 
am einfachsten konvertieren kannst. Das .bin file scheint auch nicht 
wirklich binaer zu sein, weil er mit ftell() die bytes zaehlt....
Ist aber schnell geschrieben...

<https://github.com/klammerj/jed2bit/releases/tag/v0>;

ob die endianness passt, weiss ich nicht...

Edit:
https://github.com/klammerj/jed2bit/releases/tag/v0

Hallo!

Jo, das könnte eine sinnvolle Lösung sein. Aber ich hab jetzt erstmal 
noch den Autor nach seiner Meinung gefragt:

https://github.com/vdudouyt/minipro/issues/58

Vielleicht mach ich ja was falsch. Kommt von ihm nix, muss man halt 
selbst mal schauen.

Danke nochmal,
Andreas