Jump to content
IGNORED

ASM Development Tools for the Coco3


Recommended Posts

I have noticed on eBay, this Auction:

Color Computer EDTASM+ Editor Assembler with ZBUG Radio Shack Tandy 26-3250 coco

Would this be something "worthwhile" to purchase for the CoCo 3??

Are there any better recommendations for an Assembler Development Systems for the CoCo 3??

At this point, I have a CoCo 3 with 128K, and no Tape or Disk Interface. I am getting the DriveWire System setup on my computer, so I can work with Virtual Disk Images.


The CoCo 3 is New in Box, and I am the Second Owner, the First Owner never plugged it in.. Neither have I, so I probably should..

 

MarkO

Link to comment
Share on other sites

There was some similar third-party software, but in the 1980s, EDTASM+ was very much the gold standard. The Editor, Assembler, and Debugger integrate seamlessly.

 

Note, however, that it will only save to cassette. If memory serves, Rainbow magazine published multiple patches and enhancements, including instructions for making a disk version. This would have been around 1983 or 1984.

 

William Barden authored a very good tutorial (published by Radio Shack) based around EDTASM+. Dennis Kitz (sp?) also did a tutorial series, though I do not know what assembler he favoured.

  • Like 1
Link to comment
Share on other sites

There was some similar third-party software, but in the 1980s, EDTASM+ was very much the gold standard. The Editor, Assembler, and Debugger integrate seamlessly.

That is good to know. The CoCo 3 is backward compatible, so this CoCo 1 Cartage will work fine on it??

 

Note, however, that it will only save to cassette. If memory serves, Rainbow magazine published multiple patches and enhancements, including instructions for making a disk version. This would have been around 1983 or 1984.

Did they Patch the ROM, and you then Burn a new version???

 

William Barden authored a very good tutorial (published by Radio Shack) based around EDTASM+. Dennis Kitz (sp?) also did a tutorial series, though I do not know what assembler he favoured.

I found this book:

Color Computer Assembly Language Programming (1983) (William Barden Jr)

and then Won the Auction:

Tandy CoCo Radio Shack TRS-80 Color Computer Assembly Language Programming book

 

EDTASM+ seems to be the Assembler of Choice.

 

Thanks for the Input.

 

MarkO

Link to comment
Share on other sites

I thought EDTASM+ kinda sucked myself.
If you can get a copy of SD80C (I think that's what it was called) on disk it was a far better assembler/editor.
The cart version would be ideal but the last copy I saw on ebay sold for well over $100.

Cross assemblers are much better and there are several.

I used the Rainbow IDE to do some assembly and testing on an emulator but it was pretty flaky.

  • Like 1
Link to comment
Share on other sites

Marc,

I still have William Barden Jr's book from BITD, it's pretty awesome IMO and my copy is seriously dog eared :) I still use it as a reference today! The 6809 is a really advanced 16-bit processor, Barden covers it very well.

 

Once you lean from it you will need another reference book to find the GIME mappings for the higher res coco3 modes though.

 

You can easily make a cable to save and load .asm and binaries from cassette (or your mp3 player), and like jhd said, we had patches to make it save to disk - first you would need to cover the last pin on the cart with tape and save the cart image to tape, then transfer EDTASM+ it to disk itself and apply the patch or find the patched EDTASM+.

 

James,

I never tried SD80C, what features did it have over EDTASM+?

  • Like 1
Link to comment
Share on other sites

 

That is good to know. The CoCo 3 is backward compatible, so this CoCo 1 Cartage will work fine on it??

 

I honestly don't know. I only used the Coco 3 briefly in about 1987/88, and only for BASIC.

 

EDTASM+ may not support the advanced graphics modes or expanded memory. If you are getting that serious about programming, look at OS-9 software or more modern tools.

  • Like 1
Link to comment
Share on other sites

Marc,

I still have William Barden Jr's book from BITD, it's pretty awesome IMO and my copy is seriously dog eared :) I still use it as a reference today! The 6809 is a really advanced 16-bit processor, Barden covers it very well.

 

Once you lean from it you will need another reference book to find the GIME mappings for the higher res coco3 modes though.

 

You can easily make a cable to save and load .asm and binaries from cassette (or your mp3 player), and like jhd said, we had patches to make it save to disk - first you would need to cover the last pin on the cart with tape and save the cart image to tape, then transfer EDTASM+ it to disk itself and apply the patch or find the patched EDTASM+.

 

James,

I never tried SD80C, what features did it have over EDTASM+?

The 6809 has an 8 bit ALU, it's not 16 bit.

