[Coco] 6309 microprocessor project 01-13-2004

[John Collyer]

----- 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