[Coco] Important Announcement: NitrOS-9 & 1986 GIME

[John R. Hogerhuis]

IIRC, there was a never a factory recall of Coco 3's of any year.

My guess is that the recent revelations regarding switching to a
different 512K memory upgrade fixing the problem are key. With certain
RAM boards it may very well be that the system is on the hairy edge of
working properly or not working. There may be a hardware fix external to
the GIME. 

The problem is being discussed as though we know the GIME is at fault,
when it may in fact be a combination of factors only one of which may be
marginal behavior of the GIME. What about an 86 GIME with Radio Shack
memory upgrade, for example? Or 86 GIME with memory upgrade removed
altogether?

I think an electrical engineer needs to get out an oscilloscope and take
a look at the bus before jumping to the conclusion (unwarranted in my
opinion) that the initial coco 3's are all "bad" when I personally don't
recall an uproar at the time OS-9 Level II was in wide usage that there
were a whole class of fatally flawed coco's around.


-- John.

On Tue, 2004-10-05 at 16:13, Robert Gault wrote: 
> Roger Taylor wrote:
> 
> ><snip>
> > Yes.  :)
> > 
> > The 1986 GIME chip is not really buggy if the software doesn't know how 
> > to adapt to what it requires.
> > 
> > The fact that the new NitrOS-9 can't run on such a CoCo 3 is not a 
> > hardware flaw, but something that should be fixed totally from 
> > software.  A test can be performed during boot that would let the system 
> > know which GIME chip is installed, and then correct whatever software 
> > flaw is causing this problem.
> > 
> > Has anyone tried consulting with Sockmaster?  He's a genious with the 
> > GIME chips and the differences between the 1986 and 1987 versions.
> > 
> > -- 
> > Roger Taylor
> > 
> > 
> 
> I don't know if Sockmaster has followed this discussion but I don't 
> think anyone has tried to contact him on the subject.
> 
> There are several problems with your point of view. The first is that 
> having tried many different changes to the NitrOS-9 code under the 
> assumption there the '86 GIME works as described in the service manual, 
> nothing tried makes any difference. That does not mean nothing will 
> work, but I feel this is a dead end based on my tests.
> 
> Two, there is no doubt that the '86 GIME does not conform to the 
> information in the service manual and that this is the reason for the 
> '87 update. Even the simplest of GIME operations can cause screen 
> flashes, the scroll registers don't always work as stated, and there is 
> probably more wrong. Since Tandy has not released a corrected set of 
> specs for the '86 GIME and it does not conform to the service manual, 
> the chip must be considered buggy.
> 
> Three, NitrOS-9 does indeed run on a Coco with the '86 GIME. It just 
> does not boot reliably when the boot screen is 40-80 columns. You might 
> say that means it doesn't run but consider what actually happens. 100% 
> reliable boots from a 32 col. window with no other changes to the code 
> except a value stored at $FF99. The exact same code has about a 10-20% 
> chance in a 40-80 col. window. That does not conform to the Coco3 specs.
> 
> I don't completely agree with Mark. If the only change needed for 
> NitrOS-9 is booting from a 32 col. window for any Coco3 system to work, 
> that is the way to go. This in no way is an inconvenience to NitrOS-9 
> operation because there is no restriction on the width of the initial 
> screen after the boot finishes. There is no need for a test to determine 
> which version of the GIME is present. I do agree with Mark that if '87 
> GIME chips are available, users should purchase them because the Coco3 
> will then perform to specs. However, realistically we should not assume 
> that any more GIME chips are available. Any user can choose to boot from 
> 40-80 col. screens but the distribution package should use 32 columns.
> 
> There is a completely different issue regards GIME chips and the special 
> graphics programs that you and Sockmaster write. Here the different 
> video timings must be taken into account for the graphics programs to 
> give best results. That is not a bug, where the Coco has a complete 
> crash, but optimization.
>