From Newsgroup: comp.emulators.apple2

I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.16.
The Mac executable should run on 10.13 or later. It's also a universal app,
so it runs native on Apple M1 silicon. There's a Linux executable as well.

KEGS v1.16 is available at: http://kegs.sourceforge.net

Changes in KEGS v1.16 since v1.14 (01/23/22)
- Better cursor focus tracking, less likely to have an invisible cursor
when KEGS is no longer the active window.
- F5 now toggles the status display at the bottom on/off. This state can
be saved in config.kegs.
- 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.
- Add limited Video Overlay Card (VOC) support to add new SHR mode of 640x400
(interlaced).
- You can "D"uplicate any disk image to a new file, and "V"erify any ProDOS
image.

Full source code is included. To rebuild on the Mac, all you need is to download XCode and KEGS, "cd src; make".

Kent
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

F5 rulez :-) Thank you for that shortcut.
When I open-apple-6 under Merlin 16+, macOS comes first and grabs the shortcut. I do not know if that is linked to the way key presses are handled to support multi-lingual keyboard, and I hope it is not, because that Merlin key shortcut is just necessary to me. Open-apple-6 is the command to assemble and link source files to generate a S16 program.
Great release, thank you,
Antoine
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

- 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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

Would like to mention that under MacOS 10.13, one may have to go into System Prefences and under Security, unlock the lock to make changes to allow Apps to run that are not download from the Mac app Store.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

I am Rob wrote:

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

My understanding of the interlaced modes of the VOC is that one field is
in bank $E0, and the other in $E1 (or mainmem, and auxmem on a IIe).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <b9fc4cf6-94d2-4106-9492-be0ae34c345bn@googlegroups.com>,
I am Rob <gids.rs@sasktel.net> wrote:

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

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

And then KEGS will show 640x400 (or 320x400) SHR screen, where even lines (0,2,4,etc) come from bank $e1 like normal SHR mode, and odd lines come from bank $e0 (from $2000-$9fff, using it's own palettes, etc.). The real VOC
shows interlaced data--it draws one frame of data from bank $e1, then the
next from of data from bank $e0, shifted down one line, etc., where each
from takes 16msec, for an effective display of 30fps. KEGS just draws both bank $e1 and bank $e1 changes every frame at 60fps. This can be fixed if anyone uses this mode and wants better accuracy.

Kent
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <stiuog$7e1$1@gioia.aioe.org>,
Brian Patrie <bpatrie@bellsouth.spamisicky.net> wrote:

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)

Oops, it didn't get included due to a bug in my release script.

I'm including README.dynapro.txt.

Kent

DYNAPRO
-------

Dynapro is a KEGS feature where an emulated disk (140KB 5.25" in slot 6, 800KB 3.5" in slot 5, or any size up to 32MB in slot 7) volume is mapped to a host (Mac, Linux) directory (and subdirectories). This allows easy access to move files from emulation--just look at the files from outside KEGS on your host computer, they are always up to date. It also provide a simple way to move files into emulation: update the file under the Dynapro mount point, and then remount the volume to ensure KEGS/ProDOS can see the changes.

How to enable
-------------

Create a folder on your Mac/Linux system. You can place files in it, or leave it empty. From within KEGS, press F4, select Disk Configuration, and then use arrows to move to the slot and drive you want to mount that folder as.

You have two choices: A slightly longer process where you can set the DynaPro image size (if you want less than 32MB for a slot 7 image), or a shorter process that always mounts the largest size for that slot.

Selecting the size:
------------------

Press "n" to create a new image. Select the size you would like with left/right arrows if you picked slot 7. (slot 5 is always 800KB, and slot 6
is always 140KB). It's fine to always pick 32MB, the default. Scroll down to Type, select "Dynamic ProDOS directory". Scroll down to "Create and name the image". Use the normal image selection interface to navigate to the directory you want to use. Press tab to switch to the path view (you can manually enter parts of the path if you like), and while on the path, press Cmd-Enter to select the named directory. Note: The directory that will be selected is the path listed on the "Path: " line (relative to the Current KEGS Directory if it doesn't start with a "/").

