9

Are there any areas of the 64k RAM which are permanently unusable by anything, whether by the built-in monitor ROM or user programs?

Looking at $C000-C0FF, this is the "softswitch" area, and as far as I can determine, the 256 bytes of RAM that occupies this space may be completely unusable by anything. Apparently no RAM is required here as these are mapped to I/O control lines for system devices.

Are there any special bank switch tricks to gain access to the RAM that occupies $C000-C0FF ?

  • 1
    Don't think of the Apple II as something like the C64, where stuff is layed over some RAM. Its memory philosophy is of different origin. – Raffzahn Mar 19 '18 at 10:28
9

Are there any areas of the 64k RAM which are permanently unusable by anything, whether by the built-in monitor ROM or user programs?

No. All is usable. after all, Woz did it. He never wasted a single gate, even less RAM.

Looking at $C000-C0FF, this is the "softswitch" area, and as far as I can determine, the 256 bytes of RAM that occupies this space may be completely unusable by anything. Apparently no RAM is required here as these are mapped to I/O control lines for system devices.

There is not RAM in the $C000..CFFF area and never has been.

The original Apple II had 'only' up to 48 KiB. Later the Language Card added 16 Kib in form of 12 KiB in parallel to the ROM at $D000...FFFF(using /INH to aquire the address space). Since using eight 16 Ki, 4116 type chips, was cheaper than 12 4 Ki ICs, a logic was added to switch in the remaining 4 KiB again in paralell as Language Card Bank 2 at $D000..DFFF.

While using 64 Ki RAMs, the Apple //e addressing logic (MMU) uses the same scheme.

Are there any special bank switch tricks to gain access to the RAM that occupies $C000-C0FF ?

No, as there is never RAM at that address.

  • Reading the softswitch at $C08B flips in bank 1.
  • Reading the softswitch at $C083 flips in bank 2.

In either case, $E000..FFFF is always bank 1.

  • Reading the softswitch at $C080 disables the Language Card again.

There is also anotehr bunch of combinations for reading ROM while writing the Language Cards RAM and so on, But I guess you get the picture.


Here some viualisation I used for a speech about RAM design. enter image description here

  • 1
    Would that scheme not give it slightly less than 64 kB of usable RAM? – Jim MacKenzie Mar 19 '18 at 14:41
  • 1
    Thanks. So basically there's a chunk of RAM where you can access this RAM or that RAM, to make 64 kB in total. – Jim MacKenzie Mar 19 '18 at 14:45
  • 2
    @JimMacKenzie yes, or ROM - or even more banks on RAM card. The IIe then added another 64 KiB, following the same scheme, in parallel. After all, a CPU with a 16 Bit address space does need some kind of banking to address more than 64 KiB. isn't it? And since the original II was designed with 48 KiB Ram, 4 KiB I/O and 12 KiB ROM, all further extensions have to be banked. – Raffzahn Mar 19 '18 at 14:49
  • 1
    @bjb: The 4K section of address space from 0xD000-0xDFFF can be configured to access either of two 4K sections of RAM, making up for the section of address space at 0xC000 that can't access any. – supercat Mar 19 '18 at 17:27
  • 1
    @Tommy Well, somewhat yes :)) At first the GS works (in the first 64 KiB ) exactly like the II. All switching is not only compatible with the II, but also the IIe with it's 128 KiB. When operating in 65816 mod both 64 KiB banks are maped into bank 00/01 but also shadowed to $E0/E1. When working in $E0/E1 the machine gets slowed down to 1 MHz to support hardware compatibility, when working in 00/01 (or any other page) the CPU runs at full speed. All 'real' IO and stlots are in the shadowed banks, so IIgs programms accessing I/O get slowed down for that access. – Raffzahn Mar 20 '18 at 19:41
6

Yes, all 64kb of RAM is accessible. But you ask an interesting question, if we change one letter. ; - )

Address space and device mapping

