Re: Q: Videx Videoterm

[mressl@macgui.com (Marc S Ressl)]

Marc S Ressl wrote:
> Michael J. Mahon wrote:
>> Marc S Ressl wrote:
>>> Michael J. Mahon wrote:
>>> 
>>>>Marc S Ressl wrote:
>>>>
>>>>>Hello there,
>>>>>
>>>>>I am emulating the Videx Videoterm for OpenEmulator (and it is mostly
>>>>>done!), but I have a problem.
>>>>>
>>>>>When scrolling past the last line, there often appear ghosts from other
>>>>>lines at the last line. This also happens (more rarely) on some other
>>>>>parts
>>>>>of the screen.
>>>>>
>>>>>I can understand this as the Videx firmware takes quite some time for
>>>>>the
>>>>>scrolling, but something does not feel right. Is this ghosting visible
>>>>>on
>>>>>real boards?
>>>>
>>>>Marc, what, exactly, does the "ghosting" look like?  Is it a mixture
>>>>of the previous line with the new (scrolled) one?  Is it other random
>>>>lines showing up?  If so, do the ghosts show up preferentially at one
>>>>place, or are they pretty uniformly distributed?
>>>>
>>>>It's been years since I looked at the Videoterm code, but if it updates
>>>>the SRAM asynchronously with 6845 refresh, then line "mixing" can easily
>>>>occur.  (I don't mean electrically asynchronously, just unsynchronized
>>>>with the video frame generation.)  This is the result of 6845 video
>>>>generation proceeding as the buffer contents are moved.
>>>>
>>>>If the code makes an attempt to synchronize with the 6845 horizontal or
>>>>vertical blanking interval (which would account for some slowness), then
>>>>the emulation of the status reads that permit this synchronization may
>>>>not be working properly, resulting in unsynchronized text buffer updates
>>>>and consequent visible line mixing.
>>>>
>>>>Some simple test cases with scrolling lines of different contents
>>>>and/or lengths should case some light on the cause.
>>>>
>>>>-michael
>>>>
>>>>NadaNet 3.1 for Apple II parallel computing!
>>>>Home page:  http://home.comcast.net/~mjmahon/
>>>>
>>>>"The wastebasket is our most important design
>>>>tool--and it's seriously underused."
>>>>
>>> 
>>> 
>>> Hi Michael!
>>> 
>>> Thanks a lot for your blessings :-)!
>>> 
>>> I guess an image is worth a thousand words, so here go two images:
>>> 
>>> http://openemulator.googlecode.com/files/Videx%201.png
>>> (here you see the ghosting at the lower right, this happens fairly
>>> often,
>>> several times per second)
>>> 
>>> http://openemulator.googlecode.com/files/Videx%202.png
>>> (here you see the ghosting+another effect in the middle of the screen,
>>> this
>>> happens not very often, maybe one time per 2-3 seconds)
>>> 
>>> With the best wishes,
>>> 
>>> Marc.-
>> 
>> So the frequently occurring "ghost" line at the lower right is
>> the line just scrolled off the top of the screen, while the
>> less frequently occurring ghost looks like lines horizontally
>> displaced from where they were prior to a few scrolls.
>> 
>> Do these "ghosts" only last one video frame, or do they persist
>> longer?  (I'm betting only one frame, hence "ghost".)
>> 
>> I'm still guessing that this is a problem with unsynchronized
>> updated to the card's text buffer.
>> 
>> I've forgotten how the Videoterm scrolls.  Does it actually move
>> the buffer contents, leaving the 6845 address pointers alone, or
>> does it treat the text buffer like a circular buffer, updating
>> the 6845 address registers?
>> 
>> Clearly, something is not happening at the right time in this
>> process.
>> 
>> -michael
>> 
>> NadaNet 3.1 for Apple II parallel computing!
>> Home page:  http://home.comcast.net/~mjmahon/
>> 
>> "The wastebasket is our most important design
>> tool--and it's seriously underused."
>>
> 
> Hi Michael:
> 
> yes, by ghosts I mean single frames that are incorrectly rendered.
> 
> The Videoterm uses the MC6845's start address register for scrolling (as
it
> is supposed to be used). So when you scroll, the video RAM start address
is
> advanced 80 characters, and therefore some characters of older lines could
> be visible at the line that just "appeared".
> 
> I just did some math, and 80*24 = 1920. The Videx has 2048 bytes video
> memory, so there is extra space after the last line for 2048-1920 = 128
> characters.
> 
> So right now I think I must be doing something wrong, as there must be
some
> provision in the Videoterm code for clearing the extra characters after
the
> last visible line. Or maybe there wasn't and the ghosting did in fact
> occur.
> 
> I just thought it would be easier to ask on CSA2 instead of spending time
> trying to understand 1980's code :-).
> 
> With the best wishes,
> 
> Marc.-
>

I found the problem and it was of course silly :-). I was updating video at
the wrong time.

Now the ghosting of the lines in the middle is almost gone (as I expected),
but the ghosting at the bottom remains because the Videoterm firmware seems
to change the MC6845 start address first, and erases the line next. Maybe a
different firmware fixes that, I have 2.4.

With the best wishes,

Marc.-