1
0
mirror of https://github.com/cc65/cc65.git synced 2024-12-25 17:29:50 +00:00
Commit Graph

4 Commits

Author SHA1 Message Date
Oliver Schmidt
8e75906737 Switched Apple II output format to AppleSingle.
Although the primary target OS for the Apple II for sure isn't DOS 3.3 but ProDOS 8 the Apple II binary files contained a DOS 3.3 4-byte header. Recently I was made aware of the AppleSingle file format. That format is a much better way to transport Apple II meta data from the cc65 toolchain to the ProDOS 8 file system. Therefore I asked AppleCommander to support the AppleSingle file format. Now that there's an AppleCommander BETA with AppleSingle support it's the right time for this change.

I bumped version to 2.17 because of this from the perspective of Apple II users of course incompatible change.
2018-03-07 23:05:21 +01:00
Oliver Schmidt
7521ae888a Marked Apple II EXEHDR segment as optional.
The docs say "Use -D __EXEHDR__=0 to omit the header." so it should work without generating a linker warning.
2018-02-02 14:46:57 +01:00
Oliver Schmidt
80b09ba9fc Significantly simplified recently added linker config files.
I just forgot about the 'start' segment attribute - which makes the scenario at hand dead easy.
2018-01-31 08:54:48 +01:00
Oliver Schmidt
855aceaba8 Added Apple II linker configs for programs including a hires screen.
The Apple II hires screen buffer is located at $2000 (and can't be moved). The usual way to get along with this is to load the cc65 program above the hires screen buffer at $4000. However, that means that it becomes difficult to make good use of the memory below the hires screen buffer. The simplest approach is to add that memory to the heap. But there are programs containing just lots of code and not much data. One could think of moving the code to the area below the hires screen after loading (like it is done with the code for the language card). But if the program is really large (and already contains code to be moved to the language card) it won't just fit into memory in the first place.

The alternative is to load the program at the usual $803 and have it "cover" the hires screen buffer. Of course the part of the program that actually "covers" the hires screen buffer mustn't contain anything necessary for the program. The downside of this approach is that the program file on disk contains 8kB that can't be used by the program. But instead of just containing zeros the program can as well contain a hires screen picture that can be displayed right after startup.

Now the user can have code loaded below the hires screen buffer by setting the code-name to LOWCODE. However, he needs to explicitly do so. Otherwise the memory below the hires screen is totally wasted.

Trivia: Allowing to do this hires screen buffer "covering" was the very reason to change tgi_init() to not clear the hires screen anymore.
2018-01-29 17:46:36 +01:00