Pacman4K Source Code

[DEBRO]

Hi there,

 

Attached is the latest source code for Pacman4K. Hopefully it is documented well enough for others to follow.

 

For those that would like to build the version in the AtariAge store then assemble the attached with PUBLISHER = ATARIAGE and FASTER_SPEED = TRUE.

 

I hope this source will help others wanting to develop programs on the 2600. Maybe it can help with the development of the new Pac-man project in development. Enjoy...

Pacman4K_1_2.zip

[DINTAR816]

Hi, I had not seen this topic, thanks for leaving the source available to everyone.

I was watching the source and found a routine called "DetermineMonsterNewDirection"

and is very similar to the routine I did (suspiciously similar ) for the same function, is 8 bytes less, but it works exactly the same. I saw in the code that Thomas Jentzsch had to do in the modification of this routine, I wonder if it was based on my version or is it just coincidence.

Well, would you be in agreement that I use this code in my version to save 8 bytes ?.

[Thomas Jentzsch]

You are right, that piece of code is heavily inspired by your code. I should have mentioned that clearly to Dennis.

 

And of course you can use that optimization. That's the main reason why code is released.

[jenorton]

Hi:

 

I am totally blind, and have never assembled any Atari 2600 code before.

 

However, I thought I'd see what the process was like.

 

I tried assembling Mr. Debro's source posted here, and it seems to give me a working rom, but, I do get a bunch of errors.

 

Are these anything serious, or are they just warnings?  Here are the last few lines of the output from Dasm:

 

source.s (3804): error: Value in 'byte byte -64951' must be <$100.
source.s (3805): error: Value in 'byte byte -64951' must be <$100.
source.s (3806): error: Value in 'byte byte -64993' must be <$100.

Unrecoverable error(s) in pass, aborting assembly!
Complete. (5)
 

 

Just curious.

 

Thanks!

[+Andrew Davie]

2 hours ago, jenorton said:

 

 

source.s (3804): error: Value in 'byte byte -64951' must be <$100.
source.s (3805): error: Value in 'byte byte -64951' must be <$100.
source.s (3806): error: Value in 'byte byte -64993' must be <$100.

Unrecoverable error(s) in pass, aborting assembly!
Complete. (5)

 

I had a look and yes -- these are definitely errors in the source code.

My guess is that it worked with an earlier version of dasm but that no longer does because dasm has had these sorts of errors fixed.

Basically, these are byte value tables but the value being used is actually a word.  It's definitely source code errors which need fixing.

@DEBRO

 

[Thomas Jentzsch]

Looks like some brackets would fix the problem, e.g.:

.byte <(Mush - FruitSprites + H_OBJECTS)

 

[+Andrew Davie]

4 hours ago, Thomas Jentzsch said:

Looks like some brackets would fix the problem, e.g.:

.byte <(Mush - FruitSprites + H_OBJECTS)

 

No, it's more than that.

For example, line #1442...

 

pacman4K_1_2.asm (1442): error: Value in 'byte byte 256' must be <$100.

pacman4K_1_2.asm (1442): error: Value in 'byte byte 768' must be <$100.


The line in question...

   .byte CHERRIES_SCORE, STRAWBERRY_SCORE

.. and the definition of those values...

 

; fruit score values
CHERRIES_SCORE          = $0100
STRAWBERRY_SCORE        = $0300

 

There's clearly something strange going on.

I don't see how that could could ever have assembled!

 

 

 

[Thomas Jentzsch]

Old DASM versions used the lower bytes automatically. It assembles e.g. with DASM 2.12.04

 

To fix the code, prefix everything not working with '<'.

dasm.exe

pacman4K_1_2.asm

Edited October 23, 2020 by Thomas Jentzsch

[+Andrew Davie]

3 hours ago, Thomas Jentzsch said:

Old DASM versions used the lower bytes automatically. It assembles e.g. with DASM 2.12.04

 

To fix the code, prefix everything not working with '<'.

dasm.exe 28 kB · 1 download

pacman4K_1_2.asm 173.63 kB · 0 downloads

That's interesting, so much for backwards compatibility.

I guess we should have a switch to enable this to be optional.

 

[jenorton]

Thanks for the assistance.

 

To paraphrase Heinlein, "I know as much about assembly as a pig knows about patty-cake".

[jenorton]

speaking of backwards compatibility (or the lack thereof), when I compiled originally and got all those errors, I did get a binary as a result.

I just compared what I originally got with the modified .asm file posted here, and, they end up exactly the same.  So, maybe there was some backwards compatibility, but, there sure were a lot of complaints from DASM.

Again, thanks for all the help.  One feels better when programs don't complain

[+Andrew Davie]

3 minutes ago, jenorton said:

speaking of backwards compatibility (or the lack thereof), when I compiled originally and got all those errors, I did get a binary as a result.

I just compared what I originally got with the modified .asm file posted here, and, they end up exactly the same.  So, maybe there was some backwards compatibility, but, there sure were a lot of complaints from DASM.

