Anyone ever used EDTASM+ for CoCo2?

[johnnystarr]

I would like to open the discussion on EDTASM+ and your experience with it. I realize this is an Atari forum, but I'll take any input I can get

I have a CoCo 2 with 64K and I'm curious how large my applications can get with it. I found this manual online: http://www.colorcomputerarchive.com/coco/Documents/Manuals/Programming/EDTASM+%20With%20ZBUG%20%28Tandy%29.pdf

 

It's been helpful as it references EDTASM+ cartridge version. However, due to the time it was written, it goes into more detail about the 16K and 32K versions. I'm curious if it has support to take advantage of the 64K machine I have.

 

I get that this is more than antiquated, but I have a feeling you understand why I would want to learn this.

 

Thanks in advance to anyone who wants to discuss this.

[ceratophyllum]

You know, I would like to know more about EDTASM+, too. With my other retro systems (C64 and TI99/4A) I ended up setting up MESS for testing and using a cross-assembler on my PC. Too much eye strain on an old TV and 40 column text editors are mostly no fun. (I also keep typing extra colons because I'm so used to vim. Doh!)

 

Maybe if I had one of those TV to VGA converter boxes for the coco2 it wouldn't give me a headache.....

Edited April 13, 2016 by ceratophyllum

[JamesD]

I tried EDTASM+, but I wasn't impressed with it feature wise. It will certainly do the job though.
It really wasn't designed to take advantage of 64K.
Macro 80C is a lot better assembler, has a better editor, supports macros, etc... but editing assembly language in 32 columns is still horrible.

You are much better off using a cross assembler.
I've tried several but think the last one I used was with lwtools.
http://lwtools.projects.l-w.ca/

[Mr SQL]

I would like to open the discussion on EDTASM+ and your experience with it. I realize this is an Atari forum, but I'll take any input I can get

I have a CoCo 2 with 64K and I'm curious how large my applications can get with it. I found this manual online: http://www.colorcomputerarchive.com/coco/Documents/Manuals/Programming/EDTASM+%20With%20ZBUG%20%28Tandy%29.pdf

 

It's been helpful as it references EDTASM+ cartridge version. However, due to the time it was written, it goes into more detail about the 16K and 32K versions. I'm curious if it has support to take advantage of the 64K machine I have.

 

I get that this is more than antiquated, but I have a feeling you understand why I would want to learn this.

 

Thanks in advance to anyone who wants to discuss this.

 

Very cool, EDTASM+ was loads of fun bitd! You will have an awesome time learning with it - the EDTASM+ cart works with tape or ipod for loading/saving which is also convenient.

 

It will only take advantage of 32k, but that's plenty of room to assemble pretty big Machine Language programs without linking.

 

I tried EDTASM+, but I wasn't impressed with it feature wise. It will certainly do the job though.

It really wasn't designed to take advantage of 64K.

Macro 80C is a lot better assembler, has a better editor, supports macros, etc... but editing assembly language in 32 columns is still horrible.

You are much better off using a cross assembler.

I've tried several but think the last one I used was with lwtools.

http://lwtools.projects.l-w.ca/

 

What kind of Assembly are you writing James? 32 columns is perfect imo - big easy to see mnemonics and operands with room even for comments!

[johnnystarr]

 

It will only take advantage of 32k, but that's plenty of room to assemble pretty big Machine Language programs without linking.

I know EDTASM builds a symbol table before the 32K RAM. Is there anyway to tell how big my unlinked binaries can be? I would like to at least be able 16K machine code applications. Is this viable?

[JamesD]

 

Very cool, EDTASM+ was loads of fun bitd! You will have an awesome time learning with it - the EDTASM+ cart works with tape or ipod for loading/saving which is also convenient.

 

It will only take advantage of 32k, but that's plenty of room to assemble pretty big Machine Language programs without linking.

 

What kind of Assembly are you writing James? 32 columns is perfect imo - big easy to see mnemonics and operands with room even for comments!

Only taking advantage of 32K = source code + symbol table + binary. So not 32K of code.

 

32 columns is perfect?

The MC-10 version of my 64 column text code (RG6 graphics mode) is 1010 lines long, and with comments is over 120 characters wide at times.

The source file is 34K and that's with macros to shorten it. (FWIW, the Z80 version source is about 39K on disk, and the current 6502 version is 41K)

 

I'm using Notepad++ and can view around 150 columns of text with comments, opcodes, and keywords in different colors.

I can also compare different versions side by side and have many source files in the editor at once.

Plus, it only takes a couple seconds to assemble my code on my laptop.

When I get around to a 6809 CoCo port, the source will probably shrink to just over 30K and I highly doubt EDTASM+ could assemble it even if I don't use macros.

That's just a demo that prints the font over and over.

The final project will probably have multiple assembly language pieces that large designed to link to C, something which EDTASM+ is totally unsuitable for.

 

If you want to learn assembly, EDTASM+ is fine. If you want to start a major project, it's just going to slow you down.

I'm not saying you can't write a decent game or other program in it, but it will limit what you can do.

 

[Mr SQL]

I know EDTASM builds a symbol table before the 32K RAM. Is there anyway to tell how big my unlinked binaries can be? I would like to at least be able 16K machine code applications. Is this viable?

 

Yes, see the memory layout in Appendix E, the top of RAM is moved from 3FFF to 7FFF with 32K/64K CoCo's; you'll have enough room to Assemble a 16K binary if you keep comments brief.

 

That book was a great read btw, thanks for sharing, brought back great memories!

 

The manual really is superb, I suggest reading it from cover to cover like I just did again, and you'll already have an enhanced understanding of programming the 6809 for the CoCo's architecture.

 

I was going to reccommend William Barden Jr's book but the EDTASM manual it does a much better job of telling you just what you need to know, while Barden's book is more of a comprehensive reference.

[Mr SQL]

Only taking advantage of 32K = source code + symbol table + binary. So not 32K of code.

 

32 columns is perfect?

The MC-10 version of my 64 column text code (RG6 graphics mode) is 1010 lines long, and with comments is over 120 characters wide at times.

The source file is 34K and that's with macros to shorten it. (FWIW, the Z80 version source is about 39K on disk, and the current 6502 version is 41K)

 

I'm using Notepad++ and can view around 150 columns of text with comments, opcodes, and keywords in different colors.

I can also compare different versions side by side and have many source files in the editor at once.

Plus, it only takes a couple seconds to assemble my code on my laptop.

When I get around to a 6809 CoCo port, the source will probably shrink to just over 30K and I highly doubt EDTASM+ could assemble it even if I don't use macros.

That's just a demo that prints the font over and over.

The final project will probably have multiple assembly language pieces that large designed to link to C, something which EDTASM+ is totally unsuitable for.

 

If you want to learn assembly, EDTASM+ is fine. If you want to start a major project, it's just going to slow you down.

I'm not saying you can't write a decent game or other program in it, but it will limit what you can do.

 

 

Your 64 column soft text screen is awesome on the MC-10, reminds me of Telewriter!

 

120 characters are some really long comments though - I tend to be verbose/descriptive too with modern assemblers because we have the room.

 

If you keep comments brief your source would easily fit in EDTASM.

[johnnystarr]

Does anyone have a comprehensive list of memory addresses for ROM / Extended Color Basic that I can use in assembly? I've seen examples of JSRs to addys for things like CLS etc. Ideally I would like to leverage the routines like SOUND, SCREEN and CIRCLE while keeping RAM free. Actually, I cant find any documentation on full graphics mode without using basics SCREEN command.

[Mr SQL]

Extended BASIC unraveled had a comprehensive listing of all the routines. Barden's book lists many of them too with calling examples.

 

Edit: http://bitchin100.com/files/coco/super-extended-basic-unravelled.pdf

wrong one...

http://searle.hostei.com/grant/6809/extended-basic-unravelled.pdf

Edited April 14, 2016 by Mr SQL

[JamesD]

Your 64 column soft text screen is awesome on the MC-10, reminds me of Telewriter!

I used VIP Writer myself. It got me through several years of college!

It was definitely slower at rendering text than my code though. But I don't think they spent as many hours optimizing it either.

Not sure about the speed of Telewriter since I never got to use it, but I doubt it's as fast either.

One of my goals was to make it fast enough it would be difficult to tell a program was using graphics for text.

 

I'm about to test a version that uses a completely unrolled screen scroll.

The scroll code is generated at run time rather than by using macros, so the source code has shrunk somewhat, and it's over 3000 clock cycles faster than the old scroll.

 

 

120 characters are some really long comments though - I tend to be verbose/descriptive too with modern assemblers because we have the room.

 

If you keep comments brief your source would easily fit in EDTASM.

I agree, that is pretty wide, but it's easy to read on my editor.

It wouldn't be bad if I were to use 80 or even 64 columns. But 32 or 40 just isn't very readable. Uppercase only doesn't help either.

 

While I could probably cut the source code size in half without comments, the code would be difficult to follow and I've publicly posted it for other people to use.

 

Edited April 14, 2016 by JamesD

[Mr SQL]

I used VIP Writer myself. It got me through several years of college!

It was definitely slower at rendering text than my code though. But I don't think they spent as many hours optimizing it either.

Not sure about the speed of Telewriter since I never got to use it, but I doubt it's as fast either.

One of my goals was to make it fast enough it would be difficult to tell a program was using graphics for text.

 

I'm about to test a version that uses a completely unrolled screen scroll.

The scroll code is generated at run time rather than by using macros, so the source code has shrunk somewhat, and it's over 3000 clock cycles faster than the old scroll.

 

 

I agree, that is pretty wide, but it's easy to read on my editor.

It wouldn't be bad if I were to use 80 or even 64 columns. But 32 or 40 just isn't very readable. Uppercase only doesn't help either.

 

While I could probably cut the source code size in half without comments, the code would be difficult to follow and I've publicly posted it for other people to use.

 

Telewriter is a little faster than VIP but I think your soft text screen on the MC-10 is faster than both, looking forward to seeing it running on the CoCo!

 

Very cool you are doing the calcs at run time instead of via macros (optimization).

 

Found Barden's book with ROM routine calling and graphics and sound examples for johnnystarr:

 

http://www.colorcomputerarchive.com/coco/Documents/Books/Color%20Computer%20Assembly%20Language%20Programming%20(1983)%20(William%20Barden%20Jr).pdf

 

I have a dog eared real copy of this book I need to read through again!

 

[johnnystarr]

So, here's a question guys:

 

Using EDTASM is fine, but I can only really test by adding break points. Once I assemble my program and CLOADM it it just bounces Extended Basic even though I have an endless loop. Do I have to disable basic or something? How do programs maintain control of the Machine? I wanna say by disabling an interrupt or something?

[Mr SQL]

So, here's a question guys:

 

Using EDTASM is fine, but I can only really test by adding break points. Once I assemble my program and CLOADM it it just bounces Extended Basic even though I have an endless loop. Do I have to disable basic or something? How do programs maintain control of the Machine? I wanna say by disabling an interrupt or something?

 

You have to specify the start address; EXEC start.

 

EDTASM has an option to save the start address to tape with the program so that you won't have to specify it and can just type EXEC. It's in the manual you posted, check the assemble options.

[johnnystarr]

Thanks all for your help so far. I switched do using lwasm locally on my OS X machine and outputting to a .bin file which i then push to a .dsk image. The problem I have now is that anytime the file gets above 1K or so, it cant run. I chose execution address 0x600 as I figured that was a good place. However, Im curious if I am mangling RS-DOS memory somehow. Does anyone know of a good address to start with? My binary is going to be roughly 16K That or a memory map of RS-DOS would help