Printer Spooler Software -- "Antic Spooler"

[reifsnyderb]

Hello,

 

I was looking carefully at this "Antic Spooler" and it's source code.  My belief is that the advantage is that you can continue working on your document.  However, I doubt it's a great idea to try saving a document to disk while the printer is printing via the spooler.  Does anyone know if this is the case or if you could load and/or save while still printing?

 

https://www.atarimagazines.com/v7n1/anticspooler.html

 

Thanks!

 

Brian

 

Edited October 3, 2023 by reifsnyderb

[_The Doctor__]

You won't want anything that utilizes dup.sys etc. but it looks like you can load/save while it runs it does it's thing. I am sure people could do a better job today, and we have physical print spoolers (external devices) and hybrid spoolers like the BlackBox utilized and later offered external memory as well. MIO spooler was PBI external.

Did the ANTIC spooler work? YES. Could it be improved? More than likely. Still pretty nifty though. Printing while working on a paper was still nice. Sometimes it would be late to show what you typed though.

[reifsnyderb]

3 hours ago, _The Doctor__ said:

You won't want anything that utilizes dup.sys etc. but it looks like you can load/save while it runs it does it's thing. I am sure people could do a better job today, and we have physical print spoolers (external devices) and hybrid spoolers like the BlackBox utilized and later offered external memory as well. MIO spooler was PBI external.

Did the ANTIC spooler work? YES. Could it be improved? More than likely. Still pretty nifty though. Printing while working on a paper was still nice. Sometimes it would be late to show what you typed though.

Sounds promising.  A printer spooler would have been awesome when the 800XL was the primary computer.  I am thinking that it may be possible to load DOS if the spooler memory was elsewhere.  (i.e.  banked in)  If the spooler, itself, was running off of a PBI ROM maybe it would work.  Since the spooler would send to the printer during VBLANK, it might be fine as SIO access sets CRITIC...which would prevent a differed VBLANK interrupt from running.  At least that's how I understand it now.

[phaeron]

One issue is that this makes the SIO working variables volatile -- the spooler saves and loads the DCB but not SIO internal variables. I've seen programs reuse such OS variables when not using the facilities in question. The Atari OS Manual even recommends this general approach for CIO handlers in Section 9, Zero-Page RAM, where it gives an example of temporarily reusing Display Handler variables.

 

[reifsnyderb]

36 minutes ago, phaeron said:

One issue is that this makes the SIO working variables volatile -- the spooler saves and loads the DCB but not SIO internal variables. I've seen programs reuse such OS variables when not using the facilities in question. The Atari OS Manual even recommends this general approach for CIO handlers in Section 9, Zero-Page RAM, where it gives an example of temporarily reusing Display Handler variables.

 

What about this possibility:

 

On VBLANK, a deferred print spooler VBLANK routine....

 

1.  Only sends to the printer when the printer buffer is empty.  (PBPNT=0)

2.  Saves the DCB

3.  Saves the other SIO working variables (they shouldn't have moved for XL/XE OS's???)

4.  Loads the printer buffer

5.  Sets up a DCB

6.  Calls the SIO directly at $E971 to send the printer buffer to the printer

7.  Restores the SIO working variables

8.  Restores the DCB

9.  Exits

 

 

The reason for calling SIO directly is to simplify things by avoiding PIO.  This is because PIO is already intercepting CIO printing to SIO and saving the data in a spooler buffer that is in banked RAM.

 

Thoughts?

 

 

 

 

Edited October 4, 2023 by reifsnyderb

[reifsnyderb]

Ok.  I haven't been experimenting with the Antic Spooler but have been experimenting.  At this stage, I am thinking that the only way to properly do an SIO print spooler during VBLANK is to write custom SIO printer code.  After a lot of experimenting, I've built an SIO spooler that works.....as long as I don't actually try to do anything else.  So, that sort of defeats the purpose.  I've intercepted the printing via PIO, spooled the data in PORTB banks, and can print it out during VBLANK.  The current code will handle more than one 16k bank, as well.  If I try to type anything, while printing, the system can hang for at least 30 seconds.  It sucks.  My current thought is that the deferred VBLANK code, when tied to SIO, just hogs up too much time.

 

i.e.

 

[phaeron]

It is of course possible to write a fully asynchronous and event-based SIO routine, but sadly the OS isn't set up for it. The main issue you'd run into would be programs overwriting the audio registers, sometimes from unexpected source. For instance, the END statement in BASIC or the implicit END at the end of the BASIC program triggers an audio register clear.

 

There is potentially another way, which is just issuing the print command without waiting for the complete response and then waiting for the printer to respond to a status command. It relies on (a) the printer controller not being able to respond to SIO commands while printing and (b) not having an interrupt to abort its current operation if SIO command is asserted. It'd be a dirty hack, but we're already talking about trying to shoehorn in a print spooler into the VBI.

[reifsnyderb]

1 hour ago, phaeron said:

It is of course possible to write a fully asynchronous and event-based SIO routine, but sadly the OS isn't set up for it.

The OS source code shows a line that states ".define    ACMI    FALSE    ;no asynchronous communications mod".  I wonder if this may be what they are referring to or if it's something else.

 

Either way, a lot of potential was wasted.   😞

 

1 hour ago, phaeron said:

There is potentially another way, which is just issuing the print command without waiting for the complete response and then waiting for the printer to respond to a status command. It relies on (a) the printer controller not being able to respond to SIO commands while printing and (b) not having an interrupt to abort its current operation if SIO command is asserted. It'd be a dirty hack, but we're already talking about trying to shoehorn in a print spooler into the VBI.

I was thinking something along this line.  Atari at one point implemented a high speed SIO routine for a disk drive they never released.  That code didn't rely on interrupts and may be something to explore and use as you are suggesting.  But it would be quite the hack and I am wondering about how high the probability of success would be.

 

I also tried having the spooler code run every 5th VBI.  That didn't help, either.

 

At this point, I think I am going to shelve the printer spooler code and get the rest of the project working.  It is rather disappointing, though, as I really wanted to get such a spooler working as I've got plenty of memory on a 1090 card to play with.

 

 

 

 

Edited October 6, 2023 by reifsnyderb