Jump to content

Photo

ASM Development Tools for the Coco3

CoCo 3 ASM Programming Tools

84 replies to this topic

#51 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Sat Jul 5, 2014 7:21 AM

 

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.

Or add a 3.5" drive like I did.



#52 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Sat Jul 5, 2014 9:59 AM

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

 

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

Yes, it's done via the vertical offset registers $FF9D and $FF9E.  Works on all CoCos, although it's a bit more work because on CoCo 1 and 2 you're only working with a 64k address space, with the CoCo 3, you have more memory, so it's a combination of using $FF9d and FF9E and another register that I don't recall at the moment, but it's totally possible to do on all CoCos.



#53 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Sat Jul 5, 2014 10:14 AM

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

It was Tandy management put the kibosh on the 256 color mode.  They were implementing the 256 color mode when Tandy made it clear they didn't want a 320x200x256 color mode because they feared it would have killed the sales of Tandy 1000's, their first PC clones, which had EGA graphics (320x200x256).  I think what happened was they had got so far as to have the mode working internally in the chip, but because Tandy didn't allow the 256 color mode, they never finished implementing access to the mode.  In other words, it never was tied to a memory location so the mode could be controlled.  That's why to activate the mode you had to do goofy non standard sort of stuff to cheat the chip into that mode.  I think that if they finished the mode they would have likely tied it to $FF96 or $FF97 (or a combination of both) as those locations were, (and still are) unused locations, and the video mode register is at $FF98, so it would have been the logical place to implement control of the 256 color mode.  Instead, while they were working on it, there was a way to activate the mode, but it involved triggering it during a specific interrupt, and you had to do it within a certain page in upper memory to get it to work.  If they would have been able to finish the mode, it would have been controllable via a register similar to other modes.  What it boils down to is that it's only 1/2 implemented.  



#54 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Sat Jul 5, 2014 10:22 AM

Or add a 3.5" drive like I did.

Yep, as a matter of fact, When 3.5" drives first came out, the very first computer it was sold for was the Color Computer.  My buddy bought one, and it was a nice upgrade, even though I believe it was single sided (720k).  At the time, 5 1/4" floppies were the industry standard, and although we could see that they outperformed 5 1/4" drives, and had smaller disks that were in a hard case, we thought it would be difficult for them to displace 5 1/4" drives because they were so ubiquitous.  Ultimately though they did.



#55 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Sun Jul 6, 2014 5:12 AM

It was Tandy management put the kibosh on the 256 color mode.  They were implementing the 256 color mode when Tandy made it clear they didn't want a 320x200x256 color mode because they feared it would have killed the sales of Tandy 1000's, their first PC clones, which had EGA graphics (320x200x256).  I think what happened was they had got so far as to have the mode working internally in the chip, but because Tandy didn't allow the 256 color mode, they never finished implementing access to the mode.  In other words, it never was tied to a memory location so the mode could be controlled.  That's why to activate the mode you had to do goofy non standard sort of stuff to cheat the chip into that mode.  I think that if they finished the mode they would have likely tied it to $FF96 or $FF97 (or a combination of both) as those locations were, (and still are) unused locations, and the video mode register is at $FF98, so it would have been the logical place to implement control of the 256 color mode.  Instead, while they were working on it, there was a way to activate the mode, but it involved triggering it during a specific interrupt, and you had to do it within a certain page in upper memory to get it to work.  If they would have been able to finish the mode, it would have been controllable via a register similar to other modes.  What it boils down to is that it's only 1/2 implemented.  

Frankly, it would require more hardware to implement the 256 color mode if they made access too complex so I doubt it's more than a few AND gates and accessing some address to enable the alternate palette lookup for the DAC.  An "unused" address would be a good choice for the enable signal.
I have to wonder if it even made it from the prototype to the GIME.  The engineer's story about it was a bit sketchy. 
 



#56 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Sun Jul 6, 2014 11:11 AM

