Eudimorphodon
Veteran Member
So... why do you want to "undo" the scroll? Are you wanting to write software which directly "pokes" the screen instead of using the terminal routines provided by the card's firmware, and therefore need the video memory map in a known/consistent state? (Like it would be on a Commodore PET or whatever?) Because I kind of doubt that just scrolling backwards would in and of itself be particularly useful; this is a guess, but I would assume that it would make sense for the firmware routine for the card to blank the memory contents of the lines scrolled off the top so they'd be clean and ready to receive new contents when the cursor wraps back around the CRTC's memory buffer. Can't really know for sure, of course, without a dump of the firmware source code, which I can't seem to find.
(Closest I've found is this page, which has a brochure for the RM-65 but it doesn't have enough technical detail to really be useful.
There *is* on this page an application note for a 6845-based "TV interface" that looks like it may well be a prototype for the RM65, and this *does* have the assembly code for a video driver in it; however, it looks to me like this version of it does *not* use hardware scrolling? The only writes to the CRTC I can find after the initial register load are updates to the cursor registers; the start address register seems to remain untouched?)
Anyway, if you *know* the hardware address of the CRTC in the RM-65 you *could* just poke zeros into CRTC registers 12 and 13, that should put the start register back at the top of the video buffer, but the problem with this is that the CRTC will now be out of sync with the video driver's idea of where the screen lies. I mean, I guess that might be okay as long as you don't use the normal character I/O routines for the duration of the time you want to "direct-poke" the screen display? (It should "fix" the CRTC's programming the next time you output enough characters to trigger a scroll, although the actual screen contents are going to be messed up until you've refreshed the whole thing.) If you want to do it "right" then you're going to want to know the memory locations the driver uses to maintain the current video positioning pointers and poke new values into those to reset the screen driver to the "homed" position. Just be aware, of course, that if you mix direct VRAM poking with normal character I/O any operation that triggers a scroll is going to mess up your poking.