A couple of programmnig questions

[jacobus]

I’m having a few programming issues (which I don’t believe are related to the development language) that I thought I’d throw out to see if anyone has an idea.

 

1. As per the attached DL fragment, I have set up a scrolling playfield using an entire page per line. As that the LMS instructions are set to the start of each page, and I write to the beginning of those pages, I have every reason to believe that the data I write should show up exactly at the left hand edge of the screen. It does not. The screen appears to be scrolled over 4 bytes to the right, and even with the LMS set to the start (0), I can’t see the start of the data.

112 ;blank lines

128 ;DLI

112 ;blank lines

194,192,63 ;text line

0 ;blank line

116,0,8 ;scrolling Antic 2

116,0,9 ;scrolling Antic 2

116,0,10 ;scrolling Antic 2

116,0,11 ;scrolling Antic 2

116,0,12 ;scrolling Antic 2

 

I can get around this issue by offsetting my writes by 4 bytes, but this issue continues to bug me.

 

1. As per the attached executable, I’m getting some corruption on the right hand side of the playfield. Debug mode of Altirra shows nothing there. Code written to dump the locations shows zeros in that area, but apparently random $0F’s written and cleared throughout the lower part of RAM (under 10K) as well as the more stable phantom corruption at the far right.

In the attached program, pressing “L” will print all non-zero locations between page 8 and page 32 – make sure Altirra’s printer is configured and activated. “L” will fill the same area with $03’s.You will notice that the three bytes of corruption at the right side cannot be over written.

Any ideas for either of these issues would be very welcome! Thank you!

TEST1.atr

[Xuel]

Horizontal scrolling skips pixels at the start of the line. You can minimize the number of pixels skipped by setting HSCROL to 15 but I think one pixel is still skipped. See the Altirra hardware manual for details.

[jacobus]

Horizontal scrolling skips pixels at the start of the line. You can minimize the number of pixels skipped by setting HSCROL to 15 but I think one pixel is still skipped. See the Altirra hardware manual for details.

Thanks Xuel, I did play with HSCROL, but the offset is 4 chars or 16 pixels - far more than fine scrolling can account for.

[MaPa]

It's not far more, it's 1 pixel more as fine scrolling can scroll up to 15 pixels.

 

I don't know what exactly you mean by the corruption on the right side of playfield, but I assume it's the fact that you scroll by LMS too far to the right (you are scrolling LMS up to $d8=216 so then add 4 chars hidden at the left screen edge=220, and next 40 bytes visible on the screen going to 260=byte "overflow"), so you see 4 characters at the right side which are 4 bytes from the beginning of the next page or start of 4kB block if it's crossing its' boundary.

[jacobus]

It's not far more, it's 1 pixel more as fine scrolling can scroll up to 15 pixels.

 

I don't know what exactly you mean by the corruption on the right side of playfield, but I assume it's the fact that you scroll by LMS too far to the right (you are scrolling LMS up to $d8=216 so then add 4 chars hidden at the left screen edge=220, and next 40 bytes visible on the screen going to 260=byte "overflow"), so you see 4 characters at the right side which are 4 bytes from the beginning of the next page or start of 4kB block if it's crossing its' boundary

If you scroll over to the right (all the way) you will see a single blue block on what appears to be the eighth line of the PF. On either side of this character are two more - they will become visible if you press the "F" key. They only appear on this line, and always in the same configuration and they cannot be overwritten. My first thought was, OK, something is writing to these locations. It's not my code, and it's not DOS. Interestingly enough, according to the memory dump these locations are filled with zeros - the 'corrupt" data only shows on the screen.

[+playsoft]

As MaPa says, when you have fully scrolled to the right you have a lms like this in the display list:

 

mode.v.h 4 @ 0FD8

 

With horizontal scrolling enabled (and HSCROL set to 0) ANTIC reads 48 bytes and displays the middle 40.

 

So ANTIC would read FD8..1007 and display FDC..1003 - but it can't go over a 4K boundary so it actually displays FDC..FFF 0..3.

[Rybags]

With H-Scrolling you have to note a few things:

. the memory used per line will be 8 bytes more than normal. Narrow mode will fetch 40 bytes rather than 32, Normal mode 48 bytes instead of 40.

. with HSCROL=00 you will have non-visible characters to the left of the normal display start. Even in Wide mode, not all 48 characters are ever visible, only 44.

. you can't just set up a screen mode using the OS then convert it all to HScrolling - since more memory is used you'll probably cross a 4K boundary. So best method is setup the mode yourself taking the 4K crossovers into consideration.

[Xuel]

@jacobus Instead of using values 0-3 for HSCROL try using values 12-15. This has two benefits: 1) less ANTIC DMA since 3 fewer characters need to be fetched, 2) the visual glitch you're getting due to 4K wrapping will be shifted off screen.