This is very noticeable if you want to perform bit shifts on the D register. There are no such instructions.

 

I remember the macros were really powerful. You could program them pretty much like any high level language.

If you wanted to automate the generation of some tables they came in handy.

There were some other things but it's been so long I can't even remember. I'd have to dig out a manual.

 

Link to comment
Share on other sites

 

I honestly don't know. I only used the Coco 3 briefly in about 1987/88, and only for BASIC.

 

EDTASM+ may not support the advanced graphics modes or expanded memory. If you are getting that serious about programming, look at OS-9 software or more modern tools.

EDTASM+ has nothing to do with supporting any of that. That depends on your code.

 

Support for 80 column text within the editor is lacking and that's one of the biggest improvements they could make.

Programming assembly in 32 characters per line really limits how readable code is when you add comments.

 

Come to think of it, SD80C's editor has issues with the CoCo 3 and requires a patch.

 

 

  • Like 1
Link to comment
Share on other sites

That is good to know. The CoCo 3 is backward compatible, so this CoCo 1 Cartage will work fine on it??

The CoCo 3 slot is compatible except for the lack of +12v but the CoCo 2 is the same way.

*Most* CoCo 1/2 carts work on the 3 but there are some exceptions.

Anything using the unsupported semi-graphics modes and a few games that messed with the wrong hardware bits don't work.

Downland and a couple other carts had updated versions with white labels for versions that had CoCo 3 updates.

  • Like 1
Link to comment
Share on other sites

The 6809 has an 8 bit ALU, it's not 16 bit.

This is very noticeable if you want to perform bit shifts on the D register. There are no such instructions.

 

I remember the macros were really powerful. You could program them pretty much like any high level language.

If you wanted to automate the generation of some tables they came in handy.

There were some other things but it's been so long I can't even remember. I'd have to dig out a manual.

 

James,

the 6809 has a 16 bit accumulator; the X and Y index registers are also 16 bit - this makes it a 16-bit processor. Also has plenty of 16 bit instructions like 16 bit multiply (no need for bit shifts) and sign extension, etc. By contrast the 6502 has an 8 bit accumulator and 8 bit X and Y index registers (and not even an 8 bit multiply).

 

Cool that SD80C had macros - pretty advanced :) I never used them BITD. Don't fancy them now, feels like scripting.

Edited by Mr SQL
  • Like 1
Link to comment
Share on other sites

James,

the 6809 has a 16 bit accumulator; the X and Y index registers are also 16 bit - this makes it a 16-bit processor. Also has plenty of 16 bit instructions like 16 bit multiply (no need for bit shifts) and sign extension, etc. By contrast the 6502 has an 8 bit accumulator and 8 bit X and Y index registers (and not even an 8 bit multiply).

 

<< SNIP >>

 

And the 6309 has Two additional 8 Bit Registers that can be Combined to make One Additional 16 Bit Register, that can be Combined with the Original A and B, or D to make a 32 Bit Register.. And still can be Backward Compatible with the 6809!!! That is so very, Way Cool!!!

  • Like 1
Link to comment
Share on other sites

 

And the 6309 has Two additional 8 Bit Registers that can be Combined to make One Additional 16 Bit Register, that can be Combined with the Original A and B, or D to make a 32 Bit Register.. And still can be Backward Compatible with the 6809!!! That is so very, Way Cool!!!

Wow, that is really cool! :) IMO that makes the 6309 is a 32-bit chip in many respects :)

Link to comment
Share on other sites

Just read the memo on the secret features of the 6309 - plenty of 32 bit instructions too; multiply and divide!

 

Really fantastic, chip could have made the CoCo4!! :)

 

 

And still would have been Backward Compatible with the CoCo 1, 2 & 3.. ;) Thus Not Breaking the Cardinal Rule..

  • Like 1
Link to comment
Share on other sites

James,

the 6809 has a 16 bit accumulator; the X and Y index registers are also 16 bit - this makes it a 16-bit processor. Also has plenty of 16 bit instructions like 16 bit multiply (no need for bit shifts) and sign extension, etc. By contrast the 6502 has an 8 bit accumulator and 8 bit X and Y index registers (and not even an 8 bit multiply).

If your definition of an 8 bit cpu were that it only have 8 bit registers, it could only have an 8 bit program counter and only address 256 bytes of RAM.

Even the 6502 has a 16 bit program counter and it also supports 16 bit indirect addressing.

 

The Z80 has 16 bit index registers and supports combined accumulators for 16 bit support, has a 16 bit stack pointer, etc...

