Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1215 > unrolled thread

Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download)

Back to article view | Back to comp.sys.apple2.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-23 21:45 -0500
    Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) Michael J. Mahon <mjmahon@aol.com> - 2014-05-23 22:20 -0500
      Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-23 23:03 -0500
        Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) David Schmidt <schmidtd@my-deja.com> - 2014-05-24 00:18 -0400
          Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-24 08:49 -0500
        Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-24 10:58 -0500
        Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) Michael J. Mahon <mjmahon@aol.com> - 2014-05-24 11:04 -0500
          Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-24 14:28 -0500
            Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) ol.sc@web.de (Oliver Schmidt) - 2014-05-30 21:20 +0000
              Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download) "Bill Buckels" <bbuckels@mts.net> - 2014-05-30 18:35 -0500

#1215 — Re: Linker Configs and Screen Holes (Was: Re: Double Hi-Res Demo in cc65 available for Download)

"David Schmidt" <schmidtd@my-deja.com> wrote:
>I don't do graphics, so I have no idea why screen holes are important to 
>DHGR and when/how they need to be poked.

Some terminology:

A "Screen Hole" is  a memory hole in a C65 program is an area of memory that 
the code jumps past to avoid the screen memory. It is not BSS memory. It is 
part of the program, and its is initialized data and makes the program 
larger.

You don't poke screen holes. You place bitmapped graphics in them for 
display. If your program code covers the screen and you overwrite it with a 
graphic image then you will crash into the monitor. That is why screen holes 
are important to DHGR.

In a prodos sys program that loads at 0x2000 and uses page 2 to do HGR and 
DHGR graphics, a screen hole of 8192 bytes is placed in the program at 
0x4000. An HGR image of a title screen often embedded in such a program can 
be displayed on startup without loading from disk.

Memory holes in a C65 program can be placed anywhere and of any size.

>But I know a little about linker configs and how you tell cc65 where you 
>intend to put stuff.

Thank goodness... so in English now:

I want to build a program in cc65 that runs code both above and below screen 
memory on the apple II, but this does not seem possible without modifying 
the linker. I don't know enough about the linker anyway to muck with it.

So I need to link 8192 bytes in some segment explicitly to screen memory  at 
address 0x4000 in main memory.

Of course I would also like to organize the program so the code runs at 
0x6000 and above if possible as well as below 0x4000 but avoids the screen 
memory. So I assume that the best use of memory is to use loader.system:

1. Root Module including main() loads at 0x803
2.screen segment at 0x4000
3. 0x6000 Root module continues... or Overlays are loaded

In auxmem:

4. Screen segment at 0x4000

>Can you explain in simple (and hopefully brief) terms what you need to 
>accomplish - and what you expect the linker to do to enable you to do it?

Does this give you enough information?

Bill

[toc] | [next] | [standalone]

#1216

"Bill Buckels" <bbuckels@mts.net> wrote:
> "David Schmidt" <schmidtd@my-deja.com> wrote:
>> I don't do graphics, so I have no idea why screen holes are important to 
>> DHGR and when/how they need to be poked.
> 
> Some terminology:
> 
> A "Screen Hole" is  a memory hole in a C65 program is an area of memory that 
> the code jumps past to avoid the screen memory. It is not BSS memory. It is 
> part of the program, and its is initialized data and makes the program 
> larger.

Just to clarify, in the Apple II world, the term "screen holes" usually
refers to those chunks of the primary text buffer ($400..$7FF ) that are
not displayed by the video hardware, but are used as scratchpad by slot
cards. 

You're using the term to describe gaps in a program's code or data used to
avoid graphics buffers. This is often called "protecting" the graphics
buffer(s) or "splitting" a program. 

Because they have absolute addresses, the compiler or linker needs a
mechanism for allocating these large, absolutely addressed regions,
preferably without requiring a lot of manual code splitting to make good
use of all the surrounding memory. 

Most programmers deal with this non-automatically, by adjusting ORGs and
code layout after doing a trial link (or assembly). 

It's pretty cool if a compiler/linker has automatic support for such
program splitting. 
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1217

"Michael J. Mahon" <mjmahon@aol.com> wrote:
>It's pretty cool if a compiler/linker has automatic support for such 
>program splitting.

The Aztec C65 linker provided this support since 1985 or earlier. I am aware 
of the trailing bytes in the text screen interleaf of course. I have never 
thought of them as screen holes since my use of the MS-DOS LN65 linker 
created holes in screen memory. So what is perfectly clear to me is 
perfectly clear to me...

Screen segments don't properly describe a hole in a program over screen 
memory in Aztec C65 since the Aztec C documentation calls them holes. They 
also call them reserved areas. They will never split a segment.

You can have up to 4 of them, whatever they are:)

I am still working with Payton's suggestion but I don't think it will give 
me what I have been used-to. cc65 will give me much smaller code and quicker 
for calls. For file I/O about the same since that is OS dependent. cc65 is 
slightly faster for inline assembly, but since MS-DOS is almost dead, cool 
linker features may soon not have much value outside DosBOX and other MS-DOS 
emulators.

Bill

[toc] | [prev] | [next] | [standalone]