Using the maximum size:
----------------------

Press return on the slot/drive line you want to mount as a Dynapro directory. Using selection, select into the directory you want to use, then press Cmd-Enter to select that directory. A maximum size Dynapro directory will be mounted. The maximum size for slot 7 images is 32767.5KB (65535 blocks).

How to use
----------

If you pick a directory that has files whose total size exceeds the size you selected, it will fail to mount. The slot/drive entry will be commented out showing no disk mounted.

Now, from within KEGS, you can do any operation to this volume that you would have if it were a normal disk image--copy files, initialize it, etc. This works under ProDOS 8 or GS/OS, or any program that supports ProDOS images.
All changes to the image as ProDOS volume are immediately reflected in the directory on your host machine.

Gotchas to watch out for
------------------------

KEGS aggressively makes the directory match the ProDOS volume. If you erase a file using GS/OS (as an example), KEGS will erase that file from the directory you selected. If you format the volume, KEGS will erase all files in the directory you selected. So: be careful what you points KEGS at!

How it works
------------

KEGS keeps a version of the ProDOS volume in memory (so 32MB if you mount a 32MB Dynapro directory). Whenever any writes happen, KEGS looks to see what file(s) are affected, and reparses them to recreate the files in the Dynapro directory on your host system. Since ProDOS and GS/OS write one block at a time, there are many times during a write to a file where the file is invalid. KEGS erases all files from the Dynapro host directory when the ProDOS file appears invalid, even briefly. So, writing to a file can cause it to be
erased from the Dynapro host directory until the file is completely written
and appears valid again.

How to copy files from your host system to KEGS emulation ---------------------------------------------------------

ProDOS and GS/OS do not expect ProDOS volumes to change behind their back. To reliably transfer files from your host system into the emulated //gs system, you should unmount and re-mount the Dynapro directory. This tells ProDOS 8
and GS/OS to expect changes to the volume, and to see any changes you've made.

So if you create a new file called "NEW.TXT" in the Dynapro host directory, it doesn't show up in KEGS right away.

Press F4, go to the Disk Configuration page (you may already be there if you left the F4 configuration here), select the slot/drive of the Dynapro volume
to remount and press Return. A file selection dialog appears. Just press Cmd-Enter to re-mount the image (the selection for the existing volume will already be correct). Press F4 to return to the emulated system.


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

- 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?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <f2bf22cc-e731-483e-857a-8769f23d0c2bn@googlegroups.com>,
I am Rob <gids.rs@sasktel.net> wrote:

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

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.

Kent
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <87227c06-e7c8-4c20-b732-fb4f5f290e27n@googlegroups.com>,
I am Rob <gids.rs@sasktel.net> wrote:

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.

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.

I'm not sure what you're referring to as "linear mode". KEGS adds
emulation for the VOC interlaced SHR mode. You'll have to define what
you want so I can understand it.

Several people over the years have asked KEGS to support something like
VGA graphics or whatever. And that's the limit of what they asked for.
How should this be done? What memory banks in the IIgs will hold the
memory buffer?

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.

Kent
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.

Oh, I will be using it alright! I have been wanting something like this for awhile. I don't think anyone really cares how you implement VGA or VOC as long as it is there for people to use to allow for the extra screen resolution. And I don't think it is a big priority to have it compatible with existing hardware, as it will be mostly used for personal use.
As it stands, to display a font in VOC mode, I would have to program the driver to printer every second line of a font character to Bank E0, then every other second line to Bank E1.
With Linear mode, the top half of the screen (first 200 lines) would be in bank E0 and the bottom half of the screen (last 200 lines) would be bank E1. This way the font driver doesn't have to break up the font characters to print to alternate lines. Any pre-existing Font display routines can be used as is, and just extended to print to lines 201-399 with just one bank switch call.
Rob
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

