briza

Hi guys. Yeah I agree with Atarileaf. The Disk drive setup will garner most attention etc. Plus the Printer parallel pack will also fetch some good money. If you were here in Aus. The coco 3 unit would get a good price as with the NTSC 256 color artifact mode is something Pal units do not have. But what I'm more interested in knowing is what is on the 3 stacks off floppy disks mentioned. I'm hoping it contains some games I'm after. I do think it was a good find at the thrifty shop well done Midnight Synergy. Shame you are not interested in playing around with it mate. You may end up liking the untapped potential in the coco 3. laters Briza

Tempest, Now you have the cable correct. pull the cable off the fdc and use a rubber erazor and clean the connections in the FDC. If this fails. pull the FDC apart and check if the Disk prom is properly seated in the socket, maybe this could use a clean up as well. laters Briza

G'Day Tempest. Sounds like your Floppy drive and FDC are fine mate. Sounds to me like the Ribbon cable is back to front, Check to see if pin 1 is Pin 1 etc thru to 34. What you describe is what happens if the cable is not pin for pin from the FDC to the Floppy drives. Check this and you may find it will work no probs. laters Briza

Herbarius: as JamesD replied I 'hand-converted' the music, so basically *any* SID could be played but only by working for hours converting notes, frequency, instruments, etc. Note that CocoSID was mainly designed to mimic Rob Hubbard musics, and might not be well suited for some complex or weird SID. Also important to note that some feature of SID are not supported at all, so music containing "digital samples" or other funky modulation would not work. That being said, I don't know if the CoCo is female. Sure you could argue that its 'character impersonation' might be effeminate ( look here: http://www.spacious-mind.com/assets/images/radioshack_trs80coco2_ad.gif ) but with the bow-tie I would rather think it's male. Anyway you make your own mind Yes, basically the only coco 3-specific stuff going on in this demo is the background screen in 16 colors, which could be removed anyway. And about the high speed POKE, there is also a High Speed POKE for CoCo 2, so it could be modified to work on a CoCo 2 (or Dragon for that matter) probably without too much problem by someone with the appropriate knowledge. There is also a thing about PAL vs NTSC for games and video tricks. But in this case, the CoCoSID demo doesn't rely on video timing at all, so this shouldn't be an issue. Hi Guys. Yeah can't wait to hear this CocoSid being routed through the Orch-90 pack. Should sound pretty darn cool. Plus this should free up enough Cycles to do a game demo using the Cocosid technique. I have not looked at the source code yet will do that soon enough and calculate Cycles and see if it is possible to create a Game demo using this CocoSid. Overall I think it sounds excellent in it's current format. RemZ is seriously pushing the Coco 3 to do things not normally done, Well Done mate keep up the good work. laters Briza

Hi RXD. I can send you a Dsk image copy of Roller Controller RXD. Send me a email too: tigers2roar at yahoo.com.au laters Briza

No these 2 games are not on the coco 3 at the moment. But if a talented programmer decided to port them over he could use this 256 artifact feature. I would guess Kings Quest 5 would be the easier off the 2 to port over. I'm hoping MajorG from the coco community decides to try and port it over. PotatoHead. Jason and I are going to try and use the scrolling reg to see if it will work and not screw up the colors. I can't see why it won't work. 1st we will try the normal scrolling settings. If that fails try increasing the pixel increments. I reckon 4 pixel movement should work. Forgot to mention that the pics were from a Pc. loaded into Photoshop pro. reduced to fit the resolution of the coco 3 640x192x4 mode. then the colors were matched as close as possible to the Composite colors from the RGB palette. Then you load it up on the coco 3 and it will do the rest.

No one really knows what the coco 3 can do. It's been the last 2-3 years that people have been seeing it do stuff it was never meant to do. Only need look at Donkey Kong by Sock Master. Or too hear music and sounds being done by CPU only with scrolling etc only need to look at Gold Runner 2000 by Chet Simpson. These showcase the awesome power off the 6809 chip and Gime chip. But now we have this 160x192x256 color artifact mode it should really show the world what the coco 3 could be made to do. Happy to hear another retrogamer has brought a coco 3. Drop into www.coco3.com anytime and leave posts. If you need answers to questions this is the place to get them. Btw mate. Have fun playing around with it. laters Briza

No these 2 games are not on the coco 3 at the moment. But if a talented programmer decided to port them over he could use this 256 artifact feature. I would guess Kings Quest 5 would be the easier off the 2 to port over. I'm hoping MajorG from the coco community decides to try and port it over. PotatoHead. Jason and I are going to try and use the scrolling reg to see if it will work and not screw up the colors. I can't see why it won't work. 1st we will try the normal scrolling settings. If that fails try increasing the pixel increments. I reckon 4 pixel movement should work.

