Q: Videx Videoterm

[Marc S Ressl]

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?

With the best wishes,

Marc.-

[Steven Hirsch]

Only one data point but, no, I've never seen this on a real Videoterm (or
Ultraterm for that matter).

[Marc S Ressl]

Thanks a lot for the reply!

Is there somebody else who can report something similar?
(I'm puzzled now! :-?)

[Nama]

I also have not seen ghosting on either my Videx Videoterm, or on a
VIdex Videoterm clone board that I also own.

[D Finnigan]

Marc S Ressl wrote:
>
> 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?
>

I think so, but it depends on the type of monitor being used. Some TV sets
have "slow" phosphor that takes a perceivable time to go dark.

--
]DF$
Mac GUI Vault - A source for retro Apple II and
Macintosh computing.
http://macgui.com/vault/

[Michael J. Mahon]

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."

[Marc S Ressl]

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)

[aiia...@gmail.com]

On Tuesday, May 22, 2012 11:27:55 PM UTC-7, 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 you have this done, please share it with the Applewin programmers.

it would be nice to have a videoterm for programming purposes (more
video output!)

[Michael J. Mahon]

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.

[Marc S Ressl]

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 :-).

[Marc S Ressl]

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.