[Coco] a not very important drivewire question

[Bill Pierce]

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