[Coco] 6309 microprocessor project 01-13-2004

[Roger Taylor]

At 12:13 PM 1/13/2004 -0500, you wrote:
>6309 microprocessor project.
>
>I been real busy lately and been working on the emulator.  It will be a
>win32 app and will only work with virtual *.dsk and *.vhd.  This way I'll

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.


>If I keep a virtual memory extent (64K) and change the page number pointer
>this will give me a easy way to keep track of the memory.  But, I'll have to
>I can't decide which one of these would be the best choice.  The question is
>Getbyte and PutByte are called constantly so they should be the quickest.

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.


>I was wondering about what the emulator lacks in making Sockmaster's demos
>work?  Is it the horizontal/vertical offset registers or is it more then
>just that going on?  Any insights into why Jeff's emulator does not run
>Sockmaster's demo appreciated.

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.

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.



----------
Roger Taylor