Jump to content

Photo

ASM Development Tools for the Coco3

CoCo 3 ASM Programming Tools

84 replies to this topic

#76 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Fri Jul 11, 2014 12:14 AM

I just meant the alternate bit patterns for blue and red, not PMODE 3.  But yeah, most games from the U.S.A. used RG6 artifacting.
It was a PITA some times when the 6847 didn't want to change.  Nothing more frustrating than hitting reset over a dozen times.

Yeah, which is why the fixed it on the coco 3 and forced it to sync 1 way, and the other by holding down f1, but realistically, reset never had to be hit if you just painted a box and asked what color it was....lol



#77 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 12:26 AM

Ok, went back and looked, and Yes, popeye does it, it displays a screen and says press enter if the screen is red, clear if it is blue, then the game starts... no resetting...

 

There was also one other game, I forget, but it displayed a flag, and had you hit the spacebar until it looked right, then you'd continue on from there... so 2 games used the non-reset method, thousands of others didnt...

 

Popeye also puts the black mask around the sprites as you stated to prevent bleed.

Great game.
Yeah, as long as you have that masked border and don't use a lot of complex artifacting for your sprites you can get away with it but your code and graphics data may have to be different for the two bit pattern options.  Boundaries may change and hard coded sprites would have to change as well.
 

One thing to remember about artifacting is that not all emulators get it right.  

I think the only emulator that emulated 6847 NTSC artifacting accurately is M.E.S.S.

 

Yeah, which is why the fixed it on the coco 3 and forced it to sync 1 way, and the other by holding down f1, but realistically, reset never had to be hit if you just painted a box and asked what color it was....lol

The author of Popeye was also the author of Donkey King (The King) if I remember right and he seemed a bit more ambitious at pushing the machine to it's limits and didn't worry about fitting his games in 16K so that may explain why he was able to support it.
 



#78 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 1:07 AM

...
10 PMODE 4,1:PCLS:SCREEN 1,1
20 FOR X=0 TO 255
30 LINE(X,0)-(X,191),PSETl
40 FOR DL=1 TO 200;NEXT DL
50 LINE(X,0)-(X,191),PRESET
60 NEXT X
 
According to you, this should produce a vertical white line marching across the screen from left to right.  In reality, it will produce a line alternating between red and blue each time it moves.

Huh? That's not what I said at all. I drew lines (boxes) two pixels wide so that they were white.

A more appropriate example for what I was saying would be a marching white line:
10 PMODE 4,1:PCLS:SCREEN 1,1
20 FOR X=1 TO 254
30 LINE(X,0)-(X+1,191),PSET,BF
50 LINE(X-1,0)-(X-1,191),PRESET
40 FOR DL=1 TO 200;NEXT DL
60 NEXT X

Notice like 30 draws boxes 2 pixels wide like my example and line 50 erases a vertical line after the next is draw so the line never changes from white.

If you change line 20 to read:
20 FOR X=0 to 255 step 2
 
Then the program will produce a consistently colored line of either red or blue... let's say it's producing red... then, if you change line 20 once again to read:
20 FOR X=1 to 255 Step 2
 
It will then produce a blue line instead, that's because we're offsetting on odd lines instead of even lines.  To produce a vertical white line, you need to set two rows next to one another to produce white.
...
Let's go back to your first example.
00011000
 
This should produce black, red (or blue), blue (or red), then black, but... you have two 1's butting up against one another, so that pattern repeated vertically would produce a white line.


From my post:

In both cases you should just have a white vertical line.


YOU however stated this:

....
Your example 11100000 would produce 4 horizontal dots white (11), red or blue depending on color sync (10), black (00) and black (00)
after your "bit shift", and I use that term loosely because a bit shift shifts all bits left or right and any exiting bit gets written to the carry flag, but anyways, let's say you changed it to 11010000 for whatever reason... the result would be white (11), the second dot would be the opposite of the 2nd dot in the above example, in other words, let's say 10 in the above example is producing red, then here, the second dot would be blue (01), followed by black (00) and black (00)
...


You completely changed what you were saying and are trying to twist what I said!

#79 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 1:13 AM

First off...
I'm guessing you meant the Sands of Egypt picture, and if so, then there's nothing wrong with it to correct.  The sky is blue, the sand is red, it is as was intended by the author(s).  I imagine what you meant was, how would you correct the image if the red/blue were reversed, and the sky was red and the sand was blue.
...

But places where red and blue are next to each other you will end up with white.

#80 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 1:15 AM

And on top of that, I now have a bad RAM chip in my TDP-100.
I need a beer.

