You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
Check if it applies when reading raster position.
What's about MEGA65 feature to ask raster IRQ in physical rasters? Not implemented yet at all!
What's about MEGA65 feature to read current taster in physical rasters? Not implemented yet at all!
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 ...
The text was updated successfully, but these errors were encountered:
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".
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!!
I wrote a test program, running on real MEGA65: raster bars do not change position at all if V200/V400 mode is changed!
1.
and2.
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 BASIC65VSYNC
command in V400 mode as it may use (AFAIK) reading raster position and not setting an IRQ. UPDATE my newer test confirmed thatThe 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.
This is a bit confusing ...
The text was updated successfully, but these errors were encountered: