[Coco] CoCo 128-column text mode

[William Astle]

That's what it should do. On mine, though, it starts out doing that then 
the whole machine crashes after 30 or so steps. Even if it doesn't crash 
hard, it leaves a whole bunch of stuff messed up. Things like "RUN" 
giving a syntax error, ENTER not working, etc. It's like memory is 
getting corrupted somehow.

The same doesn't seem to happen on the hires screen.

It could be my coco3 that has an issue somewhere but it seems otherwise 
stable. It would be interesting if others have instability of some kind 
during or after running that program on a 32 column screen.

On 15-01-07 01:46 PM, Bob Devries wrote:
> Hi William,
> On my Coco3 (PAL) it scrolls 2 characters at a time. It looks like the
> top 2 lines are normal, i.e. black on green characters, which are being
> scrolled, and the rest of the screen is filled with inverse @ signs,
> with a few apparently random characters scrolling left on the  6th line.
> From the 8th line, the lines alternate between inverse @ and black
> blocks (32 of each).
>
> Hope that helps
>
> Regards, Bob Devries
> Dalby, QLD, Australia
>
>
> On 8/01/2015 6:28 AM, William Astle wrote:
>> It does exactly that.
>>
>> I just did some testing on the 32 column VDG screen and found an
>> interesting behaviour. It seems to behave as described but the system
>> actually crashes when it's in use, at the very least when the offset
>> gets up to around 64 bytes. It's not clear to me why that is the case.
>>
>> The test program I used is:
>>
>> 10 FORX=128TO255
>> 20 POKE&HFF9F,X
>> 30 FORY=1TO400
>> 40 NEXTY,X
>>
>> The program ran through flawlessly on an 80 column screen, stepping
>> about once per second.
>>
>> On a 32 column screen, it started out stepping two characters at a time
>> and then eventually crashed out, either scribbling all over the screen
>> or even sending the hardware squirrelly.
>>
>> I wonder if this is consistent on all Coco3s or if it's an indication
>> that mine has issues.
>>
>> On 15-01-07 01:15 PM, Nick Marentes wrote:
>>> On 8/01/2015 6:06 AM, William Astle wrote:
>>>> Theoretically, it would allow for 256 columns in a text mode with no
>>>> attributes (1 byte per character). Bit 7 of FF9F actually forces the
>>>> line width to 256 bytes instead of whatever the actual screen width is
>>>> set to (each line starts 256 bytes past the previous one).
>>>>
>>>
>>> In graphics mode, bit 7 is the Enable bit so that's 128 combinations so
>>> to extend to 256 bytes wide, the minimum increment is 2 bytes.
>>>
>>> I other words, the horizontal scrolling is 2 bytes or 4 graphic pixels
>>> at a time.
>>>
>>> I haven't played with the text mode but I think a similar restriction
>>> occurs here.
>>>
>>> It probably allows single character scrolling across 128 columns with
>>> text attributes on.
>>>
>>> Nick
>>>
>>>
>>>
>>
>>
>