Again, thanks for all the help.  One feels better when programs don't complain

 

It's a bit of a no-win situation for dasm maintainers.

The earlier version allowed incorrect code, but did its best to produce correct results.

The newer version doesn't allow incorrect code, but is bound by expectation to produce correct results.

This particular example is a good demonstration of that.

 

On reflection, I think the new version is actually correct and that old source code needs to be updated so it is correct.

 

 

[Mr SQL]

4 hours ago, Andrew Davie said:

The earlier version allowed incorrect code, but did its best to produce correct results.

The newer version doesn't allow incorrect code, but is bound by expectation to produce correct results.

I prefer the earlier version that works.

4 hours ago, Andrew Davie said:

On reflection, I think the new version is actually correct and that old source code needs to be updated so it is correct.

None of the old source code should be updated, rather the next release of DASM should address the compatibility issue.

 

Sometimes there is a new release that's just not ready yet and DASM is a mature app with myriad releases - imo there's nothing wrong with going a few versions back to avoid missed bugs present in the latest broken fork release where non-fatal warnings now break the binary.

 

This is a QA issue with DASM all the code should not have to be changed when there is a new release.

[DEBRO]

Hi Andrew,

 

12 hours ago, Andrew Davie said:

On reflection, I think the new version is actually correct and that old source code needs to be updated so it is correct.

I agree with you. Though the old version of DASM allowed it, the source files are incorrect and need to be updated to reflect proper use of .word and .byte. I have been updating my source code (original and disassemblies) for this and plan to get the updated source of Pacman4K in my github repository.

[RevEng]

I'm with Andrew and Dennis here. I'm one of the DASM maintainers that almost always falls on the "don't break existing source code" side of the oh-so-many syntax update discussions we've had, to the point where I'm often outnumbered.

 

But giving a word-sized argument to a dc.b/byte pseudo-op is clearly a syntax error. Arguing that bad syntax that used to slip through should remain working "because history" isn't a good enough justification, nor is this "a QA issue" that slipped through. This was very intentional range-check we added, knowing full well it would break some source. As an assembly developer, you should be glad to have your errors flagged, rather than ambiguously plastered over in some undocumented manner.

 

If anyone needs a stagnant version of dasm that ignores syntax errors, you can stick to the historic releases. There's little point in us continuing to develop dasm if it must be bug-for-bug the same as the old dasm.

[+batari]

Since all of the DASM developers are here and paying attention (and the current topic seems somewhat resolved), eventually it'd be nice to have a MacOS 64-bit version that runs on versions earlier than Catalina. It isn't a pressing issue, so I won't create an issue on GitHub.

[RevEng]

5 hours ago, batari said:

Since all of the DASM developers are here and paying attention (and the current topic seems somewhat resolved), eventually it'd be nice to have a MacOS 64-bit version that runs on versions earlier than Catalina. It isn't a pressing issue, so I won't create an issue on GitHub.

I wasn't aware of this, so thanks for the report. I've created an issue, because it is a pressing issue for me. All of my 7800basic and bB binaries work all the way back to Leopard/10.5. Unfortunately, for my recent releases I just bundled the dasm binary from github directly, rather than rebuilding it, so now the issue has spread to these projects.

 

I will say that Apple does make it rather difficult to support older OS releases. One needs to either hang on to very old releases, or build cross-compile environments around those same old releases. Trying to freshly install an old OS X with the old dev tools is very painful.

[Mr SQL]

14 hours ago, RevEng said:

Arguing that bad syntax that used to slip through should remain working "because history" isn't a good enough justification, nor is this "a QA issue" that slipped through. This was very intentional range-check we added, knowing full well it would break some source. As an assembly developer, you should be glad to have your errors flagged, rather than ambiguously plastered over in some undocumented manner.

I've competed in programming contests to see who could flag the most compiler warnings so I disagree  

 

Some warnings may bother you more than others, but having any warning break the binary changes it to a fatal error - which warning should change next so programmers may be glad to have more errors flagged instead of creating binaries??

 

I am curious what you have lined up, but I generally don't care for correcting or making other programmers correct already functioning structures in their code.

 

[+Pat Brady]

On 10/27/2020 at 4:26 AM, Mr SQL said:

I've competed in programming contests to see who could flag the most compiler warnings so I disagree  

 

Some warnings may bother you more than others, but having any warning break the binary changes it to a fatal error - which warning should change next so programmers may be glad to have more errors flagged instead of creating binaries??

 

I am curious what you have lined up, but I generally don't care for correcting or making other programmers correct already functioning structures in their code.

 

 

What you're advocating is: after the first release of a compiler, never introduce additional error checking. I think that is an extreme position.

 

In this specific case, the original programmer has already acknowledged that the code was incorrect and agreed with the DASM change.

[Mr SQL]

1 minute ago, Pat Brady said:

What you're advocating is: after the first release of a compiler, never introduce additional error checking. I think that is an extreme position.

 

