[Coco] (Probably stupid and newbie-ish) CoCo hardware question

[William Astle]

On 12-06-27 10:16 PM, Arthur Flexser wrote:
> Legality may have been the motivating factor, but I doubt they'd have
> achieved nearly as good compatibility with prior software had they
> used another scheme.  All you need to do is switch the ROMs in and
> Super Extended Basic vanishes and you have a configuration that is
> extremely close to what the software expects from a CoCo 1/2.
>
> 90+ percent of the incompatibilities that do exist are probably due to
> putting a bunch of new secondary vectors just below $FF00, a
> completely independent design decision.  And, come to think of it,
> probably a dubious one.  Can anybody tell me why these secondary
> vectors were actually needed?   They certainly messed up compatibility
> with a lot of software that rewrote bytes at the top of memory in
> order to test memory size.

These secondary vectors were necessary to allow interrupts to still be 
used when the MMU was in play. Otherwise, one would always have to have 
valid vectors at $100 which would be annoying as it would clobber a 
whole 8K page. These vectors combined with the ability to have FExx 
constant no matter what the MMU said allows the interrupts to be 
vectored through there and allow the rest of the 64K (63.5K) to be 
swapped around at will. Pretty much everything designed for the CoCo3 
that doesn't rely on DECB but uses interrupts uses the "secondary" 
vectors, not the ones at $100. This particular design strikes me as a 
compromise between allowing the MMU to be fully useful and causing some 
incompatibility with software that actually used RAM at FExx. It might 
have been nice to be able to turn that FExx vector table on and off 
instead of always using it but that would have required a dynamic switch 
of stuff at FFFx which is harder than it sounds.

Another possibility would have been to have the actual MPU vectors at 
$FFFx writable but that would have been more complex I think, and the 
RESET vector at $FFFE has to come from ROM anyway so that the machine 
can have an execution address to use at boot time before anything has 
had a chance to set the vector.

> Incidentally, the original Microsoft ROM code actually was changed in
> some minor ways, such as in redefining what DLOAD did, which if I'm
> remembering correctly was not done by patching.  (DLOAD does the same
> thing on a CoCo 3 as pressing reset.)

That's just an unfortunate consequence of the fact that a few patches to 
the ROM had to work even in ROM mode so that compatibility with most ROM 
paks could be maintained. There wasn't enough room anywhere else in the 
ROM to clobber so they selected DLOAD as the least useful command and 
clobbered it. Some of the code is the RESET code and some serves other 
purposes. I give them credit for having DLOAD do something harmless 
rather than crashing the system, though.

>
> Art
>
> On Wed, Jun 27, 2012 at 8:39 PM, Boisy G. Pitre<boisy at tee-boy.com>  wrote:
>> Take it from an ex-Microware engineer and employee who questioned the source directly.
>>
>> Mark Hawkins and I had a conversation about the CoCo 3 project years ago.  He told me then, personally and specifically, that ROM to RAM and subsequent patching was the approach that they (Microware) took in '86 to avoid any legal entanglements with Microsoft.  I don't know if Tandy advised them to do it, or if Microware made the suggestion, but legality was the motivating factor for the approach that was taken.
>>
>> What we need is a book that brings all of this information in... something I've been working off and on for a long time....
>>
>> Best Regards,
>> Boisy G. Pitre
>>
>> Join our forums at http://www.tee-boy.com/forums/ to exchange ideas and information with other WeatherSnoop enthusiasts.
>>
>>
>>
>>
>> On Jun 27, 2012, at 7:24 PM, Frank Swygert wrote:
>>
>>> I'm going out on a limb here... I know it for a fact. I just can't remember the exact source. I'm sure it was one of the Microware guys who modified the system ultimately, but I got the info second hand from an article in some magazine or other... I think. Could have been an on-line article, but I think it was actually in a Rainbow article sometime after the CC3 was released... maybe an interview with one or more of the Microware guys involved? I can't recall exactly where I got the info, which is why I say I'm going out on a limb by saying it's a fact. If Tandy had the rights to mod the MS code, they'd have done it rather than use a patch system though. Would have been cheaper to do it that way, I'd think. I believe the CC3 had two ROM chips, ECB and SECB, or were they both burned in different banks of the same chip? I don't remember...
>>>
>>> -------------
>>> Date: Tue, 26 Jun 2012 14:42:08 -0400
>>> From: Arthur Flexser<flexser at fiu.edu>
>>>
>>> Frank, that's the first time I've heard that explanation for why the
>>> CoCo 3 runs in all-RAM mode.  (That Tandy had rights to use, but not
>>> modify, the Microsoft ROMs.)  It seems very plausible to me.  Do you
>>> know this for a fact, or is it just a reasonable conjecture?
>>>
>>> --
>>> Frank Swygert
>>> Editor - American Motors Cars Magazine
>>> www.amc-mag.com
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>