[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