How does the apple2 RGB card work?
General_Failure
I'm feeling a little disappointed after losing an ebay auction for an
apple2 RGB card to snipers.
So, in my usual spirit, If I can't get something at a decent price I
make my own.
Are there any schematics in existence for an RGB card?
If not, can someone enlighten me on how it gets hold of the necessary
video data?
If I can find out enough, I'll probably build one on one of those
wonderful 8-bit babies.
Another If. If it is as simple as listening to the bus for certain
memory writes to track the mode and the screen data, I can see a nice
cached card with a VGA frequency horizontal refresh being relatively
easy. Relatively.
Of course, TTL levels would be a lot easier. Small steps and all that.
Bryan Parkoff
news:1148636626....@u72g2000cwu.googlegroups.com...
I am sorry to hear since you lost eBay auction. It is an offical Apple
//e's 80 Col / RGB card what you are referring. I am not aware if it has
only RGB card existence for Apple II+. There is no schematic existence. It
is very rare to find.
It is only the way to draw schematic in your own by looking at 8-bit 80
Col / RGB card because it is much simpler and less complex.
KnutRoll-Lund has succeeded building an adapter from DB-15 (80 Col / RGB
card) to DB-9 (CGA) for any CGA monitors because AppleColor M100 monitor is
rare to find. The 16 wrong colors do not look identical to Apple II colors,
but it is only acceptable what we have now. Knut used GAL16V8 chip to swap
some out of 16 colors to almost match Apple II color.
Right now, he and I are working together to develop schematic. After
the schematic is developed, he may be able to design aux controller card for
VGA monitor, but it is almost impossible to deal between 15.734K and 30K
horizontial freq. DMA may be needed.
For couple weeks, I have been working using Oscilloscope to capture
video binary from Apple //e's 80 Col / RGB card and Apple IIgs' RGB. I will
let all of folks know when 4,096 possibilities of data in a table for video
binary is complete.
Bryan Parkoff
swtow...@hotmail.com
I have a spare RGB monitor card for the IIe. If you want one to
take apart and study, or just to put in your IIe and use, let me know.
swtownsend(at)hotmail.com
General_Failure
>Hello,
Yes. Yes. Yes.
For both study and use. I'll send you an e-mail.
I've just been figuring out how to use gschem (So much neater than
hand-drawn). I'd have no objections to doing a simple circuit trace and
schematic for those who are interested.
I'm going to be doing the same on a C64 Viatel adaptor I have in the
near future too.
Unlike Mr. Parkoff, unfortunately I don't have things like a CRO, but I
can usually figure out the ins and outs of a circuit fairly quickly. I
am very interested to see the results of his research though, because
like I said, I don't have access to the equipment.
Having a //e platinum can make ascertaining the 'big picture' a little
difficult at times too because of the custom ICs.
Bryan Parkoff said:
> Right now, he and I are working together to develop schematic. After
>the schematic is developed, he may be able to design aux controller card for
>VGA monitor, but it is almost impossible to deal between 15.734K and 30K
>horizontial freq. DMA may be needed.
Speaking from a nonspecialised viewpoint, I can't understand why these
may be problematic.
If you are talking about directly pumping data to the monitor, then
yes, it is a problem. However, if all you want to do is perform an RGB
encoded version of what is being displayed via the video out, it is a
little simpler.
CGA and EGA monitors run at ~15Khz horizontal refresh, as does the
video out.
What I am uncertain of is whether the memory reads for the video
display are opaque to the expansion bus.
If not, then listening to the reads performed should be sufficient to
create the basis of a fully mirroring RGB device.
The sync signals are another matter which I am unable to address
currently.
If the card were to cache the writes done to the video area of memory,
it would render the card independent of the bus and allow custom
refresh rates.
Recently I have been considering the merits of interfacing an 8-bit VGA
ISA bus card to other architectures. So far I have not come up with any
reasons why it would not be possible.
There is an upside and downside to doing this:
-Upside-
*Heaps of pretty colours
*A second display
*The use of modern monitors
*Standard set of registers make VGA easily programmable
*VGA cards have their own RAM, thus having near nil impact on system
performance
-Downside-
*Custom written software would be needed
*The adapter would be bulky
Bryan Parkoff
I want to make sure what I understand your view. You want video modes
(TEXT40/80, LORES40/80, and HIRES40/80) from aux/main memory to be mapped
into video memory. Then RGB card reads video memory and displays pixel by
pixel to the screen.
I do not think that 80 Col / RGB card have video memory. It only runs
at 1/14M or 70 ns to read NTSC pulse from aux or main memory. NTSC pulse
goes through the RGB circuit to translate into R, G, B, and I signal. RGBI
forms a pixel to the screen. It is how 15.734K horizontial freq is
manipulated from 14M. I am not too sure if EGA is 15.734K.
You ask about sync. H sync and V sync are created through logical truth
table from videocounter and H sync and V sync are combined into composition
sync to the NTSC monitor. RGB card receives C sync and separate it into H
sync and V sync because most analog / digital monitors don't have C sync
except Apple IIgs' analog RGB monitor.
You can design a video card to create video memory which it allows to
copy byte by byte from aux and main memory into video memory. It will not
depend on 14M, but it uses its own frequency to maniuplate VGA or higher
resolution.
Is it what you are referring? It is what I am doing to capture video
data from R, G, B, and I signal and also well with Apple IIgs' RGB signals.
Bryan Parkoff
General_Failure
> I want to make sure what I understand your view. You want video modes
>(TEXT40/80, LORES40/80, and HIRES40/80) from aux/main memory to be mapped
>into video memory. Then RGB card reads video memory and displays pixel by
>pixel to the screen.
Yes. Well, partially. It's more of a mirroring than mapping. I was
thinking of a card which keeps a copy of the video data on its own
board. The video data is based on listening to write accesses performed
on the video area of memory. The card would never need to interact with
the system bus, except in its passive listening state.
> I do not think that 80 Col / RGB card have video memory.
The 80 column/language card in my //e does. It has 64kb. However I
suspect that the RGB card does not. Having never seen an actual unit or
a schematic of one I cannot tell.
> It only runs
>at 1/14M or 70 ns to read NTSC pulse from aux or main memory. NTSC pulse
>goes through the RGB circuit to translate into R, G, B, and I signal.
By NTSC pulse from memory, what exactly do you mean? Are you saying
that the colour data in memory is pre-encoded with NTSC modulation. Ie
with the phase shifts coded into the colour information?
> RGBI
>forms a pixel to the screen. It is how 15.734K horizontial freq is
>manipulated from 14M. I am not too sure if EGA is 15.734K.
EGA is also the same to my knowledge. It is just a minor extension to
CGA.
VGA was the first to use the faster HSync.
> You ask about sync. H sync and V sync are created through logical truth
>table from videocounter and H sync and V sync are combined into composition
>sync to the NTSC monitor.
Right, so it's done in the video counter. That makes sense.
RGB card receives C sync and separate it into H
>sync and V sync because most analog / digital monitors don't have C sync
>except Apple IIgs' analog RGB monitor.
Are you saying that the built in video creates a seperate H and V sync,
and then combines them. And then the RGB card has to re-split them for
its own use? I feel as if I have misunderstood you. Please correct me
if I am wrong about what I have said.
> You can design a video card to create video memory which it allows to
>copy byte by byte from aux and main memory into video memory. It will not
>depend on 14M, but it uses its own frequency to maniuplate VGA or higher
>resolution.
More or less. Except it doesn't perform any operations of its own. It
just listens and updates its own RAM accordingly.
To achieve much higher resolution, including colour depth, a register
based approach would be easiest. Ie, a PIO mode single byte write to
the fictional graphics card's memory, or a simple register based memory
banking to expose a window of the card's RAM to the system bus.
I am just taking these ideas from the way graphics are implemented in
x86 machines. It is not the best way, but it is designed for a legacy
system.
> Is it what you are referring? It is what I am doing to capture video
>data from R, G, B, and I signal and also well with Apple IIgs' RGB signals.
At which point are you capturing the signal?
Bryan Parkoff
> Bryan Parkoff Said:
>> I want to make sure what I understand your view. You want video modes
>>(TEXT40/80, LORES40/80, and HIRES40/80) from aux/main memory to be mapped
>>into video memory. Then RGB card reads video memory and displays pixel by
>>pixel to the screen.
>
> Yes. Well, partially. It's more of a mirroring than mapping. I was
> thinking of a card which keeps a copy of the video data on its own
> board. The video data is based on listening to write accesses performed
> on the video area of memory. The card would never need to interact with
> the system bus, except in its passive listening state.
>
>> I do not think that 80 Col / RGB card have video memory.
> The 80 column/language card in my //e does. It has 64kb. However I
> suspect that the RGB card does not. Having never seen an actual unit or
> a schematic of one I cannot tell.
Actually, 80 Col / RGB card does not have video RAM, but it does have
AUX RAM. AUX RAM is used to hold data for Text, LoRes, and HiRes in 80
column. I believe that it has 8 chips to hold 64KB.
>
>> It only runs
>>at 1/14M or 70 ns to read NTSC pulse from aux or main memory. NTSC pulse
>>goes through the RGB circuit to translate into R, G, B, and I signal.
> By NTSC pulse from memory, what exactly do you mean? Are you saying
> that the colour data in memory is pre-encoded with NTSC modulation. Ie
> with the phase shifts coded into the colour information?
Well, one byte is loaded from main memory or aux memory into Load/Shift
Register. One bit is loaded and shifted out to the NTSC monitor. RGB card
has similiar Load/Shift Register, but it does read a group of four phase
shift while it translates into R, G, B, and I signals. RGBI signals have
color information, but phase shift does not.
>
>> RGBI
>>forms a pixel to the screen. It is how 15.734K horizontial freq is
>>manipulated from 14M. I am not too sure if EGA is 15.734K.
> EGA is also the same to my knowledge. It is just a minor extension to
> CGA.
> VGA was the first to use the faster HSync.
>
>> You ask about sync. H sync and V sync are created through logical
>> truth
>>table from videocounter and H sync and V sync are combined into
>>composition
>>sync to the NTSC monitor.
> Right, so it's done in the video counter. That makes sense.
>
> RGB card receives C sync and separate it into H
>>sync and V sync because most analog / digital monitors don't have C sync
>>except Apple IIgs' analog RGB monitor.
>
> Are you saying that the built in video creates a seperate H and V sync,
> and then combines them. And then the RGB card has to re-split them for
> its own use? I feel as if I have misunderstood you. Please correct me
> if I am wrong about what I have said.
Almost correct. Understanding the Apple //e manual gives the pinout of
AUX slot connector. It does tell C sync. I can't remember if it has H sync
and V sync. It is why RGB card has to output only C sync because CGA
monitor does not have C sync because it does not split C sync into H sync
and V sync. You can build an adapter which it has LM1881 chip. LM1881 chip
splits C sync into H sync and V sync.
I have tested in my Oscilloscope to show that H sync and V sync are
identical. It seems that LM1881 chip is not necessary. It is possible to
use Y splitter so C sync can connect to H sync and V sync directly through Y
spliter. It will work.
>
>> You can design a video card to create video memory which it allows to
>>copy byte by byte from aux and main memory into video memory. It will not
>>depend on 14M, but it uses its own frequency to maniuplate VGA or higher
>>resolution.
> More or less. Except it doesn't perform any operations of its own. It
> just listens and updates its own RAM accordingly.
>
> To achieve much higher resolution, including colour depth, a register
> based approach would be easiest. Ie, a PIO mode single byte write to
> the fictional graphics card's memory, or a simple register based memory
> banking to expose a window of the card's RAM to the system bus.
>
> I am just taking these ideas from the way graphics are implemented in
> x86 machines. It is not the best way, but it is designed for a legacy
> system.
>
>> Is it what you are referring? It is what I am doing to capture video
>>data from R, G, B, and I signal and also well with Apple IIgs' RGB
>>signals.
>
> At which point are you capturing the signal?
>
I don't agree with most emulator projects because I claim that video
data is completely wrong for DHGR and HGR. I appreciate the programmer's
efforts to guess and build video data in their own. It is why I have to
capture R, G, B, and I signals at video cycle by video cycle. Then I
translate RGBI signals into 12 pixels. I place 12 pixels in the 4,096
possible data in a table. I believe that this table can correct video data
which it looks true VGA monitor like Apple IIgs' analog RGB monitor. DHGR
and HGR will look correct according to my efforts of capturing RGBI signals.
Bryan Parkoff
Michael J. Mahon
> Bryan Parkoff Said:
>
>> I want to make sure what I understand your view. You want video modes
>>(TEXT40/80, LORES40/80, and HIRES40/80) from aux/main memory to be mapped
>>into video memory. Then RGB card reads video memory and displays pixel by
>>pixel to the screen.
>
>
> Yes. Well, partially. It's more of a mirroring than mapping. I was
> thinking of a card which keeps a copy of the video data on its own
> board. The video data is based on listening to write accesses performed
> on the video area of memory. The card would never need to interact with
> the system bus, except in its passive listening state.
And you would also have to track Main/Aux bank switches, too.
>> I do not think that 80 Col / RGB card have video memory.
>
> The 80 column/language card in my //e does. It has 64kb. However I
> suspect that the RGB card does not. Having never seen an actual unit or
> a schematic of one I cannot tell.
Virtually all AUX slot cards contain memory, since a primary function
of the slot is to support AUX memory for "80-column" modes. 2KB is
the minimum, 64KB is typical, and 1MB+ was widely supplied by third
parties.
However, no RGB card for any Apple II (with the exception of the VGA
SecondSight card) "mirrors" all of video memory--only the AUX memory
is on the card, and it is not accessed *by the card* for video display.
Instead, the Apple accesses both main memory and AUX memory to generate
composite video, which is supplied to the AUX slot. An RGB card decodes
this composite signal to generate R, G, B, and "I" signals for a digital
RGB monitor (originally, the AppleColor 100).
>>It only runs
>>at 1/14M or 70 ns to read NTSC pulse from aux or main memory. NTSC pulse
>>goes through the RGB circuit to translate into R, G, B, and I signal.
>
> By NTSC pulse from memory, what exactly do you mean? Are you saying
> that the colour data in memory is pre-encoded with NTSC modulation. Ie
> with the phase shifts coded into the colour information?
Basically, yes. All Apple II color is "artifact" color resulting from
video signal pulses which contain 3.58MHz "color" information, in
various amplitudes and phases, causing an NTSC monitor to display color.
The sync, blanking, and color burst are generated by logic, not read
from memory, but the entire structure of the video line is created from
information read from memory--without any translation in the case of
hi-res and double-hi-res graphics modes.
-michael
Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."
Jorge Chamorro Bieling
>
> Basically, yes. All Apple II color is "artifact" color resulting from
> video signal pulses which contain 3.58MHz "color" information, in
> various amplitudes and phases, causing an NTSC monitor to display color.
various amplitudes ?
--
Jorge Chamorro Bieling
General_Failure
> Actually, 80 Col / RGB card does not have video RAM, but it does have
>AUX RAM. AUX RAM is used to hold data for Text, LoRes, and HiRes in 80
>column. I believe that it has 8 chips to hold 64KB.
Well yes, I agree. I apologise if I said otherwise. Sometimes I am not
too good at explaining what I mean.
And yes, I believe you are correct about the 8 chips.
> Well, one byte is loaded from main memory or aux memory into Load/Shift
>Register. One bit is loaded and shifted out to the NTSC monitor. RGB card
>has similiar Load/Shift Register, but it does read a group of four phase
>shift while it translates into R, G, B, and I signals. RGBI signals have
>color information, but phase shift does not.
Very interesting. I am very surprised about the single bit being output
for NTSC.
So it achieves colour by the artifacting method that is mentioned by
Michael?
I just want to be clear that the RGB card we are talking about has a
seperate R, G, B and sync(s), right?
It is why RGB card has to output only C sync because CGA
monitor does not have C sync because it does not split C sync into H
sync
and V sync. You can build an adapter which it has LM1881 chip. LM1881
chip
splits C sync into H sync and V sync.
> I have tested in my Oscilloscope to show that H sync and V sync are
>identical. It seems that LM1881 chip is not necessary.
It's strange that they would have wasted money on a chip that has no
useful effect. That does concern me. Does the chip do anything to the
signal at all, in your observations?
I don't agree with most emulator projects because I claim that
video
data is completely wrong for DHGR and HGR. I appreciate the
programmer's
efforts to guess and build video data in their own.
Video data is usually a sticking point in emulator development. At
least in the early stages of the program's life cycle. Especially when
some really nasty form of bit-banging is needed to translate data.
> It is why I have to
>capture R, G, B, and I signals at video cycle by video cycle. Then I
>translate RGBI signals into 12 pixels. I place 12 pixels in the 4,096
>possible data in a table. I believe that this table can correct video data
>which it looks true VGA monitor like Apple IIgs' analog RGB monitor. DHGR
>and HGR will look correct according to my efforts of capturing RGBI signals.
Because you cover all 4096 combinations, which is quite an amazing
feat, the bit alignment of the captured signal would not matter.
Correct?
Michael J. Mahon Said:
>And you would also have to track Main/Aux bank switches, too.
Sure would. Any data locations that affect video display would need to
be tracked.
>Instead, the Apple accesses both main memory and AUX memory to generate
>composite video, which is supplied to the AUX slot. An RGB card decodes
>this composite signal to generate R, G, B, and "I" signals for a digital
>RGB monitor (originally, the AppleColor 100).
That is so messy. It kind of saddens me that it was done that way. A
means to an end I guess.
>Basically, yes. All Apple II color is "artifact" color resulting from
>video signal pulses which contain 3.58MHz "color" information, in
>various amplitudes and phases, causing an NTSC monitor to display color.
That explains the choice of NTSC then. It's not so easy to generate
colour artifacts with PAL.
>The sync, blanking, and color burst are generated by logic, not read
>from memory, but the entire structure of the video line is created from
>information read from memory--without any translation in the case of
>hi-res and double-hi-res graphics modes.
I didn't think that I understood correctly before, because it would
have meant that every time a write to the video region of RAM was done,
something would need to recalculate the phase shift accordingly.
Alex Freed
>>Basically, yes. All Apple II color is "artifact" color resulting from
>>video signal pulses which contain 3.58MHz "color" information, in
>>various amplitudes and phases, causing an NTSC monitor to display color.
>
>
> That explains the choice of NTSC then. It's not so easy to generate
> colour artifacts with PAL.
>
Not really. In this part of the world NTSC is the only game in town.
Only now that the flat (plasma and LCD) TVs are all digital they have
PAL capability. In the 70s and 80s PAL capable TVs were vitrually
non-existant in the US.
And the color encoding in PAL is only different from NTSC by changing
the phase of the color carrier every line. So creating the same kind of
PAL "artifacts" is almost as easy.
-Alex.
Michael J. Mahon
Yes.
Since the video pulses for lores graphics and DHR are sent at 14MHz,
each cycle of 3.58MHz covers 4 pulses. Any "asymetrical" pattern
will contain a 3.58MHz component (in a Fourier sense).
So the patterns 1100, 0110, 0011, or 1001 are maximum amplitude
(saturation) 3.58MHz signals, while the patterns 1000, 0100, 0010,
0001, 1110, 0111, 1011, and 1101 are half-amplitude chroma signals.
The patterns 1010, 0101, 1111, and 0000 do not contain any 3.58MHz
component, and so are colorless.
As you can see, the phase of the 3.58MHz chroma signal is a function
of the patterns, so they produce different hues, though some hues are
the same. For example, 0100 has the same hue and saturation as 1110,
but a different luminance (1 and 3 respectively).
The luminance of the pixel group as a whole is equal to the number
of "1"s: 0,1,2,3,4. Of course, a high-resolution rendering of the
lumnance channel will cause light to be produced only at the "1"
positions in the group, though the overall hue and saturation of
the group is set as a 4-pixel group. This causes saturated colors
to be obviously composed of discrete vertical lines.
The "sliding window" algorithm treats each 4-bit group in this
way to determine hue and saturation, sliding by just one bit per
DHR pixel (560 across). This is a DSP technique to approximate
the response of analog chroma processing--though it is only an
approximation.
The algorithms used by the common Apple II RGB cards and by the
IIgs RGB conversion are not fully understood yet, but Bryan is
working on it.
Michael J. Mahon
> Bryan Parkoff Said:
> It is why RGB card has to output only C sync because CGA
> monitor does not have C sync because it does not split C sync into H
> sync
> and V sync. You can build an adapter which it has LM1881 chip. LM1881
> chip
> splits C sync into H sync and V sync.
>
>
>> I have tested in my Oscilloscope to show that H sync and V sync are
>>identical. It seems that LM1881 chip is not necessary.
There is some problem with Byran's hookup, since the LM1881 generates
a quite respectable Vsync pulse when operated correctly.
> It's strange that they would have wasted money on a chip that has no
> useful effect. That does concern me. Does the chip do anything to the
> signal at all, in your observations?
The RGB card has no use for any sync signal except, possibly, horizontal
sync, since it is provided with the master 14MHz dot clock, and the
3.58MHz color reference, with which all color information can be derived
from the composite video signal. The card just passes composite sync
through to the monitor (and most RGB monitors can handle composite
sync).
> Michael J. Mahon Said:
>
>
>>And you would also have to track Main/Aux bank switches, too.
>
>
> Sure would. Any data locations that affect video display would need to
> be tracked.
>
>
>>Instead, the Apple accesses both main memory and AUX memory to generate
>>composite video, which is supplied to the AUX slot. An RGB card decodes
>>this composite signal to generate R, G, B, and "I" signals for a digital
>>RGB monitor (originally, the AppleColor 100).
>
>
> That is so messy. It kind of saddens me that it was done that way. A
> means to an end I guess.
Actually, it is electronic poetry.
It is this technique that permitted the Apple II to have color graphics,
even hi-res graphics, years before memory became cheap enough to permit
multi-plane frame buffers in personal computers. (And the larger the
pixel, the more processor time is required to "draw" in the buffer.)
The video signal of an Apple II takes on only two values (except sync
and color burst): "0" and "1", and all the colors are artifacts of this
binary signal!
>>Basically, yes. All Apple II color is "artifact" color resulting from
>>video signal pulses which contain 3.58MHz "color" information, in
>>various amplitudes and phases, causing an NTSC monitor to display color.
>
>
> That explains the choice of NTSC then. It's not so easy to generate
> colour artifacts with PAL.
True--a PAL card has to do work similar to an RGB card.
>>The sync, blanking, and color burst are generated by logic, not read
>>from memory, but the entire structure of the video line is created from
>>information read from memory--without any translation in the case of
>>hi-res and double-hi-res graphics modes.
>
>
> I didn't think that I understood correctly before, because it would
> have meant that every time a write to the video region of RAM was done,
> something would need to recalculate the phase shift accordingly.
If you needed to represent *colors* in a "mirror" frame buffer, then
such a computation *would* be needed, and a change could affect the
rendition of neighboring pixels, too.
General_Failure
>Since the video pulses for lores graphics and DHR are sent at 14MHz,
>each cycle of 3.58MHz covers 4 pulses. Any "asymetrical" pattern
>will contain a 3.58MHz component (in a Fourier sense).
>So the patterns 1100, 0110, 0011, or 1001 are maximum amplitude
>(saturation) 3.58MHz signals, while the patterns 1000, 0100, 0010,
>0001, 1110, 0111, 1011, and 1101 are half-amplitude chroma signals.
>The patterns 1010, 0101, 1111, and 0000 do not contain any 3.58MHz
>component, and so are colorless.
You're right. It is an elegant exploit of a technology. And as realised
by many, this method does not work in PAL because the standard is
designed to neutralise a lot of abhorrent signals.
The standards of NTSC and PAL aren't really too different. However it
is the little differences that make all the difference. A good
explanation of how the video signal works exists on Rickard's PIC site
on this page I think <a
href="http://www.rickard.gunee.com/projects/video/pic/howto.php">http://www.rickard.gunee.com/projects/video/pic/howto.php</a>
Velleman sells a kit that seems to be a direct rip or Rickard's PIC
Pong too. I bought one cheaply recently.
Anyway, back to topic.
The translation would either have to be done by a nice whack of logic,
or a massive lookup table, as Bryan seems to have implemented. That
must have taken a very long time.
At any rate, from all this information gained, many different methods
of implementation seem to be possible.
Paul Schlyter
General_Failure <tristan...@gmail.com> wrote:
> Michael J. Mahon said:
>> Since the video pulses for lores graphics and DHR are sent at 14MHz,
>> each cycle of 3.58MHz covers 4 pulses. Any "asymetrical" pattern
>> will contain a 3.58MHz component (in a Fourier sense).
>
> >So the patterns 1100, 0110, 0011, or 1001 are maximum amplitude
> >(saturation) 3.58MHz signals, while the patterns 1000, 0100, 0010,
> >0001, 1110, 0111, 1011, and 1101 are half-amplitude chroma signals.
> >The patterns 1010, 0101, 1111, and 0000 do not contain any 3.58MHz
> >component, and so are colorless.
>
> You're right. It is an elegant exploit of a technology. And as realised
> by many, this method does not work in PAL because the standard is
> designed to neutralise a lot of abhorrent signals.
> The standards of NTSC and PAL aren't really too different. However it
> is the little differences that make all the difference.
True. PAL requires a delay line, to be able to sum up the color
signal from the current line and the previous line - that's the way
the phase shift cancellation is performed. This delay line was quite
expensive in early color TV sets. For awhile, the japanese TV
manufacturer Sony used something called "Poor man's PAL" -- basically
it worked by converting the PAL signal to NTSC so the delay line
wasn't needed. Otoh then you also lost the phase shift cancellation
property of PAL. Therefore, "Poor man's PAL" TV sets reintroduced
that hue knob, to adjust the color hue of the image - that knop was
present on most NTSC TV sets but was absent on all "full PAL"
receivers since it wasn't needed there. Check this link for more info:
http://stjarnhimlen.se/tv/tv.html#PAL-SIMPLE
> A good
> explanation of how the video signal works exists on Rickard's PIC site
> on this page I think <a
> href="http://www.rickard.gunee.com/projects/video/pic/howto.php">http://www.rickard.gunee.com/projects/video/pic/howto.php</a>
> Velleman sells a kit that seems to be a direct rip or Rickard's PIC
> Pong too. I bought one cheaply recently.
> Anyway, back to topic.
> The translation would either have to be done by a nice whack of logic,
> or a massive lookup table, as Bryan seems to have implemented. That
> must have taken a very long time.
>
> At any rate, from all this information gained, many different methods
> of implementation seem to be possible.
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/
Michael J. Mahon
Bryan is still "in process".
The "sliding window" approach I described can use as few as 4 bits for
its lookup, or can use a wider window, to accomodate the typically low
bandwidth of an analog chroma channel. The resultant "smearing" of the
hue and saturation information could be adjusted to produce a more
accurate rendition of what an analog NTSC monitor would display.
In today's hardware, a 4Kx16-bit ROM addressed by a shift register
would not be a big problem, and could output 5x5x5 RGB data for the
DACs. Of course, the 14MHz operating rate might be harder. ;-)
Knut Roll-Lund
> General_Failure wrote:
>
>> Bryan Parkoff Said:
>
>
>> It is why RGB card has to output only C sync because CGA
>> monitor does not have C sync because it does not split C sync into H
>> sync
>> and V sync. You can build an adapter which it has LM1881 chip. LM1881
>> chip
>> splits C sync into H sync and V sync.
>>
>>
>>> I have tested in my Oscilloscope to show that H sync and V sync are
>>> identical. It seems that LM1881 chip is not necessary.
This applies to the IBM 5153 monitor only! We have not tested it with
any other CGA monitor.
Actually this LM1881 normally works but I have made some mistake so the
output from the circuit is the inverted combined sync (CSYNC) same as
the horizontal sync output from my circuit. I made two of these, mine
and Bryan's.
The LM1881 takes a signal containing the sync (here CSYNC) and extracts
the vertical sync pulse VSYNC. (It also have an output for a cleaned
sync signal, for use as CSYNC or HSYNC when the original also contains
green or composite signal.
The CGA standard requires HSYNC and VSYNC separated but we have found
that the IBM 5153 can use the inverted CSYNC on both inputs. This is not
documented anywhere and I think that not all CGA monitors will accept
it. I have investigated this on internet and found no indication that
this is so.
So for the IBM 5153 (specifically) the LM1881 is unnecessary. An
inverter 74LS04 is enough. Invert CSYNC and apply it to both VSYNC and
HSYNC.
It is kind of embarrassing that the smaller version "dongle" type, both
my own and Bryan's, has a mistake in them (my "veroboard" prototype
works). The problem is of course that this particular CGA monitor is
forgiving and it worked in spite of the mistake. So I never used the
oscilloscope to see the signals. Bryan, when he got his oscilloscope and
tried to use the VSYNC signal for triggering discovered the fault.
--
Knut
(delete 'nogarbage.' for email)
mdj
> The algorithms used by the common Apple II RGB cards and by the
> IIgs RGB conversion are not fully understood yet, but Bryan is
> working on it.
While it's true the IIgs RGB conversion is not fully understood, the
behavior of the Apple II RGB cards, in terms of their outputs is fairly
well documented.
http://www.freepatentsonline.com/4631692.html
The URL above describes the technique used by VIDEO 7 for double hires
modes. The card sold by Apple (AppleColour Extended 80 Column Card) was
made under license from VIDEO 7
There's a big difference between IIe RGB and IIgs RGB: The IIgs
attempts to emulate composite DHR. IIe RGB on the other hand, provides
nice, clear, purified picture. You could say that for HIRES, the
approaches used by IIe RGB and IIgs RGB are equivalent in terms of
functionality, but DHR is a very different story. The IIgs will by
default provide a (IMHO terrible) approximation of colour DHR. This can
be overridden with monochrome mode, provided by the control panel.
The IIe RGB on the other hand, implements DHR as 3 seperate modes:
Colour (Mode 1), Monochrome (Mode 2), and MIX (mode 3). These modes are
implemented by toggling 80-Col and AN3 in certain sequences, which
tells the card which mode to access. If a piece of software that used
DHR is not RGB aware, it could possibly enable the wrong mode, and will
require a preboot program to override the mode to whatever is
appropriate.
The modes are as follows:
Mode 1 - 140x192 16 Colour. Basically you get DHR colour, without
artifacts, using whichever digital RGB colour most closely resembles
the Apple Colour.
Mode 2 - 560x192 Mono. Colour Information is ignored, giving full
560x192 monochrome graphics.
Mode 3 - MIX. A byte is considered to be either colour or mono
depending on the state of the high order bit in each display byte. In
DHR, this bit is irrelevant in terms of colour information or raster
pattern, so is reused in this case to provide an interesting mode.
Dazzle Draw at least, makes it possible to utilise this mode for
drawing DHR, and outputs its picture files in a manner that maintains
compatibility with Mode 3.
These are the three modes documented by Apple in the AppleColour RGB
manual. The Video 7 hardware is actually capable of two additional
modes that aren't documented by Apple, and are thus less likely to
appear in third party implementations:
Mode 4 - 160x192 16 colour. In this mode, all bits are considered,
providing a nice unrestricted colour mode, that is also significantly
easier to program, since pixels fall on byte boundaries.
There is one other mode, this one is really wierd:
Mode 5(?) 280x192 16 Colour. This mode is essentially HIRES, treated as
Mono, and the aux bank is considered as a giant palette register. I'm
unaware of the specifics of this mode, but an example of how to use it
was provided on the AppleColour RGB demo disk, even though it wasn't
formally documented by Apple. One common use is to 'emulate' HIRES
mono, which isn't supported by RGB cards, by filling the AUX bank with
the appropriate colour information.
So there you are: Apple IIe RGB in a nutshell. As has been mentioned in
previous threads, I'm unaware of whether the IIc adapters made by VIDEO
7 supported all these modes, and await the sourcing of some
documentation to find out. The absence of AN3 on the IIc makes me
wonder if they do, but I suppose if it's possible to detect 80Col from
the Video Expansion Connector, it's feasible.
I obviously haven't tested every variant of Apple II RGB adapter, but
I'd venture that since VIDEO 7 had a patent on the technique, that
every other manufacturer produced theirs under license, and therefore
most probably conformed to this "standard".
Matt
Bryan Parkoff
"mdj" <mdj...@gmail.com> wrote in message
news:1148878864.6...@38g2000cwa.googlegroups.com...
Thank you for a full explanation which it has the difference between
Apple //e and Apple IIgs.
>
> Mode 1 - 140x192 16 Colour. Basically you get DHR colour, without
> artifacts, using whichever digital RGB colour most closely resembles
> the Apple Colour.
It is Mode 3.
>
> Mode 2 - 560x192 Mono. Colour Information is ignored, giving full
> 560x192 monochrome graphics.
>
> Mode 3 - MIX. A byte is considered to be either colour or mono
> depending on the state of the high order bit in each display byte. In
> DHR, this bit is irrelevant in terms of colour information or raster
> pattern, so is reused in this case to provide an interesting mode.
> Dazzle Draw at least, makes it possible to utilise this mode for
> drawing DHR, and outputs its picture files in a manner that maintains
> compatibility with Mode 3.
It is Mode 1.
>
> These are the three modes documented by Apple in the AppleColour RGB
> manual. The Video 7 hardware is actually capable of two additional
> modes that aren't documented by Apple, and are thus less likely to
> appear in third party implementations:
>
> Mode 4 - 160x192 16 colour. In this mode, all bits are considered,
> providing a nice unrestricted colour mode, that is also significantly
> easier to program, since pixels fall on byte boundaries.
It is Mode 0. I was able to convert EGA daa from 320x200 to 160x200 as
640x200, but it was shrinked into 140x192. I did demo The Black Cauldron
(PC Version) into Apple //e's RGB card.
>
> There is one other mode, this one is really wierd:
>
> Mode 5(?) 280x192 16 Colour. This mode is essentially HIRES, treated as
> Mono, and the aux bank is considered as a giant palette register. I'm
> unaware of the specifics of this mode, but an example of how to use it
> was provided on the AppleColour RGB demo disk, even though it wasn't
> formally documented by Apple. One common use is to 'emulate' HIRES
> mono, which isn't supported by RGB cards, by filling the AUX bank with
> the appropriate colour information.
It is undocumented. The problem is that monochrome needs more data
because 7th bit is not available to reset/set monochrome like DHGR. Seventh
bit is used to switch violet/green color and blue/orange. The only way is
to put monochrome data in the screen hole. It needs 960 bytes, but screen
hole has only 512 bytes available. The only way is to store 480 bytes
leaving free 32 bytes in the screen hole. It has 2 1/2 bytes or 20 bits
each horizontial lines. It gives monochrome in each a group of two bytes.
It is 20 group of two bytes. It is great memory saving. I may be able to
demo at later time.
Bryan Parkoff
mdj
> It is undocumented. The problem is that monochrome needs more data
> because 7th bit is not available to reset/set monochrome like DHGR. Seventh
> bit is used to switch violet/green color and blue/orange. The only way is
> to put monochrome data in the screen hole. It needs 960 bytes, but screen
> hole has only 512 bytes available. The only way is to store 480 bytes
> leaving free 32 bytes in the screen hole. It has 2 1/2 bytes or 20 bits
> each horizontial lines. It gives monochrome in each a group of two bytes.
> It is 20 group of two bytes. It is great memory saving. I may be able to
> demo at later time.
It's undocumented, but relatively simple to explain:
The display is treated as 280x192 monochrome field just like composite
monochrome HR, except that 1 is treated as a 'foreground' colour and 0
treated as a 'background' colour. the high order bit is insignificant.
The corresponding byte in the auxiliary bank contains the
foreground/background colours for each byte. For example, setting each
byte in the $2000-$3FFF range in auxiliary memory to $F0 would yield an
'emulation' of monochrome hires, but you can obviously use other
colours. It's a bit restricted since each set of 7 pixels must have the
same foreground/background colours, but some interesting effects can be
achieved.
Note that this technique can be enabled in 40-column text mode too,
providing a nice 16 colour foreground/background text mode. A very
seldom used feature!
Fairly obviouisly, the RGB adapter actually has the Apple IIe in
doublehires mode while producing this mode, and likewise has it in 80
col mode while producing colour text mode
Matt
mdj
from IIe/IIc RGB, you either need an analog RGB adapter (the only one I
know about being the A.E ColourLink option for RamWorks), or a decoder
circuit added to the output of a digital RGB adapter.
The AppleColour Monitor 100 actually had such a thing internally, since
it was actually an adapted analog display, but it simply mimiced the
digital colours.
IIRC, there was a switch inside this monitor that could disable the
digital decoder, making it compatible with the IIgs RGB monitor. This
information was provided to purchasers of the IIgs upgrade kit for the
IIe.
Matt
Bryan Parkoff
I do know that background and foreground data are in aux $400-$7FF. It
allows 40 column to have colored text in main memory while high nibble for
background and low nibble for foreground to set one of 16 colors in aux
memory.
I am not sure what I understand that you are referring $2000-$3FFF in
aux memory for HGR (not DHGR). Can you please explain little more?
Bryan Parkoff
mdj
Bryan Parkoff wrote:
> I am not sure what I understand that you are referring $2000-$3FFF in
> aux memory for HGR (not DHGR). Can you please explain little more?
This is the undocumented Mode 5 I referred to previously ...
Essentially it applies the same technique used to produce 40 column
colour text to the HIRES display. The main memory buffer is treated as
monochrome HIRES, and the auxiliary buffer is used for colour
information.
It would seem that the VIDEO7 crew after implementing mono DHR, then
colour DHR as seperate modes, realised that MIX was only an extra IC
away. The other modes are also very simply generated from the available
data stream.
There was an article on the undocumented mode in Apple Assembly Line,
which is how I learned of it's existence. The AppleColour RGB demo disk
also includes a demonstration for it, but it's use other than emulating
monochrome HIRES correctly is pretty limited, IMHO
It's worth preserving even just to achieve that, however.
Matt
Bryan Parkoff
Where can I find monochrome HGR undocumented article on website?
Bryan Parkoff
mdj
Bryan Parkoff
Thanks for the information. Like I said earlier 160 Mode is on Mode 0.
I think that 160 Mode is not true 640x200 because it has restricted to
560x192. When you put low nibble in $2000, four pixels will be displayed in
position 0 through 3 and high nibble displays only three pixels in position
4 through 6. The fact is that it does read four bits in high nibble to
select one of 16 colors, but it can't display 4 pixels. It is what I refer
shrinked from 8 pixels to 7 pixels each column.
I think that 160 Mode is misconcept so it should be referred to 160
columns shrinked into 140 Mode. What do you think?
Do AE RAMWorks III have optional RGB? If yes, where should I start
configuring it?
I intend to write Video 7 RGB in emulator project.
Bryan Parkoff
Michael J. Mahon
> The AppleColour Monitor 100 actually had such a thing internally, since
> it was actually an adapted analog display, but it simply mimiced the
> digital colours.
>
> IIRC, there was a switch inside this monitor that could disable the
> digital decoder, making it compatible with the IIgs RGB monitor. This
> information was provided to purchasers of the IIgs upgrade kit for the
> IIe.
Very interesting! Does anyone have more info on this?
mdj
Bryan Parkoff wrote:
> "mdj" <mdj...@gmail.com> wrote in message
> news:1148960973.3...@j55g2000cwa.googlegroups.com...
> > What am I, Google? ;-)
> >
> > http://bobsc5.home.comcast.net/aal/1986/aal8608.html#a6
> >
>
> Thanks for the information. Like I said earlier 160 Mode is on Mode 0.
> I think that 160 Mode is not true 640x200 because it has restricted to
> 560x192. When you put low nibble in $2000, four pixels will be displayed in
> position 0 through 3 and high nibble displays only three pixels in position
> 4 through 6. The fact is that it does read four bits in high nibble to
> select one of 16 colors, but it can't display 4 pixels. It is what I refer
> shrinked from 8 pixels to 7 pixels each column.
> I think that 160 Mode is misconcept so it should be referred to 160
> columns shrinked into 140 Mode. What do you think?
It has been a long, long time since I've messed with the undocumented
modes. I'd imagine, though, that what it actually does in this case is
output 4 pixel wide colours in one memory bank and 3 pixel wide in the
other bank. This would give a 160x192 colour display over a 560x192
raster signal.
The mode isn't used by any piece of software outside of demo's as far
as I know. It's possible that the spreadsheet program VIP Professional
may have used it for graph displays. It's the only piece of software
I'm aware of the made use of some of Applied Engineerings more exotic
IIe extensions.
Basically, I think you'll find that VIDEO 7 needed to implement 2
decoders to do DHR in RGB, one for mono, one for colour. This basically
meant that implementing MIX was a piece of cake, just using a selector
to switch between decoders for each byte. It was probably then very
simple to add the 'bonus' modes with the available hardware, so they
did so.
> Do AE RAMWorks III have optional RGB? If yes, where should I start
> configuring it?
Sorry, I don't follow. There were three addon boards for the RamWorks
over the years to provide RGB output. Each allowed different sorts of
displays to be driven (Apple Digital, CGA, and Apple Analog). Each was
identical to the AppleColour RGB card in terms of functionality, ie.
the VIDEO7 RGB modes.
Matt
mdj
Michael J. Mahon wrote:
> mdj wrote:
>
> > The AppleColour Monitor 100 actually had such a thing internally, since
> > it was actually an adapted analog display, but it simply mimiced the
> > digital colours.
> >
> > IIRC, there was a switch inside this monitor that could disable the
> > digital decoder, making it compatible with the IIgs RGB monitor. This
> > information was provided to purchasers of the IIgs upgrade kit for the
> > IIe.
>
> Very interesting! Does anyone have more info on this?
It was just a simple resistor/zener diode network. All you need to do
to convert digital RGB to analog is level adjust the r,g,b digital
output to full intensity analog, which I think it 1V, then allow for
1/2 level output dependant upon the intensity level. Pretty simple
circuit, I've used a similar thing to adapt my Ramworks digital RGB
output to drive televisions that have SCART connectors. Provides a nice
plentiful source for Apple II displays, and I can have either true
composite colour via the composite input, or nice, clear RGB via the
SCART ;-)
Of course as has been noted before, digital RGB produced this way is
only an approximation of the real Apple II colour palette, but it's
reasonable. You get the 16 possible digital RGB colours instead. You
could do a more accurate conversion I suppose by decoding the digital
signal into a 12 bit RGB representation, and using either an actual
DAC, or a poor mans version with resistors.
Matt
Matt
mdj
display to provide an RGB 'input' by feeding analog RGB signals
directly to the amplifier board in the monitor, and leaving the
composite input connected to provide 'sync', but my knowledge of video
electronics is rather limited, and I'm not sure if this approach would
work. It seems fine in theory though, and would actually give me the
exact setup I've always wished for.
Matt
Michael J. Mahon
> Michael J. Mahon wrote:
>
>>mdj wrote:
>>
>>
>>>The AppleColour Monitor 100 actually had such a thing internally, since
>>>it was actually an adapted analog display, but it simply mimiced the
>>>digital colours.
>>>
>>>IIRC, there was a switch inside this monitor that could disable the
>>>digital decoder, making it compatible with the IIgs RGB monitor. This
>>>information was provided to purchasers of the IIgs upgrade kit for the
>>>IIe.
>>
>>Very interesting! Does anyone have more info on this?
>
>
> It was just a simple resistor/zener diode network. All you need to do
> to convert digital RGB to analog is level adjust the r,g,b digital
> output to full intensity analog, which I think it 1V, then allow for
> 1/2 level output dependant upon the intensity level.
Presumeably only the attenuation is required, and the zener is just to
prevent overloads? With a 5:1 attenuation required, any DC level shift
would be very easy just with resistors.
I had expected some matrixing of the RGB signals to produce "Apple"
colors instead of RGBI colors.
> Pretty simple
> circuit, I've used a similar thing to adapt my Ramworks digital RGB
> output to drive televisions that have SCART connectors. Provides a nice
> plentiful source for Apple II displays, and I can have either true
> composite colour via the composite input, or nice, clear RGB via the
> SCART ;-)
>
> Of course as has been noted before, digital RGB produced this way is
> only an approximation of the real Apple II colour palette, but it's
> reasonable. You get the 16 possible digital RGB colours instead. You
> could do a more accurate conversion I suppose by decoding the digital
> signal into a 12 bit RGB representation, and using either an actual
> DAC, or a poor mans version with resistors.
From this group I got the idea that there was special "Apple"
non-standard matrixing in the AppleColor RGB 100 that created a
pretty good approximation of the composite colors, rather than the
typical RGBI colors.
Frankly, it always seemed strange to do this matrixing in the monitor
instead of on the RGB card.
You also mentioned that there is a *switch* inside the monitor that
bypasses the digital conversion, making it an analog RGB display...?
(Getting screwdriver...)
Michael J. Mahon
It should work fine--especially since you have 5v RGBI signals to work
with!
(Hmmm. Thinking about the "I" input, I may see what the zeners were
for...)
mdj
Michael J. Mahon wrote:
> mdj wrote:
> > For years I've considered the idea of hacking an Apple Colour Composite
> > display to provide an RGB 'input' by feeding analog RGB signals
> > directly to the amplifier board in the monitor, and leaving the
> > composite input connected to provide 'sync', but my knowledge of video
> > electronics is rather limited, and I'm not sure if this approach would
> > work. It seems fine in theory though, and would actually give me the
> > exact setup I've always wished for.
>
> It should work fine--especially since you have 5v RGBI signals to work
> with!
>
> (Hmmm. Thinking about the "I" input, I may see what the zeners were
> for...)
Yeah, I've now gotten rid of all but one of them, and am a bit reticent
to modify it... I thought it might provide a possible solution for
those in 50Hz markets wanting RGB output.
Matt
mdj
> Presumeably only the attenuation is required, and the zener is just to
> prevent overloads? With a 5:1 attenuation required, any DC level shift
> would be very easy just with resistors.
> I had expected some matrixing of the RGB signals to produce "Apple"
> colors instead of RGBI colors.
I've not seen the actual monitor myself, I don't think they were ever
available for sale in Australia, probably owing to issues with 50hz
IIe's and RGB output...
A copy of the circuit is in *one* of the manuals... I'm not sure
whether it's the AppleColour RGB Card manual, Apple III manual, etc.
Since you've actually got one, I'd recommend just having a look....
> You also mentioned that there is a *switch* inside the monitor that
> bypasses the digital conversion, making it an analog RGB display...?
> (Getting screwdriver...)
If memory serves, yes.
Liam Busey
Michael J. Mahon wrote:
-snip-
>
> You also mentioned that there is a *switch* inside the monitor that
> bypasses the digital conversion, making it an analog RGB display...?
> (Getting screwdriver...)
There is a switch. IIRC its positions are are marked '8' and '16'.
You'll want to put the switch in the '8' position for analog use. I
used one of them on my IIgs for a while but decided I liked the normal
Applecolor RGB better.
I found the case to be a PITA open.
Liam