Question: How *exactly* does an Apple IIGS emulate the 8-bit Apple IIe?

For decades the answer has seemingly been the Mega II chip, essentially
an entire 8-bit Apple IIe computer on a single chip (minus the CPU, RAM
and ROM). In fact Apple's marketing and technical documentation always
pointed to the Mega II as how the Apple IIGS was backwards compatible.

I've always know the Mega II is what provides classic Apple II video
modes for the IIGS (40/80 ASCII, including Mousetext and international
symbols, LR, HR, DLR, DHR). And while some functions are not used
such as its keyboard control and mouse support, I just assumed the rest
was responsible for the Apple IIGS's 8-bit emulation mode....

Then I saw James Lewis' project to build a single chip Apple II, and
read his claim the Mega II's primary (sole?) function is to provides 8-bit
video modes. So, that got me curious. What, exactly, is allowing the
IIGS to emulate the Apple IIe? Such as its sound generation, or replicating
the MMU, IOU and various other components? Is it simply the FPI/CYA
chipset and some other TTL logic recreating the Apple IIe? If none of it
is coming from the Mega II, I'm looking for the real nitty gritty in terms of
technical details on how the Apple IIGS emulates an Apple IIe.

On a side note, if the Mega II was NOT responsible for Apple IIe
emulation, and mainly just used as an I/O controller that bottlenecked
the IIGS bus and video draws to 1 MHz, one questions why on earth
Apple didn't scrap the Mega II and design a replacement chip for the
IIGS in all those years? It seems like it was added to the IIGS simply
because it happened to be sitting unused in Apple's development
tool box (the Mega II was originally developed for other purposes).

Mitchell Spector

Mitchell Spector wrote:
>
> On a side note, if the Mega II was NOT responsible for Apple IIe
> emulation, and mainly just used as an I/O controller that bottlenecked
> the IIGS bus and video draws to 1 MHz, one questions why on earth
> Apple didn't scrap the Mega II and design a replacement chip for the
> IIGS in all those years? It seems like it was added to the IIGS simply
> because it happened to be sitting unused in Apple's development
> tool box (the Mega II was originally developed for other purposes).
>

In March 1990, Todd P. Whitesel said: "The Mega II has to run at 1 Mhz and
in the GS that's a big problem. If they had implemented its functions in a
more distributed manner then the only part of the machine that would run
slow would be the actual expansion slots. When the GS was originally
designed they barely had the technological capability to do this [chip
design], but for a couple of years now it is has been well within Apple's
custom chip capability.

https://macgui.com/usenet/?group=1&id=24939

He further said: "The Mega II "Apple II on a chip" is the Ball and Chain of
the GS -- it was originally designed for a low cost //e but wasn't cheap
enough to make the //e any cheaper. (to Apple, apparently. Certainly not to
us.)

When they get rid of it and implement the logic where it belongs (i.e. all
over the machine and integrated into the custom chips that handle each part
of the system already) it will blow away the performance limitations of the
current design and cost a hell of a lot less.

Do not assume that the IIGS is the best that the Apple II can do. You would
be doing the machine a serious injustice, and there are a number of specific
examples which are so trivial to fix that they would have done so long ago
had
they been given more than miserable funding for the project. "

https://macgui.com/usenet/?group=1&id=24989 (at the bottom of his message)

In May 1990, Brian Willoughby explained: "The Mega II is not bad. The Mega
// exists to support the old Apple video (along with some other I/O specific
hardware). The Mega // runs at 1 MHz purely because that is the rate at
which the video information is needed for every screen mode except Super
HiRes. It would do no good to speed up the Mega //, because the
functionality it provides would not be improved at all.

The only thing that needs improvement is the way in which the Mega //
accesses video RAM. Here is where the bottleneck appears. If Apple Co.
were to integrate the Video RAM from the Mac SE/030 into the GS, then the
CPU could access video RAM with no contention from the Mega //. In other
words,dual port RAM would no longer require the the CPU to slow down to 1
MHz for video I/O.

