Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MEGA65: raster position anomalies #418

Open
lgblgblgb opened this issue Nov 24, 2024 · 1 comment
Open

MEGA65: raster position anomalies #418

lgblgblgb opened this issue Nov 24, 2024 · 1 comment

Comments

@lgblgblgb
Copy link
Owner

lgblgblgb commented Nov 24, 2024

  1. Raster interrupt position in V400 modes are bad. My idea back to then: raster IRQs (and/or [?] reading back current raster) always meant in physical rasters, but it seems not the case: even in V400 mode, it seems to be in "logical rasters".
    I wrote a test program, running on real MEGA65: raster bars do not change position at all if V200/V400 mode is changed!
  2. Check if it applies when reading raster position.
  3. What's about MEGA65 feature to ask raster IRQ in physical rasters? Not implemented yet at all!
  4. What's about MEGA65 feature to read current taster in physical rasters? Not implemented yet at all!
  5. Check for 1. and 2. if it applies (and how) for the C65 emulator.

Original issue (1.) has been reported by FPhoton on Discord, thanks.

The logical raster stuff (MEGA65 + C65 too?)

Thus it seems, raster IRQs ("VIC-II style") are always measured in "logical rasters" (both in V200 and V400 modes), probably that's true for both of writing (setting raster IRQ position) and reading (for querying current raster) register $D012 (MSB 8th bit in $D011.7). So probably this Xemu bug also affected the BASIC65 VSYNC command in V400 mode as it may use (AFAIK) reading raster position and not setting an IRQ. UPDATE my newer test confirmed that

The physical raster stuff (MEGA65 only)

The other part of the story, is setting raster IRQ by physical raster, and querying raster position by physical raster.

GS $D052 VIC-IV:FNRASTERLSB Read physical raster position
GS $D053.0-2 VIC-IV:FN!RASTER!MSB Read physical raster position
GS $D053.7 VIC-IV:FNRST Read raster compare source (0=VIC-IV fine raster, 1=VIC-II raster), provides same value as set in FNRSTCMP
GS $D079 VIC-IV:RASCMP Physical raster compare value to be used if FNRSTCMP is clear
GS $D07A.0-2 VIC-IV:RASCMP!MSB Raster compare value MSB
GS $D07A.7 VIC-IV:FNRST!CMP Raster compare is in physical rasters if clear, or VIC-II rasters if set

This is a bit confusing ...

@lgblgblgb lgblgblgb self-assigned this Nov 24, 2024
@lgblgblgb lgblgblgb moved this to In Progress in MEGA65 emulator project Nov 24, 2024
lgblgblgb added a commit that referenced this issue Nov 25, 2024
Raster interrupt position in V400 modes are bad. My idea back to then was wrong:
raster IRQs (and reading back current raster) is in "physical rasters",
so different in V200/V400 modes.

However according to my tests on MEGA65, it seems, raster bars do not
change position at all, while toggling between V400/V200 mode. So
clearly they are measured in "VIC-II rasters" always, also called
"logical raster". The same seems to apply to reading current raster as
well, can be easily tested with the BASIC65 `VSYNC` command.

Introduced in branch "next".
@lgblgblgb
Copy link
Owner Author

Commit 05cca7c hopefully hopefully fixes the raster IRQ (in logical rasters!) position in V400 also for reading logical raster. Note: the red cross above before the short commit ID was caused by a travis build system problem only!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

No branches or pull requests

1 participant