Jump to content
Sign in to follow this  
therealbountybob

Loading playfield to RAM - issues/alignment

Recommended Posts

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.

post-19705-0-31948900-1555762201.png

post-19705-0-89055600-1555761974.png

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 :-o

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 :twisted: [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.

post-19705-0-41617200-1555864687.png

Edited by therealbountybob
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...