[Coco] Super IDE vs. Drive Pak

[Arthur Flexser]

I am probably the most knowledgeable authority on this, having sold
Extended ADOS-3, which requires a 16K EPROM, for some years.

The mere fact of its requiring a 16K EPROM caused essentially no problems.
After all, it was for a CoCo 3, which runs in the all-RAM mode practically
all the time, reserving the space above Disk Basic for Super Extended
Basic.  Only time it caused a problem was with one graphics program
(Colormax??) that did something weird with MMU switching, and the
incompatibility was easily fixable with a poke or 2.  (It wouldn't even run
under standard Disk Basic unless the 16K EPROM contained Disk Basic in both
8K banks, as I recall.  Drove me crazy looking for an incompatibility with
Ext. ADOS-3 specifically, before I discovered that the problem was just the
size of the EPROM in the controller.)

As far as the RS controllers, the FD-502 requires a trivial mod to accept a
16K EPROM, and the others can be fitted with an adapter.  (Sold a lot of
those adapters!)
Art

On Wed, Nov 16, 2011 at 6:50 PM, gene heskett <gheskett at wdtv.com> wrote:

> On Wednesday, November 16, 2011 06:37:52 PM Boisy G. Pitre did opine:
>
> > Ok.  As Frank says, I probably spew out a chuckle when he asks... gotta
> > love his persistence!
> >
> > So, as has been mentioned, adding extra functionality to HDB-DOS would
> > push it out of its comfy little 8K spot into a 16K footprint.
> >
> > Here's why this is bad, in my opinion:
> >
> > 1. Legacy disk controllers like the FD-500, FD-501 and FD-502 which only
> > can accommodate 8K ROMs. 2. Moving to a 16K EPROM breaks some legacy
> > M/L programs (don't remember which ones, but this was a big reason back
> > in the day for RGB-DOS (now HDB-DOS) to stay small)
> >
> > One can argue if these are really "good" reasons, seeing that everyone
> > is pretty much interested in running new software on new devices
> > now-a-days, but then there are other considerations:
> >
> > 1. Adding this functionality would require syntax changes that I haven't
> > fully explored the ramifications of.  Preserving existing syntax might
> > be a challenge, might not... 2. It would require a lot of time for both
> > development and testing.  Time is something I don't have much of
> > anymore...
> >
> > So, let me segue into another point of discussion: if I were to release
> > the source code to HDB-DOS, would anyone be willing to take it and
> > expand upon it?
> >
> > Frankly, I'm thinking of doing just that.  As far as I know, we don't
> > have a true community open source Disk BASIC DOS.  HDB-DOS has been
> > around for a long time and the source is well commented.  It has room
> > to grow, as others have mentioned...
> >
> > If more than one person can put forth a good argument for me to do it,
> > and, more importantly, promise to work on it, I may do just that...
> >
> > Best Regards,
> > Boisy G. Pitre
>
> Boisy, I think that would be a jolly great idea, but I won't promise to
> work on it as I know very little about the disk basic internals, going
> straight to os9 from power up for the last 25 years.
>
> Cheers, Gene
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> My web page: <http://coyoteden.dyndns-free.com:85/gene>
> If you're not careful, you're going to catch something.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>