I have no idea if you could do the same thing in Basic. My original Hack program was scaled down into this current code you see. Originally I had it set to execute in the protected page($FE00) and had it set on a Timer based interrupt using the IRQ bits in $FF92 plus other routines for relocation etc. But we found that the other stuff was not necessary. Now Robert G is playing around with it he will find out if the Scrolling reg's $FF9F and $FF9C(Vertical) will still work and not effect the Color Artifacts displayed. On a Plus note your Ideas for this have made it pretty clear that the coco 3 Gime chip does better color artifacts then what the coco 1,2 Pmode4 modes did. Now we just need people to play around with it, Maybe create a game or even re-design graphic viewers to use this new technique. But I do think that even basic could use this new artifact mode you discovered over 10 years ago. As basic is already set up to do the 640x192x4 mode anyway So I would have to say YES it could do it. laters Briza

============================================================== * RG This is a completely reworked program. Everything that is not needed * to obtain the results has been removed. * Dec 19, 2009 org $e00 start orcc #$50 lds #stack move stack out of the graphic area clr $ff40 stop drives sta $ffdf *All Ram Mode! * Make sure MMU and constant DRAM are on lda #%01001100 sta $ff90 * Setup MMU blocks for Task0. lda #$38 sta $ffa0 Task0 * MMu blocks at $60000, start of graphics screen. ROM code wiped! ldd #$3031 *Hi-Res graphics page1 address std $ffa1 addd #$0202 $3233 *Hi-res page 2 std $ffa3 addd #$0202 $3435 *Hi-res page 3 std $ffa5 addb #2 $36 *Hi-res page 4 stb $ffa7 * Set border color ldb #000000 xxRGBrgb stb $ff9a border color is Black * Set 1st 4 Palette Slots for 640x192x4 color mode lda #000000 Black sta $ffb0 lda #111111 White sta $ffb2 * These are CMP colors lda #010000 Dark Grey sta $ffb3 lda #100000 L Grey sta $ffb1 * Set Video Offset registers to show screen at $60000 ldd #$c000 $60000/8=$c000 std $ff9d clr $ff9c Disable Vertical scroll Reg * Set up video format lda #%10000000 *graphics, 0 screen lines per row, 50hz sta $ff98 ldb #111101 *160bytes across, (640x200x4) stb $ff99 * Place a band pattern on the screen CLRA initialize two pixels LOOP LDX #$2000 location LDY #160 bytes per line, LDB #50 number of bands to draw PSHS B L1 LDB #4 number of lines per band L2 STA ,X+ store two pixels LEAY -1,Y count bytes BNE L2 LDY #160 reset counter DECB count lines BNE L2 INCA increase pixel data DEC ,S count bands BNE L1 LEAS 1,S pop the stack * Now set up a new screen pattern with different colors wait ldb #2 b@ ldx #0 a@ leax -1,x bne a@ decb bne b@ bra LOOP Start a new screen with different colors rmb 50 stack equ * end start

Hi PotatoHead. Yeah I switched around the Grey and white order. You do get a different color result I find using the White before Grey gives you a duller set of colors while having Dark Grey before white gives you Brighter(intensity) colors will need to further experiment with this and determine why this is so. As for Cassette routines I have no clue. The best person to ask for that is Robert Gault in the coco 3 website his the local guru when it comes to knowing the ins and outs of the coco's. Leave a post in the forums there and RG will be 1 of the 1st to leave you the stuff or routines you need. 1 quirk I did find and notice using the 640x192x4 color mode. $FF99 you have bit settings 6-5 have a reserved setting for Vres when set for #%10(210line mode)this causes a bouncing endless scrolling thru memory and on the interrupts you get a screen splashed up with multiple colors Ok. Well if you set the Cres bits to 2,4,16 color mode usually you will only get the amount of colors selected by these bits on the Splash color part. Well 640x192x4 color mode should only give you 4 colors but it does not do that you actually get the whole 64 color palette appearing with the different hues of each color which total around 256 colors. Which means to me that this 640x192x256 color mode thingy you stumbled across could give us clues to how the Hardware byte/pixel 256 color mode could be activated. I am starting to think that the 640x192x4 color mode is the key to unlocking this special graphics mode Mr X's mentions. Will need to do further hacking in the Gime and try it on all Gime versions made. 1986 and 1987 chips. If it only works on the 86 gime then it could possibly mean that something is hidden in there. laters Briza Well, that's kind of interesting. What I don't get about the 256 color mode is how it is supposed to output. From what I can tell, the machine has only 4 intensities. I've never seen a GIME display where there were more than 4 intensities. If there is a 256 mode, wouldn't more than 4 be seen? Because of this, I've always thought the 256 mode was unlikely, at least on the RGB monitors. Good luck hunting. Do know the colors shown when running 640xwhateverx4, are caused by the display system and it's limits. As far as GIME is concerned, it's doing a rather ordinary 640 pixel 4 color display. If the designers of the CoCo would have provided S-video, there would only be 4 colors. (well, maybe a fringe color or two, but nothing like what we see on composite) Also, had they used interlaced color, where the phase alternates each line, the number of colors would be reduced to only a few as well, C64 style. Do you have a short extended basic program that can reproduce this mode you are seeing? I would love to get a screen capture of it for observation. Yeah I also do find this odd that the Gime only has 4 intensities levels. But when you change white around with Grey either you get bright colors or duller colors. As for a basic program to reproduce this effect I am not the guy to do it. I'm hopeless with Basic coding. I find ML coding more easier to understand, I will ask a friend who is great at basic to try and create the same display in basic, But if this cannot be done in basic then this is only a ML code feature. Will let you know how I go PotatoHead. Also this mode only displays on the CMP output only. RGB does give you more colors but this I believe to be a Color blending trick I found when I activated a 640x192x4 mode on top off a 320x192x16 color mode this seems to mirror the same effect but it seems this method you found gives a better color detail then my find earlier this year. laters Briza