Yeah, it is.. but he did say "did you find the 256 color mode" which indicates to me that it is there, what I seem to glean from it is that they had worked out the 256 color mode internally in the chip, but were shut down on implementing it any further.  In other words, they were at the point where they were able to cheat the chip into the mode by doing something specific within a certain page during an interrupt, but they never got to the point where they tied the mode on the chip to a control register and assigning certain bit(s) within that register to enable the mode.



#57 MarkO OFFLINE  

MarkO

    Dragonstomper

  • Topic Starter
  • 920 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Tue Jul 8, 2014 11:16 PM

<< REAL BIG SNIP >>
 
 
170 POKE BO+$4000,PT
 
<< SNIP >>

 
 
I typed this into my  CoCo3, with the 26-3022 and FD-500 plugged into it...  I keep getting an Error on line 170..  I tried to change it to:
 

170 POKE BO+&H4000,PT


But it still didn't like it...

Any Suggestions???

MarkO

Edited by MarkO, Tue Jul 8, 2014 11:18 PM.


#58 MarkO OFFLINE  

MarkO

    Dragonstomper

  • Topic Starter
  • 920 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Tue Jul 8, 2014 11:24 PM

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.


Just recently I got a 26-3022 Disk Controller, that I modified with the Fujitsu MB8877A chip and a FD-500 with very little use on it..  I figured I could move the Single drive from this FD-500 with the J&M Systems Controller into the first FD-500, then get a Pair of Double Sided Drives to Put in the new FD-500..  Then I would have a Drive for each CoCo I have..

 

Do you know much about the J&M Systems Disk Controller??  I have seen comments about it being not compatible with various Applications and it formats the Disks Differently...

 

MarkO



#59 MarkO OFFLINE  

MarkO

    Dragonstomper

  • Topic Starter
  • 920 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Tue Jul 8, 2014 11:26 PM

Or add a 3.5" drive like I did.

 

Is there any particular Disk Controller that works with the 3.5", 720K Disks???

 

MarkO



#60 Charlie_ OFFLINE  

Charlie_

    River Patroller

  • 2,905 posts
  • Location:NJ, USA

Posted Wed Jul 9, 2014 6:52 AM

Just recently I got a 26-3022 Disk Controller, that I modified with the Fujitsu MB8877A chip and a FD-500 with very little use on it..  I figured I could move the Single drive from this FD-500 with the J&M Systems Controller into the first FD-500, then get a Pair of Double Sided Drives to Put in the new FD-500..  Then I would have a Drive for each CoCo I have..

 

Do you know much about the J&M Systems Disk Controller??  I have seen comments about it being not compatible with various Applications and it formats the Disks Differently...

 

MarkO

Maybe you found this already? Bing turned up this page on COCOpedia:

http://www.cocopedia...hp/J&M/Owl-Ware



#61 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Wed Jul 9, 2014 9:29 AM

 
 
I typed this into my  CoCo3, with the 26-3022 and FD-500 plugged into it...  I keep getting an Error on line 170..  I tried to change it to:
 

But it still didn't like it...

Any Suggestions???

MarkO

Yeah, opps on that I goofed with the $ instead of the &H on that line, it should read as you corrected it...

 

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+&H4000,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

 

The only thing I could imagine is that you're possibly typing B(ZERO) instead of B(Oh)?  BO stands for block offset, and it's the point within the block you need to be poking the Point variable to.  Try typing 170 and pressing enter, that will delete the line, then retype it.  Sometimes when you're working in the editor you can wind up with a non printable character in the edited line, try retyping the entire line (with your correction.. &H in place of $).  It should work on any CoCo 3 128k or 512k with or without a disk system.   I posted the corrected code above... another thing to consider is that in the previous line, I'm switching out the block that's normally there, then poking in the value (because $4000-$5FFF is now mapped to the area in memory that is the high resolution screen HSCREEN 2), then it's putting the original value back to swap back in the block that's normally there, so an error in line 170 is going to leave the block swapped out.  The program as written was working fine using the MESS emulator, and should work fine on any CoCo 3 configuration.  I'm not really doing anything special, so it should work on a real CoCo 3.


