[Coco] wanting to patch HPUT routine... (ping RG!)

theother_bob theother_bob at yahoo.com
Mon Aug 17 11:06:26 EDT 2009



----- Original Message ----
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Monday, August 17, 2009 6:37:24 AM
Subject: Re: [Coco] wanting to patch HPUT routine... (ping RG!)

You have shown that HPUT is faster than HDRAW, no surprise. You probably won't find any method for significantly increasing the speed of HPUT but that is not really what you want. You would seem to want a method for speeding up the movement of the arrow cursor in Color Fog. Most of the code in the HPUT routine is there to handle generic placement of buffer content on the screen. The coordinates may be inverted, they may be out of bounds, the buffer coords may not match the HPUT coords, @ syntax might be used, the HSCREEN mode must be tested, etc. But cursor movement is a specific task and many of the HPUT tests could be bypassed as they are not needed.

You could try writing an ml routine that emulates HPUT but skips tests that are not needed for the Color Fog cursor routine. Theoretically you could remove a good chunk of code and still have a functioning HPUT. The problem would be where to put your own code in memory, load it with needed data via Color Fog, and interface it with the ROM code needed to access the graphics and buffer memory.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


That makes sense. I did notice the testing routines to swap X or Y values if they were inverted. With Color Fog. I could overwrite that code, as I will already have done it, and possibly rewrite some of the optional methods that I'm not using. I'm sure that would be plenty of space for what I need to do... maybe enough to consolidate the other patch code.

Now I'm thinking about making a 512K only version with better speed and capability, and I'll probably drop Color from the moniker and go hi-res with it. With 512K in mind...

Is there any reason I couldn't copy the SECB ROM/RAM to a spare block, apply patches to the copy and then switch my patched block in to run FOG, then restore the unpatched (or less patched) block back upon exit? That would also benefit me by further reducing code overhead. 

What is the best (fastest?) way to copy one 8K block to another?

Bob



      



More information about the Coco mailing list