I have been reading dozens of memory maps trying to make sense of them and not having a huge amount of luck. It's all quite confusing. I'm hoping some of y'all might have the special sauce.
John Relay's Apple II Info site is about the best I've seen in terms of a simple map.
I see tons of machine code examples at $0300, but some maps say that's used by monitor routines. But, in my experience, it's not and a bunch of other maps say it's free to use. Same story for $0800, $0C00, etc. I get it that the basic memory map only lives until you load something - say DOS 3.3 or ProDOS or Merlin or.... but is that it, there's a basic memory map for the iie, when it boots without a disk (where is that map) and then the map changes when you boot something like DOS 3.3 (I think I know where that map lives) and ProDOS (I see that one) and Merlin (yet another)? Why all that talk about bank switching, etc. In my emulated world of applewin or virtual ][, is there yet another map.
Or... is there some simplified, use $300 for small programs in assembler, $0C00 for larger programs advice that will suit for 90% of the cases and leave the crazy specifics for those crazy enough to need them?
Thanks!
Will
I ran into this issue when I was writing the interface program for my ESP32 SoftCard. The requirement was to have one assembly program that runs on all Apple II machines and clones both under DOS33 and ProDOS. I found a bunch of examples of programs starting at $3000 and $5000, but there were some issues with both. When I changed it to $6000 it worked like a charm. Actually the origin of the program is at $5FD0 where the variables are and the code starts at $6000.
It is also very important to be aware of the zero page location usage, which are in very short supply:
ZeroPage.jpg
My program uses $06, $07, $08 and $09 (top row on the diagram).
There are those on this forum far more current writing code for the Apple II family. My experience proficiency is about 35-40 years old, so here are some general thoughts.
Writing software code as @CVT indicated for the one or all of Apple II family usually has an important design goal to declare from the start. IMO, The Apple II, II+, IIe simply running DOS3.3 yields the greatest user progam available memory utilization options. Fewer than 6 to 10 zero page memory locations are commonly available along with $300-3CF and $C00-1FFF which are usually safe to use in this case, with or without FP Basic.
Consider there are chunks of memory available for TEXT PG1 ($400-$7FF) and TEXT PG2 ($800-$BFF), each being 2048 blocks of contiguous memory. If you only need to use TEXT PG1 that means that TEXT PG2 is free for you to use. The same applies to HIRES PG1 and HIRES PG2, if you only need to use one of their allocated memory blocks you are free to use the other for your own purposes.
So, are you writing purely in binary code using an Assembler/Compiler application or a combination of some binary code interfaced with some FP BASIC code. In this case, you should embrace and understand the use of LOMEM.
Maybe thinking about a hierarchy of users of the memory is helpful. In particular, the 6502 processor itself treats certain areas specially (like pages 0 and 1), so take that as the root of this tree, since it always applies. Then the hardware defines text pages, graphics pages, ROM pages, and I/O pages, so those will also be pretty fundamental. Then add the software stack once those are understood. Common points worth mentioning might be the input buffer at $0200 and the tendency for the operating system to be resident at the high end of the lower 48K.
Regarding $0300 specifically there are some vectors stored in the upper part of that page, if you stay below $03d0 you are always fine as far as I know. The monitor vectors are at $03f0-$0400, while the ones starting at $03d0 are associated with DOS. About $0c00, text page 2 is from $0800-$0c00. Often you don't need that second page of text (or low-res graphics which uses the same area).
About bank switching. The 6502 can only address 64K at a time. So once it was decided to address I/O from $C000 to $D000 and ROM from $D000-$FFFF you would need bank switching to get more than 48K of RAM. It gets crazy because the I/O is never switched out, so to recover the RAM space that would/should be at $C000 they use two distinct RAM areas at $D000. So this $D000 address can point to ROM or 1 of 2 RAM banks. Then on a 128K machine the whole RAM structure gets duplicated again. There are some nice (but still confusing) diagrams in the extended 80-column card manual.
Added note, just in the last few days learned a new detail. According to "Beneath ProDOS" the area in auxiliary memory (that second 64K on 128K machines) from $0800-$0e00 is available for applications even if the RAM disk is connected. But I found this is wrong. ProDOS appears to use auxiliary $0c00-$0e00 for the volume bitmap of the RAM disk.
One thing about that book is that it covered fairly early versions of ProDOS. There were erratta published to cover changes in newer versions. I don't know about those memory ranges but it is possible the book is correct for early versions but things changed.
Thanks I tried 1.0.1 and 2.4.2 so far, same behavior. But in a sense the book may be right after all. It appears you do not corrupt the RAM disk by writing to those pages, the problem is only that the RAM disk may corrupt *your* data. It seems to have a copy of the bitmap somewhere else (only 16 bytes are important) so it can restore these pages on demand. Very interesting.