From: Hatch (
Date: 2004-11-01 08:15:04

Good to get all the response, and I'm glad and a little surprised that there
is no

negative response.

From now on I will refer to the option of using C64 memory as "Option C"

The other option of banking in graphics memory into the C64map as "Option V"

This is just to make things simpler when explaining.

At the moment I'm leaning toward using option V

The clearing memory thing seems to be coming up allot.  This has been

on the CDSb forum a bit but like all areas of the cct, is still open for

At this stage if using the C64's memory (Option C) 8k of ram can be byte
filled in

about 67 rasters (if using badlines) and about double that if not using
badlines (If

using badlines you can byte fill > 8k of ram while that raster is outside of

display window, pretty cool hey).  Basically all the idol accesses the VIC

will now be used for byte filling/clearing.

If I decide to give the cct it's own memory (Option V) I can byte fill it at

ever speed I have the cct running at (like someone mentioned earlier), this

would probably mean 34 raster lines to byte fill 8k with no badlines (it

be worth having badlines).

Now would probably be a good time to mention that this cct will never
require a

badline for accessing graphics data.  The only times badlines would be used
is if

the coder enabled badlines (through an enable bit) and was using the byte

As far as rectangular filling is concerned, I will not be implementing it,
just a

matter of keeping things as simple as possible.  To rectangle fill a
combination of

code and the hardware byte filler could be used I guess.  If I go with
Option C it

might be possible to use the 4 bit color ram to indicate what cells you want
fill or

to EOR on the display, which would give you a sort of rectangle fill and


Please keep the ideas coming, and if you see a reason why something

won't work please tell me.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.