Edited by John_L, Wed Jul 9, 2014 9:35 AM.


#62 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Wed Jul 9, 2014 10:49 AM

 

Is there any particular Disk Controller that works with the 3.5", 720K Disks???

 

MarkO

I know nothing about the J&M controller, sorry no help there, but as far as other disks go.  I do recall seeing some pokes that could be done to the disk controller to enable the use of double sided, 40 track drives....

 

Found it:

For Disk Basic 1.0:

 

10 POKE 243,&HCC:POKE 244,&H41:POKE 245,&H42:POKE 246,&HFD

20 POKE 247,&HD7:POKE 248,&HAC:POKE 249,57

30 EXEC 243

 

Allows the use of double sided disk drives for Disk Basic 1.0.  Drive 2 becomes the other side of drive 0, Drive 3 becomes the other side of Drive 1.

 

For Disk Basic 1.1

10 POKE 243,&HCC:POKE 244,&H41:POKE 245,&H42:POKE 246,&HFD:POKE 247,&HD8

20 POKE 248,&H9F:POKE 249,57:EXEC 243

 

Allows the use of double sided disk drives for Disk Basic 1.1.  Drive 2 becomes the other side of drive 0, Drive 3 becomes the other side of Drive 1.

 

The original TEAC drives used on the earliest CoCos were 35 track, single sided, single density, so Disk basic was designed around those specs.  A short time later, single density drives were replaced with 40 track double density double sided drives because single density drives were no longer being made.  Single density is 256 bytes per second, double is 512, so...

 

35 tracks x 18 sectors x 256 bytes / sector = 157K per disk.

 

After doing the pokes, disk basic is setup for double sided operation, but...

 

40 tracks x 18 sectors x 512 bytes / sector = 360k per disk.  Bear in mind the above pokes assign drives 1 and 3 to the other side of 0 and 2, so the disks are not one volume, they're essentially 2 separate disks, each stored on one side of a physical disk.

 

The patches needed for 40 track drives:

 

POKE 50952,78

Patches KILL command for 40 track drives - Disk Basic 1.0

 

POKE 50986,84:POKE 51083,78

Patches the File Allocation Table (FAT) for 40 track drives - Disk Basic 1.0

 

POKE 51104,78:POKE 51135, 78:POKE 52300,78

Patches the GAT for 40 track drives - Disk Basic 1.0

 

POKE 52697,78

Patches the FREE command for 40 track drives - Disk Basic 1.0

 

POKE 53680,40

Patches the BACKUP command for 40 track drives - DIsk Basic 1.0

 

POKE 54111,78

Patches the COPY command for 40 track drives - Disk Basic 1.0

 

POKE 54342,39

Patches the DSKI$/DSKO$ command for 40 track drives - Disk Basic 1.0

 

POKE 54642,40:POKE 54677,40

Patches the DSKINI (format) command for 40 track drives - Disk Basic 1.0

 

FOR DISK BASIC 1.1

 

POKE 509997,78

Patches KILL command for 40 track drives - Disk Basic 1.1

 

POKE 51034,84:POKE 51131,78

Patches the File Allocation Table (FAT) for 40 track drives - Disk Basic 1.1

 

POKE 51183,78:POKE 51152, 78:POKE 52518,78

Patches the GAT for 40 track drives - Disk Basic 1.1

 

POKE 52917,78

Patches the FREE command for 40 track drives - Disk Basic 1.1

 

POKE 53917,40

Patches the BACKUP command for 40 track drives - DIsk Basic 1.1

 

POKE 54349,78

Patches the COPY command for 40 track drives - Disk Basic 1.1

 

