[Coco] 6309 microprocessor project 01-13-2004
johncollyer at zoominternet.net
Tue Jan 13 22:59:26 EST 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
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
> 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.
> 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
> 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.
More information about the Coco