The Pacmen evolution sources.

[LarsImNetz]

Hi all,

for anyone of interest, find here the complete source code for building Pacmen evolution.

 

pacmen.evolution

 

Since it requires the wnf.compiler, you should follow the README and install all tools for build from scratch.

 

Regards

Lars

 

[+MrFish]

6 minutes ago, LarsImNetz said:

pacmen.evolution

This is just a link to this thread.

 

[Mclaneinc]

A ground hog day link..

Edited January 2, 2023 by Mclaneinc

[_The Doctor__]

@LarsImNetz

You attached a link to your own topic, you need to attach the files or the link to the files.

[LarsImNetz]

Oh how embarrassing

https://github.com/the-atari-team/tat.pacmen.evolution

 

This is the real link.

 

 

[RetroCoder]

Glad to see that you are using Atasm

If you want any specific mods to the Assembler let me know.  I've just recently (V1.20) added better support for .IF .ELSEIF .ELSE .ENDIF blocks (.ELSEIF is new) 

[LarsImNetz]

56 minutes ago, RetroCoder said:

Glad to see that you are using Atasm

If you want any specific mods to the Assembler let me know.  I've just recently (V1.20) added better support for .IF .ELSEIF .ELSE .ENDIF blocks (.ELSEIF is new) 

Hi RetroCoder,

 

yes, I would like to get one feature, I've not seen in any Assembler.

 

You know the branch mnemonics bcc,bcs,bne,beq,... the greatest problem is the length of the jump, +-128 bytes.

 

I would like to see something like long conditional jumps. Maybe name it LBCC, LBCS... or LCC, LCS...

`LBCC jumpmark` could be replaced to `BCC jumpmark` as long as the jump is less than 128 bytes long and if the jump takes more bytes it will replaced by it's negative and a following jmp:

# BCC with long jump
 BCS ?jumpover
 JMP jumpmark
?jumpover

...

jumpmark

At the moment this works only in a macro, if the jumpmark is before this construct. Would be nice if the jumpmark could be also in front.

 

This could be nice.

 

Also the ".if .ref " ... ".endif" feature of the mac65 could be nice to see. So the code could be smaller if some functions are not need to be build, because they are not referenced.

 

Regards

Lars

 

[RetroCoder]

23 hours ago, LarsImNetz said:

 

 

Also the ".if .ref " ... ".endif" feature of the mac65 could be nice to see. So the code could be smaller if some functions are not need to be build, because they are not referenced.

 

 

Hi Lars

 

I fixed the .if .ref feature in atasm. Something like this will now create func1 but not func2. V1.21 has been pushed to github.

	*=$2000

	jsr func1
	rts

.IF .REF func1
func1
	lda #1
	sta $4000
	rts
.ENDIF	

.IF .REF func2
func2
	lda #1
	sta $4000
	rts
.ENDIF

 

 

As for the macro for the long jump, I'll take a look at that next.

 

Cheers

Peter

 

[RetroCoder]

On 1/3/2023 at 5:52 PM, LarsImNetz said:

Hi RetroCoder,

 

yes, I would like to get one feature, I've not seen in any Assembler.

 

You know the branch mnemonics bcc,bcs,bne,beq,... the greatest problem is the length of the jump, +-128 bytes.

 

I would like to see something like long conditional jumps. Maybe name it LBCC, LBCS... or LCC, LCS...

`LBCC jumpmark` could be replaced to `BCC jumpmark` as long as the jump is less than 128 bytes long and if the jump takes more bytes it will replaced by it's negative and a following jmp:

# BCC with long jump
 BCS ?jumpover
 JMP jumpmark
?jumpover

...

jumpmark

At the moment this works only in a macro, if the jumpmark is before this construct. Would be nice if the jumpmark could be also in front.

 

 

 

Hi Lars

 

Could you show me the macro you use and how you would like to have it work. Just write is as if the feature would be implemented already (and how you do it at the moment)

[pps]

On 1/3/2023 at 4:52 PM, LarsImNetz said:

Hi RetroCoder,

 

yes, I would like to get one feature, I've not seen in any Assembler.

 

You know the branch mnemonics bcc,bcs,bne,beq,... the greatest problem is the length of the jump, +-128 bytes.

 

I would like to see something like long conditional jumps. Maybe name it LBCC, LBCS... or LCC, LCS...

`LBCC jumpmark` could be replaced to `BCC jumpmark` as long as the jump is less than 128 bytes long and if the jump takes more bytes it will replaced by it's negative and a following jmp:

# BCC with long jump
 BCS ?jumpover
 JMP jumpmark
?jumpover

...

jumpmark

At the moment this works only in a macro, if the jumpmark is before this construct. Would be nice if the jumpmark could be also in front.

 

This could be nice.

 

Also the ".if .ref " ... ".endif" feature of the mac65 could be nice to see. So the code could be smaller if some functions are not need to be build, because they are not referenced.

 

Regards

Lars

 

For that I would go the way MADS uses... Simply type jne, jeq, jmi, jcs, jcc and you have that long jumps. 

[RetroCoder]

On 1/4/2023 at 8:02 PM, pps said:

For that I would go the way MADS uses... Simply type jne, jeq, jmi, jcs, jcc and you have that long jumps. 

That is a good alternative but not quite the same.  The JNE command always translates into the inverse branch and a jump.

The idea here is that one can optimize this a little if you know the jump distance is going to be less than +- 128 then you can just branch per normal. If the distance is >128 then you can use the inverse-jump implementation.

This is relatively easy to implement if you are jumping backwards in code, then the assembler would know the memory location of the target and you can decide which command sequence to use. But in a normal 2 pass assembler the forward references will prevent this from working.  The best I can think off is to output an optimization list after the assembler where it may suggest to change the jne.. commands in bne at a specific file location.

[pps]

Ah, yes it is the automatic switch which is wanted. I thought it was not included at all.

 

but imho - that automatic switch is luxury. I am fine, when the assembler shouts, that the label is out of reach. Then simply change the b to a j and assemble it again. Did that thousands of time with mads

[ggn]

I think that the assembler reporting of long jumps that could be short is the best solution. Can be ignored at will (or it could even be a switch so it isn't shown during assembly) during main development, then taken care of during the final stages of the project, or when the cycle budget gets tight.

 

But the worst part with adding extra directives is tool lock-in. Suddenly your source isn't portable (for example if others want to use your code it won't be as straightforward), and not straightforward to read for someone who isn't accustomed to the tool.

 

Just my 2 cents, and full disclosure: I do work on an assembler myself.

[matosimi]

seems we got slightly off topic but see the MADS assembly+disassembly:

 

short branches are preferred by MADS.

[RetroCoder]

On 1/4/2023 at 8:02 PM, pps said:

For that I would go the way MADS uses... Simply type jne, jeq, jmi, jcs, jcc and you have that long jumps. 

Good idea. Atasm 1.22 now has support for long jump branching (using the same names as mads).

If 'beq target' is too far away simply use 'jeq target'.

When using the jump-branch instructions and the target address is known during the first pass of the assembler and the distance is short then the code will generate the branch version of the command:

'jeq target' -> 'beq target' and not 'bne #3;  jmp target'

The assembler will dump a list of suggested optimizations at the end

[LarsImNetz]

Very nice, in my way, I have create a compiler which generate assembler source code. Due to simplification I can't check the jump range and now I will use the new jne/jeq... feature. Please give me some days to fix the compiler this way.

Also I will add the working .if .ref feature into the libraries.

 

Really great work. Thanks.