POKE 54580,39

Patches the DSKI$/DSKO$ command for 40 track drives - Disk Basic 1.1

 

POKE 54879,40:POKE 54914,40

Patches the DSKINI (format) command for 40 track drives - Disk Basic 1.1

 

Interestingly, The Tandon disk drives could actually be pushed to 42 tracks, so if you added 2 to each value above for the 40 track patches, the drives would actually format and work 

with 42 tracks per side which works out to...

 

42 x 18 x 512 = 378K per drive.

 

I usually only patched my stuff to work with 40 track drives though, even though 42 tracks work, when it hit track 42 you could hear the head assembly bang up against the stop!

 

That's not the end of the story though...

 

Back when Tandy hired Microware to write the extensions for Extended Color Basic, Microware fought for, and won 8K worth of space to write the code instead of the 2k Tandy wanted them to put it in.  Tandy had also directed Microware to fill any unused space with garbage.  As it turns out, the additional functions added only took 2K, so Microware wound up with 6K of left over space over... so they decided the "garbage" they would load into the unused space would be a digital photo of themselves.  Also, a hook was inserted such that if you depress the control and alt keys at the same time, then reset the unit, the picture will be displayed.... try it!  

 

Another thing to know about the CoCo3 if you're new to it is that the original CoCo 1 and 2 would sync to either the rising or falling  edge of the color signal, and many CoCo games took advantage of the artifacting to raise the 2 color black and white mode to 4 colors (red and blue).  The thing is, if you wrote your game while the sync was one way, if on another boot it synced the other way, the red/blue would reverse to blue/red.  This is why you see messages at the beginning of games telling you to hit reset until a specific box was either red or blue.  It was common to have to hit reset 3 or 4 times to get the signal to sync to the other edge.  Just about every game does this, and the weird thing is that to maintain the red or blue color, you had to skip ever other bit, otherwise the color would flip flop red/blue/red/blue.  Programmers knew this, so when they moved objects, they did so 2 bits at a time, and games worked great.  Funny thing is, instead of hitting reset over and over, all they needed to do was display a box, ask if it was red or blue, and if they wanted red, and it was blue, all they needed to do was change their blitter routines to shift over one bit and it would "fix" without having to reset the machine.  Despite this, most games tell you to hit reset until the color of the box changes.  With the CoCo 3, they fixed this issue and the CoCo always synced (one way or the other), and to get it to sync the other way, you HOLD DOWN F1 while resetting and it'll switch on the first reset.

 

The "Mugs" Easter egg in the CoCo 3 came out literally days after the release of the CoCo 3, and they were already shipped, so there wasn't much Tandy could do, and they never bothered to remove it throughout the entire run of the CoCo 3.  What this does is give us roughly 6K of space for 3rd party modifications, one of the best ones is called HDB-DOS.  When combined with a controller like Cloud 9's Super IDE controller, you can store on either a regular PC hard drive, or use the SD card slot in the side to store to SD cards.  HDB-DOS is an extension (that uses that extra 6K where the photo was) that adds alot of functionality to RS-DOS, enables HD support for both RS-DOS and OS9.  When using HDB-DOS and the RS-DOS extension, instead of 4 drives, you have 256 drives (0 thru 255), each one a 35 track single density drive, all stored on your hard drive or SD card.  If you're looking at controllers, the Super IDE is the one to get.

 

 

Attached Thumbnails

  • CoCo3_Easter_Egg.png

Edited by John_L, Wed Jul 9, 2014 10:55 AM.


#63 MarkO OFFLINE  

MarkO

    Dragonstomper

  • Topic Starter
  • 920 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Wed Jul 9, 2014 12:14 PM

Maybe you found this already? Bing turned up this page on COCOpedia:
http://www.cocopedia...hp/J&M/Owl-Ware


Excellent!!! I haven't seen this page yet....

