[Coco] a not very important drivewire question

[Aaron Wolfe]

On Jul 17, 2014 3:05 PM, "William Astle" <lost at l-w.ca> wrote:
>
> On 14-07-17 11:36 AM, Aaron Wolfe wrote:
>>
>> The flush command is a low level DW op code, as is the "here's some data
to
>> print".  I'm not sure how HDBDOS would know when to send the flush op, do
>> programs actually open and close #-2?  I seem to recall its just always
>> there.  In os9 I think flush is sent when the handle to /p closes, not
sure
>> if there is a good equivalent in basic.
>
>
> #-2 is always there so there's no close to do on it. HDBDOS would have to
do something like the following:
>
> 1. Flush when there has been some defined length of time with no data to
send to the printer. This is probably the best overall solution.
>
> 2. Flush when it encounters FF or some other character.
>
> 3. Flush after X characters have been sent.
>
> 4. Some combination of the above.
>
>
> 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.