[Coco] a not very important drivewire question

[Bob Devries]

Hi Bill,

I think (correct me if I'm wrong, Mr Astle) that the FF being referred 
to is FormFeed, not CHR$(255).

Regards, Bob Devries
Dalby, QLD, Australia

On 18/07/2014 8:29 AM, Bill Pierce via Coco wrote:
> 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.
>