compiles fine on one mac, breaks on my mac and windows box???

[kisrael]

So @Karl G has been kind enough to help me out with some kernels on my large graphic (48px / PFs / bB PFs) editor https://alienbill.com/2600/atari-background-builder/

 

We ran into an interesting problem - attached is splash116.asm - PF code the editor makes out of Karl's template, using 116 scanlines

 

When he compiles it, he gets the attached karl_splash116.bin that looks like this

 

but when I compile it on my machine - (whether in Atari Dev Studio or freshly downloaded DASM, and also in Atari Dev Studio on an old windows laptop I have handy) I get kirk_splash116.asm.bin which makes the following:

 

Attached are the macro.h and vcs.h files we use.

 

In trying to figure this out, I took a close look at macro.h and vcs.h - they are both the 2003 1.05 versions that ... i guess most people use? Some differences including a cc0 license at the top, and then some CR/LF and other white space differences. I did try a few variations on that, but I always get the same result on my mac. And like I said, that's in Mac ADS, windows ADS, and command line dasm ala
 

dasm splash116.asm -f3 -lspash116.lst -ssplash116.sym -osplash116.bin

Real head scratcher. I'm super rusty on kernel stuff (especialy if it... involves page boundaries? Like 112 length things work fine on my machine too) and it smells like a page boundary stuff... I think... but any thoughts of what to look at, or just compiling splash116.asm and saying you get a "karl" version or "kirk" version would be interesting. 

splash116.asm karl_splash116.bin kirk_splash116.asm.bin macro.h vcs.h

[+Andrew Davie]

Will look at it as soon as I escape from this fog/funk/headache I'm brewing.

But just one comment...

 

playfield_scanlines=#playfield_lines*#playfield_line_height
remaining_lines=#kernel_lines-#playfield_scanlines-#padding_lines-2

 

Ditch the "#" in these lines. It is incorrect to have, as it means "immediate addressing mode".

In my view these lines should be flagged as an error by DASM, but clearly they're not.

 

In the context above, you are just defining values for the assembler to use; it's a calculation.  So as I said, drop every # from them.

 

[+Andrew Davie]

The images immediately make me think of a page crossing error causing timing differences.

 

[+Andrew Davie]

WHen I assemble/run the "splash116.bin" i get the "correct" display.

 

[+Andrew Davie]

WHen I use your provided macro.h/vcs.h I get the incorrect display.

Here are the "correct" macro.h and vcs.h which worked for me....

I have not analysed the differences; but this shouldn't be happening.

macro.h VCS.H

[+Andrew Davie]

Just one note; when you have page-aligned tables, but you access them with "lda table-1,x"...

well, you're effectively FORCING a +1 cycle hit on all of those tables, because that address is now guaranteed to cross a page when x >0

Which it always is.  This is not an ideal way to do things. Better to allow your x register to be from 0 to lines-1, rather than 1 to lines.

Then you access the ables with "lda table,x" and have no page crossing hit.

 

Another way to solve this, rather than changing your index value, is to put a dummy byte at the start of all tables, and access with "table,x".

Edited April 26, 2021 by Andrew Davie

[+Andrew Davie]

The safest and latest vcs.h and macro.h files are those distributed with dasm.

https://github.com/dasm-assembler/dasm/tree/master/machines/atari2600

 

[+Karl G]

4 hours ago, Andrew Davie said:

The safest and latest vcs.h and macro.h files are those distributed with dasm.

https://github.com/dasm-assembler/dasm/tree/master/machines/atari2600

 

Does DASM have any default directories where it looks for includes apart from the current directory? I know how to specify one on the commandline, but I didn't see anything in the docs about any default places it may look.

[kisrael]

6 hours ago, Andrew Davie said:

The safest and latest vcs.h and macro.h files are those distributed with dasm.

https://github.com/dasm-assembler/dasm/tree/master/machines/atari2600

 

Thanks for looking at this! I will grab the latest and retry when I have some cycles after work.

 

As far as you know, are these pretty robust against CRLF / whitespace issues? 
 

[+Andrew Davie]

If you look at the cycle counts for the draw loop, the loads being off by one, it's clear that you are using > 76 cycles/line...

I redid the counts taking into account the page crossings (+1 cycles) on the loads...

PlayfieldLoop
   sta WSYNC                       ; 3     (0)
   lda PFColors-1,x                ; 5     (5)
   sta COLUPF                      ; 3     (8)
   lda PF0DataA-1,x                ; 5     (13)
   sta PF0                         ; 3     (16)
   lda PF1DataA-1,x                ; 5     (21)
   sta PF1                         ; 3     (24)
   lda PF2DataA-1,x                ; 5     (29)
   sta PF2                         ; 3     (32)
   lda PF0DataB-1,x                ; 5     (37)
   tay                             ; 2     (39)
   lda PF1DataB-1,x                ; 5     (44)
   sta PF1                         ; 3     (47)
   sty PF0                         ; 3     (50)
   lda PF2DataB-1,x                ; 5     (55)
Check0
   sta PF2                         ; 3     (58)
   dec PlayFieldHeightCounter      ; 5     (63)
   bne ____skip_new_row            ; 2/3   (65/66)
   lda #playfield_line_height      ; 2     (67)
   sta PlayFieldHeightCounter      ; 3     (70)
   dex                             ; 2     (72)
   beq ____done_playfield_rows     ; 2/3   (74/75)
____skip_new_row
   jmp PlayfieldLoop               ; 3     (77)    <<<< whops, and then a WSYNC = 80 = 4 cycles over



____done_playfield_rows

 

Well that explains the odd display.

I don't yet know/understand why it's different with the different header files.

 

2 hours ago, Karl G said:

Does DASM have any default directories where it looks for includes apart from the current directory? I know how to specify one on the commandline, but I didn't see anything in the docs about any default places it may look.

Have you read the manual?  It's pretty comprehensive. Offhand, I don't think so, just the base directory from where it is instantiated.

Irony is, though I wrote the manual, I'd have to read the manual to know the correct answer for sure. It's pretty comprehensive.

 

13 minutes ago, kisrael said:

As far as you know, are these pretty robust against CRLF / whitespace issues? 

 

I'm not aware of any issues. From the manual... "Both Windows-style (carriage-return, line-feed) and Unix-style (line-feed)

line endings are supported by dasm."

 

 

[+splendidnut]

I'm constantly moving DASM-based projects between Windows and Macs... and so far I haven't hit any issues with line ending characters tripping up assembly.

[kisrael]

Aha, that's it!

on git macro.h is at 1.09 and vcs is at 1.06

my old versions were at 1.05 - and those are the ones ADS tends to use for bB maybe? Hmm.

(for DASM ADS uses vcs at 1.06 and macro at 1.09)

9 hours ago, Andrew Davie said:

The safest and latest vcs.h and macro.h files are those distributed with dasm.

https://github.com/dasm-assembler/dasm/tree/master/machines/atari2600

 

aha, I was wondering/asking about this but not hard enough. 

 

I wonder if bB should use newer files, or if it just risks breaking things.