daveho/galasm

Very slightly modified version of Alessandro Zummo's GALasm 2.1, for programming GAL devices

galasm's Issues

Not open source

You preface your introduction by saying that the reason GALasm was created is because there are no other open source GAL assemblers. At the same time right above that statement, is a prominent restriction specifying that "Commercial use is strictly forbidden". These two parts of the readme file contradict each other. Under every accepted definition of "open source" and "free software" one of the core liberties is the ability to use the software without restriction for any purpose. I can cite specific documents if you wish, but a quick look around fsf.org and opensource.org should convience you of the facts.

As it stands, unfortunately, GALasm is not open source, nor free software. Would you mind lifting that restriction, so we can finally have an open source GAL assembler? (assuming there are no others, I didn't check yet). Ideally please also select a common open source/free software license, and release your software under those terms.

Feature request: warning on too many pins in product terms

This might not really be a bug, but it is somewhat inconvenient and less than helpful.

If a line in a .pld file contains too many pins in a product term, the extra's are silently ignored.

This in contrast with the count of product terms which is checked.

The following .pld file defines six outputs, each defined with a single product term containing nine pins. The last one is silently ignored. Assuming the code knows about the maximum number of terms per device, a warning would be helpful for the user.

	GAL16V8    ; Address decode
	ADDRDC4  ;
	
	;1    2     3     4     5     6     7     8     9     10
	NC  /IORQ  /WR   A0    A1    A2    A3    A4    A5    GND
	NC   Q0    Q1   Q2    Q3    Q4    Q5    A6    A7     VCC
	;11  12    13   14    15    16    17    18    19     20
	
	Q0 = /A0 * /A1 * /A2 * IORQ * WR * A3 * A4 * A5 * A6
	Q1 =  A0 * /A1 * /A2 * IORQ * WR * A3 * A4 * A5 * A6
	Q2 = /A0 *  A1 * /A2 * IORQ * WR * A3 * A4 * A5 * A6
	Q3 =  A0 *  A1 * /A2 * IORQ * WR * A3 * A4 * A5 * A6
	Q4 = /A0 * /A1 *  A2 * IORQ * WR * A3 * A4 * A5 * A6
	Q5 =  A0 * /A1 *  A2 * IORQ * WR * A3 * A4 * A5 * A6
	
	DESCRIPTION

But when a pin is defined with too many product terms, like the attached file, GALasm throws an error:

	Error in line 54: too many product terms

Simplyfied versions of attached file did compile, but the GAL didn't work, this might be related with the issue described above, or I don't really understand registered mode (the latter is most likely).

RINCREMENTER1.pld.txt

Unexpected inversion when using inverted registered outputs

Consider this example:

GAL22V10
PS2

CLK  A    B    NC   NC   NC   NC   NC   NC   NC   NC   GND
/CS  Q1   Q2   NC   NC   NC   NC   NC   NC   NC   NC   VCC

/Q1.R = A * B
/Q2.R = /Q1

DESCRIPTION
t

If I invert Q1 and Q2 in pin definitions as such:

< /CS  Q1   Q2   NC   NC   NC   NC   NC   NC   NC   NC   VCC
---
> /CS /Q1  /Q2   NC   NC   NC   NC   NC   NC   NC   NC   VCC

...I can observe the following difference in fuses:

132c132
< Pin 15 = Q2           S0 = 0   S1 = 0
---
> Pin 15 = /Q2          S0 = 1   S1 = 0
134c134
< 112  ---- ---- ---- ---- ---- ---- ---- ---- ---- --x- ----
---
> 112  ---- ---- ---- ---- ---- ---- ---- ---- ---- ---x ----
145c145
< Pin 14 = Q1           S0 = 0   S1 = 0
---
> Pin 14 = /Q1          S0 = 1   S1 = 0

I would expect only the S0 bit to change. However, the actual column is also getting changed (from true to inverted).

I checked the datasheet (http://web.mit.edu/6.115/www/document/gal22v10.pdf). On page 4 in the top section (S1=0) it's stated that the feedback originates from /Q while the pin itself is driven by Q, so pin inversion does not have any influence on the feedback since it's driven by a separate driver.
This means that S0=0,S1=0 and S0=1,S1=0 should only change the behavior of the physical output, not the matrix. In other words, inverting a pin in the definition section should only change the S0 flag.
Is this a bug or am I misunderstanding something?

equation parse going wrong

ok, I only been at this 3 days, but I think its not behaving right.

I have the following config
GAL16V8
main
A B C NC NC NC NC NC NC GND
NC NC NC NC NC NC X Y Z VCC

X = A * B * C
Y = /A * B * C + A * /B * C + A * B * /C
Z = /A * /B * /C + /A * /B * C + /A * B * /C + A * /B * /C

DESCRIPTION
X is active with 3 inputs high
Y is active with two inputs high
X is active with less than 2 inputs high

X is ok, but the other two channels aren't working correctly. There are no assemble errors. Its just not working right.
Tried to make heads of tails of how the formulas are parsed, but this could be a lot faster for someone else more familiar with the code.

too many terms??

Missing break statements

Hi,

The 4 switch statements here are missing break:

GALasm/src/galasm.c

Line 2143 in 4acb978

case GAL16V8: num_of_col = MAX_FUSE_ADR16 + 1;

Combinatorial Output with Feedback Configuration for Simple Mode (mode 1) is not supported

According to GAL16V8 datasheet pages 8 and 9, it should be possible to have feedback from an output pin in simple mode (galasm mode 1).
Unfortunately, it looks that galasm does not allow this.
If such configuration is attempted, it will switch to mode 2 (complex mode).

Here is a simple example showing this issue:

GAL16V8         ; first line : used GAL
FEEDBACK        ; second line: any text (max. 8 char.)

A       B       NC      NC      NC      NC      NC      NC      NC      GND
NC      NC      NC      NC      NC      NC      NC      D       C       VCC

C = /A
D = B * C


DESCRIPTION

This example shows a bug in galasm

According to GAL16V8 datasheet, it should be possible to have feedback
from an output pin in mode 1, but galasm does not allow this, and
will switch to mode 2 (complex mode) if it encounters any pin with feedback

Checksum Ok for GAL16V8 but not for GAL22V10

INCREMENTER5.pld.zip
A GAL16V8 .pld file assembled to .jed is accepted by the https://gitlab.com/DavidGriffith/minipro programmer software and the GAL appears to work as expected. But my GAL22V10 .pld file is not. The problem appears to be a wrong file checksum. The checksum in the GAL16V8 file is four hex digits, but in the GAL22V10 file is five digits. Replacing the value by the one suggested by the minipro software results in a accepted .jed file, which can be programmed. As an experimental test, a quick hack in jedec.c:FileChecksum() truncating the checksum to 4 digits appears to be working to:

checksum = checksum & 0xFFFF;

On the minipro gitlab site is a link to a .jed file specification (http://www.pldtool.com/pdf/fmt_jedec.pdf), and it indeed specifies a four digit file checksum.

Greetings,
Fred Jan

Edit: Attached the offending pld file.

Feature Request. More Flexibility in Pin Naming

I was wondering if there would be any logical reason why we could not implement a bit more flexibility in the Pin Naming conventions. For example being able to name pins with names such as /ROM_EN etc.

Example code could be

#define isalpha IsALPHA_E

and

  int IsALPHA_E(char chr){
         if ((chr >= 'a' && chr <= 'z') || (chr >= 'A' && chr <= 'Z') || chr == '_')
           return(1);
        else
           return(0);
   }