Display list question

[sanny]

You can also take a look at http://cc65.github.io/doc/ld65.html#s5 for a description of the linker config file syntax.

[JamesD]

This is how I've been building things. I was trying to avoid custom build configurations but since the linker won't recognize the align without it... I'll just reserve memory myself for now.
It's just a test program and the code will end up part of a C library eventually.
At some point I'll have to create a separate test suite with a more complete build setup.

@echo off
:top
ca65  Print80.CA65 --large-alignment -v -l Print80.lst -o Print80.o 
ld65 -t none -o Print80.xex Print80.o
shift
if not %1.==. goto top
:end

[JamesD]

You can also take a look at http://cc65.github.io/doc/ld65.html#s5 for a description of the linker config file syntax.

I looked. Where does that say if I don't use a config file and specify to align the data there that the linker will ignore alignment directives in the code?

The assembler docs don't mention it either.

It's not in the code as a suggestion.

[sanny]

If the code should finally be part of a C library, probably the best way is to define a special section just for the display list.

Tell the users to add this section before "DATA" in the linker config file.

[sanny]

I looked. Where does that say if I don't use a config file and specify to align the data there that the linker will ignore alignment directives in the code?

The assembler docs don't mention it either.

It's not in the code as a suggestion.

 

I gave you the link to show you the linker config file syntax.

 

You get a warning by the linker, telling you "the resulting executable might not be functional". Maybe it should say ".align directive ignored".

 

And, btw., you are always using a config file, you just don't notice :-)

 

In your example you are using the none.cfg file. Any special reason why you are using -t none instead of -t atari (or -C atari-asm.cfg)?

[JamesD]

If the code should finally be part of a C library, probably the best way is to define a special section just for the display list.

Tell the users to add this section before "DATA" in the linker config file.

Ok.

 

 

I gave you the link to show you the linker config file syntax.

 

You get a warning by the linker, telling you "the resulting executable might not be functional". Maybe it should say ".align directive ignored".

 

And, btw., you are always using a config file, you just don't notice :-)

 

In your example you are using the none.cfg file. Any special reason why you are using -t none instead of -t atari (or -C atari-asm.cfg)?

I think if the warning is changed as you mention and the docs have a place you can look up the error and see a better explanation that would be a perfect.

Something about the object file requesting code alignment but the linker ignored it because the config file did not?

 

I don't mind if a tool does something differently than I expect as long as it's documented in a manner that lets me find out why.

 

The library presents some challenges that I haven't stopped to deal with yet.

The code can be assembled for 64 or 80 columns and I need to differentiate between the two, do I allow the user to set up the screen themselves or do I require they use my code...

And there are a whole lot of other things I have to do.

 

I just took the code and link stuff from the Atom version I made and tried to port it with the least amount of effort. I WAS LAZY!

That probably came from what I used to rebuild the Star Raiders source code.

Where that came from... who knows.

[sanny]

The library presents some challenges that I haven't stopped to deal with yet.

The code can be assembled for 64 or 80 columns and I need to differentiate between the two, do I allow the user to set up the screen themselves or do I require they use my code...

And there are a whole lot of other things I have to do.

 

 

Do I understand it correctly? You are working on a 64/80 column driver (library) to be used from C?

 

If yes, have you considered to build it in a way that it can be included in cc65? cc65's c64 target some time ago got a "softc80" CONIO driver, and it would be nice if Atari could catch up

 

If still "yes" or you might want to do it, head over to http://cc65.github.io/cc65and subscribe to the mailing list. If you have questions on the way, ask them on the mailing list or with PM to me...

[JamesD]

Do I understand it correctly? You are working on a 64/80 column driver (library) to be used from C?

That's an intermediate goal.

 

If yes, have you considered to build it in a way that it can be included in cc65? cc65's c64 target some time ago got a "softc80" CONIO driver, and it would be nice if Atari could catch up

 

If still "yes" or you might want to do it, head over to http://cc65.github.io/cc65and subscribe to the mailing list. If you have questions on the way, ask them on the mailing list or with PM to me...

I don't know anything about that but I could take a look. It may suit my needs as well. But if it deals with 1 character at a time then it's slow.

 

The demo is printing somewhere around 140 characters per screen refresh when printing the character set string in 80 column mode (which seems to work btw).

Strings let it print 2 characters at a time. Single characters take slightly less time than 2 but you have to print twice so... much slower.

60 * 140 = 8400 characters per second if you don't have to scroll. At least if I didn't screw up the math and the estimate is right.

Scrolls are slow which is why the MVN is important.

 

BTW, I looked at the Plus/4 code and it's not faster, but it's smaller since I can use INY instead of LDY #.

 

[JamesD]

With the 65816 MVN instruction performing the scroll, the Atari is now in 2nd place speed wise so far.
It's about in the middle between the MC-10 and VZ200.
The most important thing is that the text scrolls much smoother now... at least if you have a 65802 or 65816.

Thanks to the people here that offered suggestions on how to optimize the 6502 text rendering code, and helped me with tool and hardware questions!
The Atari has a bit of an initial learning curve, but it's really nothing terrible.