#81 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Fri Jul 11, 2014 12:09 PM

No, the little program I wrote was to demonstrate that a single line (with black on either side) will be one color on even lines, and the other on odd... As far as sands of Egypt is concerned, I thought you meant if it came up with reverse colors, not white lines produced by red and blue butting up against one another.  Yeah, I totally agree that two lines together will produce a white line.  I think we're more in agreement with each other, it's just that we're misunderstanding each other.

 

Ok, off artifacting and onto your TDP-100.  I seem to remember the TDP-100, but my memory is fuzzy in that area.  I looked up some pics online, and it looks like a coco 2 case design in the shape of a CoCo 1.  I worked for Radio Shack back in the day, and I do remember when the CoCo 2 was released, and I remember the very last CoCo 1's off the line were white, but had the old case design with the vent holes on the left and right sides.  The pictures I'm seeing of the TDP-100 have vent holes running all the way across the unit, like the CoCo 2 and 3 design had.  Strange, I don't recall that, but I do recall "TDP-100".

In any case, sorry to hear you have a bad ram chip.  Considering they're 64K chips though, I imagine they're pretty cheap to replace.  Hope your soldering skills are up to snuff !!



#82 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 1:19 PM

No, the little program I wrote was to demonstrate that a single line (with black on either side) will be one color on even lines, and the other on odd... As far as sands of Egypt is concerned, I thought you meant if it came up with reverse colors, not white lines produced by red and blue butting up against one another.  Yeah, I totally agree that two lines together will produce a white line.  I think we're more in agreement with each other, it's just that we're misunderstanding each other.

I know what you wrote. I was just responding to what you said I said.
My whole binary bit pattern thing was to explain it's not as simple as 00, 01, 10 and 11 on even bit boundaries for 4 colors. I intentionally placed 01 and 10 as well as 11 10 next to each other to point out that red + blue can equal white.

We are on the same page now though.

 

Ok, off artifacting and onto your TDP-100.  I seem to remember the TDP-100, but my memory is fuzzy in that area.  I looked up some pics online, and it looks like a coco 2 case design in the shape of a CoCo 1.  I worked for Radio Shack back in the day, and I do remember when the CoCo 2 was released, and I remember the very last CoCo 1's off the line were white, but had the old case design with the vent holes on the left and right sides.  The pictures I'm seeing of the TDP-100 have vent holes running all the way across the unit, like the CoCo 2 and 3 design had.  Strange, I don't recall that, but I do recall "TDP-100".
In any case, sorry to hear you have a bad ram chip.  Considering they're 64K chips though, I imagine they're pretty cheap to replace.  Hope your soldering skills are up to snuff !!

Yeah, the TDP-100 was a Tandy attempt to penetrate regular retail stores so it never sold at Radio Shack. If it had offered something new capability wise they might have had a chance but without something more competitive the whole thing was a flop. I think the only places that carried it were mail order houses that had already been selling CoCos on the sly.
Nice machine though, it was the first CoCo with the top vents that ended up on the CoCo 2/3.
I have an upgraded keyboard on it.

FWIW, the RAM is still socketed on the TDP-100 so no soldering needed though I have had a lot of practice.

Edited by JamesD, Fri Jul 11, 2014 1:20 PM.


#83 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Fri Jul 11, 2014 1:25 PM

Ok, did a bit of research, and my memory hasn't failed me yet... The TDP-100 was distributed by RCA in non-Tandy stores.  Basically it was (originally) a CoCo 1 motherboard in a case that that the CoCo 2/3 case is obviously based upon with the vent holes running the length of the case.  I was correct though... towards the very end of the original CoCo 1, they were white, and had the version 1 CoCo 2 keyboard, an improvement over the Chiclet style keyboard, before the improved keyboard found on later CoCo 2's, and modified with control/alt/f1/f2 keys added for the CoCo 3.  Here's a pic of the late model CoCo 1...

 

 

Attached Thumbnails

  • 1024px-TRS-80_Color_Computer_1-white_case.jpg


#84 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,482 posts
  • Location:Flyover State

Posted Fri Jul 11, 2014 2:59 PM

I have a white CoCo 1 I need to fix as well.

#85 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Fri Jul 11, 2014 10:48 PM

Yeah, well, it's inevitable to happen, these units were well constructed, and alot of them have faired really well throughout the years.  Cool thing is people have worked out FPGA's for CoCo, so regardless, CoCos can live on through programmable hardware







Also tagged with one or more of these keywords: CoCo 3, ASM, Programming, Tools

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users