[Coco] What do you make of this non-approved HSCREEN mode?

[jdaggett at gate.net]

On 7 Jun 2009 at 22:19, Robert Gault wrote:

> jdaggett at gate.net wrote:
> > On 3 Jun 2009 at 21:12, Robert Gault wrote:
> > 
> >> Anyone who has looked at the middle chart on page 18 of the Coco3
> >> service manual will have noticed that there are missing entries. I
> >> and other Coco enthusiasts have expanded this table to fill in the
> >> missing entries.
> >>
> >> It seems to me that there are two alternating series of screen
> >> widths in bytes. Expanding on what is given by Tandy, the chart
> >> logically would be:
> >>
> >> HRES2 HRES1 HRES0  Width in bytes
> >>   1     1     1         160
> >>   1     1     0         128
> >>   1     0     1          80
> >>   1     0     0          64
> >>   0     1     1          40
> >>   0     1     0          32
> >>   0     0     1          20
> >>   0     0     0          16
> >>
> > 
> > This is true for BP = '1', HVEN = '0' , and COCO ='0' bits. That is
> > the Coco3 is in graphics mode and that the Horizontal Virtual screen
> > is not set and we are not in the COCO compatible mode. 
> > 
> > 
> >> I've tested the new entries and not all work for all color
> >> resolutions. For example 160 bytes of 2 colors requires a screen
> >> 1280 pixels wide which could be beyond the capabilities of the
> >> Coco3.
> >>
> > 
> > Correct there are two modes that exceed the pixel per line maximum
> > of 640 pixels. In addition to what you mentioned there is 128 bytes
> > per row and 2 colors will yield 1024 pixels. In either of the two
> > cases 
> > 
> > It is hard to say with 100% certainty as to what will be displyed in
> > there two modes.
> > 
> > 
> >> Here is a program in Basic that demonstrates something weird with
> >> the "new" 20byte width screen. I'd love to hear comments about what
> >> might be happening with the hardware that could cause what I, and
> >> hopefully you, see.
> >>
> > 
> > Simple. The Coco3 video section reads video memory in so many bytes
> > per row based on the settings of the HRES bits. Graphics mode
> > differs from character mode with the setting of the HRES bits. In
> > text mode HRES1 is ignored and essentially CRES0 bit along with
> > HRES2 and HRES0 determine the number of bytes per row that a screen
> > will show. This again is also dependant on the setting of the COCO
> > bit and the HVEN bit. In both graphics and text mode the HVEN will
> > override any HRES settings to 256 bytes per row. 
> > 
> > Setting the HVEN in text mode is useless and also causes funny
> > things to happen as RSBASIC may be writing video data at a different
> > bytes per row setting. The GIME chip has a lot of little things that
> > needed clean up with a third pass that never was done. Some video
> > resolution modes should have not been allowed in either graphics or
> > text mode. 
> > 
> > james
> > 
> 
> So, ignoring the comments that don't apply to the program in question,
> you are saying there are bugs in the GIME design?
> 

Yes and No. For the most part the GIME chip does what it is supposed to 
do. What seems to be an issue is the designers allowed the chip to be put 
into modes that have not real use or definition. Not exactly a good thing to 
do. 

> Do you think that in Coco3 graphics mode an HRES=000 is 20 bytes wide
> or just too buggy to be anything?
> 

I can see where a 20byte wide window could be used. From all that I have 
read, the HRES bits determine the bytes per row and thus the displayable 
window. 

SOme of the issues you bring up are some things I have encountered in my 
GIME chip FPGA design. That is why I jumped into this. A 20 byte per row 
window in the current context of the COCO3 is meaningless. Yet in a 
windowing system much like a modern PC, a 20 byte per row window 
makes a nice popup widow for some data. It seems to be that this chip has 
some hooks built in that a future chip would have built on for more 
functions. I am only guessing but it seems logical. 

I also believe the RSBASIC may not fully take advantage of the capabilities 
of the chip. So in that aspect they are not bugs. It is just that DECB can not 
take full advantages of the chip.  

By the way my work so far has progressed better than I had thought. One 
of the more difficult items I have ran across is decoding and making sense 
of the HRES bits. I am now convinced that I can do a base desktop of 
800x600 with a single color background. On that desktop will be a window 
that its size is controlled by the HRES bits. Yes I plan to actually have a 
window the size of 20 bytes wide. That would be 20 characters with no 
attributes in text mode and 10 characters wide with attributes. That part is 
nearly coded. 

I better understand how the GIME chip aceesses memory now. I have 
come to the realization that it is bytes per row and not pixels per row that 
drives the video address generator to do the video reads. This changes 
how I will code the SRAM interface and when I read. The only problem may 
come when the window is put into 640 pixel wide 256 color mode. That 
ends up being 640 bytes per row. In that mode one will almost surely need 
a 2Meg system. 

james