What we need is not a replacement for the Mega //, but a way for the Mega //
to share RAM with a very fast processor without adding wait states.

https://macgui.com/usenet/?group=1&id=43028

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

Here's some information from David A. Lyons dated December 1988:

The slow side of the GS runs at 1MHz, and exists in the first place, for a
very good reason (and complexity is not it!). The old Apple II video modes
(text, lores graphics, 80-col text, double-lores graphics, hires graphics,
and double-hires graphics) are designed so that the display hardware needs
to read from the display memory (which is in Slow RAM on the GS) once each
microsecond to get data
to feed to the screen.

When the CPU was running at 1MHz, this worked out perfectly, since the 6502
only needs access to its RAM during half of the clock cycle (which is 1
microsecond with a clock speed of 1MHz). No cycle stealing of any kind was
needed with a 1MHz CPU.

As I understand the GS, the FPI (Fast Processor Interface) synchronizes the
fast and slow sides of the system by making the 65816 wait, during access to
slow RAM, for the appropriate part of the slow side's clock cycle. By
"access to slow RAM" I mean a read or write of a location from $E00000 to
$E1FFFF, or a Write (not a read) to an area of fast RAM that happens to be
shadowed into slow RAM; shadowed RAM normally includes the text screen and
$Cxxx I/O locations, and also the hires/double-hires areas except when
ProDOS 16 or GS/OS is active.

https://macgui.com/usenet/?group=7&id=8690

Todd P. Whitesel was not a fan of the Mega II and the hardware design of the
IIgs. In February 1990 he wrote:

The //gs was not designed from scratch in any sense of the word. The Mega //
was originally designed to replace the //e chip set but wasn't cheap enough.
The decision to run with the Mega // was the worst made by the //gs design
team, and the next was the way they limited its expansion to the chips that
were available when it first came out. 4 mhz 65816s were quickly available,
and some very easy design changes could have been made which would have
improved the video I/O performance. Since you have implied that you aren't a
hardware guru I won't bore you with details, but I can support my contention
that the //gs hardware was neutered in many places.

https://macgui.com/usenet/?group=7&id=21427

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

D Finnigan wrote:
> He further said: "The Mega II "Apple II on a chip" is the Ball and Chain of
> the GS -- it was originally designed for a low cost //e but wasn't cheap
> enough to make the //e any cheaper. (to Apple, apparently. Certainly not to
> us.)
>
> When they get rid of it and implement the logic where it belongs (i.e. all
> over the machine and integrated into the custom chips that handle each part
> of the system already) it will blow away the performance limitations of the
> current design and cost a hell of a lot less.

Apple made the same mistake that Commodore did a year earlier: Implement backward compatibility in a discrete "system on a chip" (such as Mega II) that advances in VLSI made possible. While providing 100% compatibility, by walling off the "old" and "new" modes from each other, software developers had to choose one to support and of course chose the mode with the far larger installed base.

What both companies should have done is implement the new features within the existing software and hardware interfaces, as Apple had done with double hi-res, 80-column text, and lowercase. This would have decreased the level of backward compatibility, but developers would have released updated versions of existing software (just as software incompatible with IIe and IIc quickly got updated), and the IIgs would have benefited in the long run. Similarly, Commodore should have designed the 128 as a 64 with more memory, 80-column support, and a better BASIC. Again, backward compatibility would have been impacted, but over the long run there would have been more incentive for developers to release software that supports the 128's enhancements, and to update existing incompatible software.

One can argue—probably accurately—that Commodore would not have done this given its record of (lack of) backward compatibility, and that the 128 having a 64-on-a-chip is the most to be hoped for. But Apple did have both the history of incremental improvements and commitment to backward compatibility, so there is less excuse there. On the other hand, it's understandable how seductive the promise of being able to provide 100% backward compatibility with a single chip was.

