Jump to content
IGNORED

Back to the emulator...


robus

Recommended Posts

PMs - depends how accurate you want them to be.

You have the initial GRAF loads that can be by DMA early in the scanline or by CPU at any time.

Then you have triggering for display, not sure what the thresholds are there, it was a long time ago I played around with repeating players on a line.

I might be wrong but I reckon handling the priorities might be the hardest part.

Edited by Rybags
  • Like 1
Link to comment
Share on other sites

2 hours ago, Rybags said:

PMs - depends how accurate you want them to be.

You have the initial GRAF loads that can be by DMA early in the scanline or by CPU at any time.

Then you have triggering for display, not sure what the thresholds are there, it was a long time ago I played around with repeating players on a line.

I might be wrong but I reckon handling the priorities might be the hardest part.

I’m practicing TDD which is really helping me focus on particular situations in isolation.

Link to comment
Share on other sites

Some more progress, realized I was resetting the text "cursor" when switching between text modes (when there was no corresponding screen memory switch) which was causing some duplication, so the intro screen is now looking much nicer for Centipede:

 

What's puzzling is the centipede itself has gone missing, this happened because I saw that the mushrooms are character 0x40 which weren't showing up. I found that I was masking the Mode 4 chars with 0x3F (should have added a comment as to why), but removing that, while making the mushrooms appear has made the centipede disappear. I guess it's looking in a different bank of glyphs?

Monosnap Window 2023-12-19 17-06-53.png

  • Like 1
Link to comment
Share on other sites

Probably the wrong numbering scheme for P/M addressing. P/M fetches use the same vertical counter as VCOUNT, just sometimes without the division by two. For single-line mode, the address offset counts from 8 to 247 over the visible range, and for double-line mode, 4 to 123.

  • Like 2
Link to comment
Share on other sites

6 hours ago, phaeron said:

Probably the wrong numbering scheme for P/M addressing. P/M fetches use the same vertical counter as VCOUNT, just sometimes without the division by two. For single-line mode, the address offset counts from 8 to 247 over the visible range, and for double-line mode, 4 to 123.

I’ll look into that, but it’s also offset to the right by about 20 pixels. The docs say the HPOS is based on color clocks and that’s being driven by GTIA so I know exactly which color clock I’m on when I start drawing the player graphics. So I’m not sure how it could be so far off?

Link to comment
Share on other sites

57 minutes ago, robus said:

I’ll look into that, but it’s also offset to the right by about 20 pixels. The docs say the HPOS is based on color clocks and that’s being driven by GTIA so I know exactly which color clock I’m on when I start drawing the player graphics. So I’m not sure how it could be so far off?

Well, the obvious question is how are you numbering the color clocks? An HPOS value of 128 aligns the left edge of a P/M graphics object to the center of the playfield, 48 aligns flush left with the left edge of a normal width playfield, and 208 abuts against the right edge of a normal width playfield. If the P/M graphics logic is handling those coordinates correctly then the playfield must be misaligned.

 

  • Like 1
Link to comment
Share on other sites

7 hours ago, Rybags said:

How about just whip up a quick program that puts stuff in certain known positions and use it for verification rather than relying on something you have little control over?

That’s what I’m doing with my tests. :) But I’ve yet to do a precise measurement test as I thought it was just based on color clocks and I know the precise position of that as it’s all in GTIA.

Link to comment
Share on other sites

On 12/23/2023 at 11:28 PM, phaeron said:

Well, the obvious question is how are you numbering the color clocks? An HPOS value of 128 aligns the left edge of a P/M graphics object to the center of the playfield, 48 aligns flush left with the left edge of a normal width playfield, and 208 abuts against the right edge of a normal width playfield. If the P/M graphics logic is handling those coordinates correctly then the playfield must be misaligned.

This is definitely somewhere where things have gone wrong. I'm taking the described maximum of 228 color clocks as the entire width of a horizontal scan line, but that seems to be short. I've not seen any discussion of GTIA having additional color clocks beyond that, but it must be 256 if 128 is the center for PM graphics. Looking through the docs again for some more info on that.

 

Ah this helps from "De Re Atari"

Quote

There are only 228 color clocks in a singe scan line; furthermore, some of these are not displayed because of overscan. The horizontal position register can hold 256 positions; some of these are off the left or right edge of the screen.

 

Edited by robus
Link to comment
Share on other sites

10 hours ago, robus said:

This is definitely somewhere where things have gone wrong. I'm taking the described maximum of 228 color clocks as the entire width of a horizontal scan line, but that seems to be short. I've not seen any discussion of GTIA having additional color clocks beyond that, but it must be 256 if 128 is the center for PM graphics. Looking through the docs again for some more info on that.

The entire width of the scan line is 228 color clocks (114 cycles at two color clocks per cycle), but some of that is in horizontal blank and not visible. To be precise, the horizontal visible region for player/missile graphics is from 34 to 222, where HPOS=34 is flush left and HPOS=222 is just barely completely off-screen on the right. Thus, there are only 188 color clocks pertinent -- nothing can ever be visible and neither the playfield nor P/M graphics can trigger collisions outside of that horizontal range.

 

One of the reasons for this numbering is that there has to be at least 32 color clocks invisible on the left for quad-width players to be positionable partially off-screen. Any P/M graphics that intersect borders are clipped, so there has to be enough positions on both sides to completely scroll a player off the screen. Technically GTIA does process P/M graphics continuously over the entire 228 color clocks, but it takes some nasty hackery to observe this.

 

Note that the horizontal visible range for P/M graphics is not the same as for playfields -- wide playfields are asymmetrically clipped on the left further in than P/M graphics at hpos 44 to allow for horizontal scrolling.

 

  • Like 2
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...