Steve

On Jan 17, 2:01*pm, Charlie <charlieD...@verEYEzon.net> wrote:
> On 1/17/2012 8:55 AM, Steve wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 15, 5:35 am, Antoine Vignau<antoine.vig...@laposte.net> *wrote:
> >> Please, Steve, for the non hardware guy I am, tell me if that would
> >> display the IIgs video modes? If so, I would be interested in your
> >> card. Unless your card deals with video output and not with Apple II
> >> video modes. I don't know, I don't understand!
> >> Thank you,
> >> antoine
>
> > Hi Antoine,
>
> > I dont know yet. ive been using an apple IIe to get it up and running
> > - but only with test screens at this point. I hope to give it a spin
> > on the IIgs at some point. Charlie has done some work on the IIgs
> > version for carte blanche.
>
> > Steve
>
> Hi Antoine and Steve,
>
> *From what I've seen and heard my code would probably work with only
> changes to the output pins. *Give it a try. *For what it's worth all my
> testing was done on a ROM 01 GS and it may have problems with a ROM 03.
> * I say this because Bill Garber who is testing my 6 bit, fixed palette
> code is getting errant pixels on his ROM 03. *I've also gutted all the
> code that is unrelated to video output (including the code to flash the
> Carte Blanche) so that I would have room in the FPGA BRAM for the
> palettes and for faster access when in the //e DHR mode.
> 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.
>
> Charlie

Hi Charlie,

Wow, even with the bugs you mentioned, that still sounds like great
progress!. This card and your code sounds like they could be very good
friends. All thats needed for a picture is pointers to each of you
colour groups (the 3x 4bits), active video cycle and sync. Ill clean
up my schematic and get it up on applelogic.

Steve

Daniel Kruszyna

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? Do you reimplement the IIgs video scanner
into a line or frame buffer which is then rescanned at the VGA frequency?
Or do you directly scan video ram with the VGA scanner?

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. This includes reading
palette and pixel data at the correct times. 3200 mode depends on software
modifying the palette tables while the screen is being drawn.

Also, what do you refer to by "overscanning modes"? Border tricks? If so, then
these also depend on software modifying the border register while the screen
is drawn.

Even if you duplicate the video scanner exactly, it is not synchronized to
the MegaII scanner which the software is reading. 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

Daniel Kruszyna

Steve <srkh28@gmail.com> wrote:
> Thats great info. Thats exactly why I chose it. I simply wanted to
> interpret the existing memory map into a HDMI framed data stream. I
> did make available dual edge triggering so as only 12 of the FPGA's IO
> can be used for transferring data to the device and the remaining 12
> FPGA IO's can still be used on carte blance's IDE connector. The last
> chip I used for HDMI was an analogix anx9804 - very nice device -
> produced both display port and HDMI/DVI, but way too fancy for a
> simple Apple II HDMI video card.

Why not output DVI directly from the FPGA? Is it an issue of remaining
logic area?

-- Daniel

Steve

> Why not output DVI directly from the FPGA? Is it an issue of remaining
> logic area?
>
> -- Daniel

Hi,

Well, it is possible, but not with the FPGA on carte blanche. The
Spartan 3E series cannot provide a transition minimized differential
signaling output to the monitor, which is what HDMI requires. Id also
have to either write or buy a DVI/HDMI parallel to serial video frame
formatter core, which either wont happen. The external chip is $7 and
is almost transparent, so a digital video interface can be realised
very easily with little logic required from the FPGA.

Steve

Charlie

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

Daniel Kruszyna

Charlie <charlieDOTd@vereyezon.net> wrote:

> 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?

The current state of the video scanner can be read at $c02e and $c02f. These
registers contain the horizontal and vertical counters which are used to
calculate which video ram address to access. A 3200 mode program will use these
counters to determine when to switch the palettes. Now, the VOC has its own
MegaII, with another set of counters. If the two sets are not synchronized,
then the software will store the palettes for one section of the screen while
the VGA scanner is actually drawing a different section.

(Also, for the record, there is a way to read the VOC counters directly.)

-- Daniel

Charlie

On 1/18/2012 3:24 PM, Daniel Kruszyna wrote:
> Charlie<charlieDOTd@vereyezon.net> wrote:
>
>> 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?
>
> The current state of the video scanner can be read at $c02e and $c02f. These
> registers contain the horizontal and vertical counters which are used to
> calculate which video ram address to access.

Yes, I understand this. My code does not use these register values for
anything.

> A 3200 mode program will use these
> counters to determine when to switch the palettes.

Okay. That's something I can look at.

> Now, the VOC has its own
> MegaII, with another set of counters. If the two sets are not synchronized,
> then the software will store the palettes for one section of the screen while
> the VGA scanner is actually drawing a different section.

Okay, that could be my problem, and if I'm understanding you correctly I
should be synchronizing the RGB/VGA output to the current state of the
video scanner at $c02e and $c02f. Thank you for the info.

> (Also, for the record, there is a way to read the VOC counters directly.)

Care to elaborate?

Charlie

Antoine Vignau

If that can be helpful, Brutal Deluxe's 3200-color display code can be
found in the disk image of the source code of The Tines @
http://www.brutaldeluxe.fr/sourcecode/thetinies.html

Antoine

Charlie

On 1/18/2012 5:54 PM, Antoine Vignau wrote:
> If that can be helpful, Brutal Deluxe's 3200-color display code can be
> found in the disk image of the source code of The Tines @
> http://www.brutaldeluxe.fr/sourcecode/thetinies.html
>
> Antoine

Thanks Antoine, I will take a look at it.

Charlie