#1218

On 5/24/2014 12:03 AM, Bill Buckels wrote:
> The Aztec C65 linker provided this support since 1985 or earlier. I am aware
> of the trailing bytes in the text screen interleaf of course.

That's what Apple, Inc. calls "Screen Holes."  Looks like we have a 
failure to communicate there. ;-)

> So what is perfectly clear to me is perfectly clear to me...

Ayup.

> I am still working with Payton's suggestion but I don't think it will give
> me what I have been used-to.

I'm not sure I can improve on Payton's description.  It was quite good. 
  You tell cc65 what areas of memory to use, and it uses them.  I'm not 
sure you can define a single segment that, say, occupies several 
non-contiguous areas, though - and I _suspect_ that's what you're after. 
  If I have non-contiguous areas I want to occupy, they each have a 
unique name and contents.

[toc] | [prev] | [next] | [standalone]

#1219

"David Schmidt" <schmidtd@my-deja.com> wrote:
>That's what Apple, Inc. calls "Screen Holes."  Looks like we have a
failure to communicate there. ;-)

Roger, Number one:) I plead being distracted by MS-DOS in those years and 
project deadlines but today I did not RTFM so my pleas must surely fall on 
deaf ears...

>>So what is perfectly clear to me is perfectly clear to me...
>Ayup.

Billy Potter:) Geez David, I guess I'd better rewrite the FileType Notes 
next and add my own FileTypes:)

>I'm not sure I can improve on Payton's description.  It was quite good.

A google or two on Payton and cc65 segments also turns-up more good info. 
The segment example he provided compiled and inserted nicely but I am too 
slow at reading and thinking to have this debugged and done today. I am 
certain to be done sometime shortly once I memorize and apply the rest of 
the cc65 documentation on linker configs. It's hard to argue with success.

>You tell cc65 what areas of memory to use, and it uses them.

Of course we all know this in theory. But as always doing something about it 
is both fun and a pain.

>I'm not sure you can define a single segment that, say, occupies several 
>non-contiguous areas, though - and I _suspect_ that's what you're after.

I am certain I can't. I am also certain I would bust the cc65 linker if I 
don't work my way through for about a year. Others might do this in a day...

>If I have non-contiguous areas I want to occupy, they each have a unique 
>name and contents.

I got that part of it really clearly since that part doesn't change between 
Aztec C65 and cc65. Or on other C compilers.

The obvious affirmation from you, Payton, Mike Mahon, provides some 
authority.

A shift in mindset is the hard part for me, so getting my butt kicked is the 
only way I know to get out of a rut and on the road.

Thanks for taking the time.

Bill

 

[toc] | [prev] | [next] | [standalone]

#1220

"Bill Buckels" <bbuckels@mts.net> wrote:
>since MS-DOS is almost dead, cool linker features may soon not have much 
>value outside DosBOX and other MS-DOS emulators.

I should add that the Aztec C65 native mode compiler version 3.2b that runs 
on the Apple II also provides for the same holes or protected regions as 
well as defining other linker characteristics, and other Aztec C65 
cross-compilers provide for this as well, for the Apple II, commodore 64, 
and atari. However these compiler libraries for other targets, especially 
the Atari are missing, or only opartially complete or too old to be useful. 
The Aztec C65 pcode also provides for holes (protected areas) in 
exceutables.

The CG65 compiler from the late Paul Santa-Maria with manuals sent to me 
before he passed provides for ROMable code for all 6502 processors which can 
be embedded to this day and has no problems running in DOSBox. So like the 
Z80 compilers some of this can still be used but is not as efficient as 
cc65.

cc65 can be adapted to any of these uses by reviewing the Aztec C65 
documentation and a limited amount of additional study. However, the 
detailed knowledge of how they did it is only available after spending years 
reading and working with it like I accidentally did.

I think Oliver Schmidt probably is the most knowledgeable if he and I were 
having a contest, but I think I have more time to work with what I have 
said.

My final word on the native mode Aztec C65 compiler is that it did not 
receive the bug fixes and additional features that the cross-compilers did. 
The versions that we have available are buggy in many subtle ways. They are 
relatively useless beyond a retro-experience. The code they produce is 
extremely stack intensive as well as being in a severely deprecated and 
non-Ansi C.

So as bad as it is by today's standard, and by cc65's standard, the MS-DOS 
AppleX C65 3.2b compiler and Paul's CG65 compiler are better than the native 
mode compiler that Mike (phoenyx) and other Apple II C65 programmers used. 
Manx discovered that the Apple II wasn't such a great C compiler market 
except for MS-DOS programmers like me, so flogged this on unsuspecting Apple 
II users in the same old version until the company disappeared. All source 
was long ago discarded. There is no future for C65 especially on the native 
Apple II, and for the other the only way forward is to consider how the 
features that are missing from cc65 may be added.

I should also note that Michael Mahon's description of how an assembly 
language programmer organizes segments can be done as easily in cc65 since 
beneath cc65 is an assembler. But my idea here is to provide a higher and 
re-usable level that suits Oliver, which shall be a longer task, but more C 
like in the end.

Bill


 The mindset

