[Coco] Pseudo CoCo4???
farna at att.net
farna at att.net
Sun Jan 21 13:08:06 EST 2007
Just a thought here... I haven't played with MESS yet, one of those "when I get some extra time" things. But as I recall it can work with added features such as hard drive support, and run in a full screen mode (sort of a "letterbox" mode). What is the lowest speed/level processor MESS runs well under? Will it work reasonably well with a Pentium I, or does it require at least a PII or PIII to run at CoCo3 speeds? What I'm thinking is why not package a "live" CD with everything to run like a CoCo3 but make a few enhancements (like HD support, faster clock speed, access to some of the PC peripherals)? It's cheaper than doing it in hardware since there is so much cheap PC hardware out there now.
--
Frank Swygert
Publisher, "American Motors Cars"
Magazine (AMC)
For all AMC enthusiasts
http://farna.home.att.net/AIM.html
(free download available!)
-------------- Original message ----------------------
From: coco-request at maltedmedia.com
> Send Coco mailing list submissions to
> coco at maltedmedia.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://five.pairlist.net/mailman/listinfo/coco
> or, via email, send a message with subject or body 'help' to
> coco-request at maltedmedia.com
>
> You can reach the person managing the list at
> coco-owner at maltedmedia.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Coco digest..."
>
>
> Today's Topics:
>
> 1. Re: CCASM to gain .cas output feature! (Roger Taylor)
> 2. Re: CCASM to gain .cas output feature! (Roger Taylor)
> 3. Re: CCASM to gain .cas output feature! (Roger Taylor)
> 4. Re: Color basic 1.0, 1.2 differences. (Arthur Flexser)
> 5. Re: Color basic 1.0, 1.2 differences. (Darren A.)
> 6. Re: CCASM to gain .cas output feature! (Roger Taylor)
> 7. Re: Glove Final Release 2... (Joel Ewy)
> 8. More colors on CoCo 1? (Joel Ewy)
> 9. Re: Color basic 1.0, 1.2 differences. (Phill Harvey-Smith)
> 10. Re: More colors on CoCo 1? (Richard Atkinson)
> 11. Re: More colors on CoCo 1? (Roger Taylor)
> 12. Re: More colors on CoCo 1? (Roger Taylor)
> 13. Re: More colors on CoCo 1? (Joel Ewy)
> 14. Re: More colors on CoCo 1? (Robert Gault)
> 15. Re: More colors on CoCo 1? (Torsten Dittel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 21 Jan 2007 00:02:21 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] CCASM to gain .cas output feature!
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121060237.A79427D113 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> Another update,
>
> CCASM 4.0 is successfully generating a digital .cas file of a program
> that CLOADM's a message onto the CoCo 32-column screen. The M.E.S.S.
> emulator loads the .cas file just fine and stops the CLOADM as it should.
>
> I also converted the .cas file to an .mp3 rendering and loaded it on
> my MP3 player, and my CoCo 1 loads the program from the player but
> doesn't stop. Junk appears to be loading periodically after the
> screen text as if the EOF block is corrupt or maybe my volume is too loud.
>
> Progress!
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 21 Jan 2007 00:05:15 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] CCASM to gain .cas output feature!
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121060636.513907D113 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 11:47 PM 1/20/2007, you wrote:
> >Roger Taylor wrote:
> >
> > > Voila. Easier said than done, but it's a start.
> > >
> > >
> >
> >My god, in French !! Good start !! ;-) ;-)
> >
> >Thierry
>
>
>
> Haha. I didn't catch that for a minute. To those who are lost,
> Thierry translated a bunch of French specs for a 6809 computer board
> and modules for me that I plan to sell soon. That project is on hold
> for now but I owe him a lot of credit for doing that work.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 21 Jan 2007 00:08:16 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] CCASM to gain .cas output feature!
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121060835.A9C057D113 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 11:15 PM 1/20/2007, you wrote:
> >tape files have to be congiguous and not have multi records or
>
> Typo...
> Rather, "contiguous", or I like to say contiuous since that's what
> contiguous really means. :)
>
> Ah, the eyes are getting heavy. Been working on CCASM all day. To
> follow comes .bas and .dat to .cas output, ASCII and binary formats
> with leader/gaps to let the CoCo having breating room while loading.
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 21 Jan 2007 01:29:36 -0500 (EST)
> From: Arthur Flexser <flexser at fiu.edu>
> Subject: Re: [Coco] Color basic 1.0, 1.2 differences.
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <Pine.SOL.4.21.0701210111130.4103-100000 at solix.fiu.edu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Sat, 20 Jan 2007, Robert Gault wrote:
> >
> > All you need to do manually if more than 16K RAM is present would be to
> > STA $FFDD, STA $FFDA after the initial boot is complete. That will
> > indicate 64K dynamic RAM. This could easily be put in a modified disk
> > ROM or entered from the keyboard.
> >
>
> I'm pretty sure it wouldn't be that simple if the instructions execute in RAM,
> since the RAM will get remapped in the process, including the addresses
> containing those instructions. For example, a 64K machine can be forced into 4K
> mode by pressing shift-break-reset (Color Basic 1.1 ROM only). But the 4K isn't
> a contiguous portion of the 64K; it consists of 64-byte strips gathered from
> all over the place, so a slice of RAM starting at $1000 in 4K mode might wind up
> at $B160 or something when you do the 64K switch, while $1020 might wind up at
> $B300. The program counter, once the map switches, will be pointing somewhere
> other than the address of the next instruction, so good luck getting subsequent
> instructions to execute unless you know exactly where they'll wind up after the
> map switch.
>
> I would imagine that there'd be some sort of workaround to force 64K mode
> through hardware even if you have the Color Basic 1.0 ROM, probably done as part
> of the earliest sort of 64K homebrew upgrades.
>
> Art
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 20 Jan 2007 23:40:54 -0700
> From: "Darren A." <darccml at hotmail.com>
> Subject: Re: [Coco] Color basic 1.0, 1.2 differences.
> To: coco at maltedmedia.com
> Message-ID: <BAY101-F34CF96E5E9F85CEC7039BCB9AF0 at phx.gbl>
> Content-Type: text/plain; format=flowed
>
> >From: Robert Gault <robert.gault at worldnet.att.net>
> >
> >Phill Harvey-Smith wrote:
> > ><snip>
> > > Ahh, but I was talking about plain non-extended color basic, version
> > > 1.0, which seems in software to only detect 4K or 16K rams. Do you know
> > > what version of Color basic is in there ?
> > >
> > > Cheers.
> > >
> > > Phill.
> > >
> >
> >The ROM is Color Basic 1.1 in my F-board Coco1. Looking at the source
> >code for the 1.0 ROM, it reads a PIA at $A057 to determine 4 or 16K of
> >RAM and sets the SAM at$A06A for 16K. However, at $A0AB the ROM has a
> >routine which looks for the top of RAM by testing memory. It stops when
> >memory can't be changed. I'm not sure what would happen if 32K or more
> >of RAM was present, the SAM set for 16K, and data stored above $4000.
> >
> >All you need to do manually if more than 16K RAM is present would be to
> >STA $FFDD, STA $FFDA after the initial boot is complete. That will
> >indicate 64K dynamic RAM. This could easily be put in a modified disk
> >ROM or entered from the keyboard.
> >
> -
> According to the data sheet for the SAM, you need to properly setup the
> memory size control bits *before* RAM is accessed. These control bits don't
> just determine how much memory can be addressed, but how the SAM interacts
> with the the type of RAM chips (4K dynamic, 16K dynamic, 64K dynamic or 64K
> static are the possible options).
>
> The Color Basic ROM sets these very early in the initialization sequence
> before any RAM is used. It does not appear that doing it later in a modified
> Disk Basic ROM or by a POKE command would be appropriate. You would have to
> modify the Color Basic ROM, which of course is what Tandy did in the 1.1
> version.
>
> Darren
>
> _________________________________________________________________
> Valentine’s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping
> http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wl
> mtagline
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 21 Jan 2007 00:43:07 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] CCASM to gain .cas output feature!
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121064325.67CCF7D116 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> Well what ya know! It was an MP3 quality issue with my MP3 player
> dealing with the cassette file. I chose a higher quality with my MP3
> encoder, and double-length sync leaders, and although it almost
> tripled the file size, this shouldn't matter at all due to the large
> capacity of most MP3 devices.
>
> 'Hello World Of Assembly' is now loading fine on my CoCo 1 from a
> cheap MP3 player. This is a $49 RCA digital voice recorder that
> saves in MP3 format, but acts as a PC drive when you connect it using
> the USB cable. So I converted my .cas file to .mp3, put it on the
> player and then took it over to my CoCo, connected it with a cassette
> cable I made, and I'm thrilled to see it's working! Type CLOADM,
> then press Play on the player and in comes the file, error-free.
>
> Now, the iPod has a volume issue which I don't understand. Apple not
> only makes a terrible iTunes program that makes is very hard to put
> MP3 files on your iPod, but when you play them back (real songs),
> even loud ones, they sound low and soft with the volume all the way
> up. Maybe there's a setting in there I'm missing, but if this is the
> way they do it, then thumbs down. However, CoCo cassette files
> stored as MP3 seem to load ok from an iPod.
>
> Now I will do the 2mhz test that I proved to work many years ago
> using my MiniDisc recorder. That device recorded through the line-in
> from the CoCo at 2mhz onto a disc. I think the MiniDisc format uses
> an early version of MP3. I used to play back the double-speed
> cassette files into the CoCo, no problem, as long as the CoCo was in
> 2mhz mode. Ever done that?! Yes, a high-speed cassette port.
>
> If only the cassette format would allow overlayed load origins like
> LOADM does, we could CLOADM in extremely long files like cartoons
> onto the VDG screen, etc. Maybe on an all-RAM CoCo 3, the CLOADM
> command could be patched in real-time by the CLOADM'ed program to
> allow further origins of the same file? If it could also poke to the
> 2mhz register then kick into high-speed loading of the other
> content.... Is any of this remotely interesting or am I extremely in
> need of sleep? :-)
>
> Sock, got any ideas?
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 21 Jan 2007 00:56:28 -0600
> From: Joel Ewy <jcewy at swbell.net>
> Subject: Re: [Coco] Glove Final Release 2...
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <45B30E9C.8030303 at swbell.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I can report that it runs on a 64K CoCo 1. I initially tried loading
> the cassette WAV file from a portable .mp3 (etc) player. The game
> loaded but I could never get the levels to load. It sounded like it was
> exercising the motor control relay. Does it need to stop the tape after
> each level or something? If so, I guess it won't work when loaded from
> a device like I was trying to use, or from a PC sound card.
>
> But I got it to run from floppy disk. One oddity I've noticed is that
> it loads the intro screen and the first part of the program, then the
> BASIC loader crashes with a syntax error on line 25. The line looks
> like perfectly good DECB to me, and in fact if you enter each line of
> the program interactively (except I didn't bother with the POKE that
> shuts off the motor) it will go ahead and run. Also, if you simply type
> 'RUN' again immediately after the loader crashes it starts over and
> works fine. Doesn't seem to do this on my CoCo 3.
>
> Thanks again for a fun game.
>
> JCE
>
>
> James McKay wrote:
> > "Joel Ewy" <jcewy at swbell.net> wrote in message
> > news:45B1A31D.8070208 at swbell.net...
> >
> >> Just tried out The Glove FR2 on a CoCo 3. Great game. It's really nice
> >> to see new software developed for the CoCo. I may even dig out my CoCo
> >> (1) just because there's a new game that will run on it. Thanks.
> >>
> >
> > I don't think it's been tried on a CoCo 1 yet, but it should work.
> >
> >
> >> p.s. I can confirm that FR2 does eliminate the flickering on the CoCo 3
> >> -- I first played the version I had downloaded earlier but not yet
> >> tried, then remembered this thread when I noticed the flicker.
> >>
> >
> > Great, thanks for testing it.
> >
> > bye,
> > James McKay.
> >
> >
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 21 Jan 2007 02:12:56 -0600
> From: Joel Ewy <jcewy at swbell.net>
> Subject: [Coco] More colors on CoCo 1?
> To: coco at maltedmedia.com
> Message-ID: <45B32088.50809 at swbell.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Ok, this may be just wild speculation. But couldn't one write a program
> that would flip between 2 9-color SG-24 screens to make a 64x192
> high(er)-color display on a CoCo 1 or 2? Not that I'm seriously
> thinking of attempting such a thing. It would take up 12K of RAM, but
> that in itself shouldn't be a show stopper on a 64K machine. Resolution
> would be quite low, and the elongated pixels would be weird. But I
> wonder if you could almost get a recognizable image by time-domain
> dithering the colors.
>
> Another question is whether the screens would even have to be in the
> same graphics mode. Could one superimpose a 256x192 2-color bitmap over
> an SG-24 colorizer? Or two? That would require 18K. Why would this
> not work?
>
> JCE
>
>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 21 Jan 2007 11:23:47 +0000
> From: Phill Harvey-Smith <afra at aurigae.demon.co.uk>
> Subject: Re: [Coco] Color basic 1.0, 1.2 differences.
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <45B34D43.6000500 at aurigae.demon.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Robert Gault wrote:
> > Phill Harvey-Smith wrote:
> >> <snip>
> >> Ahh, but I was talking about plain non-extended color basic, version
> >> 1.0, which seems in software to only detect 4K or 16K rams. Do you know
> >> what version of Color basic is in there ?
> >
> > The ROM is Color Basic 1.1 in my F-board Coco1. Looking at the source
> > code for the 1.0 ROM, it reads a PIA at $A057 to determine 4 or 16K of
> > RAM and sets the SAM at$A06A for 16K. However, at $A0AB the ROM has a
> > routine which looks for the top of RAM by testing memory.
>
> That will work if you have 2 banks of 16K which was possible on the CoCo
> by piggy backing another set of 16K chips, I believe you would have to
> do this as there are only 8 sockets. I know this works as most of the
> Dragon 32s used this configuration. I guess you could also do it with 2
> banks of 4K to get 8K but I have never seen this.
>
> > It stops when
> > memory can't be changed. I'm not sure what would happen if 32K or more
> > of RAM was present, the SAM set for 16K, and data stored above $4000.
>
> Since the machine would at that point be in map type 0 it would stop
> testing when it hit the ROM at $8000, I believe even 64K machines do
> this, as it's basically testing and setting up the ram for basic, which
> can only use the bottom 32K, on the CoCo and Dragon 32 anyway, The
> Dragon 64 has a second copy of basic assembled to run from $C000, so can
> be booted into map type 1 give 48K of ram to basic.
>
> > All you need to do manually if more than 16K RAM is present would be to
> > STA $FFDD, STA $FFDA after the initial boot is complete. That will
> > indicate 64K dynamic RAM. This could easily be put in a modified disk
> > ROM or entered from the keyboard.
>
> Yeah The 1.2 Color Basic rom does this, I rememberd I had the pdf of
> "Color Basic Unraveled" and checked in there, apparently this was one of
> the improvements 1.0->1.2 was the ability to use 64K rams, the cocoe
> driver in mess uses this, so I have set things up in the mess source, so
> that the coco (with CB 1.0), can use 4K, 16K, and 32K, but the cocoe can
> use 64K as well.
>
> Cheers.
>
> Phill.
>
> --
> Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
>
> "You can twist perceptions, but reality won't budge" -- Rush.
>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 21 Jan 2007 12:55:27 +0000
> From: "Richard Atkinson" <rga24 at cantab.net>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Message-ID:
> <fcbfde580701210455m9d361f8td4b38b5c1857f757 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Joel,
>
> It's possible to do exactly as you suggest. The multiple mode idea is
> especially interesting, for example you could take a high resolution RG6
> black and white picture and colour it in using an SG24 picture.
>
> One problem you would notice would be a 30Hz flicker (25Hz on PAL). As a way
> of getting round this, you could restrict the colours in the 2 pictures, for
> example 2 SG24 pictures, by only allowing colours to alternate between 2
> colours of the same brightness. The CoCo 1 has 4 brightness levels and 12
> colours altogether, the colours at each brightness level being:
>
> Level 0
> Black
> Dark Green (RG6 'black' or alphanumeric character 32, CSS=0)
> Dark Orange (alphanumeric character 32, CSS=1)
>
> Level 1
> Blue
> Red
>
> Level 2
> Green
> Cyan
> Magenta
> Orange
>
> Level 3
> Buff
> Yellow
> Light Orange (alphanumeric character 96, CSS=1)
>
> Although your choice of extra colours is limited to 13 extra ones in this
> case, the flickering should be much reduced. If you're prepared to tolerate
> a little more flickering, you could allow colour combinations between
> colours having adjacent brightness levels, e.g. 0/1, 1/2, 2/3.
>
> Richard
>
>
> On 1/21/07, Joel Ewy <jcewy at swbell.net> wrote:
> >
> > Ok, this may be just wild speculation. But couldn't one write a program
> > that would flip between 2 9-color SG-24 screens to make a 64x192
> > high(er)-color display on a CoCo 1 or 2? Not that I'm seriously
> > thinking of attempting such a thing. It would take up 12K of RAM, but
> > that in itself shouldn't be a show stopper on a 64K machine. Resolution
> > would be quite low, and the elongated pixels would be weird. But I
> > wonder if you could almost get a recognizable image by time-domain
> > dithering the colors.
> >
> > Another question is whether the screens would even have to be in the
> > same graphics mode. Could one superimpose a 256x192 2-color bitmap over
> > an SG-24 colorizer? Or two? That would require 18K. Why would this
> > not work?
> >
> > JCE
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 21 Jan 2007 09:17:21 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121151738.D9E997D112 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 02:12 AM 1/21/2007, you wrote:
> >Ok, this may be just wild speculation. But couldn't one write a program
> >that would flip between 2 9-color SG-24 screens to make a 64x192
> >high(er)-color display on a CoCo 1 or 2? Not that I'm seriously
> >thinking of attempting such a thing. It would take up 12K of RAM, but
> >that in itself shouldn't be a show stopper on a 64K machine. Resolution
> >would be quite low, and the elongated pixels would be weird. But I
> >wonder if you could almost get a recognizable image by time-domain
> >dithering the colors.
> >
> >Another question is whether the screens would even have to be in the
> >same graphics mode. Could one superimpose a 256x192 2-color bitmap over
> >an SG-24 colorizer? Or two? That would require 18K. Why would this
> >not work?
>
>
>
> Sockmaster would be the guy to pull that off, although I think pixel
> resolution has a lot to do with it.
>
> Blockier graphics will result in flicker being much more noticable
> because you're spreading the same colors across so many dots on the screen.
>
>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 21 Jan 2007 09:31:22 -0600
> From: Roger Taylor <operator at coco3.com>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <20070121153143.C770E7D112 at qs281.pair.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 06:55 AM 1/21/2007, you wrote:
>
> >Although your choice of extra colours is limited to 13 extra ones in this
> >case, the flickering should be much reduced. If you're prepared to tolerate
> >a little more flickering, you could allow colour combinations between
> >colours having adjacent brightness levels, e.g. 0/1, 1/2, 2/3.
>
>
> You could even alternate the combination positioning for each
> scanline or the other flickered page if you're mixing that way in
> addition to the single-page half-tone dithering. I think the
> following might yield about 43 to 49 grayscales that are more
> accurate than just using a set of 7 pairs per screen like
> (0,0 0,1 1,1 1,2 2,2 2,3 3,3). The even/odd line patterning
> can reduce artifacts and vertical striping.
>
> page 1, even lines
> 0,0
> 0,1
> 1,1
> 1,2
> 2,2
> 2,3
> 3,3
> 3,3
>
> page 1, odd lines
> 0,0
> 0,0
> 1,0
> 1,1
> 2,1
> 2,2
> 3,2
> 3,3
>
> You can also achieve a simulated vertical resolution increase like
> for tall Macintosh pictures, by dividing the picture into two
> screens, one containing just the even lines, and the other containing
> just the odd lines.
>
>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 21 Jan 2007 10:06:14 -0600
> From: Joel Ewy <jcewy at swbell.net>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <45B38F76.8090408 at swbell.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Roger Taylor wrote:
> > At 02:12 AM 1/21/2007, you wrote:
> >
> >> Ok, this may be just wild speculation. But couldn't one write a program
> >> that would flip between 2 9-color SG-24 screens to make a 64x192
> >> high(er)-color display on a CoCo 1 or 2? Not that I'm seriously
> >> thinking of attempting such a thing. It would take up 12K of RAM, but
> >> that in itself shouldn't be a show stopper on a 64K machine. Resolution
> >> would be quite low, and the elongated pixels would be weird. But I
> >> wonder if you could almost get a recognizable image by time-domain
> >> dithering the colors.
> >>
> >> Another question is whether the screens would even have to be in the
> >> same graphics mode. Could one superimpose a 256x192 2-color bitmap over
> >> an SG-24 colorizer? Or two? That would require 18K. Why would this
> >> not work?
> >>
> >
> > Sockmaster would be the guy to pull that off, although I think pixel
> > resolution has a lot to do with it.
> >
> >
> Yeah. The line of thinking was of course influenced by looking at
> Sock's CoCo 3 HiColor code. Also by Robert Gault's web page on S-24 (
> http://home.att.net/~robert.gault/Coco/History/Semi24.htm ).
> > Blockier graphics will result in flicker being much more noticable
> > because you're spreading the same colors across so many dots on the screen.
> >
> Some amount of flicker is a given with this kind of thing. The point is
> just to see if it could be done. If you would superimpose a G6R with a
> dithered high-res bitmap over the color screen you could break up the
> 4-pixel long blocks. 33%-50% of the time (depending on # of screens)
> many of the big blocks of color would be broken up into high-res
> pixels. I don't know whether that would have any effect on perceived
> flicker, but it would add detail.
>
> How would PMODE 4 artifact colors blend with S-24 real colors? Also, it
> occurs to me that many of the 'mixed' colors would likely be duplicates
> of each other, and possibly existing 'real' colors. So would it be just
> as effective to use one of the higher resolution 4-color modes like G6C?
>
> JCE
>
>
>
> ------------------------------
>
> Message: 14
> Date: Sun, 21 Jan 2007 11:29:07 -0500
> From: Robert Gault <robert.gault at worldnet.att.net>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <45B394D3.1000002 at worldnet.att.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Joel Ewy wrote:
> ><snip>
> > How would PMODE 4 artifact colors blend with S-24 real colors? Also, it
> > occurs to me that many of the 'mixed' colors would likely be duplicates
> > of each other, and possibly existing 'real' colors. So would it be just
> > as effective to use one of the higher resolution 4-color modes like G6C?
> >
> > JCE
> >
> >
>
> Give it a try and tell us the results. :)
>
>
> ------------------------------
>
> Message: 15
> Date: Sun, 21 Jan 2007 17:36:42 +0100
> From: Torsten Dittel <Torsten at Dittel.info>
> Subject: Re: [Coco] More colors on CoCo 1?
> To: coco at maltedmedia.com
> Message-ID: <45B3969A.52E2FFD6 at Dittel.info>
> Content-Type: text/plain; charset=us-ascii
>
> I once patched the Dragonfire ROM Pak to work with 50Hz PAL CoCo1/2.
> This program displayed 8 colors (both PMODE3 palettes) at once. I have
> then written an "intro" mixing more graphic modes to get more colors and
> even smooth "on border animation". However, this worked only on the
> "real" thing, my 50Hz PAL 64KB CoCo 2B (with T1 lowercase VDG). A nice
> file for emulator flaccidity proving... ;-). For those PAL guys who want
> to try:
>
> http://TRS-80.CC/DRAGFIR2.BIN
>
> Regards,
> Torsten
>
>
>
> ------------------------------
>
> _______________________________________________
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
> End of Coco Digest, Vol 42, Issue 33
> ************************************
More information about the Coco
mailing list