The Picture of the J&M Box in my auction, doesn't look like it has a Switch, so it must be the JFD-COCO model.. But appears to have the RS-DOS 1.1 ROMs because of the Message, "DISK EXTENDED COLOR BASIC 1.1"

MarkO

#64 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Wed Jul 9, 2014 1:13 PM

...

Another thing to know about the CoCo3 if you're new to it is that the original CoCo 1 and 2 would sync to either the rising or falling  edge of the color signal, and many CoCo games took advantage of the artifacting to raise the 2 color black and white mode to 4 colors (red and blue).  The thing is, if you wrote your game while the sync was one way, if on another boot it synced the other way, the red/blue would reverse to blue/red.  This is why you see messages at the beginning of games telling you to hit reset until a specific box was either red or blue.  It was common to have to hit reset 3 or 4 times to get the signal to sync to the other edge.  Just about every game does this, and the weird thing is that to maintain the red or blue color, you had to skip ever other bit, otherwise the color would flip flop red/blue/red/blue.  Programmers knew this, so when they moved objects, they did so 2 bits at a time, and games worked great.  Funny thing is, instead of hitting reset over and over, all they needed to do was display a box, ask if it was red or blue, and if they wanted red, and it was blue, all they needed to do was change their blitter routines to shift over one bit and it would "fix" without having to reset the machine.  Despite this, most games tell you to hit reset until the color of the box changes.  With the CoCo 3, they fixed this issue and the CoCo always synced (one way or the other), and to get it to sync the other way, you HOLD DOWN F1 while resetting and it'll switch on the first reset.

...

 

The problem with your idea is that you can't just shift sprite bits and expect the images to look as intended.  
Sprites may be made up of red, white and blue and involve masking the background.  Simply shifting the bits would mess up the image.
It can also mess up more complex artifacting that uses more colors.
On top of that, to draw faster, many sprites are hard coded.
Sure, a programmer could create an alternate set of graphics and/or code but when you are trying to squeeze a game in 16K to begin with it's often not practical.
Remember, 6K out of 16K goes to graphics and that's if you don't double buffer.  On top of that, some RAM must be preserved if you want to play nice with the OS.
Hitting reset in a simple loop was annoying but it worked.



#65 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Wed Jul 9, 2014 3:21 PM

10 PMODE 4,1;PCLS;SCREEN 1,1

20 LINE(10,10)-(20,20),PSET,B

30 LINE(25,10)-(35,20),PSET,BF

40 FOR X=40 TO 50 STEP 2

50 LINE(X,10)-(X,20),PSET

60 NEXT X

70 FOR X=55 TO 65 STEP 2

80 LINE(X,10)-(X,20),PSET

90 NEXT X

100 GOTO 100

 

If you run this program, you'll see 4 boxes, 1 black, 1 white, one red and one blue, or one blue and one red, depending on the color sync to the clock.  As you can see lines 50 and 80 are identical except for the values being used.  Line 50 uses even numbers, line 80, odd.  The computer wasn't built to do this, it was an artifacting effect caused by using TVs as computer monitors, and while every computer or video game that connects to a TV or composite monitor has this effect, it was used heavily by the CoCo community because the highest resolution mode had but 2 colors, and this "trick" doubled it to 4.  Now, to animate the red and blue boxes about the screen, you have to shift on even or odd lines to maintain the red or blue color.  Therefore all the games that used this trick did that.  Try changing line 40 to read FOR X=41 TO 51 STEP 2, and whatever color you saw before will flip to the other color.  I wasn't speculating about anything... I know factually this is how it was done, I've done it myself, and it was a very common practice in the Color Computer crowd.  This wasn't a 4 color mode it had only black and white.  Red and blue were generated by taking advantage of television artifacting, and by drawing vertical alternating stripes of black and white (for one color), white and black (for the other color).  The TV would fuse the black/white colors and artificially produce red or blue.  So, without ever resetting the machine, I could draw alternating white/black lines on an even row, and ask what color it was.  The user would choose red or blue, and whatever color they choose, I would assign all calls to draw that color with the white/black on even lines, and black/white on even lines for the other color, and never have to ask the user to reset the machine over and over again.   In other words, instead of forcing the machine into a state that agreed with the program, the program would simply ask one question, and adjust the program around the current machine state.  This didn't make coding any more or less difficult as once the colors are defined, the game would operate the same either way.

 

