On Friday, October 7, 2022 at 8:19:49 PM UTC-7, james... wrote:
On Saturday, October 8, 2022 at 6:50:06 AM UTC+9, MG wrote:
...The card has 256K of memory, which is divided into four parts, one main RAM bank, two Aux RAM banks (the second of which probably no software knows about), and a fourth bank that becomes the "ROM" from the Apple IIe perspective.
The fourth bank is divided into four parts as well, one of which is the main firmware bank (AppleSoft + the monitor), two auxiliary firmware banks, and the slot ROMs.
Again, this is not actual firmware in ROM, it is RAM acting like ROM.
Very interesting! I humbly appreciate your time in providing such an amazingly helpful information.
So 128K of the card's physical 256K is being used as the IIe's "one main RAM bank," while the remaining 128K is divided into 2 Aux RAM banks (56K each?) and the "ROM" bank (16K divided into 4 parts).
64K is the main RAM, 64K is one aux memory bank just like a normal IIe, 64K is a second aux bank that can be selected via bit 4 of $C02B, and 64K is the "ROM."
To understand how it's addressed, we go back to the original Apple IIe. The Apple IIe memory map itself is somewhat complicated. In a stock machine with no expansion there is 64K of memory, which (up to) 56K is visible at any given time. The extra 4K
is switchable into $D000-$DFFF, allowing access to the full 64K. This precedent was set by the Apple II/II+ (48K) with a 16K expansion. The memory can be selected for write-only (reads come from ROM), read-only, or read+write.
When a 64K memory card is inserted into the IIe Aux slot, it creates a second ("aux") 64K bank alongside the regular memory that may be switched in two large regions. Addressing what is switched in works the same as above. There are also some features
that make it so you can write into the aux memory while reading the main memory.
The Apple IIe Card adds a second aux memory bank that can be switched in that is otherwise addressed the same way. I haven't figured out what it is used for though I suspect the AppleTalk stuff might buffer things there. A notable thing is that this
extra bank of memory is not selected the same way that extra aux memory cards for a standard IIe are selected, so it's not compatible with software that understand "ramworks-style" memory.
When I launch IIe Startup and display the IIe Option Panel, I see the virtual Memory Expansion Card in virtual slot 7 is set to 256K, which apparently uses the Mac's RAM. If I then enter the IIe environment and check, it says the total RAM is 384K.
That 384K indicates 128K (physical RAM on the IIe Card) + 256K (memory expansion card, which uses the Mac's RAM) is being used.
That's a totally different type of expansion RAM, known as "slinky" memory. The memory is addressed by a 3-byte address register and a single-byte data register. Accessing the data register reads or writes to the byte pointed to by the address register,
and then increments the address register. You can't execute program code out of this style of memory, and it normally functions as a RAM disk. The physical equivalent to this is the "Apple II Memory Expansion Card" and there were more-functional
clones like the AE RAMFactor card. In fact, the RAMFactor card firmware can work with the emulated memory card and add the firmware features (but no battery backup). I did this as a proof-of-concept for modifying the IIe Card's "firmware":
http://
apple2.guidero.us/doku.php/projects/rf_lc
FBBE does not indicate any hardware differences whatsoever. It comes from the "Monx" resource in the IIe Startup application. If you use an old enough version of IIe Startup, you will see a different value in FBBE. All of the "firmware" / "ROM" in
the fourth bank of RAM I mentioned above is loaded into the card by the IIe Startup application.
Frank is correct, they do have different numbers at FBBE. As for any meaningful difference between the different versions, I haven't really investigated them or even map the IIe Startup -> FBBE numbers.
I run one in a Color Classic with a Mystic board, one in a Quadra 605, and one in an LC III. But I generally run 2.2.2d1 on all of them.
Very interesting.
In that Github discussion, Frank mentions 7 different versions of the IIe Startup app, and yet it seems that only FBBE = 00, 01, 02 & 03 were used as identifiers. Since I know by my own testing that v.2.2.1 & v.2.2.2d1 share FBBE = 03, we then have the
following (based on what Frank wrote on Github):
[snip]
Separately from that...
I recently posted a YouTube video on my experience with the IIe Card installed in my overclocked Color Classic Mystic with the standard 60Hz VGA mod installed. Please understand that I have a lot of vintage Mac experience, but the IIe Card is my first
use of an Apple II of any kind, so I am basically sharing that experience with others here:
https://youtu.be/iKF_zGshSWY?t=1973
At that particular timestamp in my video, I show how the IIe Card environment looks with the VGA mod. Instead of spanning the same horizontal width of the CRT as the Macintosh environment does when you have the stock 512x384 resolution, with the VGA
mod, the IIe environment displays as 560x384 within the 640x480 VGA resolution. I don't see that as a problem, but I found it interesting. When you have the stock 512x384 resolution, the Color Classic can switch to 560x384 (spanning the same physical
width on the CRT as the stock 512x384 resolution), but with the 60Hz VGA mod (I don't know if the 67Hz VGA mod will work), 560x384 is displayed within the 640x480. This means the IIe environment will display smaller when you have the VGA mod, as compared
to a Color Classic with its stock resolution.
This is normal. The Macintosh will switch to the 560x384 resolution if, and only if, the machine is capable of displaying 512x384. Furthermore, if a resolution larger than that is selected, on some Macs that are otherwise capable of 512x384, you will
get 560x384 centered in that display rather than the native resolution. This is due to how the circuitry is wired in the machine. The IIe Card contains a crystal that generates the horizontal frequency for that resolution and switches it in to the
video generation circuit. The machine has to support that.
Anyway, if you continue watching you will see that I show how ProDOS icons vanish off the desktop when you enter the IIe environment (which is normal), and then I present a problem I encountered -- not being able to Format disks inserted into the Mac's
internal Floppy drive (or even Write any data to it). I can Read data from it just fine though.
Hmm, I don't recall running in to that. I don't have any of my machines set up right now to test, unfortunately. I keep hoping someone comes along that is an expert on the Mac side who wants to reverse-engineer the 68K code in the IIe Startup
application, that would increase the overall level of understanding of the card, probably let me complete the picture for the IIe side of the card, and maybe even allow the IIe Startup application to be patched or outright replaced. All of the IIe-side
code that I've looked at is the same between 2.2.1 and 2.2.2d1, so the blame for disk problems is likely in the 68K code.
For some reason I don't fully understand, the solution is to use older version 2.2.1 of IIe Startup, which amazingly works on with the LC575 motherboard (even at a 40MHz overclock). That allows me to Format and Write data within the IIe environment,
whereas v2.2.2d1 will not (at any Mac clock speed). But when I overclock the Mac's 68040 to 44MHz or higher, the version 2.2.1 app throws an error saying the IIe Card is damaged (it's not), and only 2.2.2.d1 will launch. Even with the 040 overclocked to
50MHz, the v2.2.2d1 app still launches and enters the IIe environment. The lone caveat with v.2.2.2d1, as shown in my video, is that you cannot (1) Format or (2) Write Data to a ProDOS formatted 3.5" floppy disk inserted into the Mac's internal floppy
drive. Drives attached via Y-cable (in my case, using a FloppyEMU) still allow me to write data to them just fine, even with the Mystic motherboard highly overclocked.
It doesn't surprise me that you eventually run in to trouble at higher speeds, as this will mess with timing on the bus and in the overall system. It's possible that at higher clock speeds the electrical interface becomes a problem or the software just
doesn't wait long enough for the card to finish doing things.
MG
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)