--
geo:37.783333,-122.416667

From "Cortland Custom ICs - Wayne Lowry - Preliminary notes - 19860214"
(via https://www.brutaldeluxe.fr/documentation/cortland.html)

The Mega II is the integration of several enhanced Apple II chips. The
following chips comprise the Mega II:

* MMU Custom Chip
* IOU Custom Chip
* Character Generator ROMs (8 languages)
* TMG Timing Generator
* GLU General logic Unit
* Video logic

The Mega II, shown in Figure 10, has virtually all the characteristics
of an Apple II on a chip; it supports a slotted architecture and has
built-in peripherals.

---
It's possible that everybody, including Apple, has been wrong for 37
years but extraordinary claims require extraordinary evidence.

-------
ProLine: kelvin@pro-kegs

Kelvin Sherlock wrote:
> ---
> It's possible that everybody, including Apple, has been wrong for 37
> years but extraordinary claims require extraordinary evidence.
>

I found articles going back to the 1986 release of the IIgs that described
the Mega II as a "complete Apple II on a chip." Most likely someone made an
assumption about the chip, and it spread around, was repeated, and stuck for
37 years. This happens in every knowledge domain, not just with vintage
computers.

Here's a post from September 1986 that asks if the Mega II is an emulator
chip:
https://macgui.com/usenet/?group=6&id=3010

Here's a reference to an October 1986 BYTE Magazine article about the Mega
II:
https://macgui.com/usenet/?group=1&id=3626

THE MEGA II
The Mega II is a custom CMOS chip containing about 3000 gates and a 2K-byte
by 8 ROM (for the character generator). It replaces the following chips from
the Apple IIe and IIe: char­acter generator ROMs for eight lan­guages.
several TTL chips that per­form logic functions. and the MMU (memory
management unit). IOU (in­put/output unit). TMG (timing genera­tor). and GLU
(general logic unit) custom chips.

In previous Apple II designs, the re­freshing of memory was tied directly to
the Apple II video mode. The Mega II includes an 8-bit counter for
refresh­ing the 128K bytes of (slow) memory associated with the Apple
IIe/IIc model; it does five cycles of RAM refresh during the horizontal
retrace of each video scan line and refreshes the 128K bytes of memory in
3.25 milliseconds. By taking care of RAM refresh the Mega II chip opens the
Apple II design to new video modes that were impossible before.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

D Finnigan wrote:
> Kelvin Sherlock wrote:
>> ---
>> It's possible that everybody, including Apple, has been wrong for 37
>> years but extraordinary claims require extraordinary evidence.
>>
>
> I found articles going back to the 1986 release of the IIgs that described
> the Mega II as a "complete Apple II on a chip." Most likely someone made
> an
> assumption about the chip, and it spread around, was repeated, and stuck
> for 37 years.

Never mind; more reading yields the answer. It came from Apple Computer, per
the Cortland documentation that Kelvin Sherlock referred to in his previous
article.

From page 27 of the Custom ICs document:

"The Mega II, shown in Figure 10, has virtually all the characteristics of
an Apple II on a chip; it supports a slotted architecture and has built-in
peripherals."

-+-

But I think it got corrupted into "a complete Apple IIe on a chip," which
definitely isn't correct.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

On 2/11/24 2:38 AM, Mitchell Spector wrote:
> Question: How *exactly* does an Apple IIGS emulate the 8-bit Apple IIe?

[... is it complete, is it not complete, potato, potahtto... ]

More information from an actual recent project from James
Lewis/baldengineer (he's active on Slack) :
https://www.youtube.com/watch?v=gFCD4s_hsb4

- David

D Finnigan <dog_cow@macgui.com> wrote:

>From page 27 of the Custom ICs document:
>
>"The Mega II, shown in Figure 10, has virtually all the characteristics of
>an Apple II on a chip; it supports a slotted architecture and has built-in
>peripherals."
>
>-+-
>
>But I think it got corrupted into "a complete Apple IIe on a chip," which
>definitely isn't correct.

The Mega II *is* a complete Apple IIe on a chip. It's just, for the most
part, missing the CPU and ROM firmware.

Whether it can act as full fledged Apple IIe computer isn't the question,
it's whether or not the Apple IIGS uses it for emulating and running Apple
IIe software. According to James Lewis (and his "Mega Lie" segment in
his YouTube video) the answer is: 'No.' See the video below:

https://youtu.be/vKhUGuODqOM?t=162

The Mega II apparently just sits in the IIGS performing unrelated I/O
tasks, NOT emulating an Apple IIe (the fact that it can, is wasted). A small
part of it is used for providing classic Apple II text and video modes, but
that may be it. Which again begs the question....if it isn't the Mega II,
what logic allows the Apple IIGS to emulate an Apple IIe?

Mitchell Spector

Mitchell Spector wrote:
> D Finnigan <dog_cow@macgui.com> wrote:
>
>>From page 27 of the Custom ICs document:
>>
>>"The Mega II, shown in Figure 10, has virtually all the characteristics of
>>an Apple II on a chip; it supports a slotted architecture and has built-in
>>peripherals."
>>
>>-+-
>>
>>But I think it got corrupted into "a complete Apple IIe on a chip," which
>>definitely isn't correct.
>
> The Mega II *is* a complete Apple IIe on a chip. It's just, for the
> most
> part, missing the CPU and ROM firmware.

We don't need to argue this further, but in my opinion, if you state that it
is missing the CPU and ROM firmware, then in my opinion you conclude that it
is not a complete Apple IIe on a chip.

:-)

>
> The Mega II apparently just sits in the IIGS performing unrelated I/O
> tasks, NOT emulating an Apple IIe (the fact that it can, is wasted). A
> part of it is used for providing classic Apple II text and video modes,
> but
> that may be it. Which again begs the question....if it isn't the Mega II,
> what logic allows the Apple IIGS to emulate an Apple IIe?

Part of the answer is the 8-bit mode in Mensch's 65C816, right?

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

In article <kvrgsipj5orb244msd7nk4l0agt76gr3c7@4ax.com>,
Mitchell Spector <mitch2gs@hotmail.com> wrote:
> Question: How *exactly* does an Apple IIGS emulate the 8-bit Apple IIe?
>
> For decades the answer has seemingly been the Mega II chip, essentially
>an entire 8-bit Apple IIe computer on a single chip (minus the CPU, RAM
>and ROM). In fact Apple's marketing and technical documentation always
>pointed to the Mega II as how the Apple IIGS was backwards compatible.
>
> I've always know the Mega II is what provides classic Apple II video
>modes for the IIGS (40/80 ASCII, including Mousetext and international
>symbols, LR, HR, DLR, DHR). And while some functions are not used
>such as its keyboard control and mouse support, I just assumed the rest
>was responsible for the Apple IIGS's 8-bit emulation mode....
>
> Then I saw James Lewis' project to build a single chip Apple II, and
>read his claim the Mega II's primary (sole?) function is to provides 8-bit
>video modes. So, that got me curious. What, exactly, is allowing the
>IIGS to emulate the Apple IIe? Such as its sound generation, or replicating
>the MMU, IOU and various other components? Is it simply the FPI/CYA
>chipset and some other TTL logic recreating the Apple IIe? If none of it
>is coming from the Mega II, I'm looking for the real nitty gritty in terms of
>technical details on how the Apple IIGS emulates an Apple IIe.
>
> On a side note, if the Mega II was NOT responsible for Apple IIe
>emulation, and mainly just used as an I/O controller that bottlenecked
>the IIGS bus and video draws to 1 MHz, one questions why on earth
>Apple didn't scrap the Mega II and design a replacement chip for the
>IIGS in all those years? It seems like it was added to the IIGS simply
>because it happened to be sitting unused in Apple's development
>tool box (the Mega II was originally developed for other purposes).
>
>Mitchell Spector

Here's how the IIgs works:

There's a 65816 CPU, and it talks to the FPI/CYA chip at 2.8MHz, and it
connects to the 16MB of RAM/ROM on the motherboard and in the memory
expansion slot. This is all the "fast" side of the system, and it all runs
at 2.8MHz. The FPI generates refresh cycles as needed to the fast RAM.

There's a "slow" side to the system, where there is a 16-bit address bus
and is clocked at 1MHz. The 16-bit ABUS[15:0] address bus and the
DBUS[7:0] data bus that the 65816 and FPI use at 2.8MHz are buffered to
a "1MHz" BABUS[15:0] address and MDBUS[7:0] data bus which connects to
all 1MHz components. The FPI determines when a CPU cycle needs to
access the slow side of the system, and generates all the control
signals needed to do this. The slow side includes the Mega II, but is
also includes the IWM, VGC, SCC, and Ensoniq.

As for what the Mega II is, it's important to think of what an Apple //e
is. An Apple II+ is a bunch of random 74LS TTL logic that generates the
video control signals, decodes the address and selects RAM/ROM/IO, etc.
An Apple //e adds the auxiliary memory (the second 64KB bank), and other
stuff, and although this could all be done in 74LS TTL chips, it would
be a much larger board. So the //e adds MMU and IOU chips to make the
board simpler, just putting the II+ (and some new //e logic) 74LS TTL
logic on fewer chips that take less space. The Mega II is just this
process done again, merging the //e MMU, IOU, and video control circuits
into one chip. It's the "same" logic effectively, with some tweaks. By
freeing up board space, the IIgs now has room for IWM, ADB, VGC,
Ensoniq, SCC, etc. The Mega II is not a complete Apple //e--decode
logic for the slots is not included and requires the Slotmaker chip.

It is logically the "same" as the //e logic it is performing, so it's
not especially "magic" in what it's doing. The "magic" is at the FPI/CYA
chip, which does the speed conversion. The fast side of the system runs
at 2.8MHz, and when something "slow" is touched, the FPI is the chip which
does the conversion to 1MHz. The FPI is the bridge to the "Apple II" side.

There is some additional magic where the Mega II and VGC work together to
create the SHR graphics mode. I believe the VGC provides the video
addresses, but the Mega II continues to provide the memory control signals
(RAS, CAS).

So, the FPI is the magic that talks to the slow Apple II side. The Mega II
is just one of the things it talks to, which is just most of Apple //e
logic rolled into one chip to take less board space.

The Mega II is MMU, IOU, and non-SHR video generation on a IIgs, but
only for banks $E0 and $E1. So the FPI has to ALSO have the MMU logic
in it since it affects fast side memory as well. One way to think of
the Mega II is it controls the memory in banks $E0 and $E1, and that is
the Apple //e part, so it's doing the MMU features for that memory. But
the FPI is handling all other banks, so it has replicated the MMU logic,
too (aux/main and LC switches are all in the FPI, too, as well as the
Mega II). The FPI just replicates the needed logic to get the Apple //e
compatibility right. The FPI handles shadowing, passing writes to the
video memory in banks $00 and $01 to also go to the Mega II to update
the bank $E0 and $E1 memory. So this is likely where some confusion
arises--the FPI also has to do lots of things for Apple //e
compatibility, and does it in parallel, duplicating some Mega II
functionality.

Kent

In article <dog_cow-1708091984@macgui.com>,
D Finnigan <dog_cow@macgui.com> wrote:
>Kelvin Sherlock wrote:
>> ---
>> It's possible that everybody, including Apple, has been wrong for 37
>> years but extraordinary claims require extraordinary evidence.
>>
>
>I found articles going back to the 1986 release of the IIgs that described
>the Mega II as a "complete Apple II on a chip." Most likely someone made an
>assumption about the chip, and it spread around, was repeated, and stuck for
>37 years. This happens in every knowledge domain, not just with vintage
>computers.
>
>Here's a post from September 1986 that asks if the Mega II is an emulator
>chip:
>https://macgui.com/usenet/?group=6&id=3010
>
>Here's a reference to an October 1986 BYTE Magazine article about the Mega
>II:
>https://macgui.com/usenet/?group=1&id=3626
>
>
>THE MEGA II
>The Mega II is a custom CMOS chip containing about 3000 gates and a 2K-byte
>by 8 ROM (for the character generator). It replaces the following chips from
>the Apple IIe and IIe: char­acter generator ROMs for eight lan­guages.
>several TTL chips that per­form logic functions. and the MMU (memory
>management unit). IOU (in­put/output unit). TMG (timing genera­tor). and GLU
>(general logic unit) custom chips.
>
>In previous Apple II designs, the re­freshing of memory was tied directly to
>the Apple II video mode. The Mega II includes an 8-bit counter for
>refresh­ing the 128K bytes of (slow) memory associated with the Apple
>IIe/IIc model; it does five cycles of RAM refresh during the horizontal
>retrace of each video scan line and refreshes the 128K bytes of memory in
>3.25 milliseconds. By taking care of RAM refresh the Mega II chip opens the
>Apple II design to new video modes that were impossible before.

I don't know the source of the above paragraph and what it's trying to say,
but I do not believe it is correct. The memory refresh of slow memory in a
IIgs done by the Mega II is identical to how a //e does it. The //e had to
make changes to the II+ logic since it supported 64kbit DRAMs (a II+ only
supports 4kbit and 16kbit DRAMs), and these new big DRAMs require 8 bits of
rows to be refreshed, but the IIgs uses the same 64kbit DRAMs so it's just
done the same way. There are differences in how SHR works, and maybe that's
what they're trying to describe (as far as I know, the details of SHR
memory accesses and refresh are not fully documented, but note that simply
showing the SHR screen fully refreshes memory just like all other video
modes on an Apple II). On an Apple II, it's the text and lores modes which
have to do careful trickery to fully refresh memory in the required time
(and it's why the video memory layout is so weird). HGR and SHR could
easily refresh memory if they were linear--but HGR can be done with slight
tweaks to text mode and need very little additional logic, and that's why
it is the way it is. SHR was a new mode done on a new chip where saving one
TTL part didn't matter, so it's linear in memory.

Kent

kegs@provalid.com (Kent Dickey) wrote:

>In article <kvrgsipj5orb244msd7nk4l0agt76gr3c7@4ax.com>,
>Mitchell Spector <mitch2gs@hotmail.com> wrote:
>
>> Then I saw James Lewis' project to build a single chip Apple II, and
>>read his claim the Mega II's primary (sole?) function is to provides 8-bit
>>video modes. So, that got me curious. What, exactly, is allowing the
>>IIGS to emulate the Apple IIe?
>
>Here's how the IIgs works:
[snip]
>So, the FPI is the magic that talks to the slow Apple II side. The Mega II
>is just one of the things it talks to, which is just most of Apple //e
>logic rolled into one chip to take less board space.
>
>The Mega II is MMU, IOU, and non-SHR video generation on a IIgs, but
>only for banks $E0 and $E1. So the FPI has to ALSO have the MMU logic
>in it since it affects fast side memory as well. One way to think of
>the Mega II is it controls the memory in banks $E0 and $E1, and that is
>the Apple //e part, so it's doing the MMU features for that memory. But
>the FPI is handling all other banks, so it has replicated the MMU logic,
>too (aux/main and LC switches are all in the FPI, too, as well as the
>Mega II). The FPI just replicates the needed logic to get the Apple //e
>compatibility right. The FPI handles shadowing, passing writes to the
>video memory in banks $00 and $01 to also go to the Mega II to update
>the bank $E0 and $E1 memory. So this is likely where some confusion
>arises--the FPI also has to do lots of things for Apple //e
>compatibility, and does it in parallel, duplicating some Mega II
>functionality.

Thanks for providing all that, it provides more of a picture of what's
going on behind the scenes when emulating an Apple IIe on a IIGS.

I think the short answer falls somewhere between what James Lewis
claimed in 2022, and what Apple claimed back in 1986. Neither are
entirely correct. It's somewhere in the middle.

Would it be a fair assessment to say, then, the Mega II is not solely
responsible for emulating the Apple IIe, but nor is it almost completely
sitting unused (jn 8-bit emulation mode) and just merely "spitting out"
some classic Apple II video modes as needed?

This is unlike the Gemini chip on the Apple IIe PDS card. In that
situation this Apple IIe-on-a-chip takes over the host machine and
the Macintosh literally becomes an Apple IIe (for the most part, video
of course is emulated by QuickDraw, and there is still a custom GUI
control panel accessible when it's suspended).

I think the misconception has been: when the IIGS goes into 8-bit
emulation mode, the Mega II kicks in and takes over full control like
the Gemini--it does NOT. Likely why, perhaps, some IIGS-specific
features can still be accessible under Applesoft BASIC (through peeks
and pokes, I've seen the Ensoniq and SHR graphics used). Or how
there's been hybrid games possible, essentially 8-bit software with
some glorified audio/visual effects mixed in (e.g. Paperboy, Gauntlet,
John Madden's Football).

Interestingly, on a side note, it makes it sound like the Mega II is
more tied into native IIGS operations than one might think, and kind
of dispells the notion the IIGS isn't really an Apple II at heart. I've
seen the IIGS looked at as if it were an entirely new platform, that
just happens to have backwards compatibility with the Apple IIe.
Maybe that would be another discussion, is the IIGS really an Apple II? :)

Mitchell Spector

On Mon, 19 Feb 2024, Mitchell Spector wrote:

<snip>

> This is unlike the Gemini chip on the Apple IIe PDS card. In that
> situation this Apple IIe-on-a-chip takes over the host machine and
> the Macintosh literally becomes an Apple IIe (for the most part, video
> of course is emulated by QuickDraw, and there is still a custom GUI
> control panel accessible when it's suspended).

And said video emulation is slightly "off" - DGR mode doesn't work right
(the color in every other column is wrong).

> I think the misconception has been: when the IIGS goes into 8-bit
> emulation mode, the Mega II kicks in and takes over full control like
> the Gemini--it does NOT. Likely why, perhaps, some IIGS-specific
> features can still be accessible under Applesoft BASIC (through peeks
> and pokes, I've seen the Ensoniq and SHR graphics used). Or how
> there's been hybrid games possible, essentially 8-bit software with
> some glorified audio/visual effects mixed in (e.g. Paperboy, Gauntlet,
> John Madden's Football).

I've been wanting to do a modification/partial rewrite of Prince of Persia
that uses the Apple IIgs video modes - but I'm not quite at the point I
know enough about the code or the 65816 to do that.

<snip>

-uso.

Kent Dickey wrote:
> In article <dog_cow-1708091984@macgui.com>,
> D Finnigan <dog_cow@macgui.com> wrote:
>>
>>
>>Here's a reference to an October 1986 BYTE Magazine article about the Mega
>>II:
>>https://macgui.com/usenet/?group=1&id=3626
>>
>>
>>THE MEGA II
>>The Mega II is a custom CMOS chip containing about 3000 gates and a
>>2K-byte
>>by 8 ROM (for the character generator). It replaces the following chips
>>from
>>the Apple IIe and IIe: char­acter generator ROMs for eight lan­guages.
>>several TTL chips that per­form logic functions. and the MMU (memory
>>management unit). IOU (in­put/output unit). TMG (timing genera­tor). and
>>GLU
>>(general logic unit) custom chips.
>>
>>In previous Apple II designs, the re­freshing of memory was tied directly
>>to
>>the Apple II video mode. The Mega II includes an 8-bit counter for
>>refresh­ing the 128K bytes of (slow) memory associated with the Apple
>>IIe/IIc model; it does five cycles of RAM refresh during the horizontal
>>retrace of each video scan line and refreshes the 128K bytes of memory in
>>3.25 milliseconds. By taking care of RAM refresh the Mega II chip opens
>>the
>>Apple II design to new video modes that were impossible before.
>
> I don't know the source of the above paragraph and what it's trying to
> say,
> but I do not believe it is correct.

The source is the October 1986 BYTE Magazine article by Gregg Williams,
senior technical editor at BYTE.

It's on page 86 of the issue of BYTE magazine dated October 1986.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

In article <dog_cow-1708438166@macgui.com>,
D Finnigan <dog_cow@macgui.com> wrote:
>Kent Dickey wrote:
>> In article <dog_cow-1708091984@macgui.com>,
>> D Finnigan <dog_cow@macgui.com> wrote:
[snip]
>>>In previous Apple II designs, the re­freshing of memory was tied directly
>>>to
>>>the Apple II video mode. The Mega II includes an 8-bit counter for
>>>refresh­ing the 128K bytes of (slow) memory associated with the Apple
>>>IIe/IIc model; it does five cycles of RAM refresh during the horizontal
>>>retrace of each video scan line and refreshes the 128K bytes of memory in
>>>3.25 milliseconds. By taking care of RAM refresh the Mega II chip opens
>>>the
>>>Apple II design to new video modes that were impossible before.
>>
>> I don't know the source of the above paragraph and what it's trying to
>> say,
>> but I do not believe it is correct.
>
>The source is the October 1986 BYTE Magazine article by Gregg Williams,
>senior technical editor at BYTE.
>
>It's on page 86 of the issue of BYTE magazine dated October 1986.
>
>
>--
>]DF$
>The New Apple II User's Guide:
>https://macgui.com/newa2guide/

Sorry, I didn't mean to imply I doubted that BYTE magazine published those
statements in 1986. I meant I'm not sure what his source was, but I believe
he is mistaken. He seems to have fumbled up the SHR being able to read
the SCB (one cycle) and palette data (read in 4 cycles) during HBL with a
change to how refresh works.

Kent

Kent Dickey wrote:
>
> Sorry, I didn't mean to imply I doubted that BYTE magazine published those
> statements in 1986. I meant I'm not sure what his source was, but I
> believe he is mistaken.

What was the author's source? Let's assume that Gregg Williams wrote his
article in September 1986. Apart from his own direct investigation, how many
sources were even available in September 1986? He could have asked some
Apple employees, but he also could have referred to the Cortland documents
or similar pre-release developer's documentation.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

On Tuesday, February 20, 2024 at 10:32:42 a.m. UTC-8, D Finnigan wrote:
> Kent Dickey wrote:
> >
> > Sorry, I didn't mean to imply I doubted that BYTE magazine published those
> > statements in 1986. I meant I'm not sure what his source was, but I
> > believe he is mistaken.
> What was the author's source? Let's assume that Gregg Williams wrote his
> article in September 1986. Apart from his own direct investigation, how many
> sources were even available in September 1986? He could have asked some
> Apple employees, but he also could have referred to the Cortland documents
> or similar pre-release developer's documentation.
> --
> ]DF$
> The New Apple II User's Guide:
> https://macgui.com/newa2guide/

I found this to help understand what it all means. Thanks. A2ForEver 73 ve3myz James
https://www.youtube.com/watch?v=gFCD4s_hsb4&pp=ygUHTWVnYSBJSQ%3D%3D