You asked about RAM, but how is RAM read? The CPU puts a 16-bit address on the address bus, puts the R/W' line in the desired state, and then expects a value on the 8-bit data bus within a certain time. What sends the data that comes back? Something else connected to these shared buses and configured to respond to the given address. It might be onboard RAM, ROM, a peripheral card, or something else. (I will document a few anomalies below.)

The point being that because the buses are shared, the 16-bit address space is shared, and parts claimed by various devices according to physical (cards etc) and logical (soft-switch) configuration.

RAM

On the original Apple II or II+ there is up to 48kb on the motherboard. The extra 16kb (or more) of the "RAM device" decoding is split between the motherboard and a RAM (e.g. Language) Card.

A 64kb Apple //e is very similar to the II+ with LC, except that the entire 64kb is onboard. In fact in the //e, $DXXX accesses to LC Bank 1 are converted to "physical RAM device" addresses in $CXXX. (For details see Sather's Understanding the Apple //e, page 5-24, third paragraph.) If a //e has 128kb or more then the Auxiliary Slot again divides the RAM "device" decoding.

In most Apple IIs $CXXX only accesses peripheral card RAM (or card ROM etc) and onboard ROM, but the //c+ has has 2k of "secret" RAM accessed through a $20 byte window at $CE00.

ROM

If you replace the RAM in your question with ROM (one letter, as I said) the question becomes more interesting, and you have in fact suggested a good place to look: $C0XX. This address space is always claimed by the softswitch decoding logic, and yet both the Apple //e and //c have ROMs called CD, EF or CF that are large enough to fully occupy $C000 to $FFFF. And in fact they do. You cannot read the $C0XX ROM area from inside the Apple, but if you dump any //c ROM (not //c+) and look at the beginning where $C000 to $C0FF would be, you find this:

Peter Quinn, Rick Rice, Joe Ennis, J MacDougall, Ken Victor, E Beernink, JR Huston, RC Williams, S DesJardin, Randy Bleske, Rob Gemmell, Stan Robbins, Donna Keyes, Doug Farrar, Rich Jordan, Jerry Devlin, John Medica, B Etheredge, Dave Downey, Conrad Rogers

Hidden in this inaccessible $C0XX ROM are the names of the creators of the //c.

Something else

What if no device claims an address read? The Apple II was architected such that the CPU accesses the buses during one of its internal phases, and the video scanner uses the other phase to read video data from RAM to generate video. Bob Bishop discovered in 1982 that reads at unclaimed addresses return the most recently scanned video data. Examples are softswitches that do not return data, and vacant slot memory in $CXXX. A few games used this "floating bus" data to sync their graphics page-flipping with monitor refresh to avoid flicker. The technique is sometimes referred to as "vapor lock".

  • The RAM window at $CE00 in the IIc is $20 bytes, not $200. But more important, it's neither secret or a hidden feature, but a regular I/O device. $CE00 is the PROM area for slot 6 ... which happens to be exactly the 'slot' the floppy controller occupies. – Raffzahn Mar 20 '18 at 23:43
  • @Raffzahn: Thanks for the correction. I put secret in quotes. It's certainly not documented or well known and was only discovered outside Apple through emulation efforts. Just an interesting example ... or counterexample to your claim that "There is not RAM in the $C000..CFFF area and never has been." – Nick Westgate Mar 21 '18 at 0:02
  • I still stand with that. There is no RAM in that area and never has been. It's the I/O area. Ofc, every I/O 'card' is free to add whatever it needs in that area. RAM, ROM or other deviced reacting to CPU access. And thats what the IIcs disk controller did with its area - as dozend other cards did for whatever purpose they had. – Raffzahn Mar 21 '18 at 0:37
  • Snooping the video read timing by using idle bus states is really cute, and could have helped games run at consistent rates. The tough part would seem to be figuring out how to ensure that code doesn't mistake display data for the detection pattern. I'm also not sure how switching between text and graphics mid-frame affects chroma decoding. The little bit of experimentation I did suggests that having a graphics mode active for more than about 50% of the time enables chroma for the whole frame, but I'd guess that varies between monitors? – supercat Apr 30 '18 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.