Loading playfield to RAM - issues/alignment

[+therealbountybob]

This follows on from some of my previous posts about trying to get a playfiled from Envision to load into assembler using IO...

 

 

I extracted the data bytes from an playfield map (first exported and then imported into mac/65) using BASIC and "put" them into a file that I am loading into RAM from my assembler game. I think the file is correct.

 

When it's loaded into RAM it does not display all the bytes on screen/align as expected acknowleging the envision file is only *255* bytes per row, not 256 - so it should be 1 position out per row: the exclamation points should be at column 39 on the first row seeping back 1 position for each row.

If I look at the display list in altirra it appears the screen is as I expect, each row starting on a new page at byte $00

DispList.txt

If you look at $4000 (the first row) you see bytes 3,4,5 which are [the coloured squares] at the start of each row in my test map and byte #133 which is at the last column (255)

RAM4000.txt

hope this makes sense, at first I thought it was the IO routine but I don't see how the bytes *are* in RAM at $4000,$4001,$4002 but not displayed? The "X"/$6e is at $4005 so should be in the 6th column!

 

any thoughts

[Rybags]

The DList looks fine. The problem is probably with your initial export of data which is doing groups of 255 rather than 256 which causes the backward creep.

[+therealbountybob]

The DList looks fine. The problem is probably with your initial export of data which is doing groups of 255 rather than 256 which causes the backward creep.

It's not the creep I'm posting about - it's the not displayed bytes at $4000-$4003 etc where they show in RAM but not on screen and the other bytes are moved further left

[Xuel]

Maybe check you HSCROL setting? Higher values will shift the screen to the left.

[phaeron]

If you are using a normal width playfield setting, remember that enabling horizontal scrolling increases the fetch width to wide, which will then shift scanlines left.

[+therealbountybob]

Thanks guys

Maybe check you HSCROL setting? Higher values will shift the screen to the left.

I think I have HSCROL set to 0 and the VBI scrolling code not enabled at this stage.

 

If you are using a normal width playfield setting, remember that enabling horizontal scrolling increases the fetch width to wide, which will then shift scanlines left.

I am using normal width (still early days or experimenting with the format), I'll have a look in my books but if you have a link about this would be useful.

 

Looks like I have one unexpected byte in my exported file on the 2nd 9th and 15th rows so I need to figure that out too [fixed this bit - it was the numbers, I'm now using two sets of leader bytes before the data bytes]

 

[edit]

yes it is this; when I have the screen display list showing position below 0 (right edge of playfiled is on left of screen) I can see these columns.

Edited April 23, 2019 by therealbountybob

[phaeron]

Thanks guys

I think I have HSCROL set to 0 and the VBI scrolling code not enabled at this stage.

 

I am using normal width (still early days or experimenting with the format), I'll have a look in my books but if you have a link about this would be useful.

 

Don't have such a link handy, but basically, horizontally scrolled normal width with HSCROL=0 is the same positioning and memory addressing as non-scrolled wide width. Wide width is 48 characters wide instead of 40, with the same center, so there are four more characters on the left. Thus, you need to use an LMS address four bytes lower to compensate.