The 6800 has a 16 bit index register, and has a 16 bit stack pointer.

The 8080 also has 16 bit combined register support and 16 bit stack pointer.

You have to go back to the 8008 to find another cpu as 8 bit as the 6502.

 

By your standards, that would also make the intro of the Mac, Atari ST and Amiga the start of the 32 bit era rather than the start of the 16 bit era.

The introduction of the 6800 and Z80 would have also marked the start of the 16 bit era.

I'll admit the definition is pretty muddy but prior to the 6809, 16 bit index registers and combining registers to get 16 bit registers wasn't enough to call a cpu 16 bit.

 

Cool that SD80C had macros - pretty advanced :) I never used them BITD. Don't fancy them now, feels like scripting.

One of the demos included with it had macros that actually solved the Towers of Hanoi.

It doesn't take anything real complex for macros to be useful.

Have a look at the Atari 8 bit GUI thread. He's using macros to help build a cart version of the GUI.

  • Like 1
Link to comment
Share on other sites

If your definition of an 8 bit cpu were that it only have 8 bit registers, it could only have an 8 bit program counter and only address 256 bytes of RAM.

Even the 6502 has a 16 bit program counter and it also supports 16 bit indirect addressing.

 

James that is not really relevant to programming though as Johhny Mnemonic points out:
Indirect Addressing:

 

Johnny has more important things to think about and literally jumps away from this one; Jump (goto) is the only operation that uses it, and transparently at that.

The Z80 has 16 bit index registers and supports combined accumulators for 16 bit support, has a 16 bit stack pointer, etc...

The 6800 has a 16 bit index register, and has a 16 bit stack pointer.

The 8080 also has 16 bit combined register support and 16 bit stack pointer.

You have to go back to the 8008 to find another cpu as 8 bit as the 6502.

 

By your standards, that would also make the intro of the Mac, Atari ST and Amiga the start of the 32 bit era rather than the start of the 16 bit era.

The introduction of the 6800 and Z80 would have also marked the start of the 16 bit era.

I'll admit the definition is pretty muddy but prior to the 6809, 16 bit index registers and combining registers to get 16 bit registers wasn't enough to call a cpu 16 bit.

 

 

Good point about the intel series; the 80386 is a genuine 32-bit cpu just like the 68000; you can run NT, Office 2000 and .Net (1.0) on a 386, just really really slowly but it's still all 32-bit code (wowexec routines not withstanding).

Likewise the 68000 runs real 32-bit asm just like the 6809 runs real 16-bit asm.

One of the demos included with it had macros that actually solved the Towers of Hanoi.

It doesn't take anything real complex for macros to be useful.

Have a look at the Atari 8 bit GUI thread. He's using macros to help build a cart version of the GUI.

 

Sounds cool, I will check it out :)

Link to comment
Share on other sites

I believe a message or two were deleted.

 

6502 indirect addressing is using a 16 bit pointer on page zero.

I believe JMP is the immediate addressing mode and it is also 16 bit.

I was just pointing out even the 6502 isn't a purely 8 bit CPU.

  • Like 1
Link to comment
Share on other sites

I believe a message or two were deleted.

 

6502 indirect addressing is using a 16 bit pointer on page zero.

I believe JMP is the immediate addressing mode and it is also 16 bit.

I was just pointing out even the 6502 isn't a purely 8 bit CPU.

