CoCo 3 ASM Development Tools for the Coco3

[JamesD]

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

 

 

As I stated in the thread, it came from a version I wrote for the Oric.

That was a port from a Z80 Aquarius version I optimized, made interrupt driven and ported for a VZ AY hardware project.

I believe I have 6803 and 6809 versions floating around somewhere I ported for comparison.

 

[MarkO]

The Color Computer EDTASM+ Editor Assembler with ZBUG Radio Shack Tandy 26-3250 coco was re-listed as an auction, and I won it.. Hope to see it this week, and try it out with my new to me, Tandy CoCo Radio Shack TRS-80 Color Computer Assembly Language Programing book

 

MarkO

[MarkO]

I realize this is getting off topic but...

 

<<< REALLY BIG SNIP >>>

 

I don't have a problem with it.. This is All Relevant to me.....

 

MarkO

[MarkO]

You might try the LWTools for cross development.

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

This looks like a nice Tool.. I will look into it...

 

MarkO

[MarkO]

I just received my EDTASM+ Editor Assembler Debugger. It works fine with my CoCo 3. Now I just need to get some Audio and Serial Cables to be able to Save my Programs..

[MarkO]

I just won an Auction for a CoCo 2.

 

It appears to have the Cassette Cable. Now I just need the 4-pin DIN to make a Drive Wire Cable...

 

MarkO

[MarkO]

Hmm.. the coco 2 only has RF output.. so I need a tuner or tv to connect it..

 

The coco 3 is a definite improvement on the video choices..

[MarkO]

After doing a bunch more research, I see that there is a Disk Based Version of EDTASM+ and a Patch from Robert Gault, EDTASM6309 to make the Disk Based version even better...

Also Chris Lomont has some Development Tools and a version of the MESS Emulator with the Debugging Compiled into it, for CoCo Development.. ( See his CoCo Programming Page for more CoCo stuff )

 

MarkO

[John_L]

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

 

First of all Wow on picking up one that's brand new in the box!!! That's pretty rare! There is a disk version of edtasm. If you look around, you can find a bunch of .dsk files online with old CoCo software including a disk version of Edtasm. As far as assembly is concerned, disk Edtasm is fine.

 

Also though, bare in mind, besides the cartridge based RS-DOS, which is basically a handful of DOS commands built into BASIC, there is a true, full blown multi-user multi-tasking operating system for the CoCo called OS-9 (level II). OS-9 is basically a Unix clone for the MC6809 processor. There's even C programming available on OS-9 too.

 

PM me if you need some help getting a hold of any of this software.

[MarkO]

First of all Wow on picking up one that's brand new in the box!!! That's pretty rare! There is a disk version of edtasm. If you look around, you can find a bunch of .dsk files online with old CoCo software including a disk version of Edtasm. As far as assembly is concerned, disk Edtasm is fine.

