[Coco] 6309 microprocessor project 01-13-2004

[John Collyer]

I have never seen a coco3 emulator at DK website, but I have
seen the coco2 emulator there.  Share the download link so
I can check it out. OK?

John Collyer

----- Original Message ----- 
From: <jadonaldson at charter.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Cc: "John Collyer" <johncollyer at zoominternet.net>
Sent: Wednesday, January 14, 2004 10:56 AM
Subject: Re: Re: [Coco] 6309 microprocessor project 01-13-2004


> John,
>   Have you looked at David Krell (sp) coco3 emulator. It
> runs under windows XP, but is only 128K. David has it as
> a download on his web site.
>
> John Donaldson
>
> >
> > From: "John Collyer" <johncollyer at zoominternet.net>
> > Date: 2004/01/13 Tue PM 10:59:26 EST
> > To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> > Subject: Re: [Coco] 6309 microprocessor project 01-13-2004
> >
> > ----- Original Message ----- 
> > From: "Roger Taylor" <rtaylor at bayou.com>
> > To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> > Sent: Tuesday, January 13, 2004 7:02 PM
> > Subject: Re: [Coco] 6309 microprocessor project 01-13-2004
> >
> >
> > > Good deal.  I just feel for you if you're converting Jeff's original
code
> > > which is designed for DOS only.  Yikes.  All of that dealing with
segments
> > > scares me.  You can do so much more and much easier by using the
Windows
> > > API, but you're probably finding this out already.
> >
> > It seems I'm droping more of his code lately, and just using stuff that
I
> > wrote that
> > works easily in masm32 and the flat memory model.
> >
> > > I'm not sure what you're really wanting to do, so I can't suggest
anything
> > > specific.  But, I'm sure if you've made it this far, you'll come up
with
> > an
> > > excellent idea for optimized address translation from the CoCo's GIME
> > > scheme into a mere 2meg block of RAM you are guaranteed to get by the
> > > malloc function in most PC compilers.
> >
> > Thanks.  I'll get it together, and I'll make sure it is highly
optimized!
> >
> > > Precise timing is required for most of Sock's stuff.  There's too many
> > > factors involved per user system that determines how timing-critical
> > > programs and games behave.  Some of Sock's demos change video settings
> > > while the raster beam is traveling down the monitor, without
synchronizing
> > > to HSYNC or VSYNC.  It is true that Sockmaster's real nickname should
have
> > > been "Syncmaster"... because he is a master of the CoCo's video
system.
> > It
> > > doesn't surprise me at all if an emulator can't keep up with ole
> > > Sock.  However, Sock's demos should be *THE* ultimate video test
system
> > for
> > > the emulators.
> >
> > That's my hope.  My emulator will be able to handle Syncmaster's demos.
> >
> > > Nothing as far as I know is lacking from the M.E.S.S. emulator, but
I've
> > > always had problems with Jeff's emulator.  Please stick with the
standard
> > > format for .DSK and .ROM images which is to retain the pure image and
not
> > > chop off any null bytes at the end or anything else that would
otherwise
> > > show the file as being of a wierd size that a user can't directly look
at
> > > and determine what it might be for.  For instance, a 23k .DSK file
means
> > > absolutely nothing to me, but a 156k .DSK file speaks a common
language to
> > > everybody who sees it and knows anything about the CoCo disk system.
You
> > > can even tack a small header to a 156k .DSK file and Windows will show
it
> > > as either 156k or 156 "point something", which is still very
> > > revealing.  Let ZIP do the compression.  And by all means, choose
> > > predefined formats for your images... it's bad enough that there are
so
> > > many .DSK formats that are totally incompatible or unrelated, such as
the
> > > DSHRINK .DSK format, Jeff's .DSK format, M.E.S.S.'s .DSK format, and
> > > Microsoft has a .DSK format as well.
> >
> > I am sticking to the way Jeff handled things with regards to ROM and DSK
> > images.  I know about 16K or 32K rom images, howbeit they might be
banked
> > rom images with much more rom memory then just 16K or 32K.  I understand
> > that these banked rom images write to $FF40 to switch the banks.  DSK
images
> > will be the JVC standard with no deviation.
> >
> > John Collyer
> >
> >
> > -- 
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>