[Coco] a not very important Drivewire question

[Kip Koon]

Up to this point I was under the impression that the Coco 3 SECB was
executed first before any version of Disk BASIC and then it puts the SB
portion of the roms out of the way when Disk Basic was executed.  Is this
not the case?  If not, then I can see why HDB-DOS is only 8KB.  Still
though, I wonder how much can be done by just cleaning up SECB such as
merging all the additions and corrections provided by SB into their proper
places in ECB, combining all the initialization routines into one place,
removing the picture, etc. and see how much space we can gain.  
On a number of occasions I have examined SECB which seems to be very
convoluted assembler code and I just get confused every time I try to make
sense of it.  Any pointers in the right direction would be helpful.  I think
it is way past time to improve the roms in my humble opinion.  If Tandy had
come out with the Coco 4 as they had planned, what changes would they have
made to the rom code including but not limited to moving routines around yet
again.  Each new version of Color Basic and Extended Basic that Tandy put
out has routines in different places if I remember correctly.  Those that
want to keep the roms as they are is just fine with me.  I for one just want
to improve our Cocos as much as we can and see the DECB folks be able to do
more with their Cocos.
Anyone whose is interested in this project, I'd like to talk to you further
about this.  Please don't flame me about this. I very serious about making
some major changes, but I need help to do this.  Let's work together and see
what we CAN do with our little DECB Interpreter.  I understand some of my
suggestions would require some major upgrades to the code and maybe that
might come in time.  Let's do the little improvements to the SECB code first
and see how it turns out.  If people just keep saying we can't do this or
that because of something else, then nothing further will EVER get ANY
better and the DECB Interpreter as it is which for me is unacceptable.  I
want it even better.  Let's be positive about all this.  If you've read this
far, then you might want to consider further what I'm proposing.  Think
about it and let me know in detail if possible what needs to be done.  Thank
you for your time.

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 William Astle
Sent: Thursday, July 17, 2014 9:38 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] a not very important drivewire question

I'm going to take Kip's points one by one for a detailed response.

EOF character to terminate printing:

Using an "EOF" character is generally not a good idea, especially since
nothing on the CoCo has the notion of an EOF character in the first place.
That would be introducing new semantics what nothing would be expecting.
Further, no existing software would know about it which would be
problematic. Better would be a button in the Drivewire GUI or a simple
timeout that dumps the buffer. That has the highest compatibility with
everything else and is probably the easiest to implement.


16K HDB-DOS ROM:

This is *technically* possible. It runs into an extreme hurdle with the
Coco3, however, because there is only 8K between the Color Basic ROM area
and the Coco3 enhancements. While it is trivial to use the additional 8K on
a Coco1/2 system, it is not on a Coco3. It would require having different
ROMs for the Coco1/2 and Coco3 because the workarounds to make it work on a
Coco3 are not compatible with a Coco1/2 system.

All that said, I agree it would be nice if it did work. It would allow
having multiple hardware drivers at once, among other things.


DECB and extra memory on the Coco3:

This is just not practical. The entire ROM is written with the 
assumption of 16 bit pointers. It is just not possible to rework it to 
work with a larger memory map than it already uses without completely 
rewriting a nontrivial amount of it.

Paging schemes could work for some extensions. However, this, too, could 
require some very significant rewrites to a massive amount of code in 
the existing ROMs. If you don't care about binary compatibility of the 
resulting ROM, then it is at least theoretically possible to have DECB 
use the memory on the Coco3 more effectively, for buffers and the like 
at the very least. It might also be possible to relocate the variable 
table or split string space, the variable table, program space, and the 
call stack into different memory chunks, removing the need for CLEARxxx 
to get enough string space. But this starts getting complicated fast.


Combining ROMs:

Combining the ROMs (Color Basic, Extended Basic, HDB-DOS, and Super 
Extended Basic) into a single 32K ROM is definitely possible. Leaving 
off the SECB part for a Coco1/2 system makes it fairly trivial. Doing it 
for the Coco3 requires redoing a fair chunk of the system initialization 
code because the ROM space used by it is in the C000...DFFF range 
(including the fancy picture, which would have to be eliminated). 
Fortunately, there is wasted space at the top of the SECB ROM area that 
can be co-opted for this initialization code. I have actually 
successfully done this with a replacement ROM using Mess.

Removing redundant routines is certainly possible when doing this. 
However, you have to be *very* careful what you do here. Far too many 
things people use have detailed knowledge of various ROM routine 
locations. Changing any of that will break a great many things. There 
are some largish areas that could be regained, but whether they are 
large enough to be truly useful depends on the specific enhancements.

If you were happy to throw away binary compatibility altogether (which 
you would have to with your paging idea), there is a fair bit more space 
that can be freed by virtue of having unified routines. Additionally, 
there is a very significant amount of space that can be saved in the 
SECB ROM area by simply doing basic optimization on the code. Without 
trying, I think I was able to compact a few hundred bytes out of it. 
When you eliminate the extra contortions with RAM hooks, you save a fair 
chunk more.

The upside of doing it this way is that there is a large amount of space 
that can be reclaimed and it should be plenty to implement multiple 
device drivers for disks and so on.

The biggest issue with replacing the internal ROM on the Coco3 is that 
it is not socketed.

On 14-07-17 06: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