[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HDMI Video/Audio Card
On 1/18/2012 9:00 AM, Daniel Kruszyna wrote:
Charlie<charlieDOTd@vereyezon.net> wrote:
The picture I'm getting for normal 640 and 320 GS modes is as good as
any I've ever seen. Better than the Apple IIgs RGB monitor if you can
take the facts that there are no side borders and the picture is so
sharp that there is no dithering. The 320 Fill mode has a bug (I'm
working on that). Weird modes that do over-scanning don't work
correctly and for some reason 3200 color pictures are a mess.
How do you convert to VGA timing?
Using a DCM (digital clock manager) in the FPGA. Using the 14MHz
external crystal as input to the DCM we get 50MHz which is used as the
system clock. That is divided to 25MHz which is used to output 12bits
of digital RGB. Then putting resistors on the each bit's output makes
it acceptable to the monitor's VGA input. Hsync and vsync are also
generated from the 25MHz clock. This was all done in the original JAT
code written by Alex Freed and/or Steve. As far as the VGA itself is
concerned the only thing I've changed is the number of bits and where to
output them. The original had 6 bits from the video connector, mine has
12 bits from the IDE connector.
Do you reimplement the IIgs video scanner
into a line or frame buffer which is then rescanned at the VGA frequency?
Yes. All the video data is buffered. That is, everything that is in
video RAM on the Apple is duplicated in the SRAM on the Carte Blanche
card and in my 12bit code some of it is in the BRAM (block RAM) in the
FPGA and I even have some in an array of registers.
Or do you directly scan video ram with the VGA scanner?
No I don't think there is any way to do that from a card in a slot
without effecting the Apple's operation. But I'd love to hear other
opinions/ideas.
I'm not saying whether this is worth it or not, but to get things "just right",
you need to duplicate the IIgs video scanner exactly.
Agreed, I am hoping to do just that.
This includes reading
palette and pixel data at the correct times.
Yes, I believe this is where the problems arise in my code and I've been
"playing around" with the timing. Unfortunately, I've found no
documentation of what the timing should be so I'm pretty much reduced to
trial and error. At the present time the palette data and scan line
byte data are read at the same time from the BRAM and theoretically the
pixel data is read from the SRAM at the same time. I have figured that
I may have to delay slightly one or more of these "reads" in some kind
of sequence but I haven't made any headway yet.
3200 mode depends on software
modifying the palette tables while the screen is being drawn.
Understood.
Also, what do you refer to by "overscanning modes"? Border tricks?
Overscanning may be the wrong word. What I mean is there are programs
that do things like put horizontally scrolling text in the borders.
There is also a program called Overcycle that moves a multi-colored
(shades of blue) bar from top to bottom of the screen and back. The bar
extends into the borders top, bottom and sides.
If so, then
these also depend on software modifying the border register while the screen
is drawn.
The Carte Blanche code monitors all writing to all the registers.
Even if you duplicate the video scanner exactly, it is not synchronized to
the MegaII scanner which the software is reading.
I'm not sure what you mean. If you are referring to the fact that the
GS video modes output at a different dot clock you are correct. I'm not
doing that and therefore I get no side borders.
You can synchronize with
the SYNC signal, but it's only available on slot 7, which doesn't have the
also necessary M2B0 signal.
The Video Overlay Card is in a similar situation,
but in that case, you can connect the IIgs composite out to the VOC to cause
it to sync.
-- Daniel
I don't see any need to do any more syncing than is being done. The
non-GS video modes are very good. What would syncing with the composite
out to the VOC achieve?
Charlie