In this specific case, the original programmer has already acknowledged that the code was incorrect and agreed with the DASM change.

I'm advocating we keep the mature compilers backward compatible so as not to break other programmers pre-existing code.

 

 @DEBRO might not have ever changed his code if the warning from the compiler had not turned into a show stopper to prevent it from working. 

 

I think the extreme position is breaking other peoples code, please explain why you disagree.

 

[+Stephen]

Breaking existing code may be bad, but accepting a number > 256 into an 8-bit register and not showing a warning is also bad.  Just my 2 cents.

[+Pat Brady]

25 minutes ago, Mr SQL said:

I'm advocating we keep the mature compilers backward compatible so as not to break other programmers pre-existing code.

 

 @DEBRO might not have ever changed his code if the warning from the compiler had not turned into a show stopper to prevent it from working. 

 

I think the extreme position is breaking other peoples code, please explain why you disagree.

 

 

"Backwards compatible" in this context is a polite way to say never add any new error checking.

 

The explanation of my position is simple: I believe the benefits of this particular error check outweigh the costs.

 

Ideally, it would be possible for the user to demote it to a warning (like an inverted form of GCC's -Werror options). But a feature like that, in a tool which is free to its users and costly to its maintainers, is firmly in DIY territory.

 

People who have code that compiles and works only with some old version of DASM, and who refuse to update their code, are certainly welcome to continue using their old version.

 

@DEBRO released his code 6 years ago. It was generous of him to do that, and it would be entirely reasonable for him to just say, this code works with DASM 2.20.11. Instead he is now updating it which is super-generous, since he completed the project so long ago. His stated purpose in releasing the code was to provide an example for other programmers. Fixing those expressions allows people to use the latest DASM, but aside from that, it makes the code a better example.

[Mr SQL]

3 hours ago, Pat Brady said:

"Backwards compatible" in this context is a polite way to say never add any new error checking...

No backwards compatible has nothing to do with error checking unless you escalate an error (change the category) so that the programs will no longer compile, adding additional warnings isn't a problem. I write IDE's and compilers and I think this is very important particularly when the library codebase becomes large.

 

3 hours ago, Pat Brady said:

His stated purpose in releasing the code was to provide an example for other programmers. Fixing those expressions allows people to use the latest DASM, but aside from that, it makes the code a better example.

Unless you can personally track down all of the prior source code downloads and mirrors and correct them all too then it makes the code examples more difficult to use for having to "correct it" first so that warnings that have been escalated to show stopping errors can be resolved so they no longer stop the show.

 

I don't think you realize that is what you are arguing; nobody is against compiler warnings, just the idea that some of them should be escalated into show stoppers that break the binary.

 

That's what I'm questioning. "Why do that?" there's no real answer besides pedantic reasoning and there are many compiler warnings to choose from so which one do you think should be turned into a show stopper next?  

 

[RevEng]

In this specific case dasm was told to reserve a byte of rom, and then it was told that the value the byte should hold is greater than 255. This is clearly a contradiction, which is why it's an error, rather than a warning.

 

Warnings aren't friendly errors that allow you to build your ambiguously or contradictingly defined code. Warnings are reserved for things that are technically valid syntax, which otherwise may be problematic.

 

If you're expecting on the fly typing, type conversion, and other fiddling behind the scenes, check out a higher level language like cc65. Assembly language is supposed to be precise, by design.

[+Andrew Davie]

Previous code can always use previous versions of dasm. In other words, there is always the capability to assemble old code, if you wish.

 

If allowing 16-bit values for 8-bit operands (and automatically taking the low byte) is so important to anyone then they can;

 

a) use a version of dasm that allows it, and stick to it

b) maintain a local version of dasm and keep that up to date with only the changes they approve/like.

b) fork dasm and re-implement the version you like.

 

That doesn't make the previous code correct. It's still faulty and contains syntactical errors even if the old dasm makes a few assumptions (such as taking the low byte of a 16-bit value) and assembles it to a functional binary.  But, given the use of a 16-bit value for an 8-bit operand, the end result may or may not be what the programmer actually intended.

 

Python redefined the print function between version 2 and 3.  Totally incompatible and it broke absolutely heaps of code. And rightly so - it was totally the right thing to do. The print in version 2, for example, was a poor implementation/design. No thoughts of "backward compatibility" there. Is Python 3 better than Python 2.  Yes, heaps.  Likewise, dasm has fixed this issue so that incorrect values are flagged as the errors they are. Is the latest dasm better than the older versions. Oh yes, heaps and heaps.

 

Warnings are not errors that we just let "sneak by" because we happen to like the incorrect behaviour.

 

I was always taught, and firmly believe, that with any assembler/compiler you treat warnings as errors.

Pretty much all my code compiles/assembles with zero warnings/errors.  And if I get a new version of a compiler/assembler that starts telling me that my old code now has new warnings/errors... I don't complain about the compiler... I fix my code.

 

That's the way it should be.