If you view any of these games on an CM-8 RGB monitor, the monitor didn't have artifacting, so you would see the program in black and white and more easily see how red and blue were cheated with vertical strips of black and white.

 

Look at the picture below... what looked like black/white/red/blue on a TV in reality is what was programmed below.

 

 

Also.. moving an object 2 pixels at a time didn't "mess anything up", and the color computer had no hardware sprites at all in any version of the Color computer, all sprites and blitter routines were software cpu driven.

Attached Thumbnails

  • pacsample.jpg

Edited by John_L, Wed Jul 9, 2014 3:49 PM.


#66 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Wed Jul 9, 2014 7:54 PM

John,
Everything I said was accurate.
This is a topic about assembly, not BASIC and I was talking about software sprites, not hardware sprites.
At no point did I suggest the CoCo had hardware sprites.
You are treating the RG6 graphics mode artifacts as if they work like CG6.  
The fact is, RG6 artifacts do not show up as only 4 colors unless you use a certain emulator.

Change this bit pattern 11100000 to 11010000 and swap the color timing and let me know if it looks identical on a real CoCo.  
The fact is that it doesn't because the white formed by the first two bits joins with the third bit in the first byte but not in the 2nd byte.

Artifact colors change when you mess with bit patterns if you use any complex artifacting and bit masking.

If you disagree, please show me how you would draw this image the way you suggest and have it look identical:
http://www.lcurtisbo...gypt_intro2.gif
 



#67 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Wed Jul 9, 2014 8:54 PM

Here's a screenshot from an emulator that doesn't support artifacting, and it shows EXACTLY what's done, and it supports what I'm saying, look closely, the blue areas have "black/white" and the red have "white/black".

 

 

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)

 

in the picture below... look at the vertical stripes of black and white, if you look closely, the areas that are red are the opposite of the areas that are blue.  They're both sets of vertical alternating black/white stripes, but a given vertical line that is white in the red area if you follow it straight up, it's black in that area that is blue, and same for the 2nd row.

 

As far as emulators go, some support artifacting (because games depend on it), and some don't because they've not got around to implementing it.  But forget emulators, I'm talking about a real CoCo, any model, connected to a TV or composite monitor will produce this effect, and properly display most games as they were designed.... see for yourself, Sands of Egypt was written by top CoCo coders, and what you see below represents what's in the CoCo's video buffer at that moment, and as you can see, it's all done with black and white pixels.  And you can see the "blue" area, the sky, is shifted left by 1 bit compared to the red areas.  Both areas are alternating vertical stripes, it's just that one is black/white, the other white black.

Attached Thumbnails

  • sands.jpg

Edited by John_L, Wed Jul 9, 2014 9:11 PM.


#68 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Thu Jul 10, 2014 9:07 AM

The problem with your idea is that you can't just shift sprite bits and expect the images to look as intended.  
Sprites may be made up of red, white and blue and involve masking the background.  Simply shifting the bits would mess up the image.
It can also mess up more complex artifacting that uses more colors.
On top of that, to draw faster, many sprites are hard coded.
Sure, a programmer could create an alternate set of graphics and/or code but when you are trying to squeeze a game in 16K to begin with it's often not practical.
Remember, 6K out of 16K goes to graphics and that's if you don't double buffer.  On top of that, some RAM must be preserved if you want to play nice with the OS.
Hitting reset in a simple loop was annoying but it worked.