[toc] | [prev] | [next] | [standalone]

#1221

"Bill Buckels" <bbuckels@mts.net> wrote:
> "Michael J. Mahon" <mjmahon@aol.com> wrote:
>> It's pretty cool if a compiler/linker has automatic support for such 
>> program splitting.
> 
> The Aztec C65 linker provided this support since 1985 or earlier.

<snip>

In Merlin, you can semi-automate this kind of code splitting by
occasionally calling a macro that checks proximity to a reserved region,
then, if close, DSs space over the region. 

This works reasonably well if used just before a procedure. Since the macro
can't know how long the procedure will be, it can default to a reasonable
size, or an argument can be passed with the programmer's estimate of the
size. 

Another version of this, suitable for use inside a procedure, would check
for being within 3 bytes of the region, and generate a JMP around it, but
that messes up any relative branches across the region. 
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1222

"Michael J. Mahon" <mjmahon@aol.com> wrote:
>In Merlin, you can semi-automate this kind of code splitting by 
>occasionally calling a macro that checks proximity to a reserved region

Aztec C also refer to the hole as a region. So going forward with my 
documentation of porting Aztec C65 to cc65 which will become a book when I 
am finished, I will use the phraseology of a "reserved region" and "program 
hole" and attempt to refrain from "BuckSpeak" which only works for MS-DOS 
programmers. This matter of program segments in cc65 is a little too 
complicated already to talk about casually without confusing the reader.

That should do it.

>This works reasonably well if used just before a procedure. Since the macro 
>can't know how long the procedure will be, it can default to a reasonable 
>size, or an argument can be passed with the programmer's estimate of the 
>size.

LN65 has additional switches when reserved segment start addresses for code, 
data, and initialized data are used explicitly.

>Another version of this, suitable for use inside a procedure, would check 
>for being within 3 bytes of the region, and generate a JMP around it, but 
>that messes up any relative branches across the region.

I don't think any scheme is much different in theory, but the LN65 Hole 
switch seems to be a little more friendly because it is much less work for 
the programmer.

When I first got the Aztec C65 compiler, this took no explanation, unlike 
this cc65 linker config. So in the longer term, perhaps in the final chapter 
of the book, I'll change the cc65 linker and add reserved regions to its 
command line.

Bill 

[toc] | [prev] | [next] | [standalone]

#1223

Hi,

>When I first got the Aztec C65 compiler, this took no explanation, unlike 
>this cc65 linker config. So in the longer term, perhaps in the final chapter 
>of the book, I'll change the cc65 linker and add reserved regions to its 
>command line.

In 2010 we had a sort of similiar discussion and I provided you with a
linker config file that takes full advantage of what cc65 as-is can do
today:

https://groups.google.com/d/msg/comp.sys.apple2.programmer/LMdw_kBbhMU/pp9Ik_kFahcJ

That linker config file doesn't work as-is with the current cc65 but
it should provide you with all info you need to build a BIN file that
loads at $803, contains code both at $803-$2000 and $4000-<HIMEM> and
contains a hires image at $2000-$4000.

A meaningful enhancement for the cc65 linker would be to allow a
"segment" (like CODE) to be placed not only into one "memory area" but
into several memory areas. Meaning that the memory areas are used in
the given order until one is found that isn't already too full to hold
the content to be placed next.

With that enhancement in place one could create another apple2 linker
config for graphics programs coming with cc65 that contains the three
memory areas
- 0803-2000
- 2000-4000
- 4000-<HIMEM>
and have all the default segments use the first _and_ third memory
area.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#1224

"Oliver Schmidt" <ol.sc@web.de> wrote:
 >In 2010 we had a sort of similiar discussion and I provided you with a 
linker config file that takes full advantage of what cc65 as-is can do 
today:

https://groups.google.com/d/msg/comp.sys.apple2.programmer/LMdw_kBbhMU/pp9Ik_kFahcJ

Thank you for reminding me. It seems I have an error in my latest linker 
configs.

>That linker config file doesn't work as-is with the current cc65 but it 
>should provide you with all info you need to build a BIN file that loads at 
>$803, contains code both at $803-$2000 and $4000-<HIMEM> and contains a 
>hires image at $2000-$4000.

Yes, at this point it does. After reading the thread in its entirety much 
more makes sense now.

>A meaningful enhancement for the cc65 linker would be to allow a "segment" 
>(like CODE) to be placed not only into one "memory area" but into several 
>memory areas. Meaning that the memory areas are used in the given order 
>until one is found that isn't already too full to hold
the content to be placed next.

Yes, and from the old Aztec C65 documentation, that's how the LN65 linker 
almsot works except that it puts data and code together from each object 
module from the sounds of things. Keeping code together with code seems to 
make the most sense for tighter fitting of smaller code especially.

>With that enhancement in place one could create another apple2 linker 
>config for graphics programs coming with cc65 that contains the three 
>memory areas

>- 0803-2000
>- 2000-4000
>- 4000-<HIMEM>

>and have all the default segments use the first _and_ third memory area.

The way it is now, graphics library routines could be below the screen and 
program code above.

Bill

 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web