[Color Computer] [Coco] ASM Coders - Round two!

[James Diffendaffer]

Rumor has it that Roger "Merch" Merchberger may have gotten defensive
of the coco and said:

>>BTW, I think some of his routines can be optimized to save a few clock
>>cycles.  I'm not sure about the 6809 since I really haven't done much
>>on it but on the 65816 (very similar to the 6809)
>>
>Ah, no - more like "3rd cousins, twice removed."  ;-) The 65816 is a
16-bit 
>reimplementation of (but backwards compatible with) the 6502, which was 
>very loosely based on the 6800, but is not machine-code compatible.
>
>The 6809 is not machine code compatible with the 6800 (depending on the 
>assembler, it *may* be source-code compatible as in it's the assembler's 
>job to take the 6800 mnemonics and spit out the correct 6809 machine
code, 
>but that code will be by no means optimal for the 6809 as it won't
make use 
>of the secondary index & stack pointers, or the 16-bit D register
(made up 
>of A&B together).

Roger, at no time did I say the 65816 was binary compatible with the
6809 and I don't need a history lesson.  


>Question: Does the 6502 have an index register? This is an honest
question, 
>not sarcasm BTW. I know there are some design differences between the
6800 
>& 6502...


The 6502 has (this should look sorta familiar only different):
A - 8 bit Accumulator
X - 8 bit index
Y - 8 bit index
Page 0 works like the direct page but is unmovable.
Page 1 is the stack and unmovable since the stack pointer is 8 bit.
To really index stuff requires indexed indirect tables of 16 bit
pointers in page 0.  
The 6502 can only perform short reletive branches so you'll find a lot
of conditional branches that jump to an absolute branch.


The 65816 allows you to move the direct page from page 0 with the D
register (can you say DP?).
A can be 8 or 16 bits in native mode.  When it's 8 bits the top 8 (B)
can be used for temporary storage by swapping with A. Changing A
between 8 and 16 bit mode requires setting a bit in the CPU.
X and Y can now support 16 bits in native mode so you don't have to
use page 0 to get around the small index registers.
The stack pointer now supports 16 bits and it can lie anywhere in the
first 16 bits of the memory address instead of just page 0.
There is a PBR (Program Bank Register) and DBR (Data Bank Register)
used for accessing the 24 bit memory space.
No more short conditional branches to long branches.
(Insert about every other capability the 6809 has here...)
Clearly the 65816 borrowed ideas from the 6809 but it stays within the
general architecture/instruction set/register model of the 6502.
Most importantly, many of the addressing modes have identical clock
times to the equivalent mode on the 6809 and after a quick look that
includes stack relative addressing.  


The 65816 clearly takes ideas from the 6809 but if you also look up
the 6800 you will notice that the 6809 may have also borrowed from the
6502 rather than just from the 6800.


While source code between the 6809 or 65816 isn't exactly the same it
isn't difficult to port between them.  Porting from the 6502 to 6809
isn't too bad either since the 6809 is more powerfull and the code
actually gets shorter more often than it gets longer.  From the 6809
to 6502 is another matter mostly because of the small index registers.
 Some code would be much larger and slower and may even require a
totally different approach.


The 6809's A/B/D is more flexible than the 65816's A/B/A and the 2nd
stack pointer is another plus over the 65816.  However, the 65816 is a
newer design, has the PBR/DBR registers and I *think* a prefetch like
the 6309.  

How speeds compare I'm not sure but the 65816 is newer fully
synthesized design and is availabe in a 15MHz version (commonly
overclocked to 20MHz).  Western Design Center had even announced a 32
bit version.  They said it was done a few months ago... only to have
all evidence of it's existance disappear from their website shortly
afterwards.  


>>  it's common to use a
>>stack pointer when drawing on the screen since it saves a clock cycle
>>for each access.  Or is this only valid for the 65816?
>
>Very possible - I've never coded for 6502 or the 65816.

Actually I've already found it in some 6809 graphics code so it's also
valid at times there.  The ability to load multiple registers and push
them to the screen can save some clock cycles.

>>This brings me to a gripe I have about the coco.

What follows my gripe is an emotional rant.


>The following gripe is a straw-man argument.

>>If you were programming an Atari 800, C64 or even Plus/4 game I could
>>point you to music tracker plugins that you could include with only a
>>few lines of code.  Just point it to the music you want to play and
>>call the player within your interrupt handler and now your game has
music.
>>Need blitter code?  No problem.  6502 or 65816 routines ready to use.
>>The coco?  I have to extract the code from a couple places or roll my
>>own and it takes much longer.

>You might as well gripe that there's existing blitter and music code for 
>the Athlon 64 or Itanic ready to use but you must rewrite it in 6809. 

Um, actually with the Athlon 64 it would be called DirectX and there's
a lot of sample DirectX code around.  

"A straw man argument is a logical fallacy based on misrepresentation
of an opponent's position. To "set up a straw man" or "set up a
straw-man argument" is to create a position that is easy to refute,
then attribute that position to the opponent. A straw-man argument can
be a successful rhetorical technique (that is, it may succeed in
persuading people) but it is in fact misleading, because the
opponent's actual argument has not been refuted."

"refute
1 : to prove wrong by argument or evidence : show to be false or erroneous
2 : to deny the truth or accuracy of "

I had no opponent and there is no misrepresentation on my part.
You however have misrepresented my position and I refute your argument
below.  Which makes your argument a straw-man argument.

If there is a CoCo library that I can just plug in and use for music,
sound effects or graphics please point me to it.
I'll be happy to point poeple to Atari, C64 or even Plus/4 code if you
really want it.  

>The 65816 and 6809 are totally different critters! 

Still think so now?

>Why is it the CoCo's fault that no-one else wrote blitter code for
>the 6809? 
>Do you blame the hammer 
>for not hitting the nail, too?
>Sorry for the sarcasm, 
>but it's not the CoCo's fault that *humans* haven't 
>pre-written the code you desire.

Coco's fault?  Now there's a massive leap to a conclusion.

I stated a fact about how much more effort is required to create a
game for the coco... not because of the hardware but lack of sample
code or libraries.  It's obviously because PEOPLE haven't released as
much sorce code or as many tools.  

Sure it's related to the fact that the coco wasn't commonly accepted
as a major games machine and as a result there are still hundreds more
people developing games for those platforms, but that doesn't mean I
blame the machine.  "My gripe about the coco" didn't refer to the
hardware at all if you go back and look.  Not one complaint about the
hardware.

What prompted my gripe was frustration.   I see people that *want* to
write new games for the CoCo looking for help and I can't just say
"you can download simple examples here, here, here, here and here. 
And there are five different threads in 3 different forums dealing
with the same thing"  or  "to add music just add these 12 lines of
code and point this at your music data from the music tracker."


>That's my take, anyway... Laterz,
>Roger "Merch" Merchberger

And I thought it was bad when a C64 fan posted that his computer was
better than the Atari in an Atari forum.






Brought to you by the 6809, the 6803 and their cousins! 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ColorComputer/

<*> To unsubscribe from this group, send an email to:
    ColorComputer-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/