Steven Seagal wrote:
I understand it so: once the MMU has started fetching video memory, it goes on while DE is asserted, so it would be between cycles 40 and 360 on a normal STE line. DE should stop at cycle 360, not 376 or one raster too many is fetched. But we know it stops at 376.
Or should we understand that during 'preload', the MMU fetches video memory without DE signal, without incrementing the video counter? This may seem "far fetched" (lol
Whatever's easiest to implement in silicon while staying backwards compatible is likely what Atari did. Since we know it's possible to always gain 16 extra pixels to the left we can safely assume that the combination of GLUE screen synchronization, MMU address counters and Shifter display can do scanlines that start at cycle 40 and end at 376.
I would assume the following, but then again, I've never done any STE specific coding. Too new-school for me.
$FFFF8264 r/w |....xxxx| Undocumented STE pixel hard scroll
$FFFF8265 r/w |....xxxx| STE pixel hard scroll
GLUE always asserts PRELOAD at 40. This signal is used by the MMU to put the current videomem address on the bus (*DCYC), the Shifter reads it and fills internal registers. Depending on the hardware scroll registers the Shifter either outputs the pixels immediately (which would cause them to appear 16 pixels early on screen compared to STF) or waits for 16 cycles to "match up". Whether the MMU lags behind in updating the video counters or not I guess we'd need to scope to really know.
The model above fits well with the STE 16-pixel trick, and the comments in the STEEM codebase: viewtopic.php?f=1&t=23461
GLUE always deactivates DE at 376. Either the MMU makes the extra words for a 168 byte lines available and just doesn't increase the video counters for the last 8 bytes depending on HSCROLL (I don't think there's an ack from the Shifter having read words), or the last 8 bytes is only put on the bus when needed.
HSCROLL is probably not handled only by Shifter, when HSCROLL<>0, one more raster must be fetched per scanline, it's not up to the Shifter.
Sure, but these chips are not likely to contain a lot of logic to handle separate functions - the workings are most likely the same as much as possible no matter the hw scroll registers.
I know it makes no sense but otherwise I don't see the use of DE in the Shifter. In his article Alien says it switches border/image, but the timings of DE don't support that.
Well, it's true for the STF, which Alien documented. That some changes (a "delay" function in the Shifter) happened in the STE doesn't take away much from it. I also don't see what you mean by it not being supported by the timings - it seems to fit to me