[Coco] 64 column "low res" text sceen on coco3

[Arthur Flexser]

Have you tested the text rendering both in the mode with real lowercase
enabled and in the default mode?  Maybe one works better than the other.

Art
On Thu, Apr 11, 2013 at 7:26 PM, William Astle <lost at l-w.ca> wrote:

> On 13-04-11 04:16 PM, Arthur Flexser wrote:
>
>> So, all these years we've all believed that the CoCo 3 didn't support any
>> of the higher-resolution semigraphics modes...
>>
>> If I'm following you correctly, the CoCo 3 could be used for 128 x 32
>> semigraphics drawing, intermixed with half-width (but fully drawn)
>> VDG-style text.  Weird that one one seems to have noticed before.  Nice
>> work!
>>
>
> I've done some further experimentation and it turns out you don't get
> 128x32 - you actually get 64x32. See below.
>
> I stumbled onto this as a result of discussions on #coco_chat (on
> freenode) about semigraphics modes. I was bored so I started setting
> registers in the FF98..FF9F range and observing the results. This was the
> most interesting result.
>
> It turns out that FF9F also works as expected. (The horizontal
> scroll/offset register), including the "256 bytes per line" mode. I can see
> that being useful.
>
> FF9C does (as has been documented elsewhere) sets up for higher
> semigraphics modes except that text rendering doesn't function correctly.
> It seems to function by reducing the character row height depending on the
> value put in FF9C. Text characters seem to be aligned with the bottom of
> the cell instead of the top so the top of the characters gets clipped as
> the lines per character row are reduced. In any mode that is not 12 lines
> per character row, the graphics blocks are rendered differently. The values
> for FF9C work as follows. Unless otherwise noted, the bottom two elements
> of each graphic block are shown for all lines of the character row. These
> have all been confirmed experimentally.
>
> 0: 11 lines per row
> 1: 10 lines per row
> 2: 9 lines per row
> 3: 8 lines per row
> 4: 7 lines per row
> 5: 6 lines per row
> 6: 5 lines per row
> 7: 4 lines per row
> 8: 3 lines per row
> 9 : 2 lines per row
> 10: 1 line per row
> 11: 4 lines per row (1)
> 12: 3 lines per row (2)
> 13: 2 lines per row
> 14: 1 line per row (4)
> 15: 12 lines per row (3)
>
> (1) All four elements of the graphic block are rendered as expected, at 2
> lines per element.
> (2) All four elements of the graphic block are rendered as expected with
> the top elements 1 line high and the bottom elements 2 lines high.
> (3) Regular rendering is enabled as usual for the 32 column screen.
> (4) This one uses the top two elements in the graphic block rather than
> the bottom two.
>
> Further careful experimentation reveals that the graphics blocks behave
> differently when combined with the 64 column mode. It turns out that only
> the left hand elements in the graphics block are shown for whichever row is
> displayed. So what we actually have is 64x32 where every horizontal pixel
> can have a different colour. Combined with the semigraphics bits in FF9C,
> we can have 64x192 with 9 colours with all elements of the display having
> independent colours at the expense of twice the memory usage. (1 byte per
> pixel). This could also be 64x32, 64x64, 64x48, etc., using the FF9C bits.
> It's too bad the character generator doesn't do anything useful in these
> modes.
>
>
>
>> Art
>> On Thu, Apr 11, 2013 at 5:42 PM, William Astle <lost at l-w.ca> wrote:
>>
>>  I don't know if this is known or not. I can't believe I'm the first
>>> person
>>> to try poking values into $FF99 while in the 32 column "low res" text
>>> mode.
>>> Anyway, I found it interesting.
>>>
>>> Anyway, with the GIME set up for the 32x16 "coco2" text screen, if you
>>> set
>>> $FF99  to $10, you will end up with a 64x16 "coco2" text screen which
>>> uses
>>> 1024 bytes of memory. This screen still supports all the "SG4" graphics
>>> blocks.
>>>
>>> The "lines per field" setting seems to work, too. Setting it to 200 or
>>> 225
>>> lines seems to work as expected. Setting $FF99 to $70 yields a 64x19 text
>>> screen though the bottom 3 rows of the last line are missing. ($60 would
>>> give 32x19.)
>>>
>>> If you're messing with this from basic, you'll need to use a program like
>>> the following to see the result because basic resets all the video
>>> registers.
>>>
>>> 10 WIDTH32
>>> 20 POKE&HFF99,&H10
>>> 30 GOTO30
>>>
>>> Note that this is totally distinct from the high resolution 64 column
>>> text
>>> mode.
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/****mailman/listinfo/coco<http://five.pairlist.net/**mailman/listinfo/coco>
>>> <http://**five.pairlist.net/mailman/**listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>>> >
>>>
>>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>