Re: Colour RAM Expansion (fwd)

From: Richard Atkinson (rga24_at_hermes.cam.ac.uk)
Date: 2000-07-06 16:10:31

Forwarding a mail which got lost...

---------- Forwarded message ----------
Date: Wed, 28 Jun 2000 15:47:01 +0100 (BST)
From: Richard Atkinson <rga24@hermes.cam.ac.uk>
Subject: Re: Colour RAM Expansion

On Tue, 27 Jun 2000, COPLIN, Nicholas. wrote:

> My thinking was to create a mode where an 8k colour RAM buffer was possible,
> hence a 4bit colour byte was available for each byte in the hires map (of
> course only in MC hires would the colour RAM be of use).  Doing this would
> increase the colour independence (without CPU intensive routines), but
> whether this would work or not depends on how and when the VIC actually
> grabs the colour nibble?  Does any body know?

According to Christian Bauer's VIC article, it is at the same time as a
video matrix access (c-access in the article), which occur in the
processor's half of the cycle during a bad line.

> Option 1a) would be if colour info was grabbed in parallel to reading the
> Video RAM and then stored within the VIC for the next 8 reads of the Hires
> RAM. This would mean an expansion is not possible

This is the correct option but it does not mean that a colour RAM
expansion isn't possible. If the color RAM were changed to be 8K x 4 bits
and the extra address lines connected to A12 - A10 on the VIC, then an FLI
routine would generate accesses to the 8 1K colour matrices on each line
of every character row in turn. You'd have to make sure that the 8 video
matrices were at 8 locations with different A12 - A10 values, but this
happens anyway with consecutive video matrix pointers.

Writing to these 8 colour matrices would require extra hardware, since the
processor A12 - A10 are always 110 when writing to colour RAM.


Richard


-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.

Archive generated by hypermail 2.1.1.