No Johnny is correct! :) JMP uses indirect addressing not immediate addressing (no # prefix); it sets the 16 bit PC to the address stored at the target memory location and has the distinction of being the only instruction to use this addressing mode.

 

I need to be able to manipulate a 16-bit accumulator (and preferrably 16-bit index registers) to write 16-bit code; the PC doesn't count.

  • Like 1
Link to comment
Share on other sites

No Johnny is correct! :) JMP uses indirect addressing not immediate addressing (no # prefix); it sets the 16 bit PC to the address stored at the target memory location and has the distinction of being the only instruction to use this addressing mode.

 

I need to be able to manipulate a 16-bit accumulator (and preferrably 16-bit index registers) to write 16-bit code; the PC doesn't count.

Actually it's direct addressing. I just looked it up in my 6809 assembly book.

Indirect has the address in an index register or memory. "the instruction tells where the address is, not where the data is."

 

*edit*

It seems to me "doesn't count" gets used a lot when it doesn't agree with someone's argument.

 

 

Edited by JamesD
  • Like 1
Link to comment
Share on other sites

Actually it's direct addressing. I just looked it up in my 6809 assembly book.

Indirect has the address in an index register or memory. "the instruction tells where the address is, not where the data is."

 

*edit*

It seems to me "doesn't count" gets used a lot when it doesn't agree with someone's argument.

 

James,

you're right it's direct too: JMP MyData

 

but it's also indirect JMP($2000) ; load PC with the two bytes at mem $2000

 

This is really esoteric, I've never used that fom! :) I'm not sure if the 6809 supports indirect JMP like the 6502, but it has LBRA which does the same thing as a direct JMP.

 

Link to comment
Share on other sites

I realize this is getting off topic but...

Ah, I was thinking JMP ADDRESS, not JMP (ADDRESS). I didn't use the latter even though I used a jump table in my music player.
It's faster to load values from a jump table, push them on the stack and use RTS to call a routine that to modify ADDRESS in the code or what is at ADDRESS.
If you are calling someone else's routines through a jump table it's also faster to just use JMP ADDRESS and patch the addresses on startup. The drawbacks to that would be if there are a lot of calls in which case it isn't practical and the setup code is larger.

I mention the 2nd example because the CoCo 1/2/3 and Dragon use tables of vectors (pointers) to documented ROM routines. As long as you call the ROM routines with those pointers and don't use undocumented calls, your code should work on all of them regardless of ROM version. At least from the ROM call aspect anyway.
Imagine if Microsoft had implemented all 6502 BASICs with such a table and if the table were at the same address for all versions. You could theoretically run the same code without modifications on every 6502 machine as long as it were text based. Reading characters from the keyboard, outputting characters to the screen or printer, perform file I/O, etc...
Hindsight is wonderful.

 

 

6809 syntax (aka Motorola syntax) is slightly different than 6502.
On the 6809 it's like this:
JMP [address]

The 6809 can also do this (much better for tables):

JMP [address,X]

not to be confused with this which it also supports:

JMP address,X

Keep in mind that since the 6809's D register has no bit shift instructions you have to shift A and B registers separately to implement a 16 bit shift.
To implement the jump table in my music player on the 6809 I would have to do something like this to call built in commands (U points to the current address in the music data):

LDA #0 ; clear the upper byte of D
PULU B ; grab the # of the routine to call in the jump table
ASLB ; multiply by 2 since each address in the table is 2 bytes
ROLA ; only needed for tables with more that 128 addresses
TFR D,X ; transfer D to X
JMP [TABLE,X] ; call it

 

I believe the 6309 supports ASLD so it could be like this:

LDA #0 ; clear the upper byte of D
PULU B ; grab the # of the routine to call in the jump table

ASLD ; multiply by 2 since each address in the table is 2 bytes It would still be ASLB if the table has 128 entries or less
TFR D,X ; transfer D to X
JMP [TABLE,X] ; call it

 

It's a small improvement but if you have to do a lot of 16 bit shifts the savings add up.
The 6309 is much more 16 bit oriented than the 6809.

 

The 6803 is similar to the 6809 but it drops a few things. It doesn't support TFR so you have to use a temporary address or the stack to move stuff between D and X.

I cussed about that a few times when I was writing a line drawing subroutine for the MC-10. I would have been very happy with TDX and TXD instructions.

 

The 65C02 adds the JMP (address,X) instruction.
For the above example it's about the same as the 6809 code. Just remember that dealing with a jump table with more that 128 addresses would have to work similar to regular 6502 code where you calculate the address, push it onto the stack a byte at a time and RTS to call it.

LDA ,Y

ASL

INY

TAX

JMP (TABLE,X)

 

  • Like 3
Link to comment
Share on other sites

James,

great post, nice examples! :) Good point about having to do a shift and a roll; the 6809 could have used more 16-bit instructions but minus the extra ROL the code is all 16-bit with D and X.

 

I remember the vectors and the problems with Dragon compatability when we did not use them!! :)

 

Your player was based on the William Tell Overture codebase I think from previous conversation? All excellent topics for this thread IMO :)

  • Like 1
Link to comment
Share on other sites

James,

great post, nice examples! :) Good point about having to do a shift and a roll; the 6809 could have used more 16-bit instructions but minus the extra ROL the code is all 16-bit with D and X.

 

I remember the vectors and the problems with Dragon compatability when we did not use them!! :)

 

Your player was based on the William Tell Overture codebase I think from previous conversation? All excellent topics for this thread IMO :)

LOL, different music player.

That was Z80 code for the VZ200.

 

Try this thread:

http://atariage.com/forums/topic/205521-apple-its-on-like-donkey-kong/page-4?hl=+donkey%20+kong%20+mockingboard

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...