The CoCo 3 was for a Correspondence Course, that was never taken. It had been in storage for 20+ years, longer than the Apple ][ Platinum I got from him.. Along with some Apple ][ games..

 

I found in another Thread some Links to the Disk Version, and the Manual... The Cartridge Version reminds me of the Big Mac/Merlin Assembler I bought back in 1986..

 

Also though, bare in mind, besides the cartridge based RS-DOS, which is basically a handful of DOS commands built into BASIC, there is a true, full blown multi-user multi-tasking operating system for the CoCo called OS-9 (level II). OS-9 is basically a Unix clone for the MC6809 processor. There's even C programming available on OS-9 too.

I have been looking into the various Radio-Shack DOS's..

OS-9 looks like a good way to go, and I really like 'C' as a programming Language...

 

I am definitely replacing the 6809 with the 6309 chip.. And buying the Cloud-9 512K upgrade..

 

I just won an Auction for a FD-500 with J&M Systems Disk Controller, and I can see that the J&M can have compatibility Problems with certain programs.. But for Basic Disk Access, I thought it would work fine.. Has any one tried replacing the J&M ROM with a DCEB ROM??

 

PM me if you need some help getting a hold of any of this software.

Thanks, I will keep looking into the CoCo and its accessories....

 

MarkO

[John_L]

Well Mark, I think you can safely assume you're the LAST LIVING HUMAN BEING TO UNBOX A BRAND NEW COCO 3 !!!!!! Would have made a great "unboxing" video for YouTube, if I had it, I would have recorded it and posted it to YouTube and sent a link to Tandy!

 

If you're all Gung-Ho to replace the CPU, then you must have read the story about the Hitatchi 6309. I guess the story was that Hitachi wanted to make a better version of the 09, but Motorola would only license them to make an exact clone. Apparently Hitatchi went ahead and made the better chip anyway, and just didn't document the extra features. Years later, as CoCo's needed servicing, alot of hackers would replace a blown CPU, and some used the 6309, and, as hackers go, some started tinkering with it and found by testing "unused" bits that there were extra bells and whistles in there after all. This spawned a craze in the community, and lots of users have since done the upgrade. I even think there are some kits out there with instructions on how to go about doing the upgrade.

 

At the bottom of the page is a zip file with all the info for doing an RF to Composite conversion for the CoCo 2. The reason the CoCo 3 had composite output was because scores of people were doing the conversion so they could use either a TV with composite inputs, or, another popular thing to do at the time was to buy the Commodore 64's 1702 composite monitor, which was a really nice, high quality composite monitor for use with the C64.

 

 

One of the great things about the CoCo is even today there's a large number of vintage users who either, like me, had one way back in the day and just couldn't let go, or in recent times, discovered vintage computing and found the CoCo.

 

Another cool thing about the CoCo 3 was the GIME chip. Tandy was worried that if they made the CoCo 3 too good, it would hurt sales of the Tandy 1000. The Tandy 1000 had EGA graphics, the bleeding edge of PC graphics at the time, and Tandy intentionally held the CoCo 3 to 320x192x16 colors (palette of 64) and 640x192x4 colors. EGA was 320x200x256 with a 256k palette. The thing is Motorola had designed a 256 color mode into the GIME chip, but Tandy wouldn't allow it, so it's there, but undocumented. Some research on this last secret of the CoCo 3 has been done, and you can find further info about it here:

http://members.optusnet.com.au/nickma/ProjectArchive/256mode.html

composit.zip

Edited July 2, 2014 by John_L

[JamesD]

A 256 color mode would have been soooo fast for drawing lines for 3D graphics. No bit masking, just write a byte for each pixel.

[MarkO]

Well Mark, I think you can safely assume you're the LAST LIVING HUMAN BEING TO UNBOX A BRAND NEW COCO 3 !!!!!! Would have made a great "unboxing" video for YouTube, if I had it, I would have recorded it and posted it to YouTube and sent a link to Tandy!

I though about it, but the Box Seal was broken and a hole ripped in the Box, the Main Unit had been unwrapped at some point, but the Original Owner, had never plugged it in or powered it up.... Still Lost is the Piece that was shipped later to the Original Owner, noted as Missing in the CoCo 3 box... ( See These Photos )

 

If you're all Gung-Ho to replace the CPU, then you must have read the story about the Hitatchi 6309. I guess the story was that Hitachi wanted to make a better version of the 09, but Motorola would only license them to make an exact clone. Apparently Hitatchi went ahead and made the better chip anyway, and just didn't document the extra features. Years later, as CoCo's needed servicing, alot of hackers would replace a blown CPU, and some used the 6309, and, as hackers go, some started tinkering with it and found by testing "unused" bits that there were extra bells and whistles in there after all. This spawned a craze in the community, and lots of users have since done the upgrade. I even think there are some kits out there with instructions on how to go about doing the upgrade.

The hardest part is removing the Old 6809 chip... Luckily I do quite a bit of Through Hole and Surface Mount Rework at my Day Job..

 

 

At the bottom of the page is a zip file with all the info for doing an RF to Composite conversion for the CoCo 2. The reason the CoCo 3 had composite output was because scores of people were doing the conversion so they could use either a TV with composite inputs, or, another popular thing to do at the time was to buy the Commodore 64's 1702 composite monitor, which was a really nice, high quality composite monitor for use with the C64.

Thanks for the Link... Previously I found a Link to a Sinclair ZX81/Timex-Sinclair 1000 page that showed how to Bypass the ZX81/TS1000 RF Modulator and get Composite Output.. I figured the CoCo 2 would be very similar... The Apple ][ had an Issue with the RF Modulator, so they Gave it to another Business to Make, and Sell.. See, http://www.apple2history.org/history/ah03/ , search for "Sup’R’Mod"

 

 

 

One of the great things about the CoCo is even today there's a large number of vintage users who either, like me, had one way back in the day and just couldn't let go, or in recent times, discovered vintage computing and found the CoCo.

I am that way about the Apple ][, had One ( actually Two ), back in the Day, and now am getting back into them..

 

 

Another cool thing about the CoCo 3 was the GIME chip. Tandy was worried that if they made the CoCo 3 too good, it would hurt sales of the Tandy 1000. The Tandy 1000 had EGA graphics, the bleeding edge of PC graphics at the time, and Tandy intentionally held the CoCo 3 to 320x192x16 colors (palette of 64) and 640x192x4 colors. EGA was 320x200x256 with a 256k palette. The thing is Motorola had designed a 256 color mode into the GIME chip, but Tandy wouldn't allow it, so it's there, but undocumented. Some research on this last secret of the CoCo 3 has been done, and you can find further info about it here:

http://members.optusnet.com.au/nickma/ProjectArchive/256mode.html

Thanks for this Link too... Very Interesting Reading...

 

I have seen references to the 256 ( and 240 ) Color Mode.

 

Overall, the 6809/6309 looks like a really nice 8 bit chip.. I am excited to try programming it at the Machine Language level..

 

MarkO

Edited July 2, 2014 by MarkO

[MarkO]

A 256 color mode would have been soooo fast for drawing lines for 3D graphics. No bit masking, just write a byte for each pixel.

Unfortunately, Only One Page for Graphics could be used... So Page Flipping was Not an Option...

 

MarkO

[JamesD]

Unfortunately, Only One Page for Graphics could be used... So Page Flipping was Not an Option...

 

MarkO

I don't think that was a limitation on the original design.

[John_L]

 

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.

All of the MMU control registers and Video mode registers are reachable via EDTASM+, you can control what mode, 2 or 3, any one of 22 graphics modes (both old and new), and you have up to 64 8k banks, any 8 of which can be active. As long as you don't bank out the bank your code is running in, you're fine.

[John_L]

Unfortunately, Only One Page for Graphics could be used... So Page Flipping was Not an Option...

 

MarkO

Yeah, you can do frame buffering in any graphics mode, the number depended on amount of memory the graphics pages took, even the highest resolutions that used 32k could be frame buffered. Remember, CoCo 3 has either 128k or 512k, and there's mods that push it out to at least 2 that I know of. Even with a stock 512k CoCo 3 that gives you 16 32k blocks to work with, you could have the 32k ROM mapped, and say 1 8k block for bank switching, and the rest for zero page, text screen video, and program code. You can do double or even triple buffering schemes and would have plenty of space for program code, and even have the 32k ROM banked in so you can call ROM routines to keyboard scanning, joystick calls, std out calls, audio out, cassette/disk reads, writes, etc... There's a ton of useful ROM calls, so I usually leave the Color Basic (8k) and Extended Color Basic (8k), and Disk Basic ROMS mapped to the lower 32k of the addressable space, and use 1 8k bank at $2000-$3FFF for bank switching.to access frame buffers (1/4 of the screen at a time). It's not exactly easy, you have to write a kernel that lets you "write" to a virtual 32k routine that divides 32k into 4 8k chunks, then figure out which chunk it's in, and bank in the proper chunk and write the data.

 

Also, all video modes can define where video ram is, so with a few pokes, you can create page, make a few pokes to point the video there, then work on buffer 2, when done, flip the video ram there and go back to buffer 1 and modify that while buffer 2 is displayed.

Edited July 4, 2014 by John_L

[JamesD]

Yeah, you can do frame buffering in any graphics mode, the number depended on amount of memory the graphics pages took, even the highest resolutions that used 32k could be frame buffered. Remember, CoCo 3 has either 128k or 512k, and there's mods that push it out to at least 2 that I know of. Even with a stock 512k CoCo 3 that gives you 16 32k blocks to work with, you could have the 32k ROM mapped, and say 1 8k block for bank switching, and the rest for zero page, text screen video, and program code. You can do double or even triple buffering schemes and would have plenty of space for program code, and even have the 32k ROM banked in so you can call ROM routines to keyboard scanning, joystick calls, std out calls, audio out, cassette/disk reads, writes, etc... There's a ton of useful ROM calls, so I usually leave the Color Basic (8k) and Extended Color Basic (8k), and Disk Basic ROMS mapped to the lower 32k of the addressable space, and use 1 8k bank at $2000-$3FFF for bank switching.to access frame buffers (1/4 of the screen at a time). It's not exactly easy, you have to write a kernel that lets you "write" to a virtual 32k routine that divides 32k into 4 8k chunks, then figure out which chunk it's in, and bank in the proper chunk and write the data.

 

Also, all video modes can define where video ram is, so with a few pokes, you can create page, make a few pokes to point the video there, then work on buffer 2, when done, flip the video ram there and go back to buffer 1 and modify that while buffer 2 is displayed.

He was talking about the mythical hidden 256 color mode which was accessed differently than other modes.

It would require more hardware to treat it differently so I would tend to agree that it could be paged but there is no guarantee.

Since nobody has ever actually got it to work I don't think we can assume exactly how it works if it's even in there.

 

Paging video RAM isn't that difficult, I'd say it's more of an annoyance.

Anyone that has displayed anything on an Apple II screen in assembly will consider paged video RAM to be easy.

 

The font routine I wrote for the VZ series (modded to use hi-res) only has to deal with 2K pages but it's the same principal.

The CoCo 3 MMU is slightly more involved but nothing horrible.

 

The biggest complaint I have is that it's less efficient for drawing sprites, lines, circles, etc...

 

[John_L]

Duh, I didn't realize he was talking about the 256 color mode...

 

You're right about the paging, it's not too difficult. I never bothered to sit down and write the ASM routine, but I started work on it last night. I wrote a basic program that would calculate the proper 8k bank to have activated, and what memory location within that range, and determine if you should set the left or right pixel as each byte controls 2 pixels in the 320x192x16 color mode.

 

It's actually pretty easy to do... While in HSCREEN 2 (320x200x16) you feed the routine the X and Y values for to point you want to set.

(Bear in miind, this isn't standard CoCo BASIC, I'm using BASIC style statements just to show the flow.)

 

The actual Extended Color Basic code appears below this explanation, and can be typed in and ran on a CoCo 3. It asks for an x and y value (0 to 319 for x, 0 to 191 for y), and then it turns on the high resolution screen and sets the point, after pressing any key, it displays the calculated location, bank number, bank offset, and which pixel was set (either left or right) $10 means left, $01 means right.

 

So... to get started:

 

LOCATION = Y * 160

This gets you to the horizontal row you need

 

LOCATION =LOCATION + INT (X)/2

This gets you to the location.

 

At this point, you have the location within the entire 32K range that you

would write to if you were not bank switching, so we still need to calculate that.

 

BANK_NUMBER = INT(LO/8192)

Any value from 0 to 8K will return a zero, which is the bank we want to write to.

Any value from 8192 to 16383 will return a 1, 16384 to 24575 a 2, and 24576

to 32768 will return a 3.

The high resolution screens start at $60000 in the 512K memory range.

 

Both the 128K and 512K map to the last 8 8K banks, so the address range is the same

for either 128K or 512K Color Computer 3s. In other words, 128k CoCos are missing the

lower 384k of memory, not the upper. If you load an MMU register with the value $30, that

offsets you to $60000 where the HSCREEN memory starts, so we need to add $30 to our

bank offset so we can set the proper value to the MMU register to bank in the proper bank.

I'm using MMU register $FFA2 (MMU range is $FFA0-$FFA7 and $FFA8-FFAF (2 sets).

$FFA0 contains the zero page and low res text display video RAM, so I'm using $FFA2

which covers the range $4000 thru $5FFF. This is the range you'll write to when the

proper bank is active. Since the video memory for the high resolution screen starts at

$60000, if we divide that by 8K (8192 or $2000) we get a value of decimal 48, or $30 hex.

Therfore, we need to add that to the calculated bank number

 

BANK_NUMBER=BANK_NUMBER + $30

We now have the proper bank to activate (either $30,$31,$32 or $33) Those

values represent the 4 8K chunks from $60000 to $67FFF.

 

Ok, now, we need to know what offset within the 8K range to write to. If you're writing

to the first 8K chunk, then the offset is zero, and we can simply write to the

LOCATION value we calculated earlier, otherwise, if the bank number is 1, 2 or 3,

then we need to adjust the bank offset so that our location falls within the range values of

$0000 - $1FFF, then add $4000 to that so we point to the logical address that we

need to write to therefore:

 

IF BANK_NUMBER = 0 THEN BANK_OFFSET = LOCATION

IF BANK_NUMBER = 1 THEN BANK_OFFSET = LOCATION-8192

IF BANK_NUMBER = 2 THEN BANK_OFFSET = LOCATION-16384

IF BANK_NUMBER = 3 THEN BANK_OFFSET = LOCATION-24576

BANK_OFFSET = BANK_OFFSET + $4000

 

We're almost ready to write the pixel, but we still need to know if you're

setting the left or right pixel within the byte. All of the left pixels are even

addresses, and right are odd... therefore:

 

VALUE=X/2

IF VALUE = INT(VALUE) THEN POINT=$10 ELSE POINT=$01

 

This calculates X/2, and if it's even, then it will equal the integer of

VALUE, and set POINT to $10 (setting left dot) or if it's odd, $10

(setting right dot). At this point we now have everything we need.

The location that needs to be written to (BANK_OFFSET), and

know if we're setting the left or right pixel at that location (POINT).

We also know what bank to have activated (BANK_NUMBER), so

all that's left is to do it.

 

Ok, we're ready to write so we need to activate the bank and perform our write!!!

First, save the value in the MMU register, then bank in our bank...

 

TEMP = PEEK($FFA2)

POKE $FFA2,BANK_NUMBER

This saves what's already in $FFA2, and then banks in the 8K chunk of video

RAM into $4000-$5FFF which is addressable space we can reach with the 6809.

 

POKE BANK_OFFSET, POINT

POKE $FFA2,TEMP

Store point to bank offset, then restore MMU, and...

 

That's it!! We've converted an X,Y input to what needs to be done to write it via

machine code, all that's left is to code it in machine language... I'll post that when

it's up and working and ready.

 

Under normal circumstances, you would OR values into memory so as not to disturb the

other pixel, and any value 0 thru F will select the corresponding color pallete, and

whatever color is in that palette will be displayed. Also, any blitter you many write can

set both dots to any of the 16 palette values at the same time. I did it this way just for

demonstration purposes.

 

Here's the ECB code, you can type this in and run on a CoCo 3

 

10 PALETTE 0,0:PALETTE 1,63:PALETTE 8,63:WIDTH 80

20 CLS 1

30 INPUT "X,Y";X,Y

40 HSCREEN 2

50 LO=Y * 160

60 LO=LO+INT(X/2)

70 BN=INT(LO/8192)

80 IF BN=0 THEN BO=LO

90 IF BN=1 THEN BO=LO-8192

100 IF BN=2 THEN BO=LO-16384

110 IF BN=3 THEN BO=LO-24576

120 BN=BN+&H30

130 VA=X/2

140 IF VA=INT(VA) THEN PT=&H10 ELSE PT=&H01

150 TP=PEEK(&HFFA2)

160 POKE &HFFA2,BN

170 POKE BO+$4000,PT

180 POKE &HFFA2,TP

190 SOUND 200,1

200 A$=INKEY$:IF A$="" THEN 200

210 PRINT "LOC:";HEX$(LO);", BANK NO;";HEX$(BN);", BANK OFFSET:";HEX$(BO);", POINT:",HEX$(PT)

220 HSCREEN 0

230 GOTO 30

 

As far as BASIC is concerned, this is a drawn out way of doing this since CoCo3 BASIC includes HSET(x,y,c) and HRESET(x,y) to turn pixels on

and off, but because it works, it demonstrates I'm calculating all the proper things I would need to do from assembly language. I'll post the ASM

code when I'm done with that for anyone interested in seeing it. It actually took a bit of work to flesh all this out, but once done, it's actually

pretty simple as was stated earlier... an annoyance, once it's boiled down to it's constituent parts.

 

 

 

 

[MarkO]

I don't think that was a limitation on the original design.

I would guess it is related to Available Memory..

 

MarkO

[MarkO]

All of the MMU control registers and Video mode registers are reachable via EDTASM+, you can control what mode, 2 or 3, any one of 22 graphics modes (both old and new), and you have up to 64 8k banks, any 8 of which can be active. As long as you don't bank out the bank your code is running in, you're fine.

If you think of Modern Development Systems, that contain Libraries or Modules, it could happen that the older versions don't support a newer feature..

 

I concur that a Strict Assembler, it won't matter.. EDTASM+ won't support the Hitachi 6309, unless you get the Patch from Robert Gault.

 

MarkO

[MarkO]

<< SNIP >>

 

Also, all video modes can define where video ram is, so with a few pokes, you can create page, make a few pokes to point the video there, then work on buffer 2, when done, flip the video ram there and go back to buffer 1 and modify that while buffer 2 is displayed.

That is a very cool feature of the CoCo. Is the Video RAM configurable in all the Models, or just the CoCo 3 with the GIME???

 

 

MarkO

[MarkO]

He was talking about the mythical hidden 256 color mode which was accessed differently than other modes.

Yes, I was....

 

It would require more hardware to treat it differently so I would tend to agree that it could be paged but there is no guarantee.

Since nobody has ever actually got it to work I don't think we can assume exactly how it works if it's even in there.

Maybe it will take X-Raying the GIME to follow all the Gates and see where the Hidden Mode is....

 

Paging video RAM isn't that difficult, I'd say it's more of an annoyance.

Anyone that has displayed anything on an Apple II screen in assembly will consider paged video RAM to be easy.

Page flipping is the Old Standard to get Nice, Smooth animation on the Apple ][.. Flapple Bird is using the Vertical Blanking to get Nice, Fast, Smooth animation..

 

The font routine I wrote for the VZ series (modded to use hi-res) only has to deal with 2K pages but it's the same principal.

The CoCo 3 MMU is slightly more involved but nothing horrible.

 

The biggest complaint I have is that it's less efficient for drawing sprites, lines, circles, etc...

What is Less Efficient?? Page Flipping?? or the CoCo 3 MMU???

 

MarkO

[JamesD]

...

 

What is Less Efficient?? Page Flipping?? or the CoCo 3 MMU???

 

MarkO

Page Flipping when video RAM crosses multiple pages.

 

You can speed up line drawing by drawing the line from both ends. I did this in the MC-10 line routine I wrote.

It reduces the number of passes through the loop and tests required.

When you have to page video RAM, you have to calculate the page before drawing a pixel.

With a little creativity you only have to set the page when you cross a page boundary but you can't do that and draw from both ends since there is no guarantee they are on the same page.

Circles can be drawn multiple points at a time and you have the same problem.

 

For the font routine I only had to set the page before I started drawing on a line of text because the virtual 64x24 text screen doesn't have characters crossing a page boundary. There are 8 lines per page. Scrolling was the only time I had to constantly flip pages and even that was only when scrolling a line of text from one page to another. If I had to set the page before drawing each line of a character it would be very slow and it would actually be faster to draw the entire text string a line at a time rather than a character at a time.

Edited July 5, 2014 by JamesD

[Charlie_]

I just won an Auction for a FD-500 with J&M Systems Disk Controller, ....

MarkO

 

That is a nice disk system. The drive in that fd-500 case is a single sided drive. Fine for RS-DOS games and programs but you'll want to replace it with a DSDD 360K drive if you start using OS/9 - Nitros9.