Hi PotatoHead. Yeah I switched around the Grey and white order. You do get a different color result I find using the White before Grey gives you a duller set of colors while having Dark Grey before white gives you Brighter(intensity) colors will need to further experiment with this and determine why this is so. As for Cassette routines I have no clue. The best person to ask for that is Robert Gault in the coco 3 website his the local guru when it comes to knowing the ins and outs of the coco's. Leave a post in the forums there and RG will be 1 of the 1st to leave you the stuff or routines you need. 1 quirk I did find and notice using the 640x192x4 color mode. $FF99 you have bit settings 6-5 have a reserved setting for Vres when set for #%10(210line mode)this causes a bouncing endless scrolling thru memory and on the interrupts you get a screen splashed up with multiple colors Ok. Well if you set the Cres bits to 2,4,16 color mode usually you will only get the amount of colors selected by these bits on the Splash color part. Well 640x192x4 color mode should only give you 4 colors but it does not do that you actually get the whole 64 color palette appearing with the different hues of each color which total around 256 colors. Which means to me that this 640x192x256 color mode thingy you stumbled across could give us clues to how the Hardware byte/pixel 256 color mode could be activated. I am starting to think that the 640x192x4 color mode is the key to unlocking this special graphics mode Mr X's mentions. Will need to do further hacking in the Gime and try it on all Gime versions made. 1986 and 1987 chips. If it only works on the 86 gime then it could possibly mean that something is hidden in there. laters Briza

Hi PotatoHead. Yeah I set the Palette Slots to the colors you suggested. They sure do make a difference to the resulting colors displayed. Btw RainbowIde is `1 killer Compiler. I use that and VCC to test real disks on my Hardware. Sure does make a difference, I tried Disk Edtasm I hated using that. So RainbowIde is the way to go for fast compiling and testing of code. I can't wait for you to do some pics showing off the 256 colors generated in the 640x192x4 color modes. Imagine creating RemZ demo using this feature it would be kick ass for sure. How about it Remz willing to give it shot mate. laters Briza

In fact the result would be a 50 Hz NTSC, like the Amiga had to allow PAL game compatibility on this continent.. Interesting, however 50Hz flicker is somewhat visible to the eye. Indeed in the sprite demo it would allow maybe another sprite or more background animated tiles. Does the Tandy RGB monitor supports 50Hz too? Bet it probably does. The guys at CoCo3.com would know this answer cold. I was musing about a Propeller demo that runs in PAL, and the 50hz gives it some time. When 50Hz NTSC came up, I thought of this thread, and so there you go... Anyway, most modern displays will do the 50Hz thing, as they have to for PAL anyway, just like a PAL display will do PAL 60. There is some flicker, but on low intensity backgrounds, it's no big deal. Reducing overall screen brightness helps too. Hi Guys. Yeah the RGB CM8 monitor will do 50 or 60hz display. I'm based in Aussie Land and I use both a Pal and NTSC hooked up to my monitor. Mentioning the 50/60hz switch in $FF98 has given me a Idea for my Hacks I do in the Gime. I just may try setting the 50Hz switch on my NTsc unit and see what happens while switching in the 640x192x4 color mode. I'm curious to know If maybe the Gime designer used the 50/60hz switch on a NTSC unit which is what may cause the something Odd to occur. Stuff it I will try out that idea tonight. Thanks PotatoHead for the idea. Have fun guys. Laters Briza Ok Guys. I just ran a hack using Potatoheads theory of the 50hz switch on a Ntsc unit. It sure does work. You get a slight flicker but it is very small. Phead is right you do get multiple colors appearing in a 640x192x4 color mode. Some hues are the same but overall you get more then 16 colors. I would take a guess and say you get the whole 64 color palette with different color hues for each 64 colors in the Composite output only. Now is the question can it be used for a game tho. laters Briza