I didn't intend to indicate that bit shifting was all that was needed.  Typically, since one could offset the display area to anywhere in RAM, it was typical to have 2 frame buffers, and you would construct one buffer while the other was displayed and flip flop the video RAM offset back and forth between the two buffers.  A background image would also be buffered as well, so when constructing a scene, one would copy the background buffer to the current frame buffer you're editing, and then OR the sprite(s) over the top of the background.



#69 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Thu Jul 10, 2014 9:13 AM

I notice you didn't present an algorithm that would correct that image.
Until you do, you are just trying to distract from my point.
 

I know how images appear in B&W on a CoCo.  
I had a monochrome monitor as a kid and a composite adapter for my CoCo with color and B&W outputs.
 

 

 

Your example 11100000 would produce 4 horizontal dots white (11), red or blue depending on color sync (10), black (00) and black (00)

0 PCLEAR 4

10 PMODE 4,1
20 PCLS

30 SCREEN 1,1

40 LINE(3,0)-(4,191),PSET,BF

50 GOTO 50

That is drawing a vertical column containing the following bits:
00011000

Now change line 40 to this, run it again and tell me what you see

40 LINE(3,0)-(5,191),PSET,BF


That is drawing a vertical column containing the following bits:
00011100

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

Artifacting in RG6 does not work exactly like CG6.
 



#70 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Thu Jul 10, 2014 10:27 PM

BTW, it may be possible to convert images like the Sands of Egypt with a lookup table and by using the rightmost bit(s) of the previous byte.
It could even be pretty fast.  But that doesn't include any changes that may be required to the animation code.

Here is an example why many games don't do what you suggest.
Suppose you have a game that involves a maze which has to be displayed fairly small.  Something like Radar Rat Race's small maze maybe.

You draw the walls in blue and you assume blue is binary 10.  Red is then 01.
You can draw blue next to blue, red next to blue or white next to blue as long as you don't invade the first 2 bits with whatever you place in the maze.
A blue dot in the maze might line up with the left wall as follows:
1010
Red next to the wall would be:
1001
White would be:
1011

If we swap bits as you suggest, this is what happens:
Blue dot:
0101
Red dot:
0110
White dot:
0111

Note that everywhere a 11 occurs, no matter what bit it starts on, it is white so the Red dot is no longer red and the wall turns white with both Red and White dots.
The simple solution is to leave two zero bits between the wall of the maze and the dots in it but then your map may show less of the maze.
In the case of a PacMan type of game, the ghosts and PacMan would have such a gap between the sprites and the walls.
This is why many sprites have a black border masked around them on the CoCo or Apple II.

It is also entirely possible that many programmers didn't support the alternate colors out of lazyness.
The reset until the screen is red worked and may have required less code.
Or maybe the programmer just didn't think of it after seeing how other people did it.


  • jhd likes this

#71 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Thu Jul 10, 2014 11:07 PM

I notice you didn't present an algorithm that would correct that image.
Until you do, you are just trying to distract from my point.
---------------------------------------------------------------------------------------------

0 PCLEAR 4

10 PMODE 4,1
20 PCLS

30 SCREEN 1,1

40 LINE(3,0)-(4,191),PSET,BF

50 GOTO 50

That is drawing a vertical column containing the following bits:
00011000

Now change line 40 to this, run it again and tell me what you see

40 LINE(3,0)-(5,191),PSET,BF


That is drawing a vertical column containing the following bits:
00011100

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

Artifacting in RG6 does not work exactly like CG6.
 

 

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.

 

Second, I never said anything about an algorithm to correct the image, all I stated was that by shifting each bit in the image left or right, it would correct the image.

 

Third, you stated that 00011100 should produce a white line, you're wrong.  I explained this before... I'll restate it again differently in the hopes you'll understand what I'm trying to convey.

 

