- Add limited Video Overlay Card (VOC) support to add new SHR mode of 640x400 (interlaced).
- Add limited Video Overlay Card (VOC) support to add new SHR mode of 640x400
(interlaced).
Does this take extensive knowledge of the VOC card to initialize and use that mode, or is it just an emulated area in memory in which on can just flip a softswitch and store data to a specific memory, just like the regular SHR screen?
Would really like to use the 400 rows but don't have the VOC knowledge.
- Add limited Video Overlay Card (VOC) support to add new SHR mode of
640x400 (interlaced).
Does this take extensive knowledge of the VOC card to initialize and use
that mode, or is it just an emulated area in memory in which on can just
flip a softswitch and store data to a specific memory, just like the
regular SHR screen?
Would really like to use the 400 rows but don't have the VOC knowledge.
- Added DynaPro image support--mount a host directory as a ProDOS image of
up to 32MB, to allow easy moving of files to/from emulation.
See README.dynapro.txt.
Kent Dickey wrote:
- Added DynaPro image support--mount a host directory as a ProDOS image of >> up to 32MB, to allow easy moving of files to/from emulation.
See README.dynapro.txt.
Nice feature! But there doesn't appear to be a README.dynapro.txt. :(
I'm playing with it though. A sort option would be nice.
(Sorting a directory with Cat Doctor (had to try it) produces
interesting results on the host side. :P)
- Add limited Video Overlay Card (VOC) support to add new SHR mode of
640x400 (interlaced).
Does this take extensive knowledge of the VOC card to initialize and use >that mode, or is it just an emulated area in memory in which on can just >flip a softswitch and store data to a specific memory, just like the >regular SHR screen?
KEGS has limited support for the Apple Video Overlay Card (VOC). The VOC supports a special 640x400 interlaced SHR video mode which is what KEGS also supports. To turn on this mode, you need to do:
Enable VOC (Press F4, select "Enable VOC = Enabled")
c029:c1 # Turn on SHR
c0b1:39 # Set bits [5:4]=11 to enable Interlaced mode
c0b5:80 # Set bit 7 to enable Interlace mode
- Add limited Video Overlay Card (VOC) support to add new SHR mode of
640x400 (interlaced).
Does this take extensive knowledge of the VOC card to initialize and use
that mode, or is it just an emulated area in memory in which on can just
flip a softswitch and store data to a specific memory, just like the
regular SHR screen?
KEGS has limited support for the Apple Video Overlay Card (VOC). The VOC
supports a special 640x400 interlaced SHR video mode which is what KEGS also >> supports. To turn on this mode, you need to do:
Enable VOC (Press F4, select "Enable VOC = Enabled")
c029:c1 # Turn on SHR
c0b1:39 # Set bits [5:4]=11 to enable Interlaced mode
c0b5:80 # Set bit 7 to enable Interlace mode
Looks good on full screen. Too bad the interlaced mode makes it a
little harder to display fonts. Was hoping to display fonts at 132 >characters x 48 lines.
Is C0B1 supposed to be $30, or what does the 9 supposed to do?
KEGS has limited support for the Apple Video Overlay Card (VOC). The VOC >> supports a special 640x400 interlaced SHR video mode which is what KEGS also
supports. To turn on this mode, you need to do:
Enable VOC (Press F4, select "Enable VOC = Enabled")
c029:c1 # Turn on SHR
c0b1:39 # Set bits [5:4]=11 to enable Interlaced mode
c0b5:80 # Set bit 7 to enable Interlace mode
Looks good on full screen. Too bad the interlaced mode makes it a
little harder to display fonts. Was hoping to display fonts at 132 >characters x 48 lines.
Is C0B1 supposed to be $30, or what does the 9 supposed to do?The VOC has a lot of logic to allow an input video source to be blended with Apple II video (Video Overlay) and sent out a special video port. To really use the VOC card requires two monitors. Here's what the KEGS code has comments for $c0b1 and $c0b5:
case 1: // 0xc0b1
// bit 0: R/W: 1=GG Bus Enable
// When 0, I think VOC ignores writes to $c023,etc.
// bit 2: R/W: 0=OutChromaFilter enabled, 1=ChromaFilter disab
// bit 2 is also TextMonoOver somehow using bit[5]==1
// bit 3: R/W: 1=MainPageLin
// bits 5:4: R/W: 00=Aux mem; 01=Main Memory; 11=Interlaced
// bit 6: R/W: 1=Enable VBL Interrupt
// bit 7: R/W: 1=Enable Line interrupts
...
case 5: // 0xc0b5
// bits 3:0: R/W: KeyColor Red
// bit 4: R/W: OutExtBlank: 0=Graphics, 1=External
// bit 5: R/W: 0=GenLock enabled, 1=GenLock disabled
// bit 6: R/W: 0=KeyColor enabled, 1=KeyColor disabled
// bit 7: R/W: 1=Interlace mode enabled
This information is from various places and the VOC header files.
KEGS ignore those other bits, but I gave the proper values for a real VOC card. If you write $c0b1:30, the the VOC will stop updating its video
memory and the video memory will be all scrambled looking since bit 3 works like $c029 bit 6 for Aux memory.
KEGS alsoKEGS has limited support for the Apple Video Overlay Card (VOC). The VOC >> >> supports a special 640x400 interlaced SHR video mode which is what
The VOC has a lot of logic to allow an input video source to be blended with >> Apple II video (Video Overlay) and sent out a special video port. To really >> use the VOC card requires two monitors. Here's what the KEGS code hassupports. To turn on this mode, you need to do:
Enable VOC (Press F4, select "Enable VOC = Enabled")
c029:c1 # Turn on SHR
c0b1:39 # Set bits [5:4]=11 to enable Interlaced mode
c0b5:80 # Set bit 7 to enable Interlace mode
Looks good on full screen. Too bad the interlaced mode makes it a
little harder to display fonts. Was hoping to display fonts at 132
characters x 48 lines.
Is C0B1 supposed to be $30, or what does the 9 supposed to do?
comments for $c0b1 and $c0b5:
case 1: // 0xc0b1
// bit 0: R/W: 1=GG Bus Enable
// When 0, I think VOC ignores writes to $c023,etc.
// bit 2: R/W: 0=OutChromaFilter enabled, 1=ChromaFilter disab
// bit 2 is also TextMonoOver somehow using bit[5]==1
// bit 3: R/W: 1=MainPageLin
// bits 5:4: R/W: 00=Aux mem; 01=Main Memory; 11=Interlaced
// bit 6: R/W: 1=Enable VBL Interrupt
// bit 7: R/W: 1=Enable Line interrupts
...
case 5: // 0xc0b5
// bits 3:0: R/W: KeyColor Red
// bit 4: R/W: OutExtBlank: 0=Graphics, 1=External
// bit 5: R/W: 0=GenLock enabled, 1=GenLock disabled
// bit 6: R/W: 0=KeyColor enabled, 1=KeyColor disabled
// bit 7: R/W: 1=Interlace mode enabled
This information is from various places and the VOC header files.
KEGS ignore those other bits, but I gave the proper values for a real VOC
card. If you write $c0b1:30, the the VOC will stop updating its video
memory and the video memory will be all scrambled looking since bit 3 works >> like $c029 bit 6 for Aux memory.
Thanks for the explanation. It is probably not likely I will write
software to be fully compatible with a real VOC on a real computer.
I can see benefits to having a linear mode over the interlaced mode,
though. The interlaced mode would allow up to 512 colors per screen,
nicer for graphics.
But linear mode would be better for displaying fonts and doing
compression. I could use the same font driver without having to display >every second line of a font, or the same graphics compressor, as used
for regular SHR.
Could you let me know if linear mode is in the works? If not, then I
will just have to live with it and re-write some drivers to make use of
its interlaced mode.
Thanks for make this easy to work with, for someone without a VOC card.
All people requesting something like this have never followed up with
any proof-of-concept software. And no one had produced anything even
roughly approaching a specification--how it would work, how the memory
maps to the screen, how to detect it's present, how it interacts with existing modes, etc. Will there be a patched Quickdraw II to support
your new graphics mode, provide a library of routines for others to use, etc.?
There was a Second Sight card for the IIgs which implemented VGA (if I remember right), and there was almost no software support for it. And it
was not well designed and was buggy. I don't see how implementing that in KEGS would be useful since who's going to write the software to use it?
VOC 400 lines of SHR interlaced is different--there's existing hardware which supports it, rumors of software which supports it (which I was
unable to get working, since it was in French), and it is somewhat
defined. So I implemented it as a nice challenge since it wasn't too
hard. Note that I state KEGS cheats and doesn't really implement the
VOC 400 line interlaced mode right-- for static screens it's basically
the same, but dynamic screen changes are not modeled in KEGS the same
way as a VOC. And that's strictly because I implemented in a simple
way. My thinking was if no one ever uses the VOC in KEGS, I'm out only
a few hours of effort. And if someone uses it, I can look into
improving the KEGS emulation.
I recommend you try to maintain VOC compatibility so that any 400-line
SHR code you write would work on a real VOC.
Hi All,
I agree with nearly everything written by "I am Rob" but I would make
data start at $0 and not at $200.
I would add the use of a softswitch to tell the emulator each bank number must be used to display the 400 lines. The advantage would be to use two
or more VGA pages. A great option for game programmers :-)
People should know that A LOT of QuickDraw II routines work in 64K only, despite the huge space coordinates of QD II. That is a big limit of the
Apple IIgs implementation of QuickDraw.
Please remember Facelift. The objective was to enhance/rewrite the
toolbox to support more than the current video modes. That is a great
idea (and I still want to make it live) but one would have to
enhance/rewrite a lot of code, even TextEdit with the scrolling routines.
More than VGA, I would be more interested to get a MCGA (320x200x256)
mode in emulators. The TurboRez for emulators. With the same multiple
screen option as described above. It would be cool to write games for
such a machine, and we would stay in a 64K bank.
Antoine
And I think Kent’s point about it being hard to justify coding (or building a card!) for a new graphics mode if no significant software supports it.
The Apple II universe has quite a few hardware extensions that *sounded* really useful, but they never overcame the “chicken/egg” problem.
This is how I would think of support for VGA should be implemented.
For a 640x400x256 screen would require 4 full banks.
Each pixel would be represented by a full byte requiring 640 ($280)
bytes per line.
100 lines would require 640*100=64000 bytes in each bank
We would not need the scan lines any more and the 256 color selection
would be made up of whole bytes. 4 bytes required for each color >description.
Each Color description requires whole bytes of Red, Green & Blue and one
page for luminescence. In each bank of memory it would look like:
$FC00.FCFF - each byte being the red color for the color selected by the pixel >$FD00.FDFF - each byte being the green color for the color selected by the pixel
$FE00.FEFF - each byte being the blue color for the color seclected by the pixel
$FF00.FFFF - each byte being the luminescence of the color selected by the pixel
For example. if the pixel # is $22 then the color for that pixel is
derived from
red - $FC00 + $22
green - $FD00 + $22
blue - $FE00 + $22
lum - $FF00 + $22
4 pages of color description = $400 (1024) bytes and gives us a choice
of 256 colors out of 16,777,214.
A partial screen of graphics then would require a total of 65024 bytes
needed for 100 lines of graphics and 512 bytes of free memory.
Then, for a 640x400 screen, 4 banks of contiguous RAM memory will be needed. >Each bank uses memory from $0200.$FBFF for the screen and $FC00.FFFF for
the color palettes
Each bank holds 100 lines of 640 pixels requiring 640 ($280) bytes per
line in linear fashion
Linear meaning the first bank views the top 100 lines, 2nd bank second
100 lines, 3rd bank third set of 100 lines and 4th bank last set of 100 >lines.
Interlaced vs linear. Although an interlaced mode would allow dithered >colors to be represented and thus more colors, linear mode is way better
for displaying fonts and doing graphics compression.
This is how I would think of support for VGA should be implemented.
For a 640x400x256 screen would require 4 full banks.
Each pixel would be represented by a full byte requiring 640 ($280)
bytes per line.
100 lines would require 640*100=64000 bytes in each bank
We would not need the scan lines any more and the 256 color selection >would be made up of whole bytes. 4 bytes required for each color >description.
Each Color description requires whole bytes of Red, Green & Blue and one >page for luminescence. In each bank of memory it would look like:
$FC00.FCFF - each byte being the red color for the color selected by the pixel
$FD00.FDFF - each byte being the green color for the color selected by the pixel
$FE00.FEFF - each byte being the blue color for the color seclected by the pixel
$FF00.FFFF - each byte being the luminescence of the color selected by the pixel
For example. if the pixel # is $22 then the color for that pixel is >derived from
red - $FC00 + $22
green - $FD00 + $22
blue - $FE00 + $22
lum - $FF00 + $22
4 pages of color description = $400 (1024) bytes and gives us a choice
of 256 colors out of 16,777,214.
A partial screen of graphics then would require a total of 65024 bytes >needed for 100 lines of graphics and 512 bytes of free memory.
Then, for a 640x400 screen, 4 banks of contiguous RAM memory will be needed.
Each bank uses memory from $0200.$FBFF for the screen and $FC00.FFFF for >the color palettes
Each bank holds 100 lines of 640 pixels requiring 640 ($280) bytes per >line in linear fashion
Linear meaning the first bank views the top 100 lines, 2nd bank second
100 lines, 3rd bank third set of 100 lines and 4th bank last set of 100 >lines.
Interlaced vs linear. Although an interlaced mode would allow dithered >colors to be represented and thus more colors, linear mode is way better >for displaying fonts and doing graphics compression.
What kind of software do you expect to use this mode? As has been pointed out, 2.8MHz code will very slowly update the screen. It's 8x the data,
so even "fast" routines will be noticeably slow.
How would this mode be enabled? Do you want to support switching in and
out of the mode multiple times per screen? When are the palettes
sampled-- once before line 0, or before each line, or effectively
instantly (so if the screen is all $22 bytes, changing the the palette
entry for $22 red immediately changes the color for that line from then
on)? What banks do you want to use?
If you want the palette changes to instantly show up, it's much more
work to implement. I'd like the palettes to be sampled just before line
0, and then they are unchangeable for that screen.
KEGS already supports the VOC to deliver 640x400x2 (2-bit color) (or 320x400x4, meaning 4-bit color), and as far as I know, no one's bothered
to do anything with it yet (which does not surprise me, the software to
use these things on the IIgs is much harder to write than the code to implement it). I could more easily add a new VOC enhanced mode to do 320x200x8 (using bank $e0 for the upper 4 bits of the palette index, and bank $e1 for the lower 4 bits, using the same palette locations in bank
$e1 and bank $e0 to give 24-bit color).
As for palette sampling. They call it racing the beam. But yes, I think the palettes should be read before each line is scanned to screen. For games that do animation, I think this is a must. It is not necessary to re-read the palette as each pixel isplotted. So the sequence would be:
1) increment the vertical line counter $C02E.C02F
2) check for bottom line of screen for 400 - if so then update $C019 to show vertical blanking on
3) use the colors in the palette that are present before each line starts, to display the line
This sequence should allow a pixel color to be changed as long as it is done before $C02E.C02F reach that line.
If you want the palette changes to instantly show up, it's much more
work to implement. I'd like the palettes to be sampled just before line
0, and then they are unchangeable for that screen.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 468 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:13:56 |
| Calls: | 9,440 |
| Calls today: | 3 |
| Files: | 13,594 |
| Messages: | 6,109,629 |