[Coco] a not very important drivewire question

Fri Jul 18 16:16:55 EDT 2014

In the CoCo 3, you only have 1012 bytes available in the E000-FEFF range
(versus 7936 in the CoCo 1-2). The rest is taken by the patches to the
other three BASICes. But then again, many of the improvements to the 1 and
2 are kinda pointless in the CoCo 3, so one could focus on what's relevant.

Other than that, one should find a way to copy those 1012 bytes from the
second 8K of the cartridge ROM to RAM upon boot. (SECB copies the
in-computer ROM instead, the one that has the patches.)

Maybe even find a way to use stuff from the "unusable" parts of the ROM by
creative use of bank switching. Are the MMU registers readable, or only
writable?

So many things to do, so little time^H^H^H^H stamina. :(

Juan

On Thu, Jul 17, 2014 at 9:06 PM, <computerdoc at sc.rr.com> wrote:

> Hi Guys!
> How about using the "End of File" character in the ASCII code which is
> <ctrl-z>, $1A, or 26 decimal to signal the end of all print outs from
> HDB-DOS ECB, OS-9, NitrOS-9 or anything else for that matter being sent
> from the Cocos to Drivewire to be printed.  It seems like this character
> has already been defined for us ever since the ASCII Code was created.  We
> just need to implement it, then Drivewire can be given the capability to
> send all text printouts from the Cocos straight to the PC's default printer
> instead of a text file.
> Printing Graphics of course is a horse of another color.  May some type of
> "End of File" sequence of characters has already been created in one or
> more of the graphic file formats that we can use for this purpose -
> something that would never be used in the graphic format itself for picture
> information.
> I also feel it really is time to consider a 16KB HDB-DOS.  We who have
> used the 8KB HDB-DOS have enjoyed many new features and additions it has
> provided to DECB.  I also have enjoyed using Juan Castro's 16KB HDBDOS for
> the Coco 1 & 2 installed in my Eprom PCB for a short while now.  Since all
> the Cocos have 16KB available to use for all versions of Disk Basic
> including HDB-DOS, then let's use some or all of the 16KB for more cool
> features.
> How about giving HDB-DOS some type for mechanism for initializing multiple
> virtual and real Hard Disk drivers for several different types of Hard Disk
> Controllers all functioning simultaneously.  The presence of both virtual
> and real Hard Disks, Compact Flash and SanDisk Memory cards can be included
> in the default initialization startup code for HDB-DOS ECB.  Of course some
> standard use guidelines that the initialization code expects to see may
> have to be officially agreed upon.
> I'm sure other people here have come up with other cool ideas to bring our
> Cocos further into the 21st century as well that could also be included.
>  It seems to me that there are other people who would like to see more
> features put into HDB-DOS and maybe current features can have the
> improvements people keep taking about.
> How about giving HDB-DOS ECB the capability to load object code overlays
> into paged ram extending BASIC further into directions that were originally
> impossible due to the 64KB memory addressing limit of the 6809/6309.  Since
> paged memory is implemented in the Coco 3, let's give BASIC the capability
> to load object modules into an area of paged memory giving the illusion
> that the 6809 microprocessor and therefore HDB-DOS ECB both have more ram
> then they were originally designed to use.  Bill Pierce has been doing an
> excellent job using paged ram with his Mshell program for NitrOS-9.  Let's
> bring the paged memory concept to the attention of HDB-DOS ECB as well.
> It's high time that many of the traditional limitations of DECB and
> HDB-DOS be at least soften a bit or even eliminated altogether if possible.
> Another feature could be the automatic detection of any extra ram the Coco
> 3 has available and initialize HDB-DOS ECB to automatically use it.  Maybe
> even give the capability for the user to set or change how much memory
> HDB-DOS ECB is allowed to use freeing up the rest of the ram for the user's
> purposes.
> Heck, since Coco 3s (and some Coco 2s for that matter) have only one
> rom/eprom for ECB anyway, we could upgrade ECB itself and remove all
> unnecessary routines since both Extended Basic and Color Basic live
> together in one chip anyway.  This would free up a little more precious
> eprom space for enhancements to correct anything that still needs attention.
> We have many 6x09 assembly language coders in the Color Computer Community
> with extremely high capabilities and understanding of both DECB and
> HDB-DOS.  I'm sure a coordinated effort can be made in these directions.
>  Let's officially create an upgrade to HDB-DOS that we all can use and be
> proud of so we don't end up with a zillion potentially incompatible HDB-DOS
> images/eproms floating around.  We need a 21st century Color Computer!  I'd
> like to see this put into place for all of us.  Any thoughts or other ideas
> in these and other directions?
>
> Kip Koon
> computerdoc at sc.rr.com
> http://www.cocopedia.com/wiki/index.php/Kip_Koon
> http://computerpcdoc.com/
>
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Bill Pierce
> via Coco
> Sent: Thursday, July 17, 2014 6:29 PM
> To: coco at maltedmedia.com
> Subject: Re: [Coco] a not very important drivewire question
>
>
> The "close character" method would probably be the best, then the flush
> code could be sent when say a CHR$(255) is seen. This would make graphics
> dumps impossible, but, can dw4 even handle graphics dumps with it's print
> feature?
> The user would just end each printing job with a CHR$(255) (or whatever).
>
>
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> -----Original Message-----
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Thu, Jul 17, 2014 6:06 pm
> Subject: Re: [Coco] a not very important drivewire question
>
> > Overall, it's fairly trivial to hook the #-2 handler and redirect it
> through a routine supplied by drivewire. The flush handling bit is the
> most complex part. It would be fairly easy to trigger the flush based on
> character count or a specific character being sent. A time triggered flush
> would require an IRQ handler of some sort, but also not horribly difficult.
> The real problem is whether there is room in the ROM to actually do it.
>
> I wonder if this sort of thing could be patched in ram?  And if so, would
> it make sense to have optional features such as #-2 printer support kept as
> patches rather than trying to squeeze too much into the 8k rom? It seems
> like the size limit is a constant challenge.
>
> For flushing, there is also the option to have the user push a button or
> something in the GUI rather than trying to implement on the coco side.  I
> could make the buffer more accessible too.  Or the server could assume that
> X seconds without new print data means flush anything in the buffer, that
> kind of thing.  I prefer to always implement things on the coco side but
> when ROM space is precious maybe its better on the server end.
>
> --
> 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
>