Antoine Vignau <ntn.vignau@gmail.com> wrote:

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 an MCGA mode would be more than 4 times faster for animation and
graphics changes.

More and bigger pixels is slower and slower. ;-)

We only have multi megapixel displays because memory and processors got
much cheaper and much faster.

And I think KentrCOs 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 rCLchicken/eggrCY problem.
--
-michael - NadaNet 3.1, AppleCrate II, and Burroughs 220 emulation: http://michaeljmahon.com
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1738776716-1646765978=:13821
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 8 Mar 2022, Michael J. Mahon wrote:

And I think Kent=E2=80=99s point about it being hard to justify coding (o=

r 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 =E2=80=9Cchicken/egg=E2=80=9D =

problem.

I think the only examples I'm aware of of a third-party Apple ][=20
peripheral becoming useful enough to be supported by much of anything are=
=20
parallel port cards and the Mockingboard.

-uso.
--8323329-1738776716-1646765978=:13821--
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <2687da16-2510-4dbe-962b-a905c4c3e6c3n@googlegroups.com>,
I am Rob <gids.rs@sasktel.net> wrote:

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.

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.

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.

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).

Kent
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.

That's strange. Sorry, didn't get back to you sooner, Kent. I read Steve's and Michael's posts and even though you wrote your post an hour earlier than Steves, it didn't show up til a bit after. So seeing Steve as the last poster, I didn't check this thread til now.

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.

I expect this mode will only be used or supported with your emulator. KEGS runs at 1.8 Ghz in unlimited mode in my emulator, as long as you don't bottle-neck viewing VGA mode down to 2.8 Mhz. Shouldn't be a problem for software to keep up. The only thing I would request is that the vertical line number of the line being scanned be returned in $C02E.C02F, ($C02E is normally the vertical line and C02F the horizontal position). Since we are in VGA mode, this shouldn't interfere with their normal usage. And it would help a great deal if $C02E were limited to 0-99 for line #'s and $C02F would be 0-3 for bank #'s. And $C019 still used for timing the VBL when it reaches the top of the screen to allow for 60 FPS. Unless someone would like to see 120 FPS?

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?

You used $C0B1 and $C0B5 for VOC initialization. If you don't support VOC any further than this and VGA mode will only be used in your emulator, is there any reason we can't use the same locations. I still may use VOC even though VGA is available and would be nice to only have to remember one set of locations. How about setting just setting $C0B1 and $C0B5 with hi-bits set to enable VGA mode. And the linear bits of those bytes are set to zero, in case you want to enable linear mode down the road, you can use the same way as VOC does.
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 is plotted. 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.

This limits the screen to 256 colors per screen instead of 256 colors per line. I hope this isn't too much more to implement as the only real difference is sampling the palettes before each line instead of the beginning of each screen display. Let me know if it becomes too much more to program, more time than you are willing to spend on it. I'm flexible since I don't have the means to do it myself.

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).

The 400 lines of non-interlaced mode are more important to me for font displays and even so for gaming, and the 256 color palette I laid out would be much easier for me to port over a lot of games from the Win 95-98 era that use the 640x480x256 screen. Hopefully I can convince you to put in the extra effort to make it easier for me and I think the extra screen real-estate can make KEGS very desirable as an emulator.
Also, if you put up a donation button somewhere, I would be willing to donate to the cause. There are very few emulators that are able to run on the newer Operating Systems that are coming out. I would like to see you updating KEGS for as long as possible.
Thanks for all you have done. KEGS is a pleasure to play on.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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 is plotted. 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.

After some thought, it probably wouldn't need to have a scan line reported in $C02E.C02F or the palette loaded before each line, but each palette should be loaded from each bank before that banks has its 100 lines displayed. Allowing each bank to have a different 256 colors. There would be plenty of time to do whatever one needs to do during the blanking stage if there is no throttling of speed in the memory for graphics display.
Only $C019 would need to be updated to indicate the vertical blanking period. Hope this helps to make it easier.
--- Synchronet 3.21b-Linux NewsLink 1.2