From: Hatch (hatch_at_in.com.au)
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
discussed
on the CDSb forum a bit but like all areas of the cct, is still open for
suggestions.
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
the
display window, pretty cool hey). Basically all the idol accesses the VIC
does
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
what
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
wouldn't
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
filler.
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
rectangle
EOR.
Please keep the ideas coming, and if you see a reason why something
mentioned
won't work please tell me.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.