In reality, the mode is black and white.  a 1 will produce a WHITE dot, and a 0 will produce a BLACK one.  However, due to artifacting a vertical row of 00010000 will not produce a white dot, it will be either red or blue due to artifacting

 

Let's pretend for a minute that we're working ONLY with the pixel at (0,0)

 

Now, PMODE 4 stores 8 horizontal black or white dots in one byte.  However, due to artifacting, a horizontal combination of a black pixel followed by a white pixel will produce an artifact color.  If black/white is producing red, then white/black will produce blue, but only at even locations, at odd locations, this would reverse.  You can prove this easily

 

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.

 

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.

 

Therefore, when you code using this mode and plan to code for artifacting, you have to think in terms of 2 horizontal bits per color, hence 8 bits per byte / 2 bits per dot equals 4 dots per byte.

 

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.

 

Your second example

00011100

Again, this should produce black, red (or blue), white, then black, but again, all your 1's are bunched up together, so you'll get a fatter white line.

 

When you're using this hack, you can't pack colors up against one another.  If you draw to boxes, one directly next to another, the colors will fuse and produce a white line where they meet.

 

Try typing in my program above and try the two edits, and you'll see I know what I'm talking about.

 

Yet again, as I stated before, you can run this on any color computer, any configuration as long as it is viewed on a TV or composite color monitor and it will work.  Vcc emulator doesn't support artifacting, so it'll be just black and white lines, MESS does support artifacting, so it will work under MESS or a real CoCo.  I actually wrote the above program and tested it with MESS.


  • jhd likes this

#72 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Thu Jul 10, 2014 11:12 PM

Your right, if Blue is 10 and red is 01, then you solve the issue by not letting anything (at all) get that close to anything else.  That's how the issue is solved.  You're correct that in the blue=10/red=01 situation that you could put a blue dot, then a white dot, and it would work, and red wouldn't but that's too much work, in reality, you just code it so that nothing butts up against anything else and the issue doesn't occur.

 

Also, the hack effectively halves your horizontal resolution because you're now using 2 bits per byte instead of 1.


Edited by John_L, Thu Jul 10, 2014 11:12 PM.


#73 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Thu Jul 10, 2014 11:24 PM

It is also entirely possible that many programmers didn't support the alternate colors out of lazyness.
The reset until the screen is red worked and may have required less code.
Or maybe the programmer just didn't think of it after seeing how other people did it.

The vast majority of commercial games made for the CoCo used PMODE 4 with the black/white color set to get the black/white/red/blue artifacting.

The reset until the screen is red DID work, but it involved resetting the CoCo over and over.

 

My solution is to draw a box with each horizontal line being 10101010, and starting on an even value for x, and then simply asking is the red or blue?  When the user would respond, you just assign 10 for the color they told you, and 01 for the other color, and since they told you if it was red or blue, you know 10101010 will produce blue as long as it's on an even value for x. and 01010101 will produce red (again, on even values for x).

 

In other words, the reset method works by forcing the user to change the machine state, where my method (well,not really mine, but I realize it), wouldn't care what the machine state was and simply figure out what configuration (10 or 01) produced what color, and assigned from there.  This would be easy to implement, and it's just something most coders didn't think of.  Every game I've ever seen except for one (Popeye, I think it was) had you bang reset until the machine conformed to the program rather than vice versa.  Both methods work, but one prevents you from clicking the reset relay over and over until the machine gave in and flipped sync.



#74 John_L OFFLINE  

John_L

    Chopper Commander

  • 204 posts

Posted Thu Jul 10, 2014 11:29 PM

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.


Edited by John_L, Thu Jul 10, 2014 11:33 PM.


#75 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,483 posts
  • Location:Flyover State

Posted Thu Jul 10, 2014 11:59 PM

The vast majority of commercial games made for the CoCo used PMODE 4 with the black/white color set to get the black/white/red/blue artifacting.

The reset until the screen is red DID work, but it involved resetting the CoCo over and over.

...

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.







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