Discussion:
Where can I find out more about how RGB and VGA type cards work to get the video data on 8 bit Apple machines?
(too old to reply)
Doug Dingus
2020-10-11 20:37:31 UTC
Permalink
Right now, I just want to read up on how cards in slots do this without getting in the way of the CPU.
Charlie
2020-10-12 00:54:00 UTC
Permalink
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without getting in the way of the CPU.
Each slot has pins that show the address, data and the read/write mode.
They also have several of the Apple II clocks. All a card needs to do
is watch the read/write and address pins for writes to the Apple's video
memory map locations. Then it copies the data to a buffer on the card
for processing.

There is some timing involved because the data bus is only valid at
certain times. The card uses the other clocks to determine the correct
times.

The card can use the same technique to watch read/writes to the video
softswitches to determine what video mode (text, hgr, shr, etc.) the
Apple is using.

This is how the Carte Blanche and Carte Blanche II video card handle it
for VGA output.

All of this is completely invisible to the Apple II CPU.

You can look at my site for more information and if you are into
following source code (Verilog) download my video projects code.

http://noboot.com/charlie/Charlie's%20Stuff.htm

Charlie
Doug Dingus
2020-10-12 04:37:03 UTC
Permalink
Post by Charlie
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without getting in the way of the CPU.
Each slot has pins that show the address, data and the read/write mode.
They also have several of the Apple II clocks. All a card needs to do
is watch the read/write and address pins for writes to the Apple's video
memory map locations. Then it copies the data to a buffer on the card
for processing.
There is some timing involved because the data bus is only valid at
certain times. The card uses the other clocks to determine the correct
times.
The card can use the same technique to watch read/writes to the video
softswitches to determine what video mode (text, hgr, shr, etc.) the
Apple is using.
This is how the Carte Blanche and Carte Blanche II video card handle it
for VGA output.
All of this is completely invisible to the Apple II CPU.
You can look at my site for more information and if you are into
following source code (Verilog) download my video projects code.
http://noboot.com/charlie/Charlie's%20Stuff.htm
Charlie
Thanks! This helps a lot.
Scott Alfter
2020-10-12 22:02:22 UTC
Permalink
Post by Doug Dingus
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this
without getting in the way of the CPU.
Each slot has pins that show the address, data and the read/write mode.
They also have several of the Apple II clocks. All a card needs to do
is watch the read/write and address pins for writes to the Apple's video
memory map locations. Then it copies the data to a buffer on the card
for processing.
There is some timing involved because the data bus is only valid at
certain times. The card uses the other clocks to determine the correct
times.
The card can use the same technique to watch read/writes to the video
softswitches to determine what video mode (text, hgr, shr, etc.) the
Apple is using.
This is how the Carte Blanche and Carte Blanche II video card handle it
for VGA output.
I'm pretty sure that's also how the Second Sight and VidHD operate. The
Second Sight used (IIRC) a fast(er than the Apple II's) CPU connected to a
VGA chipset, while the VidHD uses a microcontroller connected to a
single-board computer running a stripped-down Linux distribution.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
Michael J. Mahon
2020-10-13 05:30:21 UTC
Permalink
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without
getting in the way of the CPU.
The “classic” RGB cards operated by passing the Apple composite video
through a shift register and “decoding” the bit patterns as RGB outputs in
the usual oversimplified way: 00 = black, 11 = white, and 01 and 10 =
green/purple or blue/orange depending on the high bit value.

They were often implemented on AUX memory cards for the //e, since the
video data is conveniently at hand.

This simple conversion does not consider the several surrounding bits of
“context” required to properly decode the many possible artifact shades.
For example, the NTSC chroma output after demodulation has approximately
1MHz bandwidth, and so is affected by about one microsecond worth of video
pixel clocks, or around 14 consecutive bits, not just 2.

This is the kind of RGB conversion done by the IIgs on the 8-bit Apple II
video modes.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Doug Dingus
2020-10-13 19:29:02 UTC
Permalink
Post by Michael J. Mahon
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without
getting in the way of the CPU.
The “classic” RGB cards operated by passing the Apple composite video
through a shift register and “decoding” the bit patterns as RGB outputs in
the usual oversimplified way: 00 = black, 11 = white, and 01 and 10 =
green/purple or blue/orange depending on the high bit value.
They were often implemented on AUX memory cards for the //e, since the
video data is conveniently at hand.
This simple conversion does not consider the several surrounding bits of
“context” required to properly decode the many possible artifact shades.
For example, the NTSC chroma output after demodulation has approximately
1MHz bandwidth, and so is affected by about one microsecond worth of video
pixel clocks, or around 14 consecutive bits, not just 2.
This is the kind of RGB conversion done by the IIgs on the 8-bit Apple II
video modes.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Cool, this helps too.

Is the actual signal there, on the slot?

I need to read the Apple hardware books. Just looking for that voice of experience to help put it into context. Right now.

I am contemplating a hardware project that may output Svideo and HDMI for use with simpler displays.

Really want to get the single pixel cases right. Some of the RGB cards treated the Apple display as a 2bpp one, yielding 140x192 resolution with the Apple high bit attribute. That works, but isn't all that accurate. Kills some of the great pixel art, in my view.

Is the video signal available in any other slot, or just the bit stream? I am asking for 8 bit only right now.
Michael J. Mahon
2020-10-13 22:44:08 UTC
Permalink
Post by Doug Dingus
Post by Michael J. Mahon
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without
getting in the way of the CPU.
The “classic” RGB cards operated by passing the Apple composite video
through a shift register and “decoding” the bit patterns as RGB outputs in
the usual oversimplified way: 00 = black, 11 = white, and 01 and 10 =
green/purple or blue/orange depending on the high bit value.
They were often implemented on AUX memory cards for the //e, since the
video data is conveniently at hand.
This simple conversion does not consider the several surrounding bits of
“context” required to properly decode the many possible artifact shades.
For example, the NTSC chroma output after demodulation has approximately
1MHz bandwidth, and so is affected by about one microsecond worth of video
pixel clocks, or around 14 consecutive bits, not just 2.
This is the kind of RGB conversion done by the IIgs on the 8-bit Apple II
video modes.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Cool, this helps too.
Is the actual signal there, on the slot?
No, only on the //e AUX slot.
Post by Doug Dingus
I need to read the Apple hardware books. Just looking for that voice of
experience to help put it into context. Right now.
A very good idea! In the time of the Apple II, the provided documentation
was exemplary. I recommend Apple’s “Apple IIe Technical Reference Manual”
and Sather’s “Understanding the Apple II” and “Understanding the Apple
IIe”. They are available on the Web and occasionally as hard copies.
Post by Doug Dingus
I am contemplating a hardware project that may output Svideo and HDMI for
use with simpler displays.
Really want to get the single pixel cases right. Some of the RGB cards
treated the Apple display as a 2bpp one, yielding 140x192 resolution with
the Apple high bit attribute. That works, but isn't all that accurate.
Kills some of the great pixel art, in my view.
I agree, which is why the IIgs rendition of classic modes leaves much to be
desired. Newer microprocessor-based cards would be capable of much more
accurate NTSC emulation.

I have several times suggested a 14-16 bit shift register addressing a ROM
with, say, 8/8/8-bit RGB outputs—too expensive in the day, but easy today.
The ROM could even be big enough to support multiple banks for differing
video modes.
Post by Doug Dingus
Is the video signal available in any other slot, or just the bit stream?
I am asking for 8 bit only right now.
Slot 7 *only* has the composite sync signal on pin 19 and the 3.58MHz color
reference on pin 35.

The Auxiliary slot on the //e has the color reference on pin 1, the VID7M
video shift register clock on pin 2, composite sync on pin 3, video
blanking on pin 7, an “alternative video” input on pin 27, video serial
output on pin 28, and the 14MHz master clock on pin 32. Several other
video-relevant signals are also present.

You can see why the AUX slot is the usual slot for an RGB card on the //e.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Doug Dingus
2020-10-14 19:57:04 UTC
Permalink
Post by Michael J. Mahon
Post by Doug Dingus
Post by Michael J. Mahon
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without
getting in the way of the CPU.
The “classic” RGB cards operated by passing the Apple composite video
through a shift register and “decoding” the bit patterns as RGB outputs in
the usual oversimplified way: 00 = black, 11 = white, and 01 and 10 =
green/purple or blue/orange depending on the high bit value.
They were often implemented on AUX memory cards for the //e, since the
video data is conveniently at hand.
This simple conversion does not consider the several surrounding bits of
“context” required to properly decode the many possible artifact shades.
For example, the NTSC chroma output after demodulation has approximately
1MHz bandwidth, and so is affected by about one microsecond worth of video
pixel clocks, or around 14 consecutive bits, not just 2.
This is the kind of RGB conversion done by the IIgs on the 8-bit Apple II
video modes.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Cool, this helps too.
Is the actual signal there, on the slot?
No, only on the //e AUX slot.
Post by Doug Dingus
I need to read the Apple hardware books. Just looking for that voice of
experience to help put it into context. Right now.
A very good idea! In the time of the Apple II, the provided documentation
was exemplary. I recommend Apple’s “Apple IIe Technical Reference Manual”
and Sather’s “Understanding the Apple II” and “Understanding the Apple
IIe”. They are available on the Web and occasionally as hard copies.
Post by Doug Dingus
I am contemplating a hardware project that may output Svideo and HDMI for
use with simpler displays.
Really want to get the single pixel cases right. Some of the RGB cards
treated the Apple display as a 2bpp one, yielding 140x192 resolution with
the Apple high bit attribute. That works, but isn't all that accurate.
Kills some of the great pixel art, in my view.
I agree, which is why the IIgs rendition of classic modes leaves much to be
desired. Newer microprocessor-based cards would be capable of much more
accurate NTSC emulation.
I have several times suggested a 14-16 bit shift register addressing a ROM
with, say, 8/8/8-bit RGB outputs—too expensive in the day, but easy today.
The ROM could even be big enough to support multiple banks for differing
video modes.
Post by Doug Dingus
Is the video signal available in any other slot, or just the bit stream?
I am asking for 8 bit only right now.
Slot 7 *only* has the composite sync signal on pin 19 and the 3.58MHz color
reference on pin 35.
The Auxiliary slot on the //e has the color reference on pin 1, the VID7M
video shift register clock on pin 2, composite sync on pin 3, video
blanking on pin 7, an “alternative video” input on pin 27, video serial
output on pin 28, and the 14MHz master clock on pin 32. Several other
video-relevant signals are also present.
You can see why the AUX slot is the usual slot for an RGB card on the //e.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Indeed.

One does need to provide the RAM functionality, in addition to any video option though.

Thanks again! Got plenty to think about.
Michael J. Mahon
2020-10-16 03:00:15 UTC
Permalink
Post by Doug Dingus
Post by Michael J. Mahon
Post by Doug Dingus
Post by Michael J. Mahon
Post by Doug Dingus
Right now, I just want to read up on how cards in slots do this without
getting in the way of the CPU.
The “classic” RGB cards operated by passing the Apple composite video
through a shift register and “decoding” the bit patterns as RGB outputs in
the usual oversimplified way: 00 = black, 11 = white, and 01 and 10 =
green/purple or blue/orange depending on the high bit value.
They were often implemented on AUX memory cards for the //e, since the
video data is conveniently at hand.
This simple conversion does not consider the several surrounding bits of
“context” required to properly decode the many possible artifact shades.
For example, the NTSC chroma output after demodulation has approximately
1MHz bandwidth, and so is affected by about one microsecond worth of video
pixel clocks, or around 14 consecutive bits, not just 2.
This is the kind of RGB conversion done by the IIgs on the 8-bit Apple II
video modes.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Cool, this helps too.
Is the actual signal there, on the slot?
No, only on the //e AUX slot.
Post by Doug Dingus
I need to read the Apple hardware books. Just looking for that voice of
experience to help put it into context. Right now.
A very good idea! In the time of the Apple II, the provided documentation
was exemplary. I recommend Apple’s “Apple IIe Technical Reference Manual”
and Sather’s “Understanding the Apple II” and “Understanding the Apple
IIe”. They are available on the Web and occasionally as hard copies.
Post by Doug Dingus
I am contemplating a hardware project that may output Svideo and HDMI for
use with simpler displays.
Really want to get the single pixel cases right. Some of the RGB cards
treated the Apple display as a 2bpp one, yielding 140x192 resolution with
the Apple high bit attribute. That works, but isn't all that accurate.
Kills some of the great pixel art, in my view.
I agree, which is why the IIgs rendition of classic modes leaves much to be
desired. Newer microprocessor-based cards would be capable of much more
accurate NTSC emulation.
I have several times suggested a 14-16 bit shift register addressing a ROM
with, say, 8/8/8-bit RGB outputs—too expensive in the day, but easy today.
The ROM could even be big enough to support multiple banks for differing
video modes.
Post by Doug Dingus
Is the video signal available in any other slot, or just the bit stream?
I am asking for 8 bit only right now.
Slot 7 *only* has the composite sync signal on pin 19 and the 3.58MHz color
reference on pin 35.
The Auxiliary slot on the //e has the color reference on pin 1, the VID7M
video shift register clock on pin 2, composite sync on pin 3, video
blanking on pin 7, an “alternative video” input on pin 27, video serial
output on pin 28, and the 14MHz master clock on pin 32. Several other
video-relevant signals are also present.
You can see why the AUX slot is the usual slot for an RGB card on the //e.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Indeed.
One does need to provide the RAM functionality, in addition to any video option though.
Thanks again! Got plenty to think about.
Fortunately, the RAM functionality is both optional and very simple to
provide, given the provided signals. Several large AUX RAM cards (bank
switched) provided a piggyback connector to support an optional RGB add-on